设计原则

指导 Model Context Protocol 开发的核心设计原则。

这些原则指导我们如何评估协议提案、权衡取舍以及演进 MCP。它们反映了在构建和维护该项目过程中积累的经验。在制定规范增强提案（SEP）和扩展时，它们是社区制定提案的指引，也是为社区服务的指引。

趋同而非选择

在 MCP 中，解决一个问题应当只有一种方式。与其支持多种会割裂生态的方案，我们选择一条精心设计的单一路径——在前期接受更艰难的决策，以交付一个更内聚的协议。

扩展是检验趋同的地方；规范则是将其确立下来的地方。

MCP 提供基础原语：资源、工具和提示模板。对于能够用这些现有构建块搭建出来的用例，我们不会新增协议特性。这使协议的表面积保持精简，实现保持简单。

当有人问为什么 MCP 不直接支持某个特性时，答案通常是它可以由 MCP 已有的能力构建出来。像 MCP Apps 和 Tasks 这样的扩展，正是对涌现出的模式的沉淀。

MCP 运行在能力差异极大的客户端、服务端和模型之上。我们更青睐能够优雅降级的特性，而非只有在所有参与者能力相当时才可用的特性。能力协商让这一点变得具体：参与者声明自己支持什么，协议据此适配，而不是凭空假设。

向一个像 MCP 这样被广泛采用的协议添加内容是容易的。从中移除则几乎不可能。每一次添加都是永久的承诺，也是客户端实现者需要承担的成本。我们审慎推进，深知今天的"不"仍留有回旋余地，而"是"则会永远关上这扇门。

习惯于快速交付的贡献者可能会觉得这种节奏令人沮丧，但可持续的标准需要可持续的决策方式。我们以数十年为尺度优化，而非以季度为尺度。

模型的进步快于协议的演进。我们避免为了绕开可能只是暂时的局限而添加永久性的结构——局限会消退，而复杂性会留存。

这并非无视当下现实的借口。较弱的模型所依赖、较强的模型所忽略的可选上下文，其成本为零。但当一项提案之所以存在，主要是因为当前模型离开它就难以应对时，我们会问：在我们能够卸下这份负担之前，模型是否已经成长到不再需要它。

MCP 重视可运行的实现，而非理论上的争论。在评估提案时，我们优先考虑来自真实使用的证据，而非假设性的论证。我们鼓励贡献者去制作原型、做实验、做演示，而不是靠委员会来设计。实现能揭示讨论所无法揭示的东西。

MCP 为了采用率和可用性做出务实的权衡。我们不会以牺牲现实效用为代价去追求理论上的优雅。当一种"正确"的设计给实现者带来摩擦时，我们会考虑一种"足够好"的设计是否更能服务生态。这意味着接受一些不一致、一些历史遗留的偶然，以及一些事后看来我们可能会做出不同选择的决策。

MCP 将已被证明有价值的模式标准化。我们寻找在多个实现中都行之有效的约定并将其编纂成规范，而不是发明新范式并寄望于它们被采纳。

我们鼓励使用 MCP 扩展来试验新的模式，这些模式最终可能走向标准化。