嗨，我是 Lena。第一次向别人解释 MCP 时，我总觉得哪里不太对劲。
我一直说「它把 AI 接到工具上」——技术上没错，却说不清底层到底在发生什么。对方点点头，又问：「所以就像插件？」我顿住了。因为也不完全是那样。
那种介于「我知道它能用」和「我明白它怎么工作」之间的缝隙，正是我想在这里慢慢展开的。不是做一份正式的技术拆解，而是把我观察到的、MCP Server 实际如何运作，一步一步说清楚。
MCP 要解决的问题
为什么以前的模型—工具对接都是定制
在 MCP 出现之前，把语言模型接到外部工具，往往意味着每次都要写一套定制对接。GitHub 有自己的格式。数据库有数据库的做法。每个 API 都是单独项目。
难点未必在某一单次对接本身，而在于不断叠加——彼此无法互通，模型也没有标准方式去问「这里我能做什么？」每条连接都是手工缝起来的。
Model Context Protocol 是 Anthropic 给出的回应。2024 年 11 月开源后，它提供了一种共同语言——标准化的 client–server 协议，让任意 AI 应用都能接到任意工具提供方，而无需各自接线。到 2025 年中，OpenAI 与 Google DeepMind 也已采用。此后它转入 Agentic AI Foundation（Linux Foundation 旗下项目）。
这一点有些意义：它不再只是某一家公司的标准，而更像在走向共同基础。实践里会带来什么变化，我还没完全想透，但会一再注意到这件事。
MCP 架构：三个运转中的部分
当别人问 MCP Server 是怎么工作的，我觉得最清楚的起点是三段式结构。每一块职责不同，混淆往往来自把它们揉成一团。
MCP Host（AI 应用）
Host 就是你实际在用的应用——Cursor、Claude Desktop、装了 AI 插件的 VS Code。用户看到、交互的，就是这一层。
**Host 是安全仲裁者。**它管理模型的上下文窗口，决定哪些工具可用，并控制哪些内容回传给 LLM。它并不亲自执行工具调用——只负责治理访问。除非你在搭自研 Agent 平台，多数开发者不会写 host 逻辑，但理解它很重要：是 host 决定模型能触达什么、不能触达什么。
MCP Client（内置于 host）
Client 由 host 创建。它夹在 host 与每个 MCP Server 之间，管理连接。通常是 一个 MCP Server 对应一个 MCP Client——各自维护独立会话。
Client 负责能力协商、来回路由消息，并抽象传输细节。Host 不必知道某个 Server 跑在 stdio 还是 HTTP 上，那是 client 的事。
MCP Server（工具提供方）
Server 才是能力真正所在之处。它暴露 tools、resources、prompts——取决于它被做成什么样。GitHub 的 MCP Server 暴露仓库操作；Postgres 的暴露查询函数。每个 Server 通常聚焦一个集成领域。
当我更仔细看时，有一点让我意外：Server 只是一个程序。它可以与 host 同机本地运行，也可以在互联网上远端部署。协议本身不变——变的是传输方式。
一次工具调用实际如何发生
这部分我曾长期在脑子里略搞错，直到一步步画出来才对齐。
第一步：Server 宣告可用工具
Client 首次连上 Server 时会握手。Client 发出 initialize 请求。Server 返回协议版本与能力列表——提供哪些工具、名称、入参 schema、描述。这就是 capability negotiation。
随后 Client 把这些工具定义嵌入模型的系统提示。LLM 由此知道「有什么可用」。没有魔法——只是结构化的上下文。
第二步：模型决定使用工具
模型处理请求并判断适合调用工具时，会输出结构化调用：工具名与拟传入参数。**模型不会直接调用工具。**它输出的是结构化指令，由 host 来解读。
第三步：Client 把调用发给 Server
Client 接收该结构化调用，通过 JSON-RPC 2.0 以 tools/call 请求转发给正确的 Server。这是线路格式——带方法名、参数，以及用于关联的唯一 ID。
第四步：Server 执行并返回结果
Server 执行实际函数——数据库查询、API 调用、读文件，随其设计而定。它返回结构化响应。若出错，返回的是类型化错误，而不是裸异常。写得好的 Server 会返回能帮助模型理解「失败原因」的错误信息——这对恢复很重要。
第五步：模型吸收结果
结果经 client、host 回到模型上下文。模型把它当作对话的一部分继续往下推。
……好，我好像看清它在做什么了。每一步刻意分开。模型从不直接接触工具。中间始终隔着一层。
传输层：Server 与 Client 如何通信
stdio（本地）与 HTTP/SSE（远端）
Stdio 传输使用标准输入输出流。当 host 把本地 MCP Server 作为子进程拉起——例如运行 npx my-mcp-server——client 与 server 通过读写这些流通信。不经网络，没有额外往返延迟。快，因为就是同机进程间通信。
Streamable HTTP 传输（2025 年 3 月协议更新里规定的、当前远端 Server 的主流方式）用 HTTP POST 承载 client→server 消息，并可用 Server-Sent Events 流式返回。远端 Server——例如托管在 Cloudflare 或 Vercel、同时服务许多 client——用的就是这套。
还有更老的 HTTP+SSE 形态（2024 年 11 月版规范），需要两个独立端点。新版 Streamable HTTP 规范把它收束为单一端点。若在读旧文档，值得留意——模式已经变过。
对延迟与安全意味着什么
本地 stdio Server 更快，攻击面也更小。能与它们通信的主要是 host 进程。远端 Server 带来网络延迟，并需要鉴权。2025 年 7 月的研究发现，近 2000 个暴露在互联网上的 MCP Server 完全没有鉴权——任何人都能访问其工具列表。2025 年 6 月的规范更新将 MCP Server 归类为 OAuth Resource Server，试图缓解部分问题，但落地仍不一致。
这个细节我一直记着。协议可以定义安全模式，却无法替你强制执行。官方 MCP 安全文档涵盖推荐实践——在部署任何处理敏感数据的东西之前，值得一读。
多数开发者会漏掉的那一层
一次成功的工具调用之后会发生什么
曾让我困惑许久的一点是：一次成功的工具调用本身并不会持久化任何东西。
结果会回到该会话内模型的上下文。模型用它生成回复，然后继续。但「调用了哪个工具、走了哪条路径、传了什么入参、得到了什么结果」——这些信息只存在于对话窗口里。会话结束，也就没了。
MCP Server 不会累积知识，也不会因为历史会话而「越用越聪明」。每次新连接都从相近的初始状态开始——握手、能力列表、干净起点。
为什么「连接」不等于「能力持久化」
这就是我所说的「connection is not capability persistence」。
接上 MCP Server，是给模型工具访问权；并不会自动给模型关于「以前怎么用这个工具、什么管用、什么失败」的记忆。每个会话里，Server 暴露的能力集合与过往无关。
我常会回到这一点。它不完全是缺陷——更像设计边界。协议处理的是通信与执行。执行产出之后要不要存、要不要学、要不要带到下一轮，完全是另一层问题。
……这里或许还有更多可挖。我会继续想。
FAQ
- MCP Server 究竟是什么？
MCP Server 是一个轻量程序，通过 Model Context Protocol 向 AI Agent 暴露 tools、resources 与 prompts。它把来自语言模型的结构化请求翻译成实际操作——数据库查询、API 调用、读文件——并以标准格式返回结果。它可以与 AI 应用同机运行，也可以通过 HTTP 远端部署。
- MCP 使用哪些传输协议？
MCP 支持两种传输机制。Stdio 用标准输入输出流做同机、本地通信——快、无网络开销。Streamable HTTP（当前远端 Server 的主流标准）使用 HTTP POST，并可用 Server-Sent Events 做流式传输。无论哪种传输，底层消息格式都是 JSON-RPC 2.0。
- MCP Server 能再调用另一个 MCP Server 吗？
协议上允许。一个 MCP Client 可以同时维护到多个 Server 的连接——数据库一个、文件一个、外部 API 一个，同一会话里并行存在。较少见、且在现有实现里定义不够清晰的是：某个 Server 再作为 client 去连另一个 Server。这种模式存在，但会抬高复杂度，安全边界也更难推理。
协议仍在成形。从 2024 年 11 月发布、2025 年 3 月更新，到当下实际在用的内容，规范已经发生过实质变化。再过一两个版本架构会长成什么样——我真心说不准。但我会继续学。
