什么是 MCP 协议在将项目接入 MCPModel Context Protocol模型上下文协议之前首先需要理清它的核心定位。1. 核心定位解耦 Agent 与工具开发MCP 协议本质上是一个标准化桥梁用于解耦 Agent 开发与工具Tool开发。Agent 开发者无需关心服务端工具的具体实现细节。MCPServer 开发者无需关心 Agent 是如何被触发或调度的。只要双方都遵循 MCP 协议的规范就能实现无缝衔接。需要注意的是要区分清楚MCP 协议通信规范与MCP Server使用该规范的工具服务端避免概念混淆。2. 底层通信为什么是 JSON-RPC 2.0MCP 的底层通信基于JSON-RPC2.0。REST协议面向资源Resource-oriented适合常规的 CRUD 数据流转。JSON-RPC协议面向动作/过程Action/Process-oriented。因为 MCP 的核心任务是“触发工具执行特定动作”所以天然契合 JSON-RPC。3. 两种核心传输方式MCP 协议支持两种主流的数据传输形态各有其适用场景传输方式运行机制核心优势额外成本/缺点stdioAgent 进程开启一个子进程作为 Server双方通过标准输入/输出stdin/stdout通信。无网络延迟本地运行且不联网安全性极高。只能本地使用。Streamable HTTPMCP Server 部署在云端或独立服务中通过网络协议进行流式通信。支持一对多一个 Server 可同时被多台主机的 Agent 调用。存在网络延迟且必须增加鉴权逻辑。4. 协议交互生命周期MCP 协议明确定义了客户端Agent与服务端MCP Server的交互流程与数据格式。完整闭环如下第一步初始化握手 (Initialization)客户端主动发起initialize请求对齐版本与能力边界{ method: initialize, params: { protocolVersion: 2025-03-26, capabilities: { tools: {} }, clientInfo: { name: agent, version: 1.0.0 } } }protocolVersion客户端实现的协议版本号。Server 端会进行校验若版本不一致可直接拒绝请求拦截后续报错。capabilities客户端声明自身支持的能力MCP 总共支持 Tools、Resources、Prompts 三种能力。上例中声明仅支持工具Server 就会只暴露工具列表。clientInfo客户端的基础元数据信息。收到 Server 的成功响应后客户端需再发送一条单向通知notifications/initialized表示初始化完成Server 无需响应此通知。第二步获取工具列表 (List Tools)初始化完成后客户端向 Server 询问可用工具{ method: tools/list, params: {} }Server 会返回工具集合包含名称、描述以及输入参数的 Schema 定义{ name: read_file, description: Read the complete contents of a file, inputSchema: { type: object, properties: { path: { type: string, description: Path to file } }, required: [path] } }合并机制Agent 客户端拿到此列表后会将其与本地原有的工具定义进行合并。随后Agent 就可以将完整的工具集合提交给大模型LLM大模型调用 MCP 工具的体验与调用本地原生工具完全一致。第三步工具调用与执行 (Call Tools)当大模型决定触发某个工具时Agent 客户端会向 MCP Server 发送具体的调用请求{ method: tools/call, params: { name: read_file, arguments: { path: /README.md } } }Server 接收请求并执行对应的本地代码逻辑然后将执行结果返回给客户端。最终由客户端将结果传回大模型完成整个调用流程。