Model Context Protocol（MCP）

1. 调研缘由

MCP 是 Anthropic 在 2024 年 11 月 25 日开源发布的，当时的目标就是给 AI 助手连接数据源、业务工具和开发环境提供一套统一标准。[S15]

要搞清楚的是，MCP 不是某个具体的 AI 产品，也不是某个具体的 MCP server，而是一个连接层项目，里面包含了协议规范、官方 SDK、开发工具、参考实现和 Registry。[S1] 2025 年 12 月，Anthropic 宣布把 MCP 捐赠给 Linux Foundation 旗下的 Agentic AI Foundation（AAIF），让它进入了多方参与的基金会治理框架。[S5]

现在 OpenAI 的开发者文档已经支持远程 MCP server；GitHub Copilot 和 VS Code 也分别发布了 MCP 接入、配置、信任和管理文档。[S6][S7][S8] 所以，我们这次不看某一个 server 的具体功能，而是想搞清楚三件事：MCP 真正标准化的是哪一层；跨客户端的生态有没有形成一个可复用的连接层；以及安全、兼容和治理责任到底落在谁头上。

2. 简介与产品工作流

MCP 是一套开放协议，让 AI 应用和外部系统“按同一套规则通信”。它主要规定 AI 应用怎么发现、读取和调用外部能力；至于模型怎么推理、Agent 怎么规划任务、保存记忆或管理拿到的上下文，协议本身不管。[S1]

协议用的是 Host—Client—Server 架构：

• Host：就是 AI 应用本身，比如 IDE、桌面助手或者 Agent 产品。
• Client：Host 内部用来连接某个 MCP server 的组件。一个 Host 通常会为每个 server 建一个独立的 client。
• Server：对客户端暴露上下文或能力的程序，可以跑在本机，也可以远程部署。[S1]

一次典型的工作流是这样的：

1. Host 连上 MCP server 后，双方先做初始化和 capability negotiation，也就是互相确认一下彼此都支持哪些协议功能。[S1][S2]
2. Server 可以向 Host 暴露三类核心能力：Tools 是可执行的操作，比如查数据库或调 API；Resources 是可读取的上下文，比如文件、表格或接口响应；Prompts 是可复用的提示模板或工作流模板。[S1]
3. Host 通过 tools/list、resources/list、prompts/list 这些方法去发现可用的能力，再按照自己产品的权限和审批逻辑来调用它们。[S1]
4. MCP 的标准传输方式包括 stdio 和 Streamable HTTP。stdio 适合本地进程间通信；Streamable HTTP 适合远程 server，还可以搭配 Server-Sent Events 做流式消息传递。[S2]

到本次调研为止，官网上标注的最新 MCP 规范版本是 2025-11-25。[S2]

3. 团队与资本背景

MCP 最早由 Anthropic 的 David Soria Parra 和 Justin Spahr-Summers 创建，2024 年以开放标准、SDK 和开源 server 仓库的形式对外发布。[S15]

2025 年 12 月，Anthropic 把 MCP 捐给了 Linux Foundation 旗下的 AAIF。AAIF 是由 Anthropic、Block 和 OpenAI 共同发起的，Google、Microsoft、AWS、Cloudflare、Bloomberg 等机构也都加入了支持。[S5]

MCP 不是一家独立公司，所以传统意义上的融资轮次、估值、客户名单和商业定价这些不适用。这里我们不会把 Anthropic 的融资、Claude 的收入或公司客户数据混到 MCP 协议头上。

官方公告的说法是，捐赠后 MCP 现有的治理模式保持不变，维护者还是会延续社区输入和透明决策的机制。[S5]

4. 技术基础与生态位

MCP 坐落在 AI 应用和外部工具、数据、业务系统之间的连接层。官方文档讲得很清楚，MCP 聚焦的是“上下文交换协议”，不规定 AI 应用怎么用 LLM，也不规定怎么管理拿到的上下文。[S1]

协议分成两层：

• 数据层：基于 JSON-RPC 2.0，定义了连接生命周期、能力协商、工具、资源、提示模板、通知这些消息的语义。[S1][S2]
• 传输层：定义本地或远程连接怎么通信、怎么建立连接、怎么封装消息和怎么做认证。[S1][S2]

MCP 有“能力协商”这一步，意味着“支持 MCP”并不是一个所有实现都一刀切的状态。不同的 Host 可以自己选择支持哪些能力。比如，GitHub Copilot 的 cloud agent 和 code review 目前只支持 MCP Tools，不支持 server 提供的 Resources 和 Prompts，也暂不支持用 OAuth 的远程 MCP server。[S7]

