什么是 MCP：从工具调用到标准化上下文协议

1. 消息层：JSON-RPC 2.0#

MCP 的请求、响应和通知使用 JSON-RPC 2.0 表达。一个最简单的请求类似这样：

1
{
2
  "jsonrpc": "2.0",
3
  "id": 1,
4
  "method": "tools/list",
5
  "params": {}
6
}

这里的 tools/list 是 MCP 定义的方法名，id 用于把响应和请求对应起来。通知没有 id，也不需要响应。

JSON-RPC 只解决“消息长什么样、如何对应请求和响应”，它不负责 HTTP、授权、工具审批或模型推理。

2. 生命周期和版本协商#

客户端和服务端需要协商协议版本以及双方支持的能力。早期和当前不同日期版本的生命周期细节可能不同：较早版本通过 initialize 请求完成初始化；较新的规范强调每个请求携带必要的元数据，并保留对旧初始化模型的兼容策略。

这意味着 MCP 的版本号不能被当作普通的产品版本号。MCP 规范使用日期版本，例如 2025-06-18、2025-11-25 和 2026-07-28。客户端和服务端应该在连接时明确协商或声明版本，不要把某个 SDK 支持的字段直接当成所有 MCP Server 都支持。

能力也需要协商。服务端可以声明自己支持：

• resources：可读取的上下文和数据；
• prompts：可复用的提示模板；
• tools：可调用的操作；
• logging、进度、取消、补全等辅助能力。

客户端也可以声明自己支持的能力，例如 roots、sampling、elicitation 等。MCP 只规定能力如何表达和交互，不代表每个客户端都必须实现所有能力。

3. 传输层：stdio 和 Streamable HTTP#

当前 MCP 定义的主要标准传输有两种。

1
Host / MCP Client
2
        | stdin/stdout
3
MCP Server 子进程

1
https://mcp.example.com/mcp

4. 服务能力层：resources、prompts 和 tools#

可以把它们分别理解成：资料、模板、动作。以“退款助手”为例：订单详情可以作为 resource 提供给模型阅读；客服可以选择一个“退款原因分析” prompt；模型判断需要查询订单时调用 query_order，用户确认后再调用 create_refund 这个 tool。

这也对应 MCP 文档中常见的控制边界：resources 偏向 application-controlled，由 Host 或用户决定何时加载；prompts 偏向 user-controlled，由用户选择或显式触发；tools 偏向 model-controlled，由模型根据描述决定是否提出调用。它们描述的是交互控制权，不是最终的安全权限；真正的权限判断仍然必须在 MCP Server 执行时完成。

5. 数据结构：JSON Schema#

MCP 工具通过 inputSchema 描述参数，通常使用 JSON Schema。这样客户端可以在把工具交给模型前，知道工具叫什么、有什么说明、需要哪些参数，以及参数是什么类型。

例如：

1
{
2
  "name": "query_order",
3
  "description": "查询当前用户有权限查看的订单状态",
4
  "inputSchema": {
5
    "type": "object",
6
    "properties": {
7
      "orderNo": {
8
        "type": "string",
9
        "description": "业务订单号"
10
      }
11
    },
12
    "required": ["orderNo"]
13
  }
14
}

Schema 解决的是参数契约和校验问题，不能替代服务端的权限校验。即使模型传入的参数符合 JSON Schema，服务端仍然必须检查用户是否有权查询这个订单。

6. 授权层：OAuth 相关标准#

MCP 并没有重新发明一套登录协议。当前 HTTP 授权规范主要组合了这些标准：

这里的“标准”有两个边界需要注意：OAuth 2.1 在 MCP 当前规范中仍以 IETF 草案形式被引用；Client ID Metadata Document 也仍是草案。实现时应以目标 MCP Server 实际支持的规范版本和元数据为准。

以前的 tools 通常是什么#

在很多模型 API 中，应用会把函数定义直接放到一次模型请求中：

1
{
2
  "type": "function",
3
  "function": {
4
    "name": "query_order",
5
    "description": "查询订单",
6
    "parameters": {
7
      "type": "object"
8
    }
9
  }
10
}

模型返回一个函数调用意图，应用自己执行函数，再把执行结果放回下一轮模型请求。这个 tool 的生命周期、执行进程、鉴权、错误重试和结果格式都由应用自行约定。

MCP tool 增加了什么#

MCP 把下面这些事情标准化了：

