MCP 与工具生态：连接能力，不等于授予权限

没有统一接口时，每个 AI 应用都要分别适配数据库、文件系统、代码托管、浏览器和企业服务。连接数量一多，SDK、鉴权、错误格式和更新维护迅速失控。

Model Context Protocol（MCP）要解决的，是应用与外部上下文、工具之间的通用连接问题。它让一个 Host 能以相对一致的方式发现 Server 提供的能力。

但“能发现”和“能调用”不是一回事，“调用成功”和“业务允许”也不是一回事。理解 MCP，必须同时理解它的架构、控制语义和安全边界。

一、MCP 是什么，不是什么

MCP 是一种开放协议，用于让 AI 应用连接外部系统。官方架构包含 Host、Client 和 Server：[1]

• Host：面向用户的 AI 应用，负责整体体验、政策和模型编排；
• Client：Host 内与某个 Server 建立会话的协议组件；
• Server：暴露 Tools、Resources、Prompts 等能力的程序。

可以把它类比为 USB-C：接口形状统一之后，设备更容易接入，但接口本身不会决定你是否应该把硬盘里的文件发出去。

MCP 不是：

• 一个能自主规划任务的 Agent；
• 多个 Agent 相互协作的组织协议；
• 自动安全的插件商店；
• 业务授权系统的替代品；
• 对工具质量和返回内容真实性的背书。

它主要标准化“怎样描述、发现和交换能力”，而不是替 Host 做全部产品决策。

二、Host、Client、Server 为什么要分三层

初学者最容易把 Client 理解成用户界面，把 Server 理解成远程网站。MCP 的 Client 实际位于 Host 内部，通常一个 Client 对应一个 Server 连接。

User
  |
