MCP 三层架构模型

MCP（Model Context Protocol）的架构定义得相当清晰，三个核心角色各司其职，分工明确。先来看看下面这张架构图，能帮助您快速建立对整体数据流向的直观认识。

Host（宿主）→ 运行 LLM 推理的应用程序：Claude Desktop、Claude Code、自研 Agent→ 负责管理与一个或多个 MCP Server 的连接→ 决定将哪些工具或资源暴露给 LLMClient（客户端，内嵌于 Host）→ 与单个 MCP Server 维持一个 1:1 的连接→ 按照 JSON-RPC 2.0 协议收发消息→ 维护会话状态（capabilities、已发现的工具列表）Server（服务端，独立进程）→ 对外提供三类能力：Tools / Resources / Prompts→ 通过标准输入输出（stdio）或 HTTP 与 Client 进行通信→ 一个 Server 可同时被多个 Host 连接

简单来说：Host 是用户眼中的 AI 应用（比如 Claude Desktop），Client 是应用内部负责适配协议的翻译层，而 Server 才是真正提供工具与数据的地方。

MCP 三类核心能力

MCP Server 对外暴露三种能力，各自用途各不相同：

Tools（工具） → LLM 主动调用的功能（action）→ 典型应用：搜索 Jira、执行 SQL、发送邮件→ 由 LLM 在推理过程中决定何时调用Resources（资源）→ LLM 可读取的数据源（data）→ 典型应用：当前 Sprint 状态、代码库文件树→ Host 决定何时注入到上下文Prompts（提示词模板）→ 预定义的 Prompt 模板（template）→ 典型应用：Bug 分析报告模板、代码 Review 模板→ 用户或 Host 直接调用，填入参数后生成完整 Prompt

这三种能力覆盖了 AI 应用最核心的需求：让模型能够执行操作（Tools）、查看数据（Resources）、以及按照规范进行交流（Prompts）。

MCP 传输方式

Client 与 Server 之间如何进行通信？目前支持以下三种方式：

stdio（标准输入输出）→ Server 以子进程方式运行，通过 stdin/stdout 交换 JSON-RPC 消息→ 最为简单，是本地开发的首选→ Claude Code 接入 MCP Server 的默认方式HTTP + SSE（Server-Sent Events）→ Server 作为独立 HTTP 服务运行→ Client → Server：HTTP POST→ Server → Client：SSE 流（支持 Server 主动推送）→ 适合远程 Server 以及多 Client 共享的场景Streamable HTTP（新增）→ HTTP POST + 可选的 SSE 流→ 同时支持同步调用与流式推送→ 2025 年规范更新后推荐的远程方案

本文的 demo 采用 stdio 传输，能够最直观地展示协议本身的运行机制。

完整协议交互过程

下面是用真实的 MCP Server 跑出的 8 轮 JSON-RPC 消息，从头到尾完整走一遍协议交互流程。

第 1 步：initialize（能力协商）

每次会话的第一条消息，双方先交换各自支持的能力。就像两个陌生人见面先确认“你都会哪些技能？”

Client → Server（请求）：

{"jsonrpc": "2.0","id": 1,"method": "initialize","params": {"protocolVersion": "2024-11-05","capabilities": {"roots": {"listChanged": true},"sampling": {}},"clientInfo": {"name": "demo-client","version": "1.0.0"}}}

Server → Client（响应）：

{"jsonrpc": "2.0","id": 1,"result": {"protocolVersion": "2024-11-05","capabilities": {"experimental": {},"prompts": {"listChanged": false},"resources": {"subscribe": false, "listChanged": false},"tools": {"listChanged": false}},"serverInfo": {"name": "mcp-protocol-demo","version": "1.13.1"}}}

解读：

• protocolVersion：双方协商确定使用的协议版本
• capabilities：双方各自声明所支持的能力。Server 这里显示 tools.listChanged: false，意味着工具列表不会动态变化，Client 无需订阅变更通知
• id 字段：initialize 属于请求-响应类型，包含 id

initialize 完成后，Client 会发送一条通知（notification）确认已就绪：

{"jsonrpc": "2.0", "method": "notifications/initialized"}

注意这条消息没有 id 字段——这是 JSON-RPC 的 Notification 类型，采用 fire-and-forget 模式，无需等待响应。这是一个巧妙的设计：它告诉 Server “我已经准备好接收后续消息了”。

第 2 步：tools/list（工具发现）

请求：

{"jsonrpc": "2.0", "id": 2, "method": "tools/list", "params": {}}

响应：

{"jsonrpc": "2.0","id": 2,"result": {"tools": [{"name": "echo","description": "Repeats the input message back. Useful for testing connectivity.","inputSchema": {"type": "object","properties": {"message": {"type": "string", "description": "The message to echo back"}},"required": ["message"]}},{"name": "add","description": "Adds two numbers and returns the result.","inputSchema": {"type": "object","properties": {"a": {"type": "number", "description": "First number"},"b": {"type": "number", "description": "Second number"}},"required": ["a", "b"]}}]}}

