MCP 一周年：2025年11月规范发布

今天，MCP 一岁了。如果你不相信我们，可以查看最初的公告博客文章。很难想象一个小的开源实验——一个为模型提供上下文的协议——在不到十二个月的时间内成为这种情况的事实标准。

但我们不仅在今天达到了第一个周年里程碑——我们还发布了一个全新的 MCP 规范版本。在我们详细了解新内容之前，让我们做一些回顾。

一年回顾

鉴于我们在过去一年中所做的所有更改，感觉十年已经过去了。协议自创建以来已经突飞猛进，并被 大量 开发人员和组织采用。我们从一个小的开源实验发展成为连接数据和应用程序与大语言模型（LLM）的 事实 标准。

但只要有实际的 MCP 服务器可以使用以及能够与之通信的客户端，采用才能增长。在同一时间范围内，我们看到活跃 MCP 服务器的数量从几个实验性服务器增长到 数千个。如果你想到一个场景，很可能就有一个 MCP 服务器。

以下只是你可以 今天 尝试的众多（非常多的）MCP 服务器中的几个：

• Notion 构建了一个 MCP 服务器来帮助你管理笔记。
• Stripe 有一个非常广泛的 MCP 服务器来管理各种支付工作流程。
• GitHub 构建了自己的 MCP 服务器来帮助开发人员自动化他们的工程流程。
• Hugging Face 创建了一个 MCP 服务器，使模型管理和数据集搜索变得轻而易举。
• Postman 构建了他们的 MCP 服务器来帮助自动化 API 测试工作流程。

在 MCP 生态系统中还有更多可以发现！这就是为什么我们今年早些时候推出了 MCP 注册表。它是所有可用 MCP 服务器的中央索引，自 9 月宣布以来已有近 2000 个条目。这与我们在同一个月上线的首批服务器相比增长了 407%。

生态系统正在蓬勃发展，采用正在增长，但支撑这一切的是什么？

社区与治理

MCP 的增长从来不是一个公司的努力。学生、爱好者、初创公司工程师和企业架构师都塑造了协议——提交规范增强提案（SEP）、发布新语言的 SDK、并在生产环境中压力测试我们对 MCP 的一些早期假设。MCP 服务器成为许多产品的主要组成部分，官方和非官方的（甚至有一个 Blender MCP 服务器）。这种有机的采用不是你可以随便想出来的，无论你在开源项目上的抱负有多大。

从一开始，我们就相信一切都关乎 MCP 社区。我们的社区围绕协议聚集在一起，组织诸如 MCP 开发者峰会、MCP之夜、MCP 开发日等活动，并参加其他重要活动，如 AI工程师世界博览会，以分享他们所学和构建的内容。

我们还在 Discord和 GitHub上培养了庞大的贡献者社区，帮助我们调试问题、构建惊人的工具，如 MCP Inspector、提出变更，并协助彼此交付出色的 MCP 体验。这种日常合作使我们走得更远，比任何个人或公司都能做到的。

实际上，MCP 在过去一年的成功完全归功于围绕项目成长的广泛社区——从传输、安全、SDK、文档、示例、扩展到开发工具，所有这些都由社区并为社区显著演进。

为了保持这种步伐可持续，我们花时间思考并整理了治理结构。通过它，社区领导者和 Anthropic 维护者过去和现在继续合作，找出需要解决的问题以及如何将正确的变更纳入规范。我们的维护者团队不是要把守；他们帮助发现问题、对齐解决方案，并将粗略的想法转化为实际的协议更新。

我们的治理方法虽然仍在不断发展，但已被证明是非常有价值的。我们已经能够在不破坏现有实现的情况下更快地推进关键改进。潜在贡献者现在也知道如何通过正式的工作和兴趣组加入（SEP-1302为此奠定了基础）。

