2026年上半年MCP的状态:实际上发生了什么变化
Senior Web Scraping Engineer
TL;DR:
- Anthropic不再拥有MCP。 在2025年12月,Anthropic将模型上下文协议转让给了Agentic AI基金会,这是一个在Linux基金会下的新定向基金,由Block和OpenAI共同创办,并得到Google、Microsoft、AWS、Cloudflare和Bloomberg的支持。该协议是一个聊天助手公司在2024年底为自己编写的,现在根据共享标准的方式进行管理。
- 线格式在二十个月内移动了五次,并且即将再次移动。 修订版于
2024-11-05、2025-03-26、2025-06-18和2025-11-25发布;一个2026-07-28的候选版本,在2026年5月锁定,完全移除了会话握手,并使协议在传输层无状态。 - 跨厂商采用是真实的,直接从协议的管理方确认,而非厂商的营销说辞。 Anthropic自己在2025年12月的数据显示,活跃的公共MCP服务器超过10,000个,SDK每月下载量超过9700万,ChatGPT、Cursor、Gemini、Microsoft Copilot和VS Code已经在客户名单上。
- 没有人发布当前有多少个MCP服务器的实时统计。 官方MCP注册表提供发现功能,而不是仪表板,因此流通中的每一个服务器计数数据——包括Anthropic自己的——都是一个过时的快照,而不是持续的总数。
- 生产服务器可以在规范之后运行一年,仍然正常工作。 Scrapeless自己托管的MCP端点,在写这段文字时实时检查,仍使用原始的
2024-11-05握手,现在提供21个工具,启动时为19个——这正是协议的向后兼容版本控制所允许的,至少在无状态修订版发布之前。 - 免费开始。 新的Scrapeless账户包括免费的MCP运行时——可以在app.scrapeless.com注册。
一个超越其创造公司的协议
今天连接到模型上下文协议服务器的代理使用了一种由Anthropic在2024年11月独自设计的握手。十八个月后,Anthropic不再管理定义该握手的文档,而该握手本身已计划在下一次修订中移除。这两个事实并未改变代理调用工具时发生的事情。这一差距——在协议治理和线格式变动的幅度与其对工作集成的影响之小之间——就是2026年上半年MCP的实际状态。
MCP作为Anthropic对M-by-N集成问题的解决方案推出:每个想要搜索网络、读取文件和查询数据库的代理都需要为每个任务提供单独的适配器,而更换模型意味着需要重建所有三个。基于JSON-RPC的单一客户端-服务器协议是解决方案。自那时以来改变的并不是核心思想,而是控制它的主体、规范被重写的频率以及生态系统吸收这两者的程度。
从Anthropic的规范到基金会的标准
在2025年12月9日,Anthropic将模型上下文协议移交给了Agentic AI基金会(AAIF),这是在Linux基金会下的新定向基金。该基金会由Anthropic、Block和OpenAI共同创办,并在转让MCP治理权的公告中指出Google、Microsoft、AWS、Cloudflare和Bloomberg等公司为支持单位。MCP与Block的goose和OpenAI的AGENTS.md一起,成为该基金会的三个创始项目之一——这是一个值得深思的细节:协议的创造者和其最重要的竞争对手之一,成为了同一治理机构的共同管理者。
同一公告是人们引用的大多数采用数字的来源:超过10,000个活跃的公共MCP服务器,每月在Python和TypeScript上的SDK下载量超过9700万,Claude自己的目录中有超过75个MCP驱动的连接器,客户名单上已经包括ChatGPT、Cursor、Gemini、Microsoft Copilot和Visual Studio Code。这些是Anthropic自己的数据,带有特定公告的时间戳,而不是独立的普查——这一点将在下一部分中再次提及。
治理成熟度体现在过程上,而不仅仅是在组织结构图中。在基础之下,MCP 现在运行一个正式的弃用生命周期——一个特性在 活跃、弃用 和 已移除 状态之间移动,每个阶段之间至少相隔十二个月——而基础的对这一变化的描述指出,标准跟踪提案现在在达到最终状态之前需要在合规套件中配套测试用例。这是一个明显更慢、更负责任的过程,而不是一家公司的变更日志发货,这是每个供应商-协议-到-基础标准交接所做的权衡。
五个修订,一个兼容性承诺,一个重大例外
MCP 自身的版本政策故意保守:协议版本是一个日期字符串,只有在变更破坏向后兼容性时才会上升。根据这一规则,MCP 的活动异常繁忙。
| 修订 | 发货 | 实际更改内容 |
|---|---|---|
2024-11-05 |
2024年11月 | 原始发布 —— JSON-RPC 2.0 基础、工具/资源/提示、stdio 和 HTTP+SSE 传输 |
2025-03-26 |
2025年3月 | OAuth 2.1 授权框架、流式 HTTP 传输(替代 HTTP+SSE)、JSON-RPC 批处理、工具注释 |
2025-06-18 |
2025年6月 | 批处理再次被移除、结构化工具输出、服务器重新分类为 OAuth 资源服务器、引导、强制 MCP-Protocol-Version 头 |
2025-11-25 |
2025年11月 | OpenID Connect 发现、采样中的工具调用、实验任务、正式化治理和工作组 |
2026-07-28(发布候选) |
锁定于2026年5月21日;最终于2026年7月28日 | 协议变为无状态 —— 会话 ID 头和 initialize/initialized 握手均被移除 |
表中的两个事项值得停下来思考。首先,JSON-RPC 批处理在2025年3月添加并在三个月后被移除——该规范已经反转,而不仅仅是扩展,这是标准仍在寻找最终形状的诚实标志,而不是平稳收敛。其次,未来的发布并不像其他的那样是增量的。使协议无状态意味着任何请求都可以到达普通负载均衡器后面的任何服务器实例,这是一个真正的操作胜利——但这也意味着今天每个现有客户端和服务器所依赖的握手将在发布候选的变更说明中被删除,而不是被弃用。Roots、Sampling 和 Logging 在同一修订中转为 Deprecated,每个都有明确的替代方案,在基础的生命周期政策所保证的十二个月的移除窗口内。
没有人可以实际检查的采用数量
上述 10,000 服务器和 9700万下载的数字是真实的,且为第一方数据,而在发布时它们也是七个月前的数字,来源于单一公告而非实时统计。该协议的当前介绍页面仍然将 Claude、ChatGPT、Visual Studio Code、Cursor 和 MCPJam 列为截至本文撰写时的支持客户端,这确认了其广泛性——但并未更新计数。官方的 MCP 注册表旨在回答“此服务器是否存在以及它公开了什么”,而不是“今天存在多少服务器”,其自身的界面没有提供总结统计。任何声称描述“当前 MCP 生态系统”的数字,要么是在重述 2025 年 12 月的快照,要么来自第三方进行自己的爬虫,定义了什么算作活跃服务器。无论哪种情况都不是停止引用真实数字的理由——这是一个理由,应该明确说明它描述的时间点,而不是让一个七个月前的数字看起来像是实时的。
一个生产服务器的实际样子
阅读生态系统级别的数据是一回事;实际运行一个服务器又是另一回事,两者不必在“当前”哪个规范版本上达成一致。Scrapeless 自己托管的 MCP 终端 https://api.scrapeless.com/mcp 在今天的握手中仍然协商协议版本 2024-11-05——这是第一版——同时报告 21 种可调用工具,涵盖 Google 搜索和趋势、直接页面抓取,以及构建在同一 抓取 API 表面上的完整云浏览器操作集,Scrapeless 也通过简单的 REST 暴露这些工具。这比服务器在 2025 年年中Scrapeless MCP Server 发布时带来的 19 个工具多了两个——这是真实的、尽管是适度的、在表面积上的增长,而客户端无需做任何改变,这正是协议的向后兼容版本控制所设计的。它还意味着“这个服务器使用哪个 MCP 规范版本”的诚实答案从来不是“当前的任何版本”——而是实际返回的任何东西,那个数字值得从正在运行的实例中读取,而不是从参考帖子中假设。
规范变化与服务器行为之间的这一差距并不是 Scrapeless 的怪癖;在 2026 年中期,它接近中位数案例。一个针对原始握手构建的服务器继续对说相同版本的客户端有效,而版本协商明确旨在让双方达成一致,而不是强制升级。当它停止免费提供服务时就是无状态发布:一个硬编码期望会话 ID 和 initialize 往返的服务器或客户端不会在另一端的对等项丢弃这两个之后继续工作,这使得 2026-07-28 成为协议生命周期中值得在日历上关注的第一个 MCP 版本,而不是当作例行的家务工作来忽视。
集成工作实际上发生的地方
MCP 成为基础设施而不是聊天应用功能的最直接证据并不是下载量——而是同一服务器表面一直出现在不同地方的事实。Scrapeless 的 MCP 覆盖范围已扩大到超过 20 篇已发布的帖子,其中的模式是同一服务器每次都接入不同的主机:一个 LangChain 代理 直接将工具列表绑定到聊天模型,一个 Databricks Mosaic AI 代理 通过 Unity Catalog 连接达到相同的工具,一个 AWS Strands 代理循环 在推理中调用它们,一个 终端编码代理 通过一个配置块增加网页访问,以及 一个单二进制 Rust 代理运行时 通过四行 TOML 块接入相同的工具集。这些集成没有重写服务器。每个都是同样的 21 个工具,以相同的方式发现,绑定到不同框架自己的工具调用约定——这正是一个协议与一堆定制 SDK 的整体推广,在广告宣传的方式下运作,而不是在幻灯片中。
这种广度也正是为什么协议的机制以及工具呼叫和REST端点之间的选择值得与本文分开阅读,而不是在此重新进行辩论:这是对协议现状的市场层面观察,而不是对握手如何工作的重复,或哪个合同适合计划中的管道与自主代理之间的区别。已经记录的五个用例——创作者研究、评审情感、本地线索生成、跨市场定价和个人资料发现——都归结为对同一工具列表的发现然后提取提示,这就是生态系统真正的重心:一个服务器,读取一次,在每个出现MCP客户端的地方重复使用。
增长数据未显示的内容
以上所有都不是将MCP视为一个已解决、静态事物的理由。一些诚实的限制与增长同处于同一画面中:
- 更多连接服务器并不一定更好。 Scrapeless自己对该领域的排名指出,一旦代理同时连接的服务器数量超过五到七个,其工具选择的准确性就会下降——解决方案是根据工作流程的适配选择服务器,而不是根据注册搜索返回的数量。
- 治理现在比代码运行得慢。 一项合规套件和一个十二个月的弃用窗口是一个真正标准所需要的,它们也是一个单一公司发布自己的变更日志时从未需要克服的摩擦。
- “当前规范”并不是固定的。 随着五个活跃的修订版本和第六个即将定稿,唯一可靠的答案是“这个集成使用什么版本”是阅读实际运行中的客户端和服务器的
initialize响应,而不是假设其中任何一个跟踪最新的版本修订日期。
结论
MCP的第一年是一个公司证明协议可以工作的过程。第二年则是一个基础,由该公司的竞争对手支持,证明协议可以在更换持有者、改变五次线格式的情况下生存,并且仍然保持大多数正在运行的集成不变。预计在2026年7月底发布的无状态版本是值得日历记录的第一个修订,正是因为它打破了之前所有修订所保留的一件事。其他一切——服务器数量、客户端列表、一个MCP服务器已被接入代理框架、终端工具和数据平台的二十多种方式——都不如一个静默的协议逐渐成为人们无需考虑的管道,直到管道形状发生改变的那一天。
准备好让MCP发挥作用吗?
加入我们的社区,了解其他开发者是如何将MCP连接的代理集成到生产中的:Discord · Telegram。
在app.scrapeless.com注册以获取免费的MCP运行时,将托管的端点连接到您已经运行的客户端,并在构建之前直接从实时握手中读取当前的工具列表。完整设置详细信息请参见Scrapeless文档,计划定价在定价页面。
常见问题
问:Anthropic放弃了对MCP的控制吗?
是的,在规范变更的治理方面。2025年12月,Anthropic将MCP转移给Agentic AI基金会,这是一个由其与Block和OpenAI共同创建的Linux基金会指导的基金,得到了谷歌、微软、AWS、Cloudflare和彭博社的支持。Anthropic仍然是创始成员,并继续发布自己的MCP客户端和服务器,但协议的规范现在通过基金会的工作组和合规流程进行,而不是仅由Anthropic单独处理。
问:我现有的MCP集成会断开吗?
不是由于迄今为止发货的任何内容——截至2025-11-25的每个修订版本都是按设计向后兼容的,客户端和服务器在连接时协商共享版本。2026-07-28的发布候选版本是个例外:它直接移除了会话-ID头部和initialize/initialized握手,因此一旦该修订版本最终确定,任何硬编码期望其中之一的集成都需要更新,而不是在此之前。
问:现在Scrapeless MCP服务器暴露了多少工具?
对https://api.scrapeless.com/mcp的实时tools/list调用今天返回21个工具——两个搜索工具、三个无状态抓取工具和十六个浏览器自动化工具——比服务器在2025年中期上线时的19个工具有所增加。请从运行中的端点读取数量,而不是任何单一的参考帖子,因为这个数字以前发生过变化。
问:是否有官方统计MCP服务器的数量?
没有实时的统计。Anthropic在2025年12月的捐赠公告中提到有超过10,000个活跃的公共服务器,但那是来自一次公告的过时快照,而不是一个实时总数。官方MCP注册表是为了发现和验证特定服务器而建立的,其自身的接口没有发布汇总计数。
问:代理应该连接到它能找到的每个MCP服务器吗?
不应该。代理在同时连接太多服务器时,工具选择的准确性会下降——实践者的指导通常将有用的上限设定在五到七个之间。根据哪个工作流程是它们独特地解锁的,选择服务器,而不是根据注册搜索返回的数量。
在Scrapeless,我们仅访问公开可用的数据,并严格遵循适用的法律、法规和网站隐私政策。本博客中的内容仅供演示之用,不涉及任何非法或侵权活动。我们对使用本博客或第三方链接中的信息不做任何保证,并免除所有责任。在进行任何抓取活动之前,请咨询您的法律顾问,并审查目标网站的服务条款或获取必要的许可。



