MCP 协议 —— Agent 工具生态的通用插座标准
MCP 让工具开发者只需实现一次就能对接所有 Agent 框架。从客户端-服务器架构到工具/资源/提示三类原语，从 5 个服务器 = 55K token 的上下文开销问题到层次化组织与动态发现，再到信任模型的四类安全风险——理解 MCP 的价值和边界。
上一节讨论了工具设计原则。这些原则要落地，需要一个统一的生态标准。这就是 MCP 要解决的问题。
每个 Agent 框架定义工具的方式都不一样——OpenAI 的 function calling 格式、Anthropic 的 tool use 格式、LangChain 的 Tool 抽象。工具开发者不得不为不同框架重复适配，就像每个国家的电源插座标准都不同。
MCP（Model Context Protocol） 是 Anthropic 于 2024 年底发布的开放标准，相当于为 AI 工具生态制定一个通用的插座标准。
MCP 的核心架构
三个关键设计决策
1. 标准化的工具描述格式。 每个工具通过 JSON Schema 定义输入参数的类型、约束和描述，确保不同客户端都能正确理解工具的使用方式。
2. 传输层的灵活性。 同一 MCP 服务器既能作为本地进程运行（stdio），也能部署为远程服务（Streamable HTTP）。早期的 SSE 方案已弃用。
3. 三类原语的分离。 MCP 不仅定义了可执行的工具，还区分了三种不同性质的原语：
| 原语类型 | 性质 | 示例 |
|---|---|---|
| 工具（Tools） | 模型可执行的操作 | 搜索、读取、写入、执行命令 |
| 资源（Resources） | 应用可读取的数据 | 文件内容、数据库记录——只读，无需调用工具 |
| 提示模板（Prompts） | 用户可选用的模板 | 服务器提供的可复用提示词 |
这种分离让 Agent 能区分"获取信息"和"执行操作"——前者轻量安全，后者需要谨慎。
生态价值：一次开发，处处可用
一个 MCP 服务器可以同时被 Cursor、Claude Desktop、OpenClaw 等任何兼容客户端使用，工具开发者无需关心上游 Agent 框架的差异。MCP 已被多个主流 Agent 框架和 IDE 采纳。
MCP 的局限性
MCP 的工具调用主体上仍是请求-响应式——客户端发起调用，等待服务器返回结果。
协议已提供若干扩展原语：资源更新通知（notifications）、执行进度（progress）、采样（sampling）、征询（elicitation）。但这些原语都作用于保持连接的单个会话之内——通知能告诉客户端"资源变了"，却没有标准方式触发 Agent 的思考循环，更无法唤醒一个当下没有运行的 Agent。
跨会话、多事件源、离线唤醒的事件驱动 Agent 架构——新邮件随时可能到达、外部系统随时可能回调、Agent 需要在没有任何会话保持时被唤醒——仍需在 MCP 之上另行构建。
构建方式是分层的：MCP 负责单次工具调用的标准化交互，Agent 框架在其上通过事件队列管理多个调用的调度、并发与外部事件源的接入。
上下文开销：5 个服务器 = 55K token
MCP 生态的快速扩张带来了一个工程问题：仅仅 5 个 MCP 服务器就可能引入数万 token 量级的工具定义开销（约 55,000 token，视具体服务器而定）。在 200K 的上下文窗口里，还没开始对话就用掉了近三成。
Cursor 在实践中验证了一种缓解方案：将工具描述同步到文件夹，Agent 默认只看到工具名称的索引，需要时再查询具体定义。A/B 测试显示，这种方式使 MCP 工具相关任务的总 token 消耗减少 46.9%。
这与第二章的 KV Cache 友好原则和 Skills 渐进式披露一脉相承：默认少给，按需加载。
从平铺到层次化：工具的组织方式
当工具数量增长到上百个时，层次化组织比扁平列表有效得多。一种按信息源性质的分类：
| 分类 | 作用 | 示例 |
|---|---|---|
| 搜索工具 | 主动查找信息 | 网络搜索、知识库搜索、文件搜索 |
| 读取工具 | 从已知位置提取内容 | 网页阅读、文档读取、数据库查询 |
| 解析工具 | 处理非结构化数据 | 图片 OCR、视频分析、音频转录 |
| 查询工具 | 访问结构化数据源 | 天气 API、股票 API、公开数据库 |
在系统提示词中显式说明分类结构，帮 LLM 快速定位相关工具组。更进一步是动态工具发现——不把全部工具定义一次性注入上下文，而是让 Agent 通过搜索按需发现工具定义。Anthropic 实验显示，按需检索使 Opus 4 在工具使用基准上的准确率从 49% 提升到 74%。
MCP 到 Skills：工具多了怎么办
MCP 解决的是互操作（一次开发，处处可用），Skills 解决的是选择过载。
当可用工具从十几个增长到数百个时，模型面对平铺的工具列表越来越难做出正确选择。第二章的 Skills 用少量通用工具加可按需加载的知识文档替代大量专用工具，在根本上把"工具选择"问题转化为"知识检索"问题——后者正是 LLM 擅长的。
MCP 的信任模型与四类安全风险
MCP 让接入第三方工具变得前所未有的容易，但每接入一个 MCP 服务器就等于把一段不受控制的文本注入了 Agent 的上下文，往往还把凭证交到了别人手里。
缓解思路
与传统的软件供应链安全一脉相承：
| 措施 | 做法 |
|---|---|
| 接入前审查 | 把 description 当作不可信输入来审计，而不是当作无害元数据 |
| 锁定版本 | 拒绝静默更新，升级时重新审查 |
| 最小权限凭证 | 每个服务器只授予完成任务所需的最小范围，设有效期，不复用高权限个人凭证 |
| 运行时 Sidecar | 独立安全审查模型只看结构化工具调用数据，不被藏在描述里的话术操纵（本章后文详述） |
第五章将系统介绍 Simon Willison 提出的致命三要素——访问私有数据、暴露于不可信内容、对外通信能力——三者齐备即构成一条完整的攻击闭环。接入的 MCP 服务器越多，同时集齐三要素的概率越高；持久记忆会让攻击影响跨会话持续。
总结
| # | 要点 |
|---|---|
| 1 | MCP = 工具生态的通用插座标准，一次开发处处可用，已被主流框架和 IDE 采纳 |
| 2 | MCP 仍是请求-响应式，跨会话事件驱动需在协议之上另行构建 |
| 3 | 上下文开销：5 个服务器 ≈ 55K token。缓解：渐进式披露 + 层次化组织 + 动态发现 |
| 4 | MCP 接入 = 信任一个外部实体。四类安全风险需从审查、锁版本、最小权限三方向缓解 |