MCP 服务器是什么 — 开发者入门指南

一句话定义

定义就这么多。剩下的篇幅都是把这句话拆开讲。

Anthropic 为什么要发明 MCP

在 MCP 之前，LLM 和外部系统之间的每一次集成都是定制胶水。ChatGPT 插件是一套做法，Copilot 的 tool calling 是另一套，Cursor 自己做了一套文件编辑集成。每家厂商都在重新发明同样的四个原语——列一个东西、读一个东西、做一个东西、描述这些工具。结果就是每家一堵墙，谁要做工具都得应付多家不同的接口。

Anthropic 在 2024 年末推出了 MCP，定位是一个小而无聊的协议：任何 LLM 客户端都能说，任何工具作者都能实现。它故意做成在你选择的传输层 (stdio 或 HTTP) 上跑 JSON-RPC，发现和调用的方法集合是固定的。没有花哨设计，这就是重点。

十八个月左右，它从 Anthropic 内部的小众标准，变成了 Claude Desktop、Cursor、GitHub Copilot 的 agent 模式、Continue、Windsurf、Zed 都支持的协议。这些客户端都用同一套 MCP 握手去连同一种服务器。也就是说，你只写一次工具——比如读 HTTP 流量的工具——就能在所有 IDE 里用上。

stdio 与 HTTP 传输的区别

MCP 支持两种传输：stdio (客户端把服务器拉起为子进程，通过标准输入输出通信) 和 HTTP (服务器监听端口，客户端连上去)。选哪种是有真实后果的。

stdio 传输适合和客户端同机运行的工具。MCP 服务器就是客户端启动的一个可执行文件或脚本。没有网络端口，没有鉴权层。进程边界就是安全边界。对本地工具来说这是合理默认：文件系统、笔记本上的数据库、像 Rockxy 这样的 HTTP 代理，以及一切"模型就是要摸你本机"的场景。

HTTP 传输适合运行在别处的工具。远端数据库、带 MCP 适配器的 SaaS API、共享的团队服务器。服务器对外暴露一个长期存活的 HTTP 端点，耗时较长的工具调用通常走流式响应。这种传输需要鉴权、TLS 和所有常规的 HTTP 加固——换来的是多个客户端可以共用同一台服务器。

一条经验法则：如果工具围绕用户自己的机器或用户自己的数据，用 stdio；如果围绕共享系统，用 HTTP。能用 stdio 解决时就别用 HTTP——哪怕只监听 localhost，HTTP 服务器也是攻击面。

MCP 的工具面：tools、resources、prompts

一个 MCP 服务器可以暴露三类东西，每一类都有自己的用途。

Tools

tool 是模型可以调用的函数。它有名字、描述、输入的 JSON Schema，以及返回结构。从模型的角度看，它和任何 function calling 接口没区别。

{
  "name": "list_flows",
  "description": "List recent HTTP flows captured by the proxy.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "host": { "type": "string" },
      "method": { "type": "string" },
      "status": { "type": "integer" },
      "limit": { "type": "integer", "default": 20 }
    }
  }
}

Resources

resource 是服务器可以交给模型作为参考材料的一段内容——一个文件、一个 URL、数据库里的一段摘录。资源用 URI 寻址。它更接近"模型读的上下文"，而不是"模型调的函数"。

一个文件系统 MCP 服务器可能会把每个文件都作为 resource 暴露。一个 HTTP 调试服务器可能把每条抓到的流量的响应体都作为 resource 暴露。

Prompts

prompt 是服务器向客户端提供的可复用模板。你可以理解成一条带参数的保存过的查询，比如"给我这条流量的漏洞摘要"。客户端通常把它们呈现为斜杠命令或快捷操作。不是所有服务器都会提供 prompt——它是三种原语里用得最少的。

好的 MCP 服务器什么样

能长期留下来的 MCP 服务器和停留在演示阶段的，差别主要在这四点。

工具面要窄。 Rockxy MCP 服务器暴露四个工具。Linear 的 MCP 服务器大可以暴露四十个——票、团队、项目、迭代、标签、评论——但更窄的工具面模型更好推理，对你来说也更好审计。工具少，和用户挂的其他 MCP 服务器撞名字的概率也小。