1. 服务发现：客户端可以通过 tools/list 获取当前可用工具，而不是把所有工具硬编码在 Host 中；
2. 能力变更：服务端可以通知工具列表发生变化，客户端重新拉取列表；
3. 调用协议：使用 tools/call，传递工具名称和参数，返回统一的内容结构；
4. 跨进程和跨网络：同一套工具契约可以通过 stdio 或 HTTP 提供；
5. 上下文组合：工具可以和 resources、prompts 放在同一个服务能力模型中；
6. 权限边界：远程服务可以根据请求中的访问令牌，只返回当前授权允许的工具，并在调用时再次校验权限。

可以把两者的关系写成这样：

1
模型 API 的 tool = 一次模型调用中的函数描述
2
MCP tool       = 通过 MCP Server 提供、可发现、可调用的远端能力

MCP tool 最终仍然可能被 Host 转换成模型 API 所需的 tool schema。因此，MCP 并没有替代模型厂商的 tool calling；它解决的是“工具从哪里来、如何被多个 Host 复用、如何统一连接和治理”。

还有一个容易误解的点：MCP 规范不会替 Agent 决定什么时候调用工具。模型是否选择某个工具、Host 是否要求人工确认、Agent Runtime 如何重试和保存任务状态，仍然是应用层的职责。MCP 也不是完整的 Agent Runtime，它不负责模型循环、记忆、工作流编排、审批中心或业务幂等。

第一步：MCP Server 返回 401 和 WWW-Authenticate#

客户端先向配置好的 MCP endpoint 发起请求。如果没有访问令牌，服务端返回类似：

1
HTTP/1.1 401 Unauthorized
2
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

这里的 resource_metadata 不是登录地址，而是“受保护资源元数据”的地址。客户端应该解析 WWW-Authenticate，不能把它当作普通字符串拼接。

如果服务端没有在响应头中给出地址，客户端还可以按 RFC 9728 规则尝试 well-known 地址。MCP endpoint 是 https://mcp.example.com/mcp 时，常见顺序是：

1
https://mcp.example.com/.well-known/oauth-protected-resource/mcp
2
https://mcp.example.com/.well-known/oauth-protected-resource

第二步：读取 Protected Resource Metadata#

元数据文档大致会包含：

1
{
2
  "resource": "https://mcp.example.com/mcp",
3
  "authorization_servers": [
4
    "https://auth.example.com"
5
  ],
6
  "scopes_supported": [
7
    "orders:read",
8
    "tickets:write"
9
  ]
10
}

authorization_servers 告诉客户端应该向哪个授权服务器继续发现。一个 MCP Server 可以声明多个授权服务器，客户端需要根据自己的用户、组织和支持能力选择其中一个，并且不能把在授权服务器 A 获得的 client credentials 或 token 拿去授权服务器 B 使用。

第三步：读取 Authorization Server Metadata#

客户端拿到授权服务器 issuer 后，按照 RFC 8414 和 OIDC Discovery 的规则读取授权服务器元数据。

没有路径的 issuer，例如：

1
https://auth.example.com

客户端会尝试：

1
https://auth.example.com/.well-known/oauth-authorization-server
2
https://auth.example.com/.well-known/openid-configuration

如果 issuer 带路径，例如 https://auth.example.com/tenant-a，则还要遵循规范规定的路径插入或路径追加规则。元数据中会给出类似字段：

1
{
2
  "issuer": "https://auth.example.com",
3
  "authorization_endpoint": "https://auth.example.com/oauth2/authorize",
4
  "token_endpoint": "https://auth.example.com/oauth2/token",
5
  "registration_endpoint": "https://auth.example.com/oauth2/register",
6
  "code_challenge_methods_supported": ["S256"]
7
}

这一步才得到真正的 authorization_endpoint。所以 Agent 不是猜测跳转地址，而是从经过校验的授权服务器元数据中读取地址。客户端还必须校验返回文档中的 issuer 是否与它用于构造发现地址的 issuer 完全一致，发现文档不匹配时不能继续使用。

第四步：确定 OAuth client_id#

在跳转前，客户端还需要有 client_id。当前 MCP 规范支持三种方式，优先级大致如下：

1. 预注册：服务提供方提前给客户端分配 client_id；
2. Client ID Metadata Document：客户端使用一个 HTTPS URL 作为 client_id，授权服务器访问这个 URL，读取客户端名称和 redirect URI 等元数据；
3. Dynamic Client Registration：通过 RFC 7591 的注册端点动态注册。当前规范把它主要作为旧服务的兼容方案；
4. 如果上述方式都不支持，由用户在客户端配置中输入服务方提供的 client 信息。

Client ID Metadata Document 可能长这样：

1
{
2
  "client_id": "https://client.example.com/oauth/mcp-client.json",
3
  "client_name": "Example MCP Client",
4
  "redirect_uris": [
5
    "http://127.0.0.1:3000/callback"
6
  ],
7
  "grant_types": ["authorization_code"],
8
  "response_types": ["code"],
9
  "token_endpoint_auth_method": "none"
10
}