尽管这是一个重大改进，但我们知道我们还没有完成。我们还有工作要做，以使这个过程变得更好——提高透明度、决策时间表、更广泛的平台覆盖等等，以帮助生态系统。我们 非常感谢 每一个参与这段旅程并帮助我们在如此短的时间内应对如此多变化的人。

其他人的看法

正如我们在上面指出的，如果没有更广泛的采用者社区，MCP 的成功 是不可能 实现的。我们很高兴该协议在行业内实现了如此多的场景。以下是我们一些关键合作伙伴和支持者的一些想法。

“在短短一年时间里，MCP 已经从一项实验演变为广泛采用的行业标准，凸显了开放合作的影响——这在 GitHub 我们深信不疑。我们社区、客户和我们自己团队的开发人员正在使用我们的 GitHub MCP 服务器、注册表和企业控制（如 MCP 允许列表），在工作流程中释放代理开发的真正好处。我们很高兴继续与更广泛的社区合作，推动这一标准向前发展。”

✦ Mario Rodriguez，首席产品官，GitHub

“我们相信开放标准是代理网络的重要组成部分——帮助模型与工具和平台更无缝地协作。OpenAI 从一开始就为 MCP 生态系统做出贡献，它现在是我们在 OpenAI 构建方式的关键部分，集成在 ChatGPT 和我们的开发者平台中。我们很高兴继续与社区合作，在协议演进时加强它。”

✦ Srinivas Narayanan，B2B 应用首席技术官，OpenAI

“自推出一年以来，MCP 已成为行业内极具影响力的开放标准，” Block 首席技术官 Dhanji R. Prasanna 说。“它迅速转向从现有系统中释放大量价值，使应用 AI 变得像很少有人预料的那样真实。MCP 是构建 Square AI 和 Moneybot 等 AI 驱动解决方案的关键，为客户节省时间并提供强大的洞察力以及我们的内部 AI 系统。它处于 goose 等开源项目的核心，证明开放标准全面推动创新。我们很高兴看到协议和 AI 代理的演进，在企业中释放更高的生产力。”

✦ Dhanji Prasanna，首席技术官，Block

“拥有一个开放源代码协议来释放真正的互操作性，使代理真正有用。在一年时间里，Foundry 从一小部分工具发展到数千个，因为 MCP 让来自 GitHub、Azure 和 M365 的工具在代理运行的任何地方显示出来。它使一次编写到处集成成为现实，并赋予代理在任何系统和任何云上工作的能力，并拥有 Microsoft 的全部支持。”

✦ Asha Sharma，总裁，CoreAI，Microsoft

“MCP 已成为 AI 集成的自然语言——连接从模型发现到推理 API 到聊天应用程序的所有内容。社区使用 Gradio 和我们的 HF-MCP 服务器创建了数千个 MCP 应用程序。拥有一个开放源代码协议来释放这种无缝互操作性，在过去一年中已经改变了游戏规则。”

✦ Julien Chaumond，首席技术官，Hugging Face

“企业 AI 的承诺正在通过 MCP 在以前孤立的系统中统一数据、工具和工作流程的能力来实现。随着代理 AI 更快地被采用，我们很高兴看到身份和授权位于安全框架的核心。通过正式将跨应用访问作为 MCP 授权扩展，组织可以拥有必要的监督和访问控制，以构建安全和开放的 AI 生态系统。”

✦ Harish Peri，高级副总裁兼总经理，AI 安全，Okta

“我们从已接受 MCP 作为将生成式 AI 代理与外部系统连接的标准的客户那里听到了好消息。开放源代码对我们的 AWS 使命非常重要，这就是为什么我们开始并继续为 MCP 做出贡献——在授权、人在环交互和异步执行方面进行改进。我们还将 MCP 构建到 Amazon Bedrock、Kiro、Strands、AgentCore 和 Amazon Quick Suite 等产品中。我们很高兴继续与这个社区合作，使代理互操作性对开发人员来说无缝衔接。”

✦ Swami Sivasubramanian，副总裁，代理 AI，AWS