官方 SDK 覆盖了 TypeScript、Python、C#、Go、Java、Rust、Swift、Ruby、PHP 和 Kotlin，按维护和功能完整度分成了 Tier 1 到 Tier 3。[S3] SDK 提供了各语言的实现入口，但这不代表不同客户端的功能、权限模式和交互体验会自动变得一致。

MCP Registry 是公开 MCP server 的集中元数据仓库。它保存 server 的名称、发布位置、安装方式和能力描述，代码和二进制通常还是由 npm、PyPI、Docker Hub 这样的包仓库来托管。[S4] 官方 Registry 目前还处于 preview 阶段，文档里也说明了，正式发布前可能会发生破坏性变更或数据重置。[S4]

Registry 主要是给下游聚合器和 marketplace 用的，不直接替所有 Host 做运行时发现和安全审查；实际 server 代码的扫描，主要还得靠底层包仓库和下游聚合器自己的额外机制。[S4]

5. 市场与外部信号

作为一个开放协议，MCP 没有统一定价，也没有传统 SaaS 意义上的客户名单。协议类项目更适合去看采纳、实现、版本演进、SDK 和 Registry 这些方面的活跃信号。

• Anthropic 在 2025 年 12 月的公告里提到，当时活跃的公开 MCP server 已经超过 10,000 个，Python 和 TypeScript SDK 的月下载量合计超过 9,700 万。这个数据来自发起方自己的披露，可以当作当时生态规模的一个信号，不能当成独立审计后的实时统计。[S5]
• OpenAI 的 Responses API 文档把远程 MCP server 当作给模型增加外部能力的一种方式，还说明它可以和 function calling 同时使用。[S6]
• GitHub Copilot CLI 支持本地和远程 MCP server；GitHub MCP server 是由 GitHub 自己提供和维护的。[S7]
• VS Code 提供了 MCP server 的安装、配置、启动、日志查看、信任确认、组织级管理，还有本地 stdio server 的沙箱能力。[S8]
• 2025 年 11 月的规范更新加入了异步操作、无状态支持、server identity 和官方扩展这些内容，说明协议还在持续演进。[S5]
• 官方 Registry 已经提供了公开的元数据目录和 REST API，但还在 preview 阶段。[S4]

这些信号放在一起看，说明 MCP 已经进入了多个 AI 客户端和开发工具的产品路线；但不同 Host 对 Tools、Resources、Prompts、远程连接、OAuth、人工审批和沙箱的支持范围仍然不一致。[S6][S7][S8]

6. 公开评价与主要分歧

正面评价（独立媒体）:

独立媒体 The Verge 的描述是，MCP 已经从 Anthropic 的内部项目扩展为多家公司参与的协议项目，并且认为由 Linux Foundation 托管，有助于缓解其他厂商对 Anthropic 单独主导协议的治理顾虑。[S10] 这是媒体的观察，不是对协议安全性、性能或跨客户端兼容性的统一测试。

主要批评/质疑（独立研究）:

一项针对 1,899 个开源 MCP server 的研究发现，样本里有 7.2% 存在通用软件漏洞，5.5% 出现了 MCP 特有的 tool poisoning 风险。研究对象是开源 server 实现，不等于 MCP 规范本身存在同样比例的问题；但它说明 server 的工具描述、权限和代码维护会形成额外的攻击面。[S11]

另一项 2026 年发布的预印本分析了 473 个活跃 MCP server 仓库里的 837 个运行时故障讨论，把问题归纳成了协议交互、工具调用、schema 校验、状态管理、模型接入、安全校验和超时这些类别。这个研究反映的是，MCP 生态的实现和运维复杂度已经成了一个独立的议题。[S12]

官方的安全文档也列出了 confused deputy、token passthrough、SSRF、会话劫持、本地 MCP server 被恶意配置或攻破、权限范围过宽这些风险。[S9] 官方规范同时明确说了，协议本身没办法在协议层强制所有安全原则，实际防护还是要靠实现方自己去设计授权、审批、访问控制和数据保护流程。[S2]

存在分歧的地方:

支持者强调，MCP 可以降低 AI 应用分别为每个工具写专用连接器的成本，还能让同一个 server 被不同 Host 接入。[S1][S15] 但 capability negotiation 和 Host 各自的实现选择，意味着“支持 MCP”并不等于完整能力、认证流程或权限体验一致。[S1][S7]