仔细观察 inputSchema，它采用的是标准 JSON Schema 格式。Host 获取到之后直接传递给 LLM，模型读到这个 Schema 就能自行判断何时调用工具、填入什么参数——本质上与 Function Calling 的 schema 结构完全一致。

第 3-4 步：tools/call（工具调用）

echo 调用：

// 请求{"jsonrpc": "2.0", "id": 3, "method": "tools/call","params": {"name": "echo", "arguments": {"message": "Hello from MCP client!"}}}// 响应{"jsonrpc": "2.0", "id": 3,"result": {"content": [{"type": "text", "text": "Echo: Hello from MCP client!"}],"isError": false}}

add 调用：

// 请求{"jsonrpc": "2.0", "id": 4, "method": "tools/call","params": {"name": "add", "arguments": {"a": 42, "b": 58}}}// 响应{"jsonrpc": "2.0", "id": 4,"result": {"content": [{"type": "text", "text": "42 + 58 = 100"}],"isError": false}}

解读：响应结构中有两个重要字段：

• content：数组形式，支持多个内容块（text / image / resource），可以一次返回多种格式
• isError：布尔值。工具执行失败时设置为 true，结果中写入错误信息。这里有一个值得注意的设计——工具报错使用的是正常响应（result），而非 JSON-RPC 协议错误（error）。为什么这样设计？因为这样 LLM 就能读取到错误详情并自适应调整，而不是直接中断通信。

第 5-6 步：resources/list + resources/read

列举资源：

// 响应{"result": {"resources": [{"name": "Server Information","uri": "info://server-info","description": "Metadata about this MCP server: name, version, capabilities","mimeType": "application/json"}]}}

读取资源：

// 请求{"method": "resources/read", "params": {"uri": "info://server-info"}}// 响应{"result": {"contents": [{"uri": "info://server-info","mimeType": "text/plain","text": "{"name": "mcp-protocol-demo", "version": "1.0.0", ...}"}]}}

这里的 URI scheme 是自定义的（info://），由 Server 自己定义格式。常见的 scheme 还有 file://（本地文件）、jira://（Jira 工单）、github://（代码仓库）。Resources 属于纯粹的数据层，只读不执行动作。

第 7-8 步：prompts/list + prompts/get

列举模板：

{"result": {"prompts": [{"name": "summarize","description": "Summarize a piece of text concisely","arguments": [{"name": "text", "description": "The text to summarize", "required": true},{"name": "max_words", "description": "Maximum words in the summary", "required": false}]}]}}

渲染模板（填入参数）：

// 请求{"method": "prompts/get","params": {"name": "summarize","arguments": {"text": "MCP defines a standard protocol for connecting AI models to tools and data sources.","max_words": "20"}}}// 响应{"result": {"description": "Summarization prompt","messages": [{"role": "user","content": {"type": "text","text": "Summarize the following text in at most 20 words:nnMCP defines a standard protocol for connecting AI models to tools and data sources."}}]}}

Prompts 是服务端维护的 Prompt 模板。Host 调用 prompts/get 获取渲染后的消息列表，可以直接用来构建 LLM 的 messages。在企业场景下，这一功能尤为实用——可以统一维护各类业务分析模板，所有 Agent 共用同一份，无需每个 Agent 单独编写 Prompt。

JSON-RPC 2.0 消息类型总结

MCP 使用的就是标准 JSON-RPC 2.0，消息分为以下三类：

请求（Request）：包含 id，需要响应{"jsonrpc":"2.0", "id": N, "method": "...", "params": {...}}响应（Response）：包含 id，与请求对应{"jsonrpc":"2.0", "id": N, "result": {...}}← 成功{"jsonrpc":"2.0", "id": N, "error": {...}} ← JSON-RPC 级错误通知（Notification）：无 id，fire-and-forget 模式{"jsonrpc":"2.0", "method": "notifications/initialized"}

关键区别：工具执行失败不使用 error 响应——那是 JSON-RPC 传输层的错误（比如方法不存在）。工具执行失败通过 result.isError: true 来表示，这样 LLM 就能读取到具体的错误内容，自主决定下一步如何处理。

运行本文 Demo

conda activate llm_basepip install mcpcd llm-in-action/mcp-02-protocol# 方式 A：命令行查看原始 JSON-RPC 消息（8 步协议交互）python demo_protocol_client.py# 方式 B：MCP Inspector 可视化界面（需要 Node.js）npx @modelcontextprotocol/inspector python demo_mcp_server.py

参考资料

• MCP 协议规范
• JSON-RPC 2.0 规范
• 本系列完整 Demo 代码：mcp-02-protocol