要点一：协议不是产品
MCP 定义客户端与服务端如何描述能力、发起调用与返回结果，本身不含模型、不含知识库，也不负责业务逻辑。企业仍需自建或采购工具服务，协议只降低连接成本。把它当成可直接采购的软件，是最常见的误解。
要点二：三种角色分工
宿主应用承载模型与会话，客户端负责与某个服务端建立连接并转发请求，服务端暴露具体能力。一个宿主可同时连接多个服务端，权限在连接层控制，治理要落在客户端配置与服务端暴露范围上，而不是模型侧。
要点三：三类交互对象
服务端通常暴露工具、资源与提示模板：工具是可执行动作，资源是只读数据，提示模板是预置指令。三者风险不同，只读资源可以放宽，写操作类工具必须限权、留痕并可回滚，否则一次误调用就可能改坏生产数据。
要点四：传输与协商
交互基于 JSON-RPC 风格的消息，按请求、响应与通知组织；本地进程常用标准输入输出，远程服务走 HTTP。连接建立时有能力协商，双方声明各自支持的特性。选型时应确认传输方式是否满足网络分区与审计要求。
要点五：安全边界在调用侧
协议不解决提示注入、越权调用与数据外泄，这些要在服务端做最小权限、参数校验、速率限制与人工确认。涉及写操作的场景应默认二次确认，敏感数据读取要有用途与范围约束，并保留完整调用日志。
适用与不适用
适合谁
- 有多个内部系统需要被模型调用的技术团队
- 同时使用多个模型或客户端、重复写适配层的企业
- 希望把工具接入做成标准化能力的平台团队
不适合谁
- 只有一个系统、一次性的简单集成需求
- 尚未建立账号权限与调用审计基础的组织
典型场景
某企业的助手需要查询订单、读取工单并生成周报。团队把订单查询与工单读取分别封装为两个服务端，只暴露只读工具；周报生成仍走内部脚本。客户端按岗位配置可连接的服务端，调用日志进入统一审计，涉及客户资料的写操作暂不开放。
可执行步骤
- 梳理需要被模型调用的系统与动作，区分只读与写操作，并标注数据敏感级别
- 按系统边界拆分服务端，明确每个服务的暴露范围、维护人与版本策略，逐项确认
- 为客户端配置可连接的服务端清单，按岗位完成映射并保留审批记录备查
- 开启调用日志与速率限制，设定写操作的人工确认规则与回滚方案，定期复核
常见坑
- 以为接入协议就获得智能，忽略工具本身的业务逻辑质量；调用成功但结果不可用，排查时还容易归错因。
- 把生产库读写权限整体授予服务端；一次误调用就可能造成数据损坏，恢复又要人工逐条比对，代价很高。
- 只记录模型输出不记录工具调用；出问题无法还原调用链与参数，责任也说不清，复盘只能靠回忆。
自检与验收清单
- 每个服务端是否明确只读或可写，并指定维护人与版本
- 客户端是否按岗位配置可连接清单与审批记录留存
- 调用参数是否做格式、范围校验，并配置限流控制
- 写操作是否默认二次确认，并具备回滚手段与人工复核
常见问题
MCP 会不会取代现有 API？
不会。它是在 API 之上增加一层统一描述与调用约定，底层仍调用既有接口。已有的接口治理、鉴权与审计体系仍是基础，MCP 只是让模型应用更容易发现和调用这些能力，而不是替代治理。
必须用某一家模型才能用吗？
协议本身与模型厂商解耦，只要客户端实现该协议即可连接。实际可用性取决于客户端实现的完整度与服务端暴露的能力，选型时应以能否满足权限与审计要求为准，并做一次连通验证。
小团队值得投入吗？
系统数量少、集成一次到位的团队，直接写接口更省事。当需要接入的系统与使用的客户端都在增加、适配代码开始重复时，标准化连接带来的收益才会显现，过早投入反而增加维护面。