01 · MCP 是什么

工具能力的瓶颈

到第 8 章结束时，agent 有 8 个内置工具：search、glob、read_file、write_file、patch_file、run_command、git_status、git_diff。加上计划工具（create_todos、update_todo），一共 10 个。

这些工具覆盖了"在本地代码仓库中读写跑验"的核心能力。但现实中，agent 可能还需要：

• 查询 GitHub Issues
• 搜索在线文档（React 官方文档、MDN 等）
• 操作数据库
• 调用内部 API

每加一个工具，都要在 src/tools/ 下新建文件、修改 tools/index.ts 导出、更新系统提示词中的工具列表。工具越多，维护成本越高。

而且，不同的团队、不同的项目需要不同的工具组合。如果把所有工具都内置，agent 会变得臃肿；如果不内置，用户又没法扩展。

MCP：标准化的工具扩展协议

MCP（Model Context Protocol）是 Anthropic 提出的一个开放协议，解决的就是这个问题：让 agent 能通过标准协议接入外部工具服务器，而不是把每个工具都写死在主进程中。

类比一下：MCP 之于 agent，就像 USB 之于电脑。电脑不需要把所有外设都做进机身——只要有一个标准的 USB 接口，任何符合标准的设备都能插上用。MCP 就是 agent 的"USB 接口"。

没有 MCP 时：
  agent 内置工具 → 写死在代码里
  新增工具 → 改代码、发版

有了 MCP 后：
  agent 内置工具 → 核心能力（搜索、读写、执行）
  agent MCP client → 标准接口
  MCP server → 外部工具（Issue 查询、文档搜索等）
  新增工具 → 启动一个 MCP server，不改 agent 代码

MCP 的通信方式

MCP 使用 JSON-RPC 2.0 协议，通过 stdio（标准输入/输出）通信：

agent (client)                MCP server (子进程)
    │                              │
    │── initialize ──────────────→│  握手
    │←─ result ──────────────────│
    │                              │
    │── tools/list ──────────────→│  发现工具
    │←─ [tool1, tool2, ...] ─────│
    │                              │
    │── tools/call {name, args} →│  调用工具
    │←─ {content, isError} ──────│

流程很简单：

1. 启动。 agent 启动 MCP server 子进程（比如 npx my-mcp-server）。
2. 握手。 agent 发送 initialize 请求，交换能力信息。
3. 发现。 agent 发送 tools/list，获取 server 暴露的所有工具定义。
4. 调用。 agent 发送 tools/call，传入工具名和参数，获取执行结果。

为什么适合 coding agent

Claude Code、Cursor、Windsurf 等产品都已经支持 MCP。原因有三：

1. 标准化。 同一个 MCP server 可以被不同的 agent 使用。团队做了一个"查询内部 Issue 系统"的 MCP server，Claude Code 能用，Cursor 也能用，我们的 mini-coding-agent 也能用。

2. 隔离。 MCP server 在独立进程中运行。它崩溃了不影响 agent；它用到的依赖（npm 包、API 密钥）不会污染 agent 的运行环境。

3. 按需加载。 不需要 MCP 工具的团队不用配置任何东西。需要了就加一个环境变量，agent 自动发现和加载。

MCP 不是万能的

MCP 解决的是"怎么接入外部工具"，不是"怎么设计好用的工具"。一个设计糟糕的 MCP tool——描述不清、参数复杂、结果格式混乱——模型调用它也不会有好结果。

所以在实现 MCP 支持之前，agent 的内置工具已经设计好了清晰的接口和描述。MCP 是锦上添花，不是雪中送炭。

下一节实现 MCP client。