“在短短一年时间里，模型上下文协议已被证明是连接模型与数据和应用程序的关键标准，解决了阻碍代理发展的碎片化问题。我们很自豪能在 Gemini 上支持 MCP，从我们的模型到 Gemini CLI 等代理软件开发工具，以及提供 Google Maps 和 Google Cloud 数据库的开源 MCP 服务器。这些正是我们自己团队使用的工具，我们很高兴通过继续构建这一基础来庆祝 MCP 的第一个生日。”_

✦ Anna Berenberg，工程研究员，Google Cloud

“MCP 为我们 Obot AI 改变了一切。一个标准的开放协议，用于将 AI 与应用程序、数据和系统连接，这是自 LLM 以来最大的转变。我们全力投入安全的 MCP 管理，因为我们相信它将成为每个组织的基础设施”

✦ Shannon Williams，总裁兼联合创始人，Obot AI；组织者，MCP 开发者峰会

当然，我们不得不提到协调 MCP 社区参与所需的 巨大 努力。我们向我们最多产的一些社区经理询问了 MCP 对他们意味着什么。这是他们的故事。

“作为社区版主和维护者，我不断回到 Donella Meadows 写的一段话：“系统无法被控制，但它们可以被设计和重新设计……我们可以倾听系统告诉我们的东西，并发现其属性和我们的价值观如何协同工作，带来比我们的意愿所能产生的更好的东西。”_

使这一年的增长成为可能的是拥抱混乱作为一种特性，并尽力解决从这种混乱中出现的实际问题，同时为系统和模型的进步和适应留出空间。这种宽松性创造了速度，我在大量的讨论、PR 和问题中看到了这种速度的展开。

作为跨 MCP 存储库合并数百个拉取请求的人，我仍然觉得我勉强跟上了这个速度。我是以最积极的方式这样说的。更好的模式和做法正从大量的贡献以及贡献者社区所代表的经验和专业知识的广度中出现。作为互联网上的一个陌生人，我很感激几乎任何人都可以做出贡献。这包括杰出的维护者，如 Cliff Hall，他提高了审查、测试和给予反馈的标准，以及 Jonathan Hefner，他对文档也做了同样的事情。

正如 Darren Shepard 最近所说：

‘人们认为 MCP 的价值在于协议。价值在于让人们同意并做某事。’_

MCP 给了人们协调和讨论同一件事的理由。帮助实现这种协调和讨论一直很有趣，这也是我一直回来的原因。”_

✦ Ola Hungerford，首席工程师，Nordstrom；MCP 维护者和社区负责人

“在过去一年里，看着 MCP 社区从小到大成长是一种乐趣。无论一个人是独立贡献者、小创业公司的成员，还是大企业的领导者：每个人都有并且继续有发言权和角色要扮演。”_

我认为这主要是因为 MCP 社区从一开始就非常务实和以用例为导向。重点是不过度设计规范，不超前于需求进行设计。当这种理念推动决策时，每个人的声音都很重要。在生产环境中工作的业余爱好者可能会提出实用的意见，大型科技工程师可以将其自信地部署到大量用户中。反之亦然：大型科技公司可以预见安全等关键问题，而业余爱好者可能在设计中忽略了这些问题。"_

这种理念也转化为社区治理。没有官僚主义层级：只是一个轻量级的、仍然分散的决策结构，让我们所有人都按照相同的鼓点行进。我们现在有 58 位维护者 支持 MCP 指导小组中的 9 位核心/首席维护者，Discord 上的 MCP 贡献者社区中有 2,900 多名贡献者，每周有 100 多名新贡献者 加入。我们成功地维护了注册表、Inspector 和一系列 SDK 等长期项目，拥有这个分散的领导者和贡献者群体——并在大约一个季度的时间内成功协作完成了 17（！）个 SEP。"_

这甚至还没有触及数千名 MCP 实施者或数百万 MCP 最终用户。看到经常竞争的 AI 社区围绕一个基础的基础设施聚集在一起，这是令人鼓舞的；我很感激这种合作的意愿，并期待看到我们的第二年将带我们走向何方。"_

