每个 AI 应用都单独接文件、数据库和业务系统，会形成重复集成。MCP（模型上下文协议）提供共同语言，但协议打通的是连接，不是信任。
Host、Client、Server：先看清信任发生在哪里
官方架构中，Host 是承载用户体验与安全策略的 AI 应用；每个 Client 与一个 Server 建立有状态连接；Server 暴露 Tools（动作）、Resources（数据）与 Prompts（可复用交互模板）。本地 Server 可以访问本机能力，远程 Server 通常通过网络和授权连接。
这层分离带来复用：同一个 Server 可以服务多个兼容客户端。但也扩大了攻击面——一个工具描述、授权流程或返回内容的错误，会被所有连接它的客户端继承。
MCP 没有替你解决的五件事
业务语义
协议知道参数叫 status，不知道“已完成”在你的公司究竟意味着什么。
数据可信度
Resource 能被读取，不代表它新鲜、权威或适用于当前决定。
最小权限
连接成功不等于应该开放写入、删除和外发。
失败语义
HTTP 成功不等于业务完成；部分写入、重复调用和超时都要另行定义。
责任归属
谁批准调用、谁审计结果、谁处理事故，不属于协议自动答案。
对于单一客户端、单一服务、稳定接口，这条反对意见一票否决：直接 API 更简单。只有能力需要被多个 AI 客户端复用、动态发现或统一治理时，MCP 的标准化收益才超过维护成本。
完整案例：搭一张产品研究工作台
不要做一个“万能公司 Server”。我会按信任边界拆成三个：Research Files 只读正式材料；Analytics 只允许参数化查询；Issue Tracker 默认只读，创建或修改必须人工确认。
MCP Server Contract：在 Schema 之外补上治理
<purpose>服务哪类任务；明确不服务什么</purpose> <primitives>Tools / Resources / Prompts 清单与所有者</primitives> <semantics>参数定义、单位、时区、枚举、业务完成条件</semantics> <authority>读取范围、写入范围、确认点、禁止动作</authority> <failure>超时、部分成功、幂等、重试与回滚规则</failure> <audit>记录调用者、参数摘要、结果、时间与批准人</audit> <versioning>兼容策略、弃用周期与撤销方式</versioning>
授权不是登录成功，而是每次都只拿到必要能力
远程 MCP 的授权建立在 OAuth 体系上。实际设计还要防止 confused deputy（混淆代理）：攻击者诱导中间服务替自己使用别人的授权。对策包括精确回调地址、短期令牌、作用域分离、禁止令牌透传，以及把写操作与只读操作拆开。
| 测试 | 破坏方式 | 通过标准 |
|---|---|---|
| Discovery | 增加相似工具名 | 模型仍能选对且说明依据 |
| Schema | 缺字段、错单位、极端值 | 明确拒绝，不猜参数 |
| Privilege | 用只读令牌请求写入 | 服务端拒绝并留下审计 |
| Injection | Resource 内夹入伪指令 | 被视为数据，不覆盖 Host 策略 |
| Failure | 超时、重复请求、部分写入 | 不重复副作用，状态可恢复 |
采用 MCP 的判断标准
我会在三个条件同时出现时采用 MCP：能力需要被多个客户端复用；需要标准发现而不是写死调用；团队愿意为权限、版本和审计维护一层产品。如果只是一次脚本或单一后端，直接集成通常更诚实。