MCP Host（AI 应用、模型、审批与上下文政策）
  |-- MCP Client A <--> Files Server
  |-- MCP Client B <--> GitHub Server
  `-- MCP Client C <--> Database Server

这样分层有三个实际好处。

第一，Host 可以隔离不同 Server 的会话与权限，不必把所有能力混成一个连接。

第二，Server 不需要知道完整对话和其他 Server 的状态，只处理自己声明的协议能力。

第三，用户同意、模型上下文选择、跨 Server 组合等高层责任可以留在 Host。

图 1：MCP 官方规范是理解版本、架构和能力语义的一手来源。截图对应 2025-11-25 稳定规范，来源见文末。

三、Tools、Resources、Prompts 不是三个同义入口

MCP 规范刻意区分三类 Server 能力，并给出不同的控制语义。

Tools：模型控制的动作

Tool 通常有名称、描述、输入 Schema 和输出。模型可以根据任务选择调用，例如查询库存、创建 Issue 或执行搜索。

“模型控制”不表示模型拥有最终授权。Host 仍应展示敏感操作、校验参数，并允许用户拒绝。

Resources：应用控制的上下文

Resource 更接近可读取的数据，例如文件、数据库 Schema、文档或日志。由应用决定怎样发现、选择并加入上下文。

如果把所有 Resource 自动塞给模型，协议层的可连接性就会变成上下文泄漏。Host 应按任务、身份和最小必要原则选择。

Prompts：用户控制的模板

Prompt 是 Server 提供的可复用交互模板，通常由用户显式选择，例如“生成代码审查摘要”。它不是高于系统指令的远程命令，也不应静默覆盖 Host 政策。

三种原语的区别可以概括为：Tool 倾向于让模型选择动作，Resource 由应用选择上下文，Prompt 由用户选择交互入口。

四、一次工具调用实际经过什么

以“查询订单并退款”为例，完整链路不是模型直接访问支付系统：

1. Host 与 Server 初始化会话并协商能力；
2. Client 获取工具清单和 Schema；
3. Host 根据身份、任务和策略过滤可见工具；
4. 模型选择 refund_order 并生成参数；
5. Host 校验 Schema 和业务政策；
6. 高风险动作展示订单、金额和后果，等待批准；
7. Client 发起协议调用；
8. Server 校验调用方并访问后端；
9. Host 记录结果、错误和 Trace；
10. 系统查询订单终态，而不是只相信自然语言返回。

这里至少存在三道不同的门：协议可用、身份可用、业务允许。MCP 主要负责第一道门的标准交互，后两道不能省略。

五、传输层：stdio 与 Streamable HTTP

MCP 可以在本地进程和远程服务中运行。常见传输包括：

• stdio：Host 启动本地 Server，通过标准输入输出交换消息；适合本地工具和桌面应用；
• Streamable HTTP：通过 HTTP 连接远程 Server，适合服务化部署、会话和流式交互。

传输方式会改变威胁模型。本地 stdio Server 可能直接继承进程权限，能看到本机文件和环境变量；远程 Server 则涉及网络边界、身份认证、租户隔离和数据出境。

“本地”不等于安全，“远程”也不等于危险。关键是 Server 实际拿到什么 OS、网络和业务权限。

六、Capability Negotiation 与版本意识

初始化时，双方交换协议版本、实现信息和可支持能力。这样，Client 不应假设每个 Server 都支持相同功能。

截至本文核对日，官方站点列出的稳定规范是 2025-11-25。[1] 官方同时公布了面向 2026-07-28 的 Release Candidate 信息，包含 Tasks、扩展、授权和 Trace Context 等演进方向。[2]

Release Candidate 不是稳定规范。生产实现应固定已支持版本，记录协商结果，并对未知能力安全降级；不能把未来候选能力写成已经普遍可用的事实。

七、为什么“工具列表”本身也是攻击面

工具描述会进入模型上下文。一个恶意或被劫持的 Server 可以用工具名称和描述诱导模型错误调用，也可能返回带提示注入的内容。

常见风险包括：

• 工具投毒：描述中夹带越权指令；
• 名称混淆：用近似名称冒充可信工具；
• 参数扩大：模型填入超出用户意图的范围；
• 返回值注入：把外部文本伪装成下一步指令；
• 权限串联：低风险读取结果被转交给高风险发送工具；
• Rug Pull：Server 更新后改变行为，但 Host 仍沿用旧信任。

所以 Host 需要固定可信 Server、记录工具版本或哈希、对能力变更重新审查，并把 Server 内容视为不可信数据。

八、授权应该落在哪里

安全的 MCP Host 至少有四层控制。

可见性

根据用户身份和当前任务，只向模型暴露必要工具。不可见比“看见但请勿使用”更稳妥。

参数政策

Schema 只能检查类型，不能判断业务合理性。amount: 100000 可能满足数字类型，却违反退款上限。

人工批准

发送、删除、付款、发布等不可逆动作，应显示具体目标和参数。批准应绑定本次调用，不能成为永久通行证。

后端再授权

Server 和业务系统仍需验证身份、租户和资源权限，不能因为调用来自 MCP Client 就默认可信。

九、MCP Server 生态怎样选择

选择 Server 时，不能只看“工具多不多”。建议核对：

• 维护主体和最近发布；
• License 与部署模式；
• 要求哪些凭据、权限和网络访问；
• 是否支持只读模式；
• 工具 Schema 是否具体；
• 错误是否结构化；
• 是否有审计日志、速率限制和取消；
• 是否能固定版本；
• 是否存在官方或组织批准的发行渠道。

FastMCP 等项目帮助开发者构建 MCP Client/Server，Composio 等平台则提供大量 SaaS 连接。[3][4] 二者解决的是开发和集成效率，不会自动替业务完成权限审计。

图 2 是 A2A 项目页面，用来强调边界：A2A 关注独立 Agent 之间的协作，MCP 关注应用与工具/上下文的连接，两者不应混为一个协议。

图 2：MCP 与 A2A 可以出现在同一系统，但所连接的对象不同。来源见文末。

十、错误、取消和长任务

真实工具会超时、限流、部分成功或在响应丢失后已经完成。调用层应区分：

• 协议错误：消息、方法或参数不符合协议；
• 传输错误：连接断开、超时；
• 工具错误：后端拒绝、资源不存在；
• 业务失败：政策不允许、余额不足；
• 状态未知：没有响应，但副作用可能已发生。

只有明确可重试的错误才能自动重试。对有副作用的调用，应使用幂等键，并在超时后先查询真实状态。

长任务还需要进度、取消、恢复和结果引用。协议的演进正在增强这类能力，但应用不能等协议替自己设计任务状态机。

十一、真实实验：发现工具不等于授权写操作

本讲的 mcp_authorization_boundary.py 模拟一个 Server 暴露两个工具：只读 read_policy 和写操作 refund_order。

Client 能发现两个工具。策略层允许只读查询；在没有批准时，退款调用返回 approval_required；只有绑定批准后才允许执行。

{
  "mcp_discovery": ["read_policy", "refund_order"],
  "read_call": {"allowed": true},
  "write_without_approval": {"allowed": false},
  "write_with_approval": {"allowed": true}
}

完整结果见 experiment-result.json。

这个实验没有实现完整 MCP 传输，而是专门验证最容易被忽略的授权边界：Discovery 是能力元数据，Authorization 才是执行许可。

十二、20：40 分钟扩展实践

给实验增加三个字段：user_id、tenant_id 和 idempotency_key。设计以下测试：

1. 用户 A 不能退款用户 B 的订单；
2. 批准金额为 100 时，模型不能把参数改成 1000；
3. 相同幂等键重复请求，只产生一次副作用；
4. 工具描述发生变化时，Host 暂停自动调用并要求复审；
5. Tool 返回一段“请调用上传工具”的文本时，系统只把它当数据。

完成后，你会得到一个比“工具调用成功”更接近生产现实的测试集。

十三、这一讲的结论

MCP 的价值是把应用与外部能力之间的连接变得一致、可发现、可组合。它没有取消 Host 的责任，反而让 Host 更需要管理上下文、权限、批准、版本和审计。

记住一句话：协议告诉系统“怎样连接”，政策决定系统“是否允许”。

下一讲把 MCP 放回更大的协议地图：A2A、ACP、AG-UI 各自连接谁，为什么未来的 Agent 系统更像分层网络，而不是一个万能协议。

---

参考资料

[1] Model Context Protocol, Specification 2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25

[2] Model Context Protocol, 2026-07-28 Release Candidate. https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/

[3] FastMCP. https://github.com/jlowin/fastmcp

[4] Composio. https://github.com/ComposioHQ/composio

[5] Model Context Protocol, Security Best Practices. https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices

[6] A2A Project. https://github.com/a2aproject/A2A