✦ Tadas Antanavicius，联合创作者，PulseMCP；MCP 维护者和社区负责人

我们非常感谢我们的合作伙伴和社区帮助我们将协议发展到今天的位置。现在让我们跳进最新的重大发布——MCP 规范的 2025-11-25 版本。

2025年11月发布

MCP 规范的最新发布包含了许多高度预期的功能，这些功能直接来自将 MCP 用于生产场景的社区。人们告诉我们什么不起作用、什么缺失以及哪些小问题阻止他们使用 MCP。我们听取了意见，并与社区专家合作，提供了许多增强功能，使 MCP 更加可扩展和可靠。

支持基于任务的工作流程

SEP： 1686

任务为 MCP 提供了一个新的抽象，用于跟踪 MCP 服务器正在执行的工作。任何请求都可以通过任务进行增强，允许客户端在任务创建后的服务器定义期限内查询其状态并检索其结果。

任务支持多种状态，包括 working、input_required、completed、failed 和 cancelled，允许客户端有效地管理多步骤操作。

此功能启用的一些值得注意的能力：

• 主动轮询：客户端可以随时检查正在进行的工作的状态。
• 结果检索：已完成任务的结果在请求完成后可访问。
• 灵活的生命周期管理：支持 working、input_required、completed、failed 和 cancelled 状态。
• 任务隔离：具有基于会话的访问控制的适当安全边界。

从我们看到的众多 MCP 服务器来看，这对于以下场景特别有帮助：

• 处理数十万个数据点的医疗保健和生命科学数据分析
• 具有复杂多步骤工作流程的企业自动化平台
• 运行数分钟或数小时的代码迁移工具
• 需要从长时间运行的测试套件中流式传输日志的测试执行平台
• 在内部生成多个代理的深度研究工具
• 代理可以并发工作的多代理系统

任务正在作为一项实验性功能推出，这意味着它是核心协议的一部分，但尚未最终确定。基于任务的工作流程是一个难以大规模解决的问题，因此我们希望给规范一些时间在现实场景中进行实战测试。我们将与社区、SDK 开发人员以及客户端和服务器实施者密切合作，以确保正确性。

简化的授权流程

社区在授权方面的首要痛点之一是动态客户端注册（DCR）。需要此功能是因为在 MCP 世界中有无限数量的客户端和服务器，因此标准的客户端预注册并不总是可行的。你不能指望世界上每个 MCP 客户端也与每个授权服务器（AS）都有客户端注册，因此 DCR 被用作解决此问题的方案。你可以在我们的授权指南中了解更多关于当前方法的信息。

然而，要使用 DCR，MCP 服务器开发人员需要依赖一个 AS，该 AS 允许客户端通过公共 API 自行注册。如果 AS 不支持此功能，开发人员现在需要构建一个 OAuth 代理，该代理将手动注册到 AS，并支持动态客户端注册本身，将其自己颁发的令牌映射到下游 AS 颁发的令牌。这是一项复杂、耗时且容易出错的任务，并不能真正解决动态客户端注册的根本问题。

另一种选择是让每个客户或最终用户提供 他们自己的 客户端注册，但这只是用一个复杂任务交换另一个复杂任务。在该模型中，当用户连接到 MCP 服务器时，他们需要通过 IT 团队创建注册，为其分配正确的权限，然后配置 MCP 客户端以使用它。

SEP-991 为此问题引入了一个更优雅的解决方案——使用 OAuth 客户端 ID 元数据文档的基于 URL 的客户端注册（你可能已经看到我们今年早些时候关于此更改的博客文章）。客户端现在可以提供自己的客户端 ID，该 ID 是一个指向客户端管理的 JSON 文档的 URL，该文档描述了客户端的属性。

你可以在 MCP 授权规范的客户端 ID 元数据文档流程部分了解更多信息。

安全和企业功能

