> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.zhcndoc.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SEP-1319: 将请求负载与 RPC 方法定义解耦

> 将请求负载与 RPC 方法定义解耦

<div className="flex items-center gap-2 mb-4">
  <Badge color="green" shape="pill">
    最终版
  </Badge>

  <Badge color="gray" shape="pill">
    标准轨道
  </Badge>
</div>

| 字段       | 值                                                                               |
| -------- | ------------------------------------------------------------------------------- |
| **SEP**  | 1319                                                                            |
| **标题**   | 将请求负载与 RPC 方法定义解耦                                                               |
| **状态**   | 最终版                                                                             |
| **类型**   | 标准轨道                                                                            |
| **创建日期** | 2025-08-08                                                                      |
| **作者**   | [@kurtisvg](https://github.com/kurtisvg)                                        |
| **赞助方**  | 无                                                                               |
| **PR**   | [#1319](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1319) |

***

## 摘要

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

## 动机

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

* **清晰度降低：** 它迫使开发者在理解交换的核心数据之前，必须在心理上解析 JSON-RPC 传输结构。这增加了认知负荷，使得规范难以阅读和正确实现。
* **阻碍可维护性：** 内联定义数据结构阻止了它们在不同方法间的复用，导致冗余，并使协议的未来更新更加复杂且容易出错。
* **与 JSON-RPC 紧密耦合：** 最关键的是，这种与 JSON-RPC 的紧密耦合是为其他传输协议定义绑定的主要障碍。为了支持像 **gRPC** 这样的传输（这是目前 [社区热门需求](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/966)），需要对其请求和响应消息进行与传输无关的定义。当前的结构使得这实际上不可能。

通过重构规范以分离数据模型（"什么"）和 RPC 方法（"如何"），本提议将创建一个更清晰、更模块化的规范。这一更改将立即改善开发者体验，最重要的是，为 MCP 跨多种传输协议的未来演进铺平道路。

## 规范

该提议引入了以下原则：所有用作 RPC 方法参数 (params) 或结果 (result) 的数据结构应定义为独立的、命名的模式。RPC 方法定义将随后使用对这些模式的引用。

### 当前方法（内联定义）：

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

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

### 提议方法（解耦定义）：

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

```ts theme={null}
/**
 * `tools/call` 请求的参数。
 *
 * @category tools/call
 */
export interface CallToolRequestParams extends RequestParams {
  name: string;
  arguments?: { [key: string]: unknown };
}
```

然后，RPC 方法定义变得简单得多，仅引用这些模型。

```ts theme={null}
export interface CallToolRequest extends Request {
  method: "tools/call";
  params: CallToolRequestParams;
}
```

## 理由

所选的提议解决方案——将负载定义与 RPC 方法分离——是实现动机中概述目标的最直接且非破坏性的路径。

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

1. **数据层：** 与传输无关的负载定义（例如 `CallToolRequestParams`），代表交换的核心信息。
2. **传输层：** 特定于协议的包装器（例如 JSON-RPC `CallToolRequest` 对象），描述数据如何发送。

这种架构分离优于为每种传输维护单独的并行规范（例如，一个用于 JSON-RPC，另一个用于 gRPC），这将引入巨大的维护开销并有不一致的风险。

至关重要的是，此设计重构了规范文档本身，但有意**保持网络传输格式不变**。这使得提议完全向后兼容，现有的合规客户端和服务器无需任何更改。简而言之，此更改是一项战略性的基础改进，能够在不惩罚当前生态系统的情况下启用未来增长。

## 向后兼容性

本提议对现有实现来说是**非破坏性变更**。它是对\_规范文档本身\_的重构，并不改变协议消息的网络传输 JSON 格式。符合旧规范结构的客户端或服务器将仍然符合新规范，因为生成的 JSON 负载是相同的。

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