Model Context Protocol (MCP)

MCP 让 AI 应用能够发现并使用另一个程序提供的资料和工具，例如搜索代码仓库 Issue 的服务。AI 应用称为宿主（Host），通过 MCP 客户端连接提供能力的 MCP 服务器。协议规范按版本定义双方怎样交换消息、发现可用能力和初始化连接。它不规定具体业务操作的含义，也不保证服务器可信；模型可以执行哪些操作，仍由应用决定。

架构

宿主应用负责用户交互、模型上下文管理、权限审批及客户端编排。每个客户端维护与服务器的单一连接。服务器提供聚焦的能力接口，并可能依赖其他后端系统。

生命周期与能力协商

连接始于初始化阶段：客户端与服务器交换协议版本、实现信息及声明的能力。只有初始化完成后，才能进入正常操作状态。

能力协商至关重要，因为可选功能和修订版本存在差异。“支持 MCP”不足以作为兼容性测试的标准。

常见的传输方式包括本地 stdio 和 Streamable HTTP。

• 本地 stdio：并非无害。启动的服务器进程会继承启动者授予的文件系统、环境和网络权限。
• 远程传输：需额外处理来源验证、身份认证、令牌管理及网络故障问题。

服务器原语

原语	典型发起者	用途	重要注意事项
tools	模型（通过宿主）	调用类型化的动作或检索	模型的选择仍需策略控制和人工审批
resources	应用	暴露 URI 寻址的上下文	内容可能过时或包含对抗性数据
prompts	用户/应用	提供可复用的消息模板	需关注模板的来源和版本

协议还包含通知机制和可选的能力族。具体产品可能仅支持其中一部分。

实战边界：只读 Issue 搜索

一个聚焦的服务器可能暴露 search_issues(query, repository, limit) 接口，返回 Issue ID、标题、URL 和摘要。即便如此，安全的宿主应用仍需做到：

1. 限制允许的仓库范围和最大结果数量；
2. 将 Issue 文本视为不可信数据；
3. 在研究任务中禁用写入工具；
4. 展示数据来源，避免将大量结果直接放入上下文；
5. 在评论或关闭 Issue 前，要求独立的审批流程。

MCP 使调用变得可发现，但上述控制措施仍是应用层的责任。

安全失效模式与宿主控制

• 混淆代理 (Confused Deputy)：模型或服务器利用宿主的广泛权限执行未批准的副作用。
• 间接提示注入：工具调用返回的不可信网页或文件负载中包含指令，触发二次破坏性操作。
• 令牌透传与泄露：凭证跨越传输边界时，缺乏受众限制或日志脱敏。
• 范围膨胀：一个便捷的“超级服务器”暴露了过于广泛的写入/删除工具。

宿主可通过以下措施降低风险：将服务器输出视为不可信数据、在执行前再次验证拟议的工具参数、仅授予每个服务器所需的凭证和路径、并对本地策略选择的副作用要求审批。

• 对于本地 stdio 服务器：进程隔离和受限环境可在服务器被攻破时限制损害。
• 对于远程 Streamable HTTP 服务器：回环绑定不是客户端侧的控制手段。应使用 HTTPS，验证服务器身份和来源，将授权令牌的作用域限制在预期受众，并遵循协议的授权指南。本地通过 HTTP 运行的服务器可绑定到回环地址，但这属于不同的部署场景。

稳定的 Schema 排序可能有助于某些宿主重用提示缓存，但这属于性能优化选择，而非 MCP 的安全特性。

MCP 与更简单的替代方案

需求	推荐方案
单个本地操作，在一个框架内完成	原生工具 / 直接 CLI 命令
无需活跃服务器状态的可复用工作流	Skill 或结构化文档
标准的应用到服务集成	SDK、REST API、OpenAPI 或 CLI 包装器
多宿主发现类型化集成	MCP（由沙箱和审批门控管理）

MCP 是一种互操作性机制，并非每个智能体系统都必须采用的架构。在采用前，请评估其生命周期复杂度、运行时延迟、传输安全性及维护开销。

我的阅读 · 打开过的笔记会记在当前浏览器里。