随着协议的成熟，我们也不能忽视众多的安全和身份验证/授权需求。MCP 不仅仅是一个业余爱好协议——我们看到它被一些最关键的工作负载采用。这意味着直接需要确保所有数据都受到保护，访问得到适当管理。

与来自整个社区的安全和身份验证专家合作，我们开发了此版本附带的许多增强功能：

• SEP-1024：本地服务器安装的客户端安全要求
• SEP-835：授权规范中的默认范围定义

我们还从行业清楚地听到，内部注册表的发现和管理是 MCP 故事的重要组成部分。在 MCP 注册表团队的帮助下，我们还建立了生态系统愿景，这将帮助企业采用 他们自己的 MCP 注册表，具有自我管理的治理控制和安全覆盖。

要了解有关其他即将到来的授权和安全改进的更多信息，你可以关注规范存储库中的 auth 和 security 标签。

扩展

随着 MCP 的不断发展，我们 不断 听到希望用特定功能扩展协议的开发人员的声音，无论是用于 UI 交互、自定义授权流程还是其他环境特定的逻辑。虽然这些添加可能很有价值，但直接将它们纳入核心规范并不总是从一开始就实用的，特别是当功能尚未达到广泛采用或证明其普遍适用性时。

为了解决这个问题，我们在协议中引入了扩展。扩展是在核心规范之外运行的组件和约定，提供了一种灵活的方式来构建遵循 MCP 约定的场景特定添加，而无需完全集成协议。这种方法允许进行实验和专业化用例，同时保持核心协议的专注和稳定。通过扩展，我们可以更快地移动，并使开发人员能够在功能成为规范的一部分之前 测试 协议功能。

扩展具有以下特点：

• 可选性。服务器和客户端实施者可以选择采用这些扩展。
• 添加性。扩展不会修改或破坏核心协议功能；它们添加新功能，同时保持核心协议行为。
• 可组合性。扩展是模块化的，设计为无冲突地协同工作，允许实施同时采用多个扩展。
• 独立版本控制。扩展遵循核心 MCP 版本控制周期，但可以根据需要采用独立版本控制。

你可能已经看到我们关于 MCP 应用扩展提案的公告。在此规范版本中，我们引入了其他几个应该进一步帮助开发人员的扩展。

授权扩展

为了使 MCP 更适合需要对授权流程进行特定级别控制的环境，我们正式引入了授权扩展的概念（建立在更广泛的 MCP 扩展之上）。与所有其他扩展一样，授权扩展建立在核心协议之上，定义了可由服务器和客户端开发人员实施的其他授权机制。

前两个授权扩展是在社区反馈之后推出的，涉及一些最常用的授权流程：

• SEP-1046：用于机器对机器授权的 OAuth 客户端凭据支持
• SEP-990：MCP OAuth 流程的企业 IdP 策略控制（跨应用访问）。这使用户能够在企业内登录 MCP 客户端一次，并立即获得对每个授权 MCP 服务器的访问，而无需额外的授权提示。

随着我们与社区更紧密地接触，我们预计授权扩展的数量也会增长——毕竟，系统获取和管理凭据的方法不止几种。

URL 模式引导：安全的带外交互

SEP： 1036

直接通过 MCP 客户端向用户询问他们的 API 密钥、令牌或任何其他凭据可能看起来相当可怕。当你需要将 MCP 服务器连接到 其他 API 数组时，这尤其关键，因为传统的客户端到服务器授权流程并不完全适用。直到现在，没有一个好的替代方案——你要么必须信任客户端直接处理用户的凭据，要么实现一堆自定义授权逻辑从头开始使用。

URL 模式引导让你可以在用户的浏览器中将他们发送到适当的 OAuth 流程（或任何凭据获取流程），在那里他们可以安全地进行身份验证，而你的客户端永远不会看到输入的凭据。凭据然后直接由服务器管理，客户端只需要担心自己对服务器的授权流程。

