设计原则

这些原则指导着我们如何评估协议提案、权衡取舍并推动 MCP 演进。它们反映了在构建和维护本项目过程中获得的经验教训，旨在为社区在制定规范增强提案（SEP）和扩展时提供指导。

​

收敛优先于选择

在 MCP 中，解决一个问题应当只有一种方式。与其支持多种会使生态碎片化的做法，我们选择一条经过精心设计的单一路径——宁可在前期承受更艰难的抉择，以交付一个更具凝聚力的协议。 扩展是收敛受到检验的地方；规范则是收敛被最终确定的地方。

​

可组合优先于专用

MCP 提供基础性原语：资源、工具和提示。对于可以由这些既有构件构造出来的用例，我们不会为其添加协议特性。这使得协议表面积保持精简，实现保持简单。 当有人问 MCP 为何不直接支持某个特性时，答案通常是它可以由 MCP 已经提供的东西构建出来。诸如 MCP Apps 和 Tasks 之类的扩展捕捉了由此涌现的模式。

​

互操作优先于优化

MCP 运行在成熟度差异极大的各种客户端、服务器和模型之上。相比那些只有在每个参与方都同样有能力时才起作用的特性，我们更青睐能够优雅降级的特性。能力协商将这一点落到实处：参与方声明各自支持什么，协议随之适配，而非假设。

​

稳定优先于速度

向一个像 MCP 这样被广泛采用的协议中添加内容很容易。从中移除则几乎不可能。每一次添加都是一项永久性的承诺，也是客户端实现者需要支持的一份成本。我们谨慎推进，因为深知今天的”不”仍留着门缝，而”是”则永远地关上了门。 习惯于快速交付的贡献者可能会觉得这种节奏令人沮丧，但可持续的标准需要可持续的决策。我们为数十年而优化，而非为季度。

​

能力优先于弥补

模型改进的速度快于协议演进的速度。我们避免为规避那些很可能是暂时性的局限而添加永久性结构——局限会消退，复杂性却会留存。 这并非无视当下现实的许可。较弱的模型所依赖、而较强的模型会忽略的可选上下文，其成本为零。但当一个提案主要因为当前模型在缺少它时表现挣扎而存在时，我们会追问：在我们能卸下这份负担之前，模型是否会先成长到不再需要它。

​

演示优先于论辩

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

​

务实优先于纯粹

MCP 为了采用度和可用性而作出务实的取舍。我们不会以牺牲现实世界效用为代价去追求理论上的优雅。当一个”正确”的设计给实现者带来摩擦时，我们会考量一个”够好”的设计是否更能服务于生态。这意味着接受一些不一致、一些历史遗留，以及一些若有后见之明我们本会作出不同选择的决定。

​

标准化优先于创新

MCP 将那些已经证明有价值的模式标准化。我们寻找在多个实现之间行之有效的约定并将其成文，而不是发明新范式再指望它们被采纳。 我们鼓励将 MCP 扩展作为一种试验新模式的方式，这些模式最终可能引向标准化。