资讯 · 改写稿

MCP 到底怎么工作：一次工具调用背后的 JSON-RPC 与 stdio

RefHub 编辑 · 发布 2026-10-08 · 更新于 2026-10-08 · 约 6 分钟

如果你用过 Claude Desktop、Cursor 或本地写码 Agent，多半配过一个 claude_desktop_config.json，或用 npx 起过一个 MCP 服务器。表面看很神奇：模型突然能连本地数据库、读本地文件、执行命令。要理解它为什么有时会坏，得看协议层。

它解决的问题：M 乘 N

在 MCP 之前，每个宿主对每个工具都要写一套对接。来源页给的算法很直观：5 个 Agent 宿主乘 20 个工具，就是 100 套要各自维护的对接。MCP 的做法是抄微软 Language Server Protocol 的作业：定义一个统一的 JSON-RPC 协议，宿主与服务器各实现一次即可。一句话，MCP 之于 AI Agent，就像 LSP 之于代码编辑器。

三个角色

宿主（Host）：面向用户的应用，比如 Claude Desktop、Cursor。它掌管权限、界面与模型推理。
MCP 客户端：宿主内部的协议控制器与状态管理者。
MCP 服务器：真正干活的进程，本地如 sqlite、git、文件系统，远程如 GitHub、Slack。

两条传输通道

本地服务器走 stdio 管道，也就是用文件描述符 0 和 1 通信；远程服务器走 HTTP 加 SSE。宿主里的 MCP 客户端负责把这两条通道统一起来，模型看到的是同一套工具接口。

那条会让服务器坏掉的 stdout 规则

因为本地通信用的是标准输出，stdout 上就必须严格只走协议消息。你在服务器代码里随手 print() 或 console.log() 打个调试日志，就会往协议流里插进一条不合规的帧，宿主解析失败，服务器当场表现为坏掉。日志要写到 stderr，或者文件里。

容易踩的坑

在 MCP 服务器的 stdout 上打日志：会污染协议流，让服务器坏掉。

以为本地和远程一样：本地是 stdio 管道，远程是 HTTP 加 SSE。

把 MCP 当成某个产品的专属：它是跨宿主、跨工具的标准协议。

忽视工具定义的上下文开销：接得越多，占的上下文越多。

自检清单

确认服务器是本地（stdio）还是远程（HTTP+SSE）
日志一律写 stderr，不写 stdout
核对配置文件名与启动命令（如 claude_desktop_config.json、npx 启动）
按需接入服务器，控制上下文占用

MCP 是宿主与工具之间的标准协议：本地服务器走 stdio 管道，远程走 HTTP 加 SSE，消息体是 JSON-RPC 2.0。

正文约 536 字（不含 FAQ 与自检清单）

常见问题

MCP 用什么协议通信？

JSON-RPC 2.0。本地服务器经 stdio 管道（文件描述符 0 与 1），远程服务器经 HTTP 加 SSE。

为什么我在服务器里 print() 会让它坏掉？

因为本地通信走标准输出，stdout 上必须只发协议消息。print() 会插入不合规的帧，宿主解析失败。日志要写 stderr。

MCP 和 LSP 有什么关系？

MCP 借用了 LSP 的思路：与其让每个宿主为每个工具写对接，不如定义一个统一的 JSON-RPC 协议，各方各实现一次。

MCP 里有哪些角色？

宿主（用户应用）、MCP 客户端（协议控制与状态管理）、MCP 服务器（实际执行，如数据库、文件系统、远程 API）。

来源参考

How Model Context Protocol (MCP) Actually Works: JSON-RPC 2.0, Stdio IPC, and Low-Level Tool Calling（dev.to，2026-10-08）

以上为外部来源；本文为 RefHub 用自己的结构重写，事实以来源页为准，价格与政策会变，请回源核对当日。

下一步：想把这些工具接进一个 Agent，读 Muse 接上 Zapier 能做什么；要估算额度，用额度计算器。