截至 2026 年 6 月下旬，Model Context Protocol 的月下载量已达 9700 万次。在 Anthropic 发布规范的十九个月之后，MCP 不再是争论的话题——它是一个依赖。每一家前沿模型厂商、每一款主流 IDE，乃至 Pinterest 一个团队据其测算的每月七千个工程小时的节省，全都构建在它之上。如今值得追问的，已不再是该不该用 MCP，而是这个体量之下还有什么会崩。
三个数字
| 指标 | 数值 | 截至 |
|---|---|---|
| MCP SDK 月下载量 | 9700 万 | 2026 年 5 月 |
| Registry 服务器记录数 | 约 10,000 个最新条目（9,652 / 含版本共 28,959） | 2026 年 5 月 24 日 |
| Pinterest 生产环境调用 | 844 名活跃用户每月调用 66,000 次，节省约 7,000 工程小时 | 2026 年 4 月 |
三个数字，一个故事。2024 年 11 月上线的协议，如今下载量已迈入九位数；公共 registry 收录了一万个权威服务器，把版本记录一并计入则是这个数字的三倍；至少有一家大型工程组织，已经用一份经过审计的硬数据，量化了 MCP 为其真正节省的成本。这些数字都不是猜想——分别来自上游 registry、Anthropic 自身的遥测和一篇 Pinterest 工程博客——合在一起，描绘了一个没有明显临界点、却已从"有趣的标准"跨入"承重基础设施"的协议。增长本身就是故事；同一张图表里没有任何竞品，则是潜台词。
MCP 到底是什么
stdio 或 HTTP 的 JSON-RPC ↔ 服务器 ↔ 真实世界目标。MCP 宿主是承载模型的程序——Claude Desktop、Cursor、VS Code、OpenAI Agents SDK，或者你自己写的应用。宿主内部，每一个 MCP 客户端通过一段 JSON-RPC 会话与一个 MCP 服务器对话。服务器为某项真实世界能力打前站：一个 Postgres 数据库、一个 GitHub 仓库、一个文件系统、一个 SaaS API。模型从不直接触碰目标；服务器对外暴露一组带类型的接口——模型可以调用的工具、可以读取的资源、可以唤起的提示——再由宿主将这套接口转换为它所属模型期望的样子。
传输层是 MCP 保持精简的地方。规范只定义了两种传输：本地进程用的 stdio（宿主把服务器作为子进程拉起，通过 stdin/stdout 转送 JSON-RPC），以及远程服务器用的、可选附带 Server-Sent Events 的 HTTP。两层都刻意做得朴素无奇。真正有趣的工作发生在传输之上——能力发现、带类型的工具 I/O、生命周期握手——这也正是为什么这个协议能干净地嵌入既有的工具调用栈，而不必另起一套运行时。参与者模型的细节，参见MCP：宿主、客户端、服务器。
MCP 不是模型自己的工具调用 API。模型依旧用各自的方言做函数调用——OpenAI tools、Anthropic tools、Gemini function declarations——再由 MCP 客户端在该方言与服务器的带类型 schema 之间做翻译。MCP 是宿主与工具提供方之间的那根线，不是模型与宿主之间的那根线。正是因为这种分层，同一个 MCP 服务器可以同时服务于 Cursor 里的一个 Claude 会话、OpenAI Agents SDK 里的一个 GPT-5 会话，以及你自己写的一个智能体循环，而三者彼此并不知晓对方在跑什么。关于更宏观的互操作图景，参见工具、动作与环境。
它为什么赢了
中立规范加先发优势
Anthropic 发布的是规范，不是产品。2024 年 11 月那次发布带出了线缆格式、一份参考实现和三种语言的 SDK——然后就停下了。没有"MCP Cloud"，没有专有 registry，也没有任何只属于 Anthropic、迫使其他实现者绕道而行的能力。这份规范在首版即已足够成熟，早期基于 pre-1.0 草案构建的服务器大多至今仍能用；协议没有经历过公开的格式重洗。标准领域的先发优势，很大程度上就在于不给后来者留下分叉的口实，而一份不必自我重写的规范，正是堵住这道口最廉价的办法。
跨厂商采纳
不到十八个月，协议已得到所有重要参与方的支持。Anthropic 首发；OpenAI 在 Agents SDK 和 ChatGPT 中加入了 MCP 支持；Google 把 MCP 集成进 Gemini 的工具体系和 Vertex；Microsoft 把 MCP 嵌入 Copilot Studio 与 Windows 智能体表面；GitHub 发布了第一方 MCP 服务器，并把 MCP 接入 Copilot；Vercel 在其 AI SDK 中暴露 MCP；VS Code 与 Cursor 双双成为 MCP 宿主。如今有九家厂商——Anthropic、OpenAI、Google、Microsoft、GitHub、Vercel、VS Code、Cursor、ChatGPT——都把 MCP 当作一等公民集成。它们任何一家都无法从分叉中获益，而这种激励的缺失，正是把协议锁死的力量。下方的厂商支持矩阵就是这种对照的图像证据；正文则把协议当作单一对象来谈，因为它已经成为单一对象。
移交给 Linux Foundation
2026 年，MCP 移交至 Linux Foundation 新设立的 Agentic AI Foundation，与 LF AI & Data 旗下一众采中立治理的协议为伍。这次移交把规范的开放性只是暗示过的事在纸面上做实了：单一厂商的风险被摘除。今天一名参与规范工作的 OpenAI 工程师，与一名 Anthropic 工程师所面对的是同一套治理流程；Microsoft 的平台团队也可以把 MCP 当作承重依赖落地，而无需承担"Anthropic 握有一票否决权"的政治解读。基金会并不能让协议在技术上更好——它们让协议在政治上更安全、值得被依赖，而这正是一项基础设施协议所需要的。
var(--accent)）表示第一方在售集成；中表示部分或预览；弱表示外部或仅社区。一整行才是关键；没有一行是空的，才是故事。规模化之下仍会崩的地方
传输层的可扩展性
stdio 传输应付一个服务器、一台开发机绰绰有余。可一旦宿主想同时把十几二十个服务器保持热态，它就撑不住了——每一个都是一个长寿命子进程，各自吃掉一份运行时、一份连接池、一份内存压力。HTTP 传输解决了进程数的问题，却没有解决连接模型的问题：基于 HTTP+SSE 的长寿命 JSON-RPC 会话，会按活跃客户端绑定一个服务端连接，而拥有一万个服务器的 registry 不可能在如此扇出之下经济地托管有状态套接字。现实里崩塌的，是宿主的启动时间和 registry 运营方的账单——两者都不以协议错误的形式现身，而是化作用户可感的延迟与单位经济学的痛苦。2026 年的路线图把传输层可扩展性列为最大单一悬而未决的问题，事实也确实如此。
Registry 的信任与供应链
一个 MCP 服务器就是一段可执行程序，宿主以用户的权限、用着用户的数据把它跑起来。registry 里大约有一万个这样的程序。它没有内建签名机制，没有权威的发布者身份，也没有让被遗弃包退场的自发机制。registry 上的拼写抢注——github-mcp 对 github-mcp-server 对 mcp-github——就是 npm 的失败模式在一个新生态里如数复刻，而且后果更糟，因为 MCP 服务器的天然权限面是"读你的文件、调你的 API、写你的数据"。在 registry 上线包签名与发布者身份（维护者已经标注但尚未交付）之前，生产环境最稳妥的姿态是把 commit hash 钉到来自已知组织的特定提交，并把 registry 当作发现工具，而非信任根。
服务器泛滥与可发现性
GitHub 上挂着 mcp-server 主题的仓库已经有一万五千九百个。registry 里也有约一万条权威条目。对于任何稍有难度的需求——比如"给我一个只读模式、带审计日志的 Postgres MCP 服务器"——你会找到八个看上去都行的候选，其中四个最后更新还在 2025 年，两个是 fork 之 fork。基于服务器描述的语义搜索能缩小范围，却没真正解决问题，因为用户实际在问的是"六个月后还有谁会维护它"。这是一种社会信号，而非文本信号，而 registry 还没有暴露能让宿主拿出有意义默认值的那些信号——下载趋势、近期 commit、维护者活跃度。同一问题在运行时一侧的样貌，参见能力发现。
治理与授权
规范定义了服务器能做什么，但对谁有权让它去做，说得就少得多。服务端的权限是每个服务器各自的实现细节；面向远程服务器的 OAuth 流程仍在 2026 年的规范草案中标准化；能力委派——"这个智能体可以读 GitHub，但不能写"——还没有权威的线缆表达方式。规模化之下崩掉的是企业落地：一支愿意爽快批准单一被审计服务器的安全团队，无法批准"一万个里随便选"，而协议又没给他们在宿主层做闸门的抓手。2026 年路线图称之为"企业就绪"；实际的关键词是授权。
2026 年路线图
传输层可扩展性。路线图的头号优先级，是让 HTTP 传输在 registry 量级的扇出之下也撑得住：更好的流式语义、可选的无状态会话模式，以及关于何时该用哪种传输的清晰指引。意图是把 stdio 退化为单纯的本地开发便利项。
智能体之间的通信。今天的 MCP 是宿主对服务器。下一层是智能体对智能体——一个智能体把另一个智能体当作对等节点而非工具来调用——需要自己的发现机制、身份模型与任务生命周期。这项工作是与 Google 的 A2A 协议并行进行的，而非对着干；最终是否收敛，仍是一个未决问题。设计空间参见智能体之间的通信。
治理走向成熟。包签名、发布者身份、registry 内的退役生命周期；规范层标准化的 OAuth 流程；更清晰的能力委派规则。这些工作技术上都不新鲜——每个包生态都做过——只是 MCP 的采纳曲线在催着它早早做。
企业就绪。审计日志的约定、RBAC 模式、密钥处理指引、把宿主作为策略执行点的部署食谱。比起协议工作，更多是文档与约定的工作，但正是这种约定决定了 MCP 是会进入 Fortune 500，还是停留在团队实验阶段。
常见问答
MCP 不就是函数调用吗？
不是。函数调用是模型侧的原语——模型发出一个结构化请求，宿主执行函数，结果再回到模型。MCP 是宿主与工具提供方之间的那根线：它让单一服务器能把自己的工具暴露给任意兼容 MCP 的宿主，无需为每种模型做绑定。函数调用层依旧存在；MCP 只是坐在它右边那一格。
我必须用 TypeScript 写服务器吗？
不必。截至撰文，官方参考 SDK 覆盖了 TypeScript、Python、Rust、Go、Java、C#、Swift 和 Kotlin，而线缆协议本身就是 JSON-RPC，所以只要某种语言有现成的 HTTP 或 stdio 工具库，写一个服务器都是轻而易举。生产环境中的多数服务器是 Python 或 TypeScript，原因在于维护者社群集中在那里，而不在于协议有任何要求。
MCP 能配非 Anthropic 模型使用吗？
可以——这正是 MCP 是一种协议而非 Claude 自家特性的全部意义。GPT-5、Gemini、Mistral、Llama、Qwen 与 DeepSeek 都跑在懂 MCP 的宿主里。宿主在模型原生的工具调用方言与 MCP 服务器的带类型接口之间做翻译；模型本身根本不需要知道 MCP 的存在。
MCP 和 OpenAPI 有什么区别？
OpenAPI 描述的是面向人和代码生成器的 HTTP API。MCP 描述的是模型宿主与能力提供方之间的一段带类型、有状态的会话，并把模型所需的一等概念——工具、资源、提示、生命周期、能力发现——写在了协议里。你可以把一个 OpenAPI 服务放在 MCP 服务器后面，很多人也确实这么做；反向就鲜有意义，因为 MCP 携带了 OpenAPI 不具备的语义。
MCP 默认安全吗？
不安全。一个 MCP 服务器以宿主进程的权限运行，能访问宿主交给它的一切。请把每个服务器都当作来自 npm 的可执行程序对待：锁定已知发布者和版本，把它的访问面（文件系统根目录、API 密钥）压到最窄，并把 registry 当作发现工具，而非信任根。2026 年规范在签名、OAuth 与能力委派上的工作正在弥合这道缺口，但缺口今天仍然真实存在。
Google 或 OpenAI 会分叉它吗？
过去十八个月里它们都没有。两家都在旗舰产品中提供第一方 MCP 支持，并在 Linux Foundation 的 Agentic AI Foundation 下共同参与规范流程。分叉的诱惑——掌控智能体基础设施的一块关键拼图——远不及切碎 registry 的代价；而 registry 正是 MCP 对它们各自用户最有价值的资产。收敛才是均衡点；分叉等同于自伤。
延伸阅读
本站推荐：
- MCP：宿主、客户端、服务器 — 参与者模型、JSON-RPC 生命周期与传输层细节。
- 为什么互操作重要：M×N 问题 — MCP 解决的那个结构性论证。
- 构建可互操作的智能体 — 何时选 MCP，何时选 A2A，何时直接做工具调用。
- 能力发现与协商 — 可发现性问题在运行时一侧的样貌。
- 工具调用详解 — MCP 紧邻的那个模型侧原语。
信息来源：
- modelcontextprotocol.io — 权威规范站点、SDK 与参考服务器。
- github.com/modelcontextprotocol — 规范仓库、各语言 SDK 与 2026 年路线图的讨论串。
- MCP Registry — 权威服务器 registry；约一万个服务器这个数字即来自此。
- Pinterest Engineering — 上文引用的 2026 年 4 月 MCP 生产实践博文的出处。
- Anthropic — Introducing the Model Context Protocol — 2024 年 11 月 25 日的发布博文。
- Linux Foundation — Agentic AI Foundation 的归属方；中立治理移交的公告托管于此。