Model Context Protocol Deep Dive
这篇文章的主要内容是深入了解和对比当前（2026年2月19日） Model Context Protocol（MCP）的版本的演进和功能集合，以及 MCP 服务端/客户端框架对标准的支持程度。这篇文章的主要目的是对于使用 MCP 时的团队决策进行支持，包括应当采纳哪些功能集合，禁止使用哪些功能集合，和其他非 AI 专…
这篇文章的主要内容是深入了解和对比当前（2026年2月19日） Model Context Protocol（MCP）的版本的演进和功能集合，以及 MCP 服务端/客户端框架对标准的支持程度。这篇文章的主要目的是对于使用 MCP 时的团队决策进行支持，包括应当采纳哪些功能集合，禁止使用哪些功能集合，和其他非 AI 专属领域的通信协议，例如 gRPC，的兼容程度等等。实现层面主要包括 Python 和 C# 生态。
MCP 协议 #
背景介绍 #
MCP（Model Context Protocol）诞生于 2024 年大模型应用爆发之后。当时各家模型、Agent 框架和 IDE 都在自定义工具调用与上下文注入方式，生态高度碎片化、难以复用。MCP 试图提供一个模型无关的标准协议，统一模型与外部能力（工具、资源、环境）的交互方式，为 LLM 工程建立稳定的基础设施层。
基本结构 #
自底向上来看，MCP 协议可以拆分为以下几个层次：
- 传输层 Streamable HTTP：MCP 定义了基于 HTTP 的流式传输协议，支持双向通信和长连接，适合模型与工具之间的实时交互。
- RPC 层：在传输层之上，MCP 继续沿用 JSON-RPC 2.0 的消息格式，定义了请求-响应模式和通知模式，支持异步调用。但是 MCP 后续移除了对 JSON-RPC 2.0 Batch 模式的支持，改为单条消息的处理方式。
- 会话层：MCP 定义了会话（Session）的概念，也支持消息重传。
- 应用层：主要是关于业务能力的定义，不展开讨论。
基于 Streamable HTTP 的传输层，支持基于 OAuth 2.0 的认证机制，保证了安全性和可扩展性。但是基于 stdio 传输层不支持认证机制。
MCP 官方文档的模块划分如下：
The Model Context Protocol consists of several key components that work together:
- Base Protocol: Core JSON-RPC message types
- Lifecycle Management: Connection initialization, capability negotiation, and session control
- Authorization: Authentication and authorization framework for HTTP-based transports
- Server Features: Resources, prompts, and tools exposed by servers
- Client Features: Sampling and root directory lists provided by clients
- Utilities: Cross-cutting concerns like logging and argument completion
传输层协议 Streamable HTTP #
传输层协议其实不止 Streamable HTTP。MCP 还支持基于 stdio 的传输层协议，适用于本地进程间通信。历史上，MCP 还支持 HTTP + SSE 双 Endpoint 的传输层协议，但在后续版本中被废弃了。现在已经是 2026 年了，我们主要关注当前版本的 Streamable HTTP 协议。
严格来说，Streamable HTTP 是在标准 HTTP 协议基础上定义的应用协议，但是对于 MCP 来说，Streamable HTTP 属于 MCP 协议栈中的传输层协议。
Streamable HTTP 主要有 3 种 Pattern
- 单次消息请求+单次回应
- 单次消息请求+流式回应
- 服务器主动推送消息
Streamable HTTP 在我看来是一个比较奇怪的协议，它的上行通道（客户端请求服务端）是（逻辑上）短连接的，但是下行通道是长连接的，两者并不对称。Streamable HTTP 的下行长连接又分为 2 种：POST-SSE 和 GET-SSE。SSE 是 Server-Sent Events 的缩写。POST-SSE 是客户端发起一个 POST 请求，服务端在这个请求上持续发送 SSE 消息，直到把跟这次请求相关的所有消息都发送完了才结束这个请求。GET-SSE 是客户端发起一个 GET 请求，服务端在这个请求上持续发送 SSE 消息，直到客户端关闭这个连接才结束这个请求。POST-SSE 用于和请求相关的结果推送，GET-SSE 用于跟 POST 请求无关的消息推送。SSE 协议是在 MCP 被发明之前很久就存在的一个标准协议（见 Server-Sent Events is a W3C Recommendation），MCP 只是把它用在了模型与工具之间的通信上。SSE 主要解决的是 HTTP 流上的消息边界问题，保证了消息的完整性和顺序性。
Streamble HTTP 这样设计，似乎可以最大限度地利用现有的 HTTP 基础设施和生态，同时又满足了模型与工具之间的实时交互需求。例如 gRPC 虽然也支持双向流式通信，但是其协议复杂性导致在浏览器端的支持非常有限，而 Streamable HTTP 则可以直接使用浏览器原生的 Fetch API 和 EventSource API 来实现客户端功能。
传输层协议 stdio #
这个也没什么可说的，就是用 stdin/stdout 来传输 JSON-RPC 消息，适用于本地进程间通信。因为 stdio 是一个简单的字节流，所以 MCP 需要在消息之间添加一些边界标识来保证消息的完整性和顺序性。由于靠换行来切分消息边界，要求消息内不能有换行。
由于 stdio 也没法接受 OAuth 认证，一般通过环境变量传递敏感信息给 stdio 模式启动的 MCP Server。
RPC 层 JSON-RPC 2.0 #
这里就是标准的 JSON-RPC 2.0 协议。MCP 曾经短暂的支持过 JSON-RPC 2.0 的 Batch 模式，但是后来废弃了。现在 MCP 只支持单条消息的处理方式。
会话层 Session #
因为上行是“一次一 POST”，不能靠“同一个 TCP 连接”来表示会话，所以 MCP 允许服务端在初始化时发 Mcp-Session-Id，之后客户端在每次 HTTP 请求里带回这个 header。
MCP 也不假设 SSE 流能中间不断开，所以允许客户端使用 Last-Event-Id 重连时带上上次收到的最后一条消息的 ID，服务端可以根据这个 ID 来决定从哪里继续发送消息。
服务器端功能 #
MCP 有几个比较重要的概念
| Primitive | Control | Description | Example |
|---|---|---|---|
| Prompts | User-controlled | Interactive templates invoked by user choice | Slash commands, menu options |
| Resources | Application-controlled | Contextual data attached and managed by the client | File contents, git history |
| Tools | Model-controlled | Functions exposed to the LLM to take actions | API POST requests, file writing |
意思都比较直接，就不展开说了。
客户端功能 #
我仿照服务器端功能，也给做了个表格，官方文档中没有这样的总结表。
| Feature | Control | Description | Example |
|---|---|---|---|
| Roots | Client-controlled（通常由用户在客户端/工作区里配置） | 客户端向服务器暴露可操作的文件系统“根目录/边界”，服务器可查询 roots 列表，并在 roots 变化时接收通知，从而知道“我被允许在什么目录范围内工作”。(modelcontextprotocol.io) | IDE/桌面客户端让用户选定一个或多个项目目录作为 workspace roots；代码服务器只在这些目录下读写/索引。(modelcontextprotocol.io) |
| Sampling | User-in-the-loop（client 负责模型访问与授权） | 服务器通过客户端请求一次 LLM 生成/补全（文本/图像/音频等），客户端掌控模型选择、权限与是否执行；规范强调应有“人类可拒绝”的审核流程（可看/改 prompt、审阅输出），且服务器无需持有模型 API key。(modelcontextprotocol.io) | 一个 MCP server 在执行工具链时，想让 LLM 先写一段解释或规划：向 client 发起 sampling/createMessage，用户确认后再把生成结果回给 server。(modelcontextprotocol.io) |
| Elicitation | User-controlled（client 负责交互与数据出境控制） | 服务器在流程中向用户补充要信息，由客户端呈现并收集；支持 Form mode（可带 JSON Schema 的结构化输入） 和 URL mode（跳转外部 URL，用于必须不经过 MCP client 的敏感交互，如登录/支付）；规范要求 form mode 不能索要敏感信息，敏感交互必须用 URL mode。(modelcontextprotocol.io) | 预订旅行：用 form mode 询问座位偏好/房型；连接第三方账号：用 URL mode 打开 OAuth 授权页（客户端展示域名并征得同意后再导航）。(modelcontextprotocol.io) |
MCP 服务器端框架 #
- Python: 官方 SDK，FastMCP
- C#: 官方 SDK
- TypeScript: 官方 SDK
特别注意，Python 官方 SDK 内部是封装了 FastMCP，然后以此实现更高层级的包装。
Python SDK #
以下是 Python 官方 SDK 版本和协议版本的支持关系
| Python SDK Version | MCP Protocol Version Supported |
|---|---|
| 1.0.0 | 2024-11-05 |
| 1.9.0 | 2025-03-26 |
| 1.10.0 | 2025-06-18 |
| 1.24.0 | 2025-11-25 |
以下是 FastMCP 版本和协议版本的支持关系
| FastMCP Version | MCP Protocol Version Supported |
|---|---|
| 2.0.0 | [2024-11-05] |
| 2.7.1 | [2024-11-05, 2025-03-26] |
| 2.10.0 | [2024-11-05, 2025-03-26, 2025-06-18] |
| 2.14.0 | [2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25] |
| 3.0.0 | [2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25] |
C# SDK #
以下是 C# 官方 SDK 版本和协议版本的支持关系
| C# SDK Version | MCP Protocol Version Supported |
|---|---|
| 0.2.0-preview.3 | [2024-11-05, 2025-03-26] |
| 0.3.0-preview.1 | [2024-11-05, 2025-03-26, 2025-06-18] |
| 0.7.0-preview.1 | [2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25] |
TypeScript SDK #
以下是 TypeScript 官方 SDK 版本和协议版本的支持关系
| TypeScript SDK Version | MCP Protocol Version Supported |
|---|---|
| 0.4.0 | [2024-10-07, 2024-11-05] |
| 1.11.0 | [2024-10-07, 2024-11-05, 2025-03-26] |
| 1.13.0 | [2024-10-07, 2024-11-05, 2025-03-26, 2025-06-18] |
| 1.24.1 | [2024-10-07, 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25] |
MCP 客户端框架 #
OpenAI SDK #
根据 OpenAI Agents SDK (for Python) 的文档，目前连接 MCP 的方式有
- HostedMCPTool: 让 OpenAI 服务端直接调用 MCP Endpoint
- MCPServerStreamableHttp: 本地通过 Streamable HTTP 协议连接 MCP Server
- MCPServerSse: 本地通过 SSE 协议连接 MCP Server（已废弃）
- MCPServerStdio: 本地通过 stdio 协议连接 MCP Server
其中 OpenAI 服务端直接调用 MCP Endpoint 要求该 Endpoint 必须是公网可访问的。
其他情况本质上相当于传统的 function calling，OpenAI SDK 作为客户端，连接本地的 MCP Server 来调用工具。
C#/Python/TypeScript 这三个语言的 SDK 都是依赖于官方 MCP SDK 来实现 MCP 客户端功能的，所以它们支持的 MCP 协议版本和官方 SDK 是完全一致的。
Anthropic SDK #
根据 Claude Agent SDK (for Python) 的文档，Claude Agent SDK 和 OpenAI 情况差不多，也同时支持服务端连接和本地连接两种模式。
Anthropic SDK for C#/TypeScript 这 2 个语言的 SDK 都是依赖于官方 MCP SDK 来实现 MCP 客户端功能的，所以它们支持的 MCP 协议版本和官方 SDK 是完全一致的。
Python SDK 没有原生支持，需要用户自己基于官方 MCP SDK 来进行适配。