MCP 协议长啥样？一文拆解大模型“动手”的通用语言

最新推荐文章于 2025-12-17 17:41:55 发布

原创最新推荐文章于 2025-12-17 17:41:55 发布 · 596 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #架构

MCP 专栏收录该内容

4 篇文章

订阅专栏

如果你已经理解了 MCP（Model Context Protocol）是大模型连接现实世界的关键桥梁，那么下一个问题自然浮现：这个“通用语言”到底长什么样？怎么写？怎么调？
与 OpenAI 的 Function Calling 那种“黑盒式”调用不同，MCP 的设计目标是开放、标准、可实现。本文将基于当前社区广泛参考的 MCP 草案规范（截至目前主流实现如 LlamaIndex MCP），逐层拆解其协议结构，从传输层到消息格式，从工具注册到安全机制，并附上可实操的 curl 示例，助你真正掌握 MCP 的“语法规则”。

一、协议层级：MCP 如何“传话”？

MCP 并不强制绑定某种网络协议，而是采用分层设计，上层定义语义，下层支持多种传输方式。这种设计极大提升了灵活性和部署适应性。

1. 传输层（Transport Layer）

MCP 支持三种主流传输方式：

HTTP/1.1 或 HTTP/2：最常用，适合大多数工具服务，便于调试和集成现有 Web 框架。
gRPC：适用于高性能、低延迟场景，支持双向流和强类型接口。
WebSocket：用于需要长期会话或实时上下文更新的场景（如持续监控任务）。

关键点：无论底层用哪种协议，上层的消息格式和语义保持一致。这意味着工具服务只需实现一次业务逻辑，即可通过不同入口暴露。

2. 消息格式（Message Format）

所有 MCP 消息均采用 JSON 格式，并严格遵循预定义的 JSON Schema。这种设计确保了：

可读性：开发人员可直接阅读请求/响应内容；
可验证性：服务端可快速校验消息合法性；
跨语言兼容：任何支持 JSON 的语言都能解析。

二、核心消息类型：MCP 的“基本词汇”

MCP 定义了三类核心消息，构成了模型与工具交互的基础语句：

1. `ToolRequest`

由 Agent 发起，请求执行某个工具。

{
  "type": "tool_request",
  "tool_name": "query_user_balance",
  "arguments": {
    "user_id": "U12345"
  },
  "request_id": "req-abc-123",
  "context_id": "ctx-xyz-789"
}

2. `ToolResponse`

由工具服务返回，包含执行结果或错误。

{
  "type": "tool_response",
  "request_id": "req-abc-123",
  "result": { "balance": 987.65 },
  "status": "success"
}

3. `ContextUpdate`

用于动态更新会话上下文（如添加新知识、标记任务状态）。

{
  "type": "context_update",
  "context_id": "ctx-xyz-789",
  "updates": {
    "last_query_time": "2025-12-12T10:00:00Z",
    "user_verified": true
  }
}

这三类消息共同构成了一个闭环：请求 → 执行 → 反馈 → 更新上下文。

三、上下文（Context）的结构与生命周期

上下文是 MCP 区别于简单工具调用的关键。它不仅是一个会话 ID，更是一个可读写的结构化状态容器。

结构示例

每个 context_id 对应一个上下文对象，通常包含：

session_id：关联用户会话
tool_history：已调用工具记录
intermediate_results：中间结果缓存
permissions：当前会话的工具调用权限

生命周期管理

创建：用户发起新任务时，Agent 生成 context_id 并初始化上下文。
更新：通过 ContextUpdate 消息增删改字段。
销毁：会话超时或任务完成后，由 Agent 或 MCP 服务主动清理。

这种显式上下文机制，使工具能感知“当前处于多步任务的哪一步”，避免状态丢失。

四、工具注册机制：Tool Manifest

MCP 要求每个工具在启动时主动注册自身能力，形成“工具目录”。注册信息称为 Tool Manifest，其结构如下：

{
  "name": "send_email",
  "description": "Send an email to a given recipient",
  "parameters": {
    "type": "object",
    "properties": {
      "to": { "type": "string", "format": "email" },
      "subject": { "type": "string" },
      "body": { "type": "string" }
    },
    "required": ["to", "subject", "body"]
  },
  "version": "1.0"
}

name：全局唯一标识，Agent 通过此名调用工具。
description：供 LLM 理解工具用途（类似 Function Calling 的 description）。
parameters：严格的 JSON Schema，Agent 生成的参数必须通过此校验。

工具可通过 HTTP POST /tools/register 接口注册，或在启动时向 MCP 服务发送注册消息。

五、安全设计：不让 AI “乱来”

MCP 明确要求安全机制，防止恶意或错误调用：

1. 认证（Authentication）

所有 MCP 请求必须携带 Authorization: Bearer <token> 头。
Token 由 Agent 管理，MCP 服务验证其有效性。

2. 鉴权（Authorization）

基于 context_id 或 agent_id 判断当前会话是否有权调用该工具。
例如：财务工具仅允许 HR 系统 Agent 调用。

3. 输入过滤与沙箱

工具服务需对 arguments 进行二次校验，即使已通过 JSON Schema。
敏感操作（如文件写入、网络请求）应在沙箱环境中执行。

安全不是可选项，而是 MCP 协议的内置要求。

六、实战：用 curl 模拟一次完整 MCP 交互

假设我们有一个 MCP 服务运行在 http://localhost:8080，提供 get_weather 工具。

步骤 1：注册工具（可选，若服务已内置）

curl -X POST http://localhost:8080/tools/register \
  -H "Content-Type: application/json" \
  -d '{
    "name": "get_weather",
    "description": "Get current weather for a city",
    "parameters": {
      "type": "object",
      "properties": { "city": { "type": "string" } },
      "required": ["city"]
    }
  }'

步骤 2：Agent 发送 ToolRequest

curl -X POST http://localhost:8080/mcp \
  -H "Authorization: Bearer demo-token" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "tool_request",
    "tool_name": "get_weather",
    "arguments": { "city": "Beijing" },
    "request_id": "req-001",
    "context_id": "ctx-001"
  }'

步骤 3：MCP 服务返回 ToolResponse（模拟）

{
  "type": "tool_response",
  "request_id": "req-001",
  "status": "success",
  "result": {
    "city": "Beijing",
    "temperature": 5,
    "unit": "Celsius"
  }
}

整个流程清晰、可追踪、可重放，完全符合工程化要求。