MCP到底是什么？与MCP Client&MCP Server区别在哪？

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协议具体长啥样呢？参考样例：

json 复制代码

{
  "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 串联有两种常见方式：
1. 上下文注入工具清单（实现简单但浪费 Token）；
2. 模型/Host 内置工具列表（部署复杂但高效可控）。
实际落地时需要关注 初始化（tools/list） 、调用（tools/call） 、错误模型 、安全策略 和 性能优化（缓存/分页/幂等）。