这不是把 client secret 放到 MCP Server 上，而是让授权服务器能够发现和校验一个公共客户端的元数据。桌面应用和 CLI 常见的是本机 loopback redirect URI；授权服务器仍然必须严格校验 redirect URI，不能接受客户端任意传入的回调地址。

第五步：使用 PKCE 打开授权页面#

客户端生成一次性的 code_verifier，计算出 code_challenge，然后拼出授权请求。核心参数包括：

1
https://auth.example.com/oauth2/authorize
2
  ?response_type=code
3
  &client_id=https%3A%2F%2Fclient.example.com%2Foauth%2Fmcp-client.json
4
  &redirect_uri=http%3A%2F%2F127.0.0.1%3A3000%2Fcallback
5
  &code_challenge=<base64url-sha256-of-code-verifier>
6
  &code_challenge_method=S256
7
  &state=<random-state>
8
  &resource=https%3A%2F%2Fmcp.example.com%2Fmcp
9
  &scope=orders%3Aread

这里最关键的是：

• 跳转的 host 来自授权服务器元数据中的 authorization_endpoint；
• resource 是目标 MCP Server 的规范 URI，不是 Authorization Server 的地址；
• state 用于防止授权响应被串到另一个请求；
• PKCE 防止授权码被截获后被其他客户端兑换；
• scope 应遵循最小权限，服务端在 WWW-Authenticate 中给出的当前请求所需 scope 应被优先考虑。

用户在浏览器中完成登录和同意后，Authorization Server 将 authorization code 重定向到客户端登记的 redirect_uri。

第六步：兑换 token 并访问 MCP#

客户端收到回调后，需要校验 state，校验授权服务器 issuer（如果响应包含 iss），再把 code 和原始 code_verifier 发送到元数据中的 token_endpoint：

1
POST https://auth.example.com/oauth2/token
2
Content-Type: application/x-www-form-urlencoded
3

4
grant_type=authorization_code&
5
code=<authorization-code>&
6
client_id=<client-id>&
7
redirect_uri=http%3A%2F%2F127.0.0.1%3A3000%2Fcallback&
8
code_verifier=<original-code-verifier>&
9
resource=https%3A%2F%2Fmcp.example.com%2Fmcp

拿到 access token 后，客户端调用 MCP endpoint：

1
POST /mcp HTTP/1.1
2
Host: mcp.example.com
3
Authorization: Bearer <access-token>
4
Content-Type: application/json
5

6
{ "jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {} }

MCP Server 不能只检查“这个 token 能不能被某个授权服务器签发”。它还应该确认 token 是发给自己的，检查 issuer、签名、有效期、scope，以及 audience 或 RFC 8707 的资源绑定。MCP Server 如果继续调用上游系统，还必须使用发给上游系统的独立 token，不能把客户端发给 MCP Server 的 token 直接透传给上游。

把 MCP 当成 Agent 平台#

MCP 规定的是连接和能力交换，不会自动提供记忆、规划、重试、任务持久化、人工审批、业务幂等和审计。企业需要的 Agent Runtime 仍然要在 MCP 之上建设。

以为拿到一个 token 就能访问所有 MCP Server#

不同 MCP Server 是不同的受保护资源。客户端应使用 resource 指明目标 MCP Server，服务端也要校验 token 的目标受众。不能因为 token 来自同一个企业身份平台，就默认它可以跨系统使用。

只在 tools/list 时做权限检查#

按权限过滤工具列表可以改善用户体验，但不能替代 tools/call 时的服务端授权判断。工具列表会变化，调用参数也可能决定实际访问范围。

把工具描述当成可信代码#

工具名称、描述、注解和返回内容都可能来自外部服务。Host 应该展示工具来源和风险，写操作最好保留人工确认；服务端不能因为描述中写了“只读”就跳过真实的权限和业务校验。

忽略本地 stdio Server 的安全边界#

stdio 没有远程 OAuth 跳转，不代表本地工具天然安全。启动命令、环境变量、文件系统 roots、子进程权限和工具参数仍然需要限制。远程网页通过 DNS rebinding 访问本地 HTTP MCP Server，也是需要特别防护的场景。

混用不同日期版本#

MCP 规范是按日期发布的。连接失败时不能只看“是不是 MCP”，还要确认双方支持的版本、传输方式、生命周期模型和认证规范。尤其是旧版 HTTP+SSE、旧版初始化流程和新版 Streamable HTTP 之间，不能只替换一个 URL 就认为兼容。