MCP 也把安全责任分散到了多个主体身上：Host 要决定是否信任和审批调用，server 运营者要对自己这边的权限、工具定义和代码安全负责，部署者还得处理密钥、网络边界和数据流向的问题。[S2][S6][S9] 目前公开的独立材料里，安全与实现质量方面的研究，多过跨客户端可移植性或企业部署收益的统一基准测试。

7. 同类对比（与头部/高知名度同类项目）

主要对标项目：

• OpenAI Function Calling
• Agent2Agent Protocol（A2A）

关键维度对比（事实，标来源）:

维度	MCP	OpenAI Function Calling	A2A
主要连接对象	AI Host / Client 与 MCP server。[S1]	OpenAI 模型与应用在 API 请求中定义的工具或函数。[S13]	相互独立、可能由不同框架或厂商构建的 AI Agent 系统。[S14]
主要解决的问题	让 AI 应用发现、读取和调用外部工具、资源、提示模板与上下文能力。[S1]	让 OpenAI 模型根据请求中提供的 JSON Schema 工具定义发起 tool call。[S13]	让 Agent 发现彼此能力、协商交互方式、管理协作任务与交换信息。[S14]
通信与绑定	基于 JSON-RPC 2.0；标准传输包括 stdio 与 Streamable HTTP。[S1][S2]	OpenAI API 中的工具调用机制，不是独立的跨厂商网络协议。[S13]	支持 JSON-RPC、gRPC 与 HTTP+JSON 等绑定。[S14]
能力发现方式	通过初始化、能力协商，以及 tools/list、resources/list、prompts/list 等方法发现能力。[S1]	开发者在 API 请求中提供工具定义，模型据此决定是否请求调用。[S13]	通过 Agent Card 发现 Agent 的能力、协议与认证信息。[S14]
是否规定 Agent 协作	不规定 Agent 间任务分工、协作协议或内部执行逻辑。[S1]	不属于跨 Agent 协作协议。[S13]	面向 Agent 间通信、协作与任务管理。[S14]

公开评价中的对比（标源，非个人裁决）:

OpenAI 文档把远程 MCP server 放在“除 function calling 外”的工具能力里，说明两者可以在同一个产品接口里并存，而不是被官方写成互相替代的关系。[S6][S13]

A2A 规范附录明确把 MCP 和 A2A 定位成互补协议：MCP 偏向 Agent 或 AI 应用连接工具、API 和数据源；A2A 偏向独立 Agent 之间的通信与协作。[S14] 这一次我们没找到足够多的公开独立资料，能把这三者放在统一维度下分出优劣。

8. 信息缺口与后续观察

• 没找到独立、持续更新的统计口径，可以可靠地比较官方 Registry、第三方目录和实际活跃 MCP server 的数量。
• 没找到覆盖主流 Host 的统一兼容矩阵，能同时比较 Tools、Resources、Prompts、OAuth、远程连接、审批、沙箱和扩展支持情况。
• 没找到能统一评估 MCP 跨客户端迁移成本、企业部署收益或权限治理效果的公开独立基准测试。
• 这次没有覆盖官方 Registry 的完整审核、恶意 server 下架、供应链签名和身份验证机制。
• 后续值得看的是，Registry 从 preview 到正式版本后的发布、验证、聚合和身份体系怎么变。
• 后续也值得观察 AAIF 治理下的规范迭代节奏、SDK 同步性、扩展提案流程和跨厂商参与情况。
• 还有一点，后续得看各 Host 会不会逐步补齐 Resources、Prompts、OAuth、server identity、最小权限和本地隔离能力。

9. 归纳洞察 ★

MCP 的核心，不是单纯让模型“会调工具”，而是把原来散落在不同模型厂商、IDE、插件和业务系统里的那些连接方式，抽成一套可复用的 Host—Client—Server 协议。[S1][S13]

它更像是 Agent 生态里的连接层：上面是模型、聊天产品、IDE 和 Agent；下面是数据源、工具、业务 API 和工作流。协议规范、SDK、Host 实现和 Registry 一起决定了实际的连接体验，光靠协议文本本身，没办法单独保证跨客户端的一致性或安全性。[S1][S3][S4][S7][S9]

眼下的采纳和基金会治理信号，都说明 MCP 已经获得了多家实现方的支持；但在实际做研究的时候，不宜只盯着“支不支持 MCP”。更有信息量的观察角度是：Host 到底支持哪些能力、授权和审批怎么做的、server 是怎么被发现和验证的，以及本地部署和远程部署的安全边界是怎么划开的。[S5][S6][S7][S8][S9]

10. 来源与更新时间

• 信息截至(as_of): 2026-06-30
• 最后复查(last_checked): 2026-06-30
• 最后更新(last_updated): null