MCP（Model Context Protocol）是为AI大模型提供外部工具调用能力的标准化协议，它扩展了传统的Function Call概念，使得模型能够提出工具调用建议（tool_call），而实际执行则由MCP Client完成，并将结果回填给模型。MCP不仅支持网络调用，也兼容本地调用，其消息层基于JSON-RPC 2.0。MCP Client作为协议的执行者，负责与模型交互、发现工具能力并发起实际调用；MCP Server则充当工具的“适配器”，向外暴露工具能力，并执行底层逻辑。二者协作，实现了LLM安全可控地使用外部资源，是AI Agent能力增强的关键技术。与LLM的串联方式包括上下文传递工具信息或模型内置工具列表。

🌟 MCP（Model Context Protocol）是AI大模型调用外部工具的标准化协议，可视为Function Call的扩展。它允许模型提出调用建议（tool_call），但实际执行由MCP Client完成，并将结果回填给模型。这种模式确保了模型不直接执行代码，而是通过客户端进行安全调用。

🌐 MCP协议定义了跨系统的通信规范，与HTTP、TCP类似，但其独特之处在于不仅支持网络调用（如Streamable HTTP），还支持本地调用（stdio），这意味着AI可以通过标准方式访问本地资源或脚本，极大地扩展了AI的能力边界。

💻 MCP Client是协议的执行者，负责与模型交互、发现工具能力（tools/list）并发起实际调用（tools/call），最后将执行结果回填给模型。其优势在于，只要Client实现了MCP，第三方接口或脚本无需直接支持MCP即可接入，提高了灵活性和兼容性。

🔧 MCP Server是工具的“适配器”，它向外暴露工具能力，供Client调用。Server可以是以stdio（JSON-RPC over STDIN/STDOUT）与本地应用交互的本地Server，也可以是通过HTTP/WS暴露工具能力的远程Server。Server接收调用请求后，执行底层逻辑（如本地命令、数据库查询、HTTP API调用）并返回结构化结果。

🚀 MCP协议与LLM的串联主要有两种方式：一是将工具清单和Schema注入对话上下文，模型据此生成调用建议，但可能浪费Token；二是模型/Host内置工具列表，调用更高效可控，但部署相对复杂。实际落地需关注初始化、调用、错误处理、安全策略和性能优化。

1. MCP概念

MCP，全称 Model Context Protocol，是为 AI 提供外部工具调用能力的协议标准，可以理解为 Function Call 的扩展。

在编程里，Function Call 是“运行过程中执行已定义好的函数”；在 AI 语境下，Function Call 变成了“模型运行过程中，调用已定义好的工具”。

但需要注意：

模型本身不会直接执行工具，它只会提出调用建议（tool_call）；真正的执行由 客户端（Client/Host） 完成，并将结果回填给模型；OpenAI、Anthropic 的函数调用规范都是这种模式。

MCP 与传统协议的关系：

相同点：像 HTTP、TCP 一样，定义了跨系统的通信规范；不同点：MCP 不只是网络协议，它既支持网络调用（Streamable HTTP），也支持本地调用（stdio）。

MCP 的基本传输与消息层：

消息层基于 JSON-RPC 2.0；

官方标准传输包括 stdio 与 Streamable HTTP（同时也支持扩展）；

MCP 的一个典型传输方式是 JSON-RPC over STDIN/STDOUT。通信时序如下图所示：

MCP参考文档：modelcontextprotocol.io/specificati…；

MCP协议具体长啥样呢？参考样例：

{  "name": "get_weather",  "description": "获取指定城市的实时天气",  "inputSchema": {    "type": "object",    "properties": {      "city": { "type": "string" }    },    "required": ["city"]  }}

协议始终只是标准，具体实现需要MCP Client和MCP Server的通力配合。

2. MCP Client

Client 是协议的执行者，它负责：

与模型交互，接收工具调用建议；发现工具能力（tools/list）；发起实际调用（tools/call）；回填执行结果给模型。

例如 VS Code 插件 Cline、Trae 就是典型的 MCP Client。

Client 的优势在于：只要它实现了 MCP，第三方接口/脚本本身 不必直接支持 MCP，仍然可以接入。

流程图如下：

