从零开始学MCP（1）| MCP 协议核心原理解析

游戏天地 2025年08月15日 20:07 1 admin

统一 AI 工具调用的“通信语言”
关键词：工具调用标准化、Client/Server 架构、上下文传递、SSE 流式响应

一、MCP 解决了什么痛点？

在 MCP 出现之前，AI 应用调用外部工具（如数据库、API）存在三大问题：

碎片化：每个模型需单独适配工具（如 OpenAI Function Calling vs Claude Tool Use）
高耦合：工具逻辑与模型代码深度绑定，难以复用
上下文丢失：多轮调用时状态管理复杂

MCP 的核心目标：

定义一套与模型无关的标准化协议，让任意 AI 模型通过统一接口调用任意工具。

二、协议架构：Client/Server 解耦设计

核心角色定义

组件	职责	示例实体
Client	发起工具调用请求	Claude/ChatGPT/Cursor
Server	路由请求到工具并返回结果	本地 FastMCP 服务
Tool	执行具体操作	天气查询/数据库连接器

三、协议通信流程拆解

步骤 1：Client 发起请求（Request）

Client 发送 结构化 JSON 到 MCP Server，包含：

**context**：历史对话/当前状态（协议核心！）
**tool_name**：目标工具标识符
**parameters**：工具调用参数

{  "context": {    "user_id": "u123",    "session_id": "s456",    "history": [{"role": "user", "content": "查询北京天气"}]  },  "tool_name": "get_weather",  "parameters": {"city": "北京", "unit": "celsius"}}

步骤 2：Server 调用工具（Execution）

Server 根据 tool_name 路由到注册的工具函数，注入上下文并执行：

# MCP 工具注册示例（Python）@mcp_tool(name="get_weather")defweather_api(city: str, unit: str, context: dict) -> dict:    # 可访问 context["user_id"] 做权限校验    return fetch_weather(city, unit)  # 调用真实 API

步骤 3：流式返回结果（Response）

通过 Server-Sent Events（SSE） 流式返回，支持大结果分块传输：

HTTP/1.1 200 OKContent-Type: text/event-streamevent: result_chunkdata: {"progress": 30, "text": "正在获取数据..."}event: final_resultdata: {"temp": 25, "humidity": 60}

四、关键技术特性解析

1. 上下文传递（Context Propagation）

核心价值：在多轮交互中保持状态连续性

客户端在每次请求中携带完整上下文（如用户 ID、对话历史）
服务端可在响应中修改上下文（实现状态机）

// Server 可返回新上下文{"result": "...", "updated_context": {"selected_city": "北京"}}

2. 工具动态发现（Tool Discovery）

Client 启动时通过 /registry 接口拉取 Server 的工具清单：

// GET http://mcp-server/registry{  "tools": [    {      "name": "get_weather",      "description": "查询城市天气",      "parameters": {        "city": {"type": "string", "required": true},        "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}      }    }  ]}

3. 安全控制（OAuth2 集成）

在工具执行前进行权限校验：

defweather_api(city: str, context: dict):    user_token = context.get("user_token")    ifnot validate_token(user_token, scope="weather:read"):        raise MCPError(code=403, message="无权访问天气服务")

五、对比传统方案：为什么选择 MCP？

能力	MCP 方案	传统 Function Calling
跨模型兼容	✅ 统一接口	❌ 每个模型需独立适配
工具热插拔	✅ 服务端动态注册	❌ 需重新部署模型
上下文管理	✅ 显式状态传递	❌ 依赖模型记忆，不可靠
调试支持	✅ 内置 Trace Viewer	❌ 自行搭建日志系统

六、实战：快速验证 MCP 流程

1. 启动 Mock 服务

pip install fast-mcpfast-mcp --tools demo_tools.py

2. 发起请求（cURL 示例）

curl -X POST http://localhost:8000/execute \  -H "Content-Type: application/json" \  -d '{    "tool_name": "get_weather",    "parameters": {"city": "上海"},    "context": {"user_id": "test"}  }'

3. 观察响应

{  "result": {"temp": 28, "condition": "sunny"},  "updated_context": {"last_city": "上海"}}

七、协议演进方向（2025+）

多模态扩展：支持图像/音频作为工具输入输出
智能体协作：MCP Server 可嵌套调用其他 MCP Server
边缘计算：轻量化客户端运行在 IoT 设备

结语：MCP 不是简单的 RPC 协议，而是为 AI Agent 设计的 “工具协作语言”。其通过上下文传递、流式响应、动态注册等机制，为构建复杂智能应用提供了基础设施。

下一篇预告：《零基础 MCP 开发环境配置》

将手把手配置 Python/Node.js 双环境，集成 Claude 与 Cursor 实战演示！