接口统一之后：MCP系统仍需补齐的架构与安全设计

让模型读取文件、查询数据库或调用业务接口时，真正难维护的往往不是某一个函数，而是每个应用都要重新约定工具清单、参数格式、连接方式和返回结构。模型上下文协议试图把这层重复工作收敛到共同接口：工具服务按协议描述能力，模型应用通过客户端发现并调用它们。这样，同一服务不必为每个聊天界面或开发工具重新发明一套私有接入方式。

协议由Anthropic在2024年11月推出，采用开放规范。把它比作通用外设接口有助于理解“统一连接”的目标，却不能把类比延伸为“插上就一定安全”。外设接口只规定通信形状，主机仍要决定信任谁、允许做什么以及失败后如何处置。MCP也是如此：标准化降低集成摩擦，应用自己的身份认证、权限控制与业务规则仍然不可缺席。

三个角色不要按三个独立产品机械划分

主机可以是IDE、桌面助手或其他模型应用；客户端通常由主机内部的协议实现承担，并不一定是用户单独看到的软件；服务器既可作为本地进程访问本机资源，也可位于网络另一端。一个主机能够连接多个服务器，各连接可协商不同能力。把客户端当作简单的网络转发器会漏掉生命周期、请求关联和错误处理，把服务器当作“模型的一部分”又会模糊数据边界。

连接建立先于能力调用

数据层以JSON-RPC 2.0消息为基础，除了普通请求和响应，还包含初始化、能力协商、通知与连接终止等生命周期动作。主机不能在尚未确认服务器能力时随意发送调用，服务器也不应假设所有客户端都支持相同扩展。请求标识用于把异步响应对应回原调用，通知则不期待普通响应；若把二者混用，界面可能永久等待一个协议上不会返回的结果。

能力协商不是授权。它只说明双方实现了哪些协议功能，不能证明当前用户有权读取某个目录或修改某张表。授权应在主机、传输入口和具体工具内部形成多层约束，并且以最窄范围为准。

工具、资源与提示模板解决的是三类不同需求

服务器可呈现的核心原语通常包括工具、资源和提示模板。工具代表可执行动作，例如调用API、写入工单或运行数据库查询；资源代表可读取的上下文，例如文件内容、记录或接口响应；提示模板提供可复用的交互起点。若把读取操作全部包装成任意命令工具，审计会变难；若把会产生副作用的动作伪装成资源读取，用户又可能在不知情时触发更改。

• 工具：定义参数、返回结构、副作用和失败语义，高风险操作应要求确认。
• 资源：使用稳定标识和内容类型，读取范围应受访问控制限制。
• 提示模板：帮助组织输入，但其中的文字不能越过主机安全策略。
• 通知与进度：适合长期任务状态，不应用来隐藏最终错误。

一些协议能力允许服务器请求主机侧模型采样、收集用户输入或记录消息。是否可用取决于双方协商，主机也应在每次使用时执行自身策略。服务器不能因为“协议支持”就获得任意调用模型或打扰用户的权利。

本地标准输入输出与远程HTTP对应不同威胁面

本地进程常通过标准输入输出传输消息，避免额外网络端口，启动和退出也可由主机管理。这种方式延迟小，但本地进程继承什么环境变量、能访问哪些文件、由谁提供可执行文件，都会影响安全。远程场景可通过支持流式响应的HTTP传输连接服务器，身份验证、TLS、反向代理、超时和水平扩展随之进入设计。历史实现中还可能看到基于服务器推送事件的旧传输方案，接入时应以双方实际支持的规范版本为准，不凭示例代码猜测。

传输加密保护的是链路，工具授权保护的是动作；拥有HTTPS并不代表一次数据库删除就应被允许。

级联调用尤其需要限制。A服务调用B，B再调用C时，最初用户意图、身份与权限是否能被可靠传递，不能由拓扑本身保证。循环、重复重试和长链超时也可能放大资源消耗。每一跳都应设置调用预算、深度上限、幂等标识和可追踪的请求链路，且下游只接受完成任务所必需的最小上下文。

1. 先把只读能力与写入能力分开部署或分开授权。
2. 为每个服务器建立允许访问的资源清单，而非默认整机可见。
3. 对外部内容中的指令保持不信任，防止它借模型转化为工具动作。
4. 在付款、删除、发送消息等不可逆步骤前显示参数并征得确认。
5. 记录调用者、工具名、参数摘要、结果状态和关联请求标识。
6. 对超时和重试定义幂等规则，避免同一副作用被执行多次。

一次“查询上周销售数据”应如何走完全程

主机先从已获准的服务器获取工具描述，将用户问题和必要工具信息交给模型。模型选择查询工具并给出结构化参数，主机检查参数、用户权限与数据范围后才发起调用。服务器查询后返回结构化结果，客户端对应请求并送回主机，模型再据此生成解释。若需要导出或发送报告，那应成为新的显式动作，而不是查询工具暗中附带的副作用。

这个流程把模型选择与系统执行分成两道门。模型可以提出调用建议，但主机负责策略；服务器可以执行业务动作，但必须再次验证身份和参数。任何一层都不能以“上一层已经检查”为由完全放弃自己的校验。

值不值得接入，可以先从变更成本反推

若只有一个应用调用一个稳定接口，私有封装可能已经足够，增加协议层会带来新的依赖和调试面。若多个主机需要共享一组工具，能力经常增删，或本地与远程资源都要统一呈现，标准接口的收益会更明显。评估时应比较新增一种工具需要改动多少处、升级能否独立进行、权限能否细分，以及故障是否容易定位，而不只统计“接入了多少服务器”。

MCP最可靠的定位，是一份连接与消息契约：它让生态中的参与者更容易说同一种协议语言，却不会替代领域API、身份系统或安全治理。先画清主机、客户端和服务器之间的数据边界，再为三类原语选择传输与权限，最后用审计和确认覆盖副作用，统一接口才会真正减少系统复杂度，而不是把原来的耦合隐藏在一条看似方便的连接后面。