能幂等就幂等。 读操作应该可以重复执行而无副作用。写操作要么接受幂等键，要么自己做去重。LLM 会重试——响应慢时、网络抖动时、模型觉得自己第一次搞错了时，都会重试。如果模型只打算重放一次，你的重放工具却造出了三条重复请求，那就是 bug。

本地优先。 默认应该是 MCP 服务器跑在用户自己的机器上，而不是某厂商的云上。数据本身就在云里的时候 (比如 Notion 的 MCP 服务器天然是云端) 走云是合理的；但给一个本地工具套一层云端 MCP 外壳，就是在漏数据。

可审计。 用户应该能在客户端里看到每一次工具调用。所有支持 MCP 的客户端默认就是这样做的。服务器作者应当让工具签名看起来直白——没有隐藏副作用，也没有名字之外还偷偷多做一堆事的工具。

生态例子

来看看不同的 MCP 服务器都暴露什么：

• Filesystem MCP。 read_file、list_directory、write_file 等工具；把配置好的根目录下的所有文件作为 resource。方便让助手读代码库而不需要复制粘贴。
• GitHub MCP。 列 issue、建 PR、读仓库元数据等工具。通常用 HTTP 传输走 GitHub API，token 由用户提供。鉴权、远端，但在大多数客户端里仍通过一个本地 stdio 垫层代理。
• Postgres MCP。 跑只读查询的工具；schema 作为 resource。工具面窄、幂等、本地 (指向本地数据库)。
• Rockxy MCP。 四个工具：list_flows、get_flow_detail、replay_request、diff_flows。stdio 传输，仅本地运行，源码基于 AGPL-3.0 可阅读。让 Claude Desktop (以及其他 MCP 客户端) 读你的 HTTP 流量并重放请求。

这些都是工具面很窄的小服务器，每个都聚焦在单一领域。没有谁想做"面向一切的 AI 集成层"。正是这份克制让生态可以组合——客户端挂上五个小服务器，每个干一件事，比挂一个什么都想干的大服务器舒服得多。

2026 年开发者日常怎么用 MCP

一个现实的 2026 年搭配：开着 Claude Desktop 用来查资料和调试，加载三个 MCP 服务器——文件系统 (限定到工作目录)、GitHub、Rockxy。claude_desktop_config.json 大概三十行。

同时你还开着 Cursor 写代码，项目级的 .cursor/mcp.json 加载文件系统服务器，外加一两个项目专属的服务器 (比如公司内部的 MCP 网关)。

两个客户端共用同一批服务器可执行文件。Rockxy 装一次，Claude Desktop 和 Cursor 里都能用。配置文件位置不同，但另一端的服务器是同一个。这就是共享协议的价值：你不再为每个客户端单独做一遍集成。

日常用起来是这样的：你问 Claude Desktop "最近一次失败的 API 调用长什么样"，它就去问 Rockxy。你让 Cursor "把这个函数改到测试能过"，它调用文件系统服务器读写文件。你不用再写任何样板去教这两个客户端认识这两个工具。

接下来会往哪走

2026 年初，有几个趋势比较明显。

多代理之间的交接。 MCP 服务器开始不止被交互式聊天客户端使用，也被互相调用的后台 agent 使用。一个 agent 分拣进来的 issue，把有希望的交给下一个读代码库的 agent，再把草稿 PR 交给第三个跑测试的 agent。每一次交接都是一次 MCP 调用。协议不是专门为这个设计的，但跑起来并不吃力。

第一方 IDE 集成。 Xcode、Visual Studio、JetBrains 全家桶等都在出或在试 MCP 客户端支持。大概一年内，每个主流 IDE 说 MCP 就像今天每个主流 IDE 说 LSP 一样正常。

服务器市场。 分发仍然是短板。大多数 MCP 服务器靠手改一份 JSON 文件来安装。一个市场层——相当于 MCP 服务器的应用商店——是显而易见的下一步，好几家客户端正在往这个方向做。

鉴权与能力模型。 当前 MCP 规范在授权方面比较简单，基本只有"你信任这个 MCP 服务器，就加载它；不信任，就不加载"。随着生态扩大，按工具粒度授权 (模型可以调 list_flows 但不能调 replay_request) 会慢慢成为标配。

想看一个小而设计得当的 MCP 服务器实际跑起来什么样，Rockxy 的接入指南 三分钟能走完，可以让你具体看到这四个原语怎么接到一次真实的调试工作流里。