MCP详解

包包555
0 阅读7分钟

基本概念

1.什么是MCP

MCP全称是Model Context Protocol，即 模型 上下文协议，2024 年 11 月由 Anthropic（一家美国人工智能公司）提出。它是一种开放协议，标准化了应用程序如何向大模型提供上下文，其中最常用的上下文信息就是用于拓展大模型能力的外部工具信息，所以MCP也可以说是标准化了为大模型提供外部工具的方案，让大模型能更好地调用各种外部工具，是扩展大模型能力和开发智能体的重要技术
MCP目前最常见的作用是解决了工具复用的问题。之前的 AI 应用提供的工具，一般都是本地代码实现的，比如cherry studio内部的工具、我们通过SpringBoot集成langchain4j编写的工具函数等，这些工具难以复用，把代码拷贝到别的地方因为语言、环境等原因一般无法运行。而在MCP中，一般是把工具发布为python或node程序，这样任何有python或node环境的主机都可以拉取到工具并调用

2.MCP架构原理

MCP遵循客户端-服务器架构。其中几个重要概念如下：

  • MCP主机(MCP Hosts)：发起请求的AI应用程序，比如聊天机器人、AI驱动的IDE等

  • MCP客户端(MCP Clients)：在主机程序内部，与MCP服务器保持1：1的连接

  • MCP服务器(MCP Servers)：为MCP客户端提供上下文、工具和提示信息，并且在需要时会完成工具调用并返回结果

    注意：有别于传统的服务器概念，MCP服务器本质上只是一个遵循MCP协议的程序，大部分情况下它都是通过python或node在本地启动的，可以联网也可以不联网只进行一些本地操作

  • 本地资源(Local Resources)：本地计算机中可供MCP服务器安全访问的资源，如文件、数据库

  • 远程资源(Remote Resources)：MCP服务器可以连接到的远程资源，如通过API提供的数据

在这里插入图片描述

MCP协议就是用于MCP客户端和服务器之间的通信协议。它支持以下传输方式：

  • STDIO：表示标准输入/输出。每个进程都会有一个标准输入\输出通道，可以发送数据给其他进程或者接收其他进程的数据，所以它是一种进程间通信的方式。这种方式要求MCP客户端和服务器必须在同一台物理主机上

  • SSE(2024.10旧方案)：客户端通过HTTP POST向服务端发请求，服务端通过SSE通道返回响应结果。这种方式可以让MCP客户端和服务端不在一台主机上

    说明：为什么采用SSE而非普通HTTP？因为MCP Server中的工具可能发生更新，此时就需要服务端主动推送消息给客户端

  • Streamable HTTP（2025.03新方案）：SSE传输方案的升级版，目前正在逐步取代SSE。Streamable HTTP并不是一个标准协议名，而是一个通用描述，指的是基于HTTP协议的“可流式传输”技术。它的核心思想是：在一个 HTTP 连接里，服务端可以持续不断地发送数据给客户端，客户端边接收边处理，类似“流”一样。与传统 HTTP 请求响应“一次性完成”不同，Streamable HTTP 保持连接不关闭，数据分片持续传输。常见实现方式包括：

    • HTTP/1.1 长连接 + 分块传输编码（Chunked Transfer Encoding）

    • HTTP/2 流式数据

    • HTTP/3 QUIC 流式传输

    说明：为什么SSE要升级成Streamable HTTP？这是因为SSE有以下几个缺点

    • 数据格式限制问题：SSE 的 Content-Type: text/event-stream 只支持文本格式；Streamable HTTP 的Content-Type支持任意格式，如 JSON、HTML、二进制等，更适合 AI 场景（可能要传 JSON + 音频 + 图片）
    • 跨平台兼容问题：SSE 支持的客户端主要是浏览器端和少量语言库；而 Streamable HTTP 支持多种客户端
    • 性能问题：SSE 是基于 HTTP/1.1 长连接，Streamable HTTP 可以基于 HTTP/2/3 ，支持多路复用和双向流。且 HTTP/2/3 的流控制和优先级机制使得高吞吐和低延迟成为可能；SSE 消息只能文本格式，Streamable HTTP 支持其他采用更紧凑的编码方式（比如二进制分包、压缩等）

说明：很多MCP工具会采用STDIO方式。虽然STDIO只能用于本地进程间通信，但是很多情况下MCP服务器和客户端是在一台物理主机上的，比如要实现本地文件操作、本地数据库操作，所以STDIO只能用于本地进程间通信的劣势显得不重要了，反而它简单高效的优势被发挥了出来

无论是采用哪种传输方式，MCP通信过程中具体的消息格式都采用JSON-RPC2.0，它是一种为RPC量身定制的 json 格式。几种常见的消息类型如下：

  • tools/list：MCP服务器启动时，MCP客户端会向服务器发送这个请求，服务器返回工具列表
  • tools/call：当AI应用需要调用工具时，MCP客户端向服务器发送这个请求，服务器执行目标工具并返回结果
  • notifications/tools/list_changed：当MCP服务器中的工具更新时，会用这个消息主动通知客户端

以tools/list为例，具体消息示例如下

在这里插入图片描述

在这里插入图片描述

一个具体的MCP客户端与服务器沟通的完整流程如下
在这里插入图片描述

3.MCP与Function Calling

虽然MCP和Function Calling都是为了让大模型可以调用外部工具，但是它们之间还是有本质上的区别的：

  • Function Calling是作用于AI应用程序与大模型之间的关于获取工具列表、调用工具的沟通规范，是大模型的能力，需要大模型自身支持

    在这里插入图片描述

  • MCP是作用于AI应用程序内部的MCP客户端，与外部MCP服务端之间的关于获取工具列表、调用工具的沟通规范，MCP协议不涉及大模型本身，所以任何大模型都能支持

    在这里插入图片描述

  • Function Calling的工具往往需要硬编码在AI应用中，难以跨项目复用。而MCP工具通过标准协议容易被复用

    注意：MCP规范流程中并没有涉及AI应用程序在调用MCP客户端从MCP服务器获取工具列表后，如何传递给大模型；大模型如何告知AI应用程序需要调用哪个工具。以上流程是AI应用程序自定义实现的，主要有以下方式：

    • 在系统提示词中规定好提供给大模型工具列表的消息格式、大模型调用工具的消息格式
    • 如果大模型支持Fuction Calling，那么也可以按照厂商规定的格式将工具列表发给大模型

MCP 协议和 Function Calling 之间绝不是“技术递进”的关系。所谓“MCP 协议会取代 Function Calling”的说法，其实是一种不严谨的表达。在很长一段时间内MCP和Function Calling将共存

关于MCP和Function Calling的选型建议：

  • 如果是通用类型的需求，如操作文件、数据库、查询天气、抓取网页等等，可以找找有没有现成的MCP服务，通过MCP集成工具
  • 如果是项目中个性化需求，比如涉及具体业务流程(如给用户增加积分、帮用户预约挂号)可以在模型支持Function Calling的前提下，用本地代码开发工具，然后通过Function Calling集成工具

实际落地

一般情况下我们不会自己开发MCP工具，而是集成现有的MCP工具，主要有以下两种方式：

  • 在一些AI客户端中集成，比如cherry studio中配置
  • 在自己开发的AI应用程序中通过SpringAI、Langchain等框架集成

这里推荐几个MCP集合网站，可以尝试在上面寻找适合自己的MCP工具：

在MCP工具的详情页面，会有工具说明、传输方式(stdio、sse或streamable http)、启动 MCP服务 器的方式(node或python等)
在这里插入图片描述

avatar
文章
阅读
粉丝