我们很高兴除了我们已有的功能（如引导）之外还包括这个功能，因为它允许协议用于一些很难正确完成的场景，例如：

• 安全凭据收集：API 密钥和密码从不通过 MCP 客户端传输
• 外部 OAuth 流程：MCP 服务器有一条途径获得第三方授权，而无需令牌传递
• 支付处理：现在可以在客户端之外使用具有安全浏览器上下文的 PCI 合规金融交易

服务器所做的只是提供一个 URL，客户端将为该 URL 提供便利。当用户在浏览器中完成流程时，服务器将 直接 获得必要的令牌，避免与客户端共享凭据或其他手动步骤。简单！

使用工具的采样：代理服务器

SEP： 1577

此功能允许 MCP 服务器使用客户端的令牌运行自己的代理循环（当然仍在用户的控制下），并降低客户端实现的复杂性，上下文支持变得显式可选。这是由于采样不支持工具调用，尽管它是现代代理行为的基石。随着新的规范发布，这不再是一个差距！

既然可以使用工具进行采样，这也意味着以下所有场景都是可能的！

• 采样请求中的工具调用：服务器现在可以包含工具定义并指定工具选择行为
• 服务器端代理循环：服务器可以实现复杂的多步推理
• 并行工具调用：支持并发工具执行
• 更好的上下文控制：模糊的 includeContext 参数被软弃用，取而代之的是显式功能声明

例如，研究服务器可以在内部生成多个代理，协调它们的工作，并使用标准的 MCP 原语交付一致的结果，而无需自定义脚手架或复杂的编排代码。

开发体验改进

MCP 的核心原则之一是 简单性——我们要使开发和集成体验尽可能直观和容易。为了帮助实现这一点，最新的规范版本还添加了一些小的更改，有助于使协议对开发人员来说更容易使用。

• SEP-986：工具名称的标准化格式
• SEP-1319：从 RPC 方法定义中解耦请求负载
• SEP-1699：通过服务器端断开进行 SSE 轮询，以更好地管理连接
• SEP-1309：改进 SDK 的规范版本管理

展望未来

此版本向后兼容。你现有的实现继续工作。当你需要新功能时，它们就在那里。

展望未来，我们对 MCP 的下一步感到兴奋。协议正在进入一个新阶段，不仅将 LLM 连接到数据，而且启用全新的 AI 驱动应用程序类别。

我们已经看到了这种转变的早期信号。开发人员正在构建跨数十个 MCP 服务器协调的多代理系统。企业团队正在大规模部署 MCP，具有复杂的安全和治理控制。初创公司正在推出以 MCP 为核心架构模式的产品。MCP 服务器甚至被转换为可执行代码，以创建沙盒化的代理工作流程。

前面的路线图包括在可靠性和可观察性方面的更深入工作，使调试和监控复杂的 MCP 部署变得更容易。我们正在探索更好的服务器组合模式，允许你通过组合更简单的构建块来构建复杂的功能。我们继续完善安全模型，以满足最苛刻的企业环境的需求。

最让我们兴奋的不是 我们 计划构建什么，而是 我们的社区 将构建什么。每周我们都会看到以新颖方式设计、开发和部署的 MCP 服务器。Discord 中的每一次对话都会揭示新的用例和模式。协议已成为 AI 创新的画布，我们无法独自填充它。

下一年的 MCP 将受到更多生产部署、更多真实世界反馈的影响，并由全球数千名开发人员的创造力放大。我们在这里支持这种增长，确保协议有思想地演进，并随着规模扩大保持 MCP 的稳定、安全和简单。

入门

要开始使用最新 MCP 规范发布中的所有新功能，请查看以下资源：

• 阅读更新日志：所有主要变更都在我们的关键变更文档中捕获
• 了解我们的文档：MCP 文档是协议所有内部运作的真实来源
• 加入讨论：如果你想做出贡献或与其他 MCP 维护者互动，请从我们的 GitHub 存储库和 Discord开始