2025 年 12 月 16 日发布的 Registry v1.4.0 版本 ，不仅是技术规格的一次迭代，更是整个协议迈向成熟的重要里程碑。该版本引入了严格的 2025-12-11 模式定义 ，正式确立了对 streamable-http 传输层的原生支持，并重构了发布者验证流程。与此同时，MCP 的治理结构发生了历史性变革------Anthropic 将该协议捐赠给 Linux 基金会旗下新成立的 Agentic AI 基金会 (AAIF)。这一举措有效地消除了企业采用该协议的供应商锁定顾虑，促成了包括 AWS、Google Cloud、Cisco 和 Microsoft 在内的行业巨头对该标准的全面拥抱。
要理解 v1.4.0 版本的技术意义，必须首先审视 MCP 旨在解决的核心架构挑战。在 MCP 出现之前，将 LLM 连接到外部数据源（如 PostgreSQL 数据库、GitHub 仓库或 Notion 文档）需要针对每个模型提供商编写定制的集成代码。
在前 MCP 时代，开发者面临着所谓的"N x M"集成困境。假设有 N 个主流 AI 模型（如 Claude 3.5, GPT-4o, Gemini 1.5）和 M 个外部工具或数据源。若要实现互操作性，理论上需要维护 N * M 个独立的连接器。这种架构不仅脆弱，而且极难扩展。一旦数据源的 API 发生变更，或者开发者决定切换 AI 模型，所有的集成工作都需要推倒重来 。
MCP 通过引入标准化的中间层，将这一复杂度降低为 N + M。
-
标准化接口： MCP 定义了一套通用的 JSON-RPC 2.0 消息格式，使得任何兼容 MCP 的主机（Host）都可以直接与任何 MCP 服务器（Server）通信，而无需了解后者的底层实现细节。
-
通用连接器： 这意味着一个针对 Google Drive 开发的 MCP 服务器，可以同时被 Claude Desktop、Cursor IDE、VS Code 甚至定制的企业 AI 代理所使用，真正实现了"一次编写，到处运行"的愿景。
随着 v1.4.0 的发布，MCP 的组件体系已高度成熟，形成了清晰的四层架构：
-
MCP Host（主机）：
这是 AI 模型的运行环境，也是集成的发起端。典型的主机包括 Claude Desktop、Cursor、Windsurf 以及各类企业级 AI 网关。主机负责管理与用户的交互上下文，并将用户的自然语言意图转化为对 MCP 工具的调用请求 。 -
MCP Client（客户端）：
嵌入在主机内部的协议实现层。它负责与服务器建立 1:1 的连接，处理协议握手、能力协商（Capabilities Negotiation）以及消息的序列化与反序列化。在 v1.4.0 生态中，客户端承担了更多安全职责，如 OAuth 2.0 令牌管理和权限范围（Scope）控制 。 -
MCP Server（服务器）：
这是生态系统的核心资产。服务器是一个轻量级的网关程序，它封装了特定的数据源或工具，并通过 MCP 协议暴露给外界。服务器可以极其简单（如一个只读的 SQLite 查询器），也可以极其复杂（如一个具有推理能力的 GitHub 运维代理）。v1.4.0 版本极大地增强了服务器的元数据定义能力，使其能够更精准地向注册表描述自身行为。 -
Transport Layer（传输层）：
通信的管道。
-
Stdio（标准输入输出）： 在 MCP 早期主要用于本地开发，通过进程间通信（IPC）实现极其低延迟的交互，且天然隔离网络风险。
-
SSE (Server-Sent Events) over HTTP: 随着 v1.4.0 对远程连接支持的完善，基于 HTTP 的 SSE 传输已成为主流。它允许服务器独立部署在云端（如 Docker 容器或 Serverless 函数中），并通过标准 URL 被远程客户端访问。这种模式是企业级"远程 MCP"部署的基石。
2025 年 12 月 16 日，modelcontextprotocol/registry 仓库发布了 v1.4.0 版本。这一版本不仅仅是代码的更新，更是对整个注册表服务（Registry Service）数据模型的一次重构，旨在适应日益复杂的分布式生态系统。
v1.4.0 最具破坏性但也最具建设性的变更是强制采用了新的 server.json 模式定义，版本号为 2025-12-11。server.json 文件是 MCP 服务器在注册表中的"身份证"，它定义了服务器的名称、描述、安装方式及版本信息。
在此之前的版本（如 2025-10-17）中，模式定义相对宽松，允许许多非标准字段存在，且对远程连接的定义不够严谨。新的模式带来了以下关键改进：
1 、严格的传输层定义：新模式显式地标准化了 remotes 字段中 streamable-http 的配置方式。在旧版本中，远程服务器的配置往往依赖于特定客户端的约定俗成。而在 v1.4.0 中，server.json 必须严格遵循以下结构来声明远程能力 。这种严格的类型定义（Type Safety）确保了无论是 VS Code 还是 Claude Desktop，在解析远程服务器时都能准确识别连接方式和认证需求，消除了因配置模糊导致的连接失败。
2 、移除 status 字段与动态健康检查：v1.4.0 移除了 server.json 中的 status 字段 。此前，开发者需要手动在 JSON 文件中标记服务器状态（如 "beta", "stable"）。这种静态标记往往与实际运行状态脱节。新版本的设计理念是：健康状态应当是动态监测的结果，而非静态声明。 注册表服务现在通过内置的验证逻辑（Validation Logic）定期轮询服务器，根据实际响应情况决定其在索引中的可见性。这显著提高了注册表数据的可信度，防止用户安装已停摆的"僵尸服务器"。
3、 版本一致性强制：新模式引入了严格的版本一致性检查。server.json 中的 version 字段现在必须与 Git Tag 或包管理器（NPM/PyPI）中的版本号严格匹配 。如果注册表检测到版本号不一致（例如 server.json 声明了 v2.0.0 但 Git Tag 只有 v1.9.0），发布流程将自动失败。这一机制有效地杜绝了"幽灵版本"问题，确保用户拉取的代码与注册表描述完全一致。
伴随注册表更新，官方发布工具 mcp-publisher 也同步升级至 v1.4.0 17。该 CLI 工具是开发者与 MCP 注册表交互的主要接口。
v1.4.0 版本的发布器深度集成了 OpenID Connect (OIDC) 协议，特别是针对 GitHub Actions 的环境。这意味着开发者不再需要生成和维护长效的 API 密钥（Long-lived Secrets）来发布更新。
通过配置 GitHub Action Workflow，mcp-publisher 可以利用临时的 OIDC 令牌向注册表证明身份。注册表服务端会验证该令牌是否由合法的 GitHub 仓库签发，从而授权发布。这极大地提升了供应链的安全性，因为即便发布脚本泄露，攻击者也无法在外部环境伪造有效的 OIDC 令牌 。
新版工具引入了更强大的 check 和 init 命令。
-
mcp-publisher init：能够智能分析当前目录结构（识别是 Node.js 项目还是 Python 项目），自动生成符合 2025-12-11 标准的 server.json 模板。
-
mcp-publisher check（或集成在发布流程中的验证）：在上传前对 JSON 文件进行本地 Schema 校验。这解决了以往提交后才发现格式错误导致发布失败的痛点，缩短了反馈循环 。
如果说 Registry v1.4.0 是技术的升级，那么 Agentic AI 基金会 (AAIF) 的成立则是 MCP 走向行业标准的政治宣言。2025 年 12 月 9 日，Anthropic 正式宣布将 MCP 项目及其相关资产捐赠给 Linux 基金会旗下新成立的 AAIF。
在 2024 年至 2025 年间，AI 领域被视为各大巨头（OpenAI, Google, Anthropic, Meta）争夺生态主导权的战场。如果 MCP 始终由 Anthropic 一家公司控制，其他竞争对手（尤其是 OpenAI 和 Google）将很难毫无保留地采纳这一标准，因为这涉及到生态锁定的风险。
通过将 MCP 移交给 Linux 基金会这一中立机构，Anthropic 效仿了 Google 捐赠 Kubernetes 给 CNCF 的成功路径。这一举措产生了立竿见影的效果：
-
消除信任障碍： AWS 和 Google Cloud 随即宣布加强对 MCP 的支持，因为标准不再属于某个单一竞争对手。
-
统一战线： OpenAI 不仅加入了基金会，还捐赠了其 AGENTS.md 标准。这意味着行业正在走向融合------OpenAI 的代理定义规范与 MCP 的工具连接规范将在 AAIF 的框架下进行整合，形成一套完整的"代理技术栈"。