外观
MCP
MCP(Model Context Protocol,模型上下文协议)是由 Anthropic 在2024年1月提出的一套开放协议,旨在实现大型语言模型(LLM)与外部数据源和工具的无缝集成,用来在大模型和数据源之间建立安全双向的链接。
Anthropic的愿景,希望把MCP协议打造成AI世界的“Type-C”接口,可以通过MCP协议工具、数据链接起来,达类似HTTP协议的那种通用程度。
| 特性 | 传统 REST API(如 Flask) | MCP(模型上下文协议) |
|---|---|---|
| 设计哲学 | 面向资源(Resource-Oriented) | 面向能力(Capability-Oriented) |
| 核心概念 | 操作的是“资源”,如用户、订单。使用 HTTP 动词(GET、POST、PUT、DELETE)对资源进行增删改查。 | 操作的是“工具”或“函数”。核心是远程过程调用(RPC)。 |
| 自发现能力 | 弱。需要依赖 OpenAPI/Swagger 等外部文档才能知道有哪些 API 端点和参数。 | 强(核心特性)。协议内置了 get_tools 这样的元调用,客户端可以程序化地查询服务端有哪些可用工具。 |
| 标准化程度 | 灵活但松散。虽然有 RESTful 风格指导,但实现五花八门。 | 高度标准化。请求和响应的结构由 JSON-RPC 规范严格定义,减少了模糊性。 |
| 适用场景 | Web 应用、移动应用后端、数据驱动的服务。 | 为大模型或 Agent 提供工具。专为“调用一个函数并获得结果”这个场景优化。 |
MCP 协议组成
整体结构:
MCP
├── Transport
│ ├── STDIO
│ ├── HTTP
│ └── SSE
│
├── JSON-RPC
│ ├── Request
│ ├── Response
│ └── Notification
│
├── Lifecycle
│ ├── initialize
│ └── initialized
│
├── Tools
│ ├── tools/list
│ └── tools/call
│
├── Resources
│ ├── resources/list
│ └── resources/read
│
├── Prompts
│ ├── prompts/list
│ └── prompts/get
│
└── Sampling
└── 调用宿主模型MCP Host(宿主)
用户直接使用的 AI 应用,负责接收用户请求、协调工具调用并生成最终结果。
例如:
- Claude Desktop
- Cursor
- OpenAI Agent
- VS Code AI 插件
MCP Client(客户端)
MCP 协议通信层,负责与 MCP Server 建立连接、发现工具、发送请求和接收响应。
通常内置于 Host 中,开发者一般无需直接编写。
MCP Server(服务端)
能力提供者,向 AI 暴露工具、资源和提示词等能力。
例如:
- 文件系统操作
- 数据库查询
- GitHub 操作
- 浏览器控制
- 自定义业务接口
Tools(工具)
Server 提供给 AI 调用的函数或能力,是 MCP 中最常用的组成部分。
例如:
@mcp.tool()
def get_weather(city: str):
return "晴天"Resources(资源)
供 AI 读取的数据资源,类似只读数据源。
例如:
- 配置文件
- 文档
- 数据库记录
- 本地文件
Prompts(提示词模板)
Server 提供的可复用 Prompt 模板,帮助 AI 快速完成特定任务。
例如:
- 代码审查
- 文档总结
- 数据分析
如果从协议层面最简洁地概括:
MCP = Host + Client + Server
Server = Tools + Resources + PromptsMCP 角色组成
MCP 包括两个核心角色:服务端和客户端。
MCP服务端 (Tool Provider):
- 角色:工具的提供者。
- 职责:将一个或多个本地函数(例如,Python函数)包装起来,通过一个标准的MCP接口暴露出去。它监听来自客户端的请求,执行对应的函数,并返回结果。
- 例子:一个天气查询服务、一个数学计算服务、一个数据库访问服务。
MCP客户端 (Tool Consumer):
- 角色:工具的调用者或消费者。
- 职责:连接到MCP服务端,查询可用的工具列表(自发现),并根据需要调用这些工具。

MCP 通信传输方式
MCP协议本身与传输方式无关,mcp及python-a2a库等提供了两种常见的实现:stdio和基于HTTP的SSE。
stdio (标准输入/输出)
stdio:一种非常经典和简单的进程间通信(IPC)方式。客户端启动服务端作为一个子进程。
工作原理: 客户端通过写入子进程的标准输入 (stdin) 来发送请求,并通过读取子进程的标准输出 (stdout) 来获取响应。这种方式简单高效,无需网络开销。
适用场景: 非常适合在本地环境中,将一个命令行工具或脚本快速封装成一个 MCP 服务。例如,server_stdio.py 文件中的代码就配置了这种传输方式。
SSE (Server-Sent Events)
SSE:一种基于 HTTP 的单向推送协议,它允许服务器在保持连接开放的情况下,持续向客户端发送事件流。
工作原理: 客户端发起一个 HTTP 请求,服务器接收请求并保持连接,然后以 text/event-stream 格式将响应数据流式传输给客户端。这在 MCP 中被用来实现请求与响应的通信。
适用场景: 适用于分布式或网络环境,当服务需要部署在远端,并通过网络供多个客户端访问时。
Streamable-HTTP (可流式 HTTP)
Streamable-HTTP:MCP 提供的另一种基于 HTTP 的传输方式,它同样用于网络通信。
工作原理: 客户端通过 HTTP 请求与服务器通信。与 SSE 的主要区别在于其传输格式和机制可能有所不同,但核心目的都是通过网络实现 MCP 协议。
适用场景: 与 SSE 类似,适用于需要通过网络进行通信的分布式应用。
| 属性 | stdio | SSE (Server-Sent Events) | Streamable-HTTTP |
|---|---|---|---|
| 通信方向 | 双向 (请求 - 响应) | 单向 (服务器推送到客户端) | 双向 (双向流) |
| 通信模式 | 本地进程间通信 (IPC) | 网络通信 (长连接流) | 网络通信 (双向流) |
| 主要用途 | 封装本地命令工具 | 仅服务端更新场景 | 复杂、实时双向交互场景 |
| 是否容易丢数据 | 否 (系统保障) | 否 (TCP 保障) | 否 (TCP 保障) |
| 关键优势 | 简单高效安全,无网络开销 | 适用于简单单向推送,兼容性好 | 灵活支持双向流,提升大型任务效率 |