SEP-1319：将请求载荷与 RPC 方法定义解耦

社区译文；来源： MCP 29affa6b

摘要

本 SEP 提议对模型上下文协议（MCP）规范进行结构重构。核心变更是把请求载荷 （例如 CallToolRequest）定义为独立定义，并让 RPC 方法定义引用这些模型。 这将数据载荷定义与传输该载荷的远程过程定义解耦，使规范更清晰、更模块化，也更易于维护。

动机

当前 MCP 规范将请求的数据载荷与传输它的 JSON-RPC 方法紧密耦合。这种设计带来若干挑战：

• 清晰度降低： 开发者仅为理解所交换的核心数据，就必须在脑中解析 JSON-RPC 传输结构。 这增加了认知负担，使规范难以阅读，也更难正确实现。
• 可维护性受限： 内联定义数据结构会阻止它们在不同方法之间复用，造成冗余， 并使未来的协议更新更复杂、更容易出错。
• 与 JSON-RPC 紧密耦合： 最关键的是，这种与 JSON-RPC 的紧密耦合，是为其他传输协议定义 binding 的主要障碍。要支持 gRPC 等传输（这目前是社区经常提出的需求）， 就需要以传输无关的方式定义其请求和响应消息。当前结构使这在实践中无法实现。

通过重构规范，将数据模型（“传输什么”）与 RPC 方法（“如何传输”）分开，本提案将形成更清晰、 更模块化的规范。此项变更会立即改善开发者体验，更重要的是，它为 MCP 将来跨多种传输演进铺平道路。

规范

本提案引入以下原则：所有用作 RPC 方法参数（params）或结果（result）的数据结构，都应定义为独立的、 具名的 schema。RPC 方法定义随后通过引用使用这些 schema。

当前方式（内联定义）：

RPC 方法定义包含其参数和结果的完整结构。

export interface CallToolRequest extends Request {
  method: "tools/call";
  params: {
    name: string;
    arguments?: { [key: string]: unknown };
  };
}

提议方式（解耦定义）：

首先，将请求和响应的数据模型定义为顶层 schema。

/**
 * Parameters for a `tools/call` request.
 *
 * @category tools/call
 */
export interface CallToolRequestParams extends RequestParams {
  name: string;
  arguments?: { [key: string]: unknown };
}

然后，RPC 方法定义会简化很多，只需引用这些模型。

export interface CallToolRequest extends Request {
  method: "tools/call";
  params: CallToolRequestParams;
}

设计理由

选择所提方案，即把载荷定义与 RPC 方法分离，是因为这是实现动机中所述目标最直接、干扰最小的路径。

这种方式在两个不同关注点之间建立了清晰的架构边界：

1. 数据层： 与传输无关的载荷定义（例如 CallToolRequestParams），表示所交换的核心信息。
2. 传输层： 协议专属的包装（例如 JSON-RPC CallToolRequest 对象），描述数据如何发送。

这种架构分离优于为每种传输维护彼此独立的并行规范（例如一套用于 JSON-RPC，另一套用于 gRPC）， 后者会带来大量维护开销和不一致风险。

关键在于，此设计重构的是规范文档本身，同时有意让线上传输格式保持不变。因此，本提案完全向后兼容， 现有的合规客户端和服务器无需做任何更改。简而言之，这项变更是一项战略性的基础改进， 既支持未来发展，也不会让当前生态承担代价。

向后兼容性

对于现有实现，本提案是一项非破坏性变更。它重构的是_规范文档本身_，不会改变协议消息的线上 JSON 格式。 符合旧规范结构的客户端或服务器仍将符合新规范，因为最终生成的 JSON 载荷完全相同。

主要影响对象是阅读规范的开发者，以及解析规范以生成代码或文档的工具。