sequenceDiagram    participant User as 用户    participant Client as MCP Client（如 Cline/Trae）    participant LocalCmd as 本地命令/脚本    participant Server as MCP Server    participant ExtAPI as 外部网络服务/API    User->>Client: 提问 / 发起需求    rect rgb(245,245,245)    Note over Client,LocalCmd: 路径 A：Client 直接执行本地命令    Client->>LocalCmd: 调用本地命令（tools/call 或内建执行器）    alt 本地命令需要外网        LocalCmd->>ExtAPI: HTTP/SDK 访问        ExtAPI-->>LocalCmd: 返回数据    end    LocalCmd-->>Client: 执行结果    end    rect rgb(245,245,245)    Note over Client,Server: 路径 B：经由 MCP Server 执行    Client->>Server: tools/call（MCP 协议）    Server->>LocalCmd: 调用本地命令/适配器    alt 本地命令需要外网        LocalCmd->>ExtAPI: HTTP/SDK 访问        ExtAPI-->>LocalCmd: 返回数据    end    LocalCmd-->>Server: 执行结果    Server-->>Client: JSON 结果    end    Client-->>User: 汇总并回答

3. MCP Server

Server 是工具的“适配器”，它向外暴露工具能力，供 Client 调用。

两种典型形态：

本地 Server（stdio）：通过 JSON-RPC over stdio 与本地应用交互；远程 Server（HTTP/WS）：通过网络暴露工具能力，支持流式返回。

Server 的职责是：接收 tools/call 请求 → 执行底层逻辑（本地命令、DB、HTTP API） → 返回结构化结果。

流程图如下：

sequenceDiagram    autonumber    participant User as 用户    participant LocalApp as 本地应用（MCP Client）    participant MCP as MCP Server    participant Tool as 工具/资源/API    User->>LocalApp: 发起请求（如：查询天气）    alt 使用 stdio（JSON-RPC over STDIN/STDOUT）        Note over LocalApp,MCP: 本地应用直接按 JSON-RPC 2.0 发送/接收报文        LocalApp->>MCP: tools/call { name: "get_weather", args: { city: "Tokyo" } }        MCP->>Tool: 执行本地命令/脚本或访问资源        Tool-->>MCP: 返回结构化结果        MCP-->>LocalApp: result / error    else 使用 HTTP(S) / WebSocket（桥接成网络端点）        LocalApp->>MCP: tools/call（JSON-RPC，经由 HTTP/WS）        MCP->>Tool: 执行工具/访问外部网络        Tool-->>MCP: 返回结构化结果        MCP-->>LocalApp: result / error（可流式）    end    LocalApp-->>User: 汇总并返回可读答案

4. 怎么与AI LLM串联

与 LLM 串联有两种常见方式：

上下文传递工具信息
每次对话时，把工具清单与 Schema 注入上下文；模型据此生成 tool_call 建议；缺点：浪费 Token，成本较高。
模型内置 Toollist
模型本身预置工具能力；需要独立部署或定制 LLM；优点：调用更高效，上下文更简洁。

大框架流程：

sequenceDiagram    autonumber    participant User as 用户    participant Host as Host/应用（Claude Desktop/Trae/VS Code 等）    participant Client as MCP Client（内嵌于 Host/应用，例如 Cline 等）    participant LLM as 模型（只提出调用建议）    participant Server as MCP Server    participant Tool as 工具/资源/API    User->>Host: 提问（如：查询东京天气）    Host->>Client: 触发外部能力流程    Client->>Server: tools/list（能力发现/获取 inputSchema）    Server-->>Client: 返回工具清单 + Schema    Host->>LLM: 组装上下文（用户问题 + 可用工具摘要）    LLM-->>Host: tool_call 提议（name + arguments）【不执行】    Host->>Client: 策略/鉴权/参数校验/路由（决定是否执行）    Client->>Server: tools/call(get_weather, {city:"重庆"})    Server->>Tool: 执行真实逻辑（HTTP API/DB/本地命令）    Tool-->>Server: 返回结构化结果    Server-->>Client: result / error（可流式）    Client-->>Host: 回填结构化结果    Host-->>LLM: 将工具结果提供给模型生成答案    LLM-->>User: 自然语言回答（可含关键数据/引用）

5. 总结

MCP（Model Context Protocol） 是一套为大模型标准化调用外部工具而设计的协议，基于 JSON-RPC 2.0，支持 stdio 和 HTTP 等多种传输。LLM 不直接执行工具，它只会输出 调用建议（tool_call）；真正的执行逻辑在 MCP Client，而 MCP Server 则负责暴露工具能力并执行底层逻辑。Client 负责调度、校验、路由，Server 负责适配、执行、返回结果。两者协作，让 LLM 能够安全、可控地使用外部资源。与 LLM 串联有两种常见方式：
上下文注入工具清单（实现简单但浪费 Token）；模型/Host 内置工具列表（部署复杂但高效可控）。
实际落地时需要关注 初始化（tools/list）、调用（tools/call）、错误模型、安全策略 和 性能优化（缓存/分页/幂等）。