误读一：接了就会干活
协议只规定如何描述与调用工具，任务拆解、参数选择与结果校验仍由应用层完成。没有编排逻辑与失败重试，模型可能反复调用同一工具，或在参数缺失时硬猜。试点时应先把任务流程画清楚，再谈接入范围。
误读二：协议自带安全
协议不提供鉴权模型、不隔离数据、也不防止提示注入。服务端若把内部接口原样透传，模型可能被诱导调用越权操作。正确做法是在服务端做最小权限、参数白名单与写操作确认，而不是指望协议层拦截。
误读三：一个服务端接全部
为图省事把所有系统塞进一个服务端，会导致权限无法按系统拆分、故障影响面扩大、升级互相牵连。应按业务域或数据敏感度拆分，宁可多几个服务端，也不要留一个万能入口，出事时只能整体下线。
误读四：工具越多越好
暴露大量功能相近的工具会让模型选择困难，调用错误率上升，排查也更难。实践中应控制单个服务端的工具数量，写清适用与不适用场景，把低频或高风险工具移出默认清单，只在明确任务中临时启用。
误读五六：数据与运维
工具调通不等于结果可用，字段缺失、状态不同步会让回答看似正确实则过期。另一类误读是把接入当成一次性项目，缺少版本管理、超时重试与变更通知，接口一改整条链路静默失败，往往几天后才被发现。
适用与不适用
适合谁
- 正在做 MCP 试点验证的架构与平台团队
- 准备把内部系统开放给模型调用的企业
不适合谁
- 尚无账号权限与调用日志基础的团队
- 期望一次接入解决全部集成问题的项目
典型场景
一家零售企业的试点团队最初把商品、订单、库存三个系统放进同一个服务端，权限只能整体授予。测试中出现越权查询与工具选择混乱，团队随后按系统拆分服务端，只读与写操作分开，工具数量压到每端数个，并补上调用日志与超时重试。
可执行步骤
- 列出试点范围内的系统、动作与敏感级别，标出可写动作、数据范围与责任人
- 按业务域拆分服务端，把只读与写操作分端并分别授权，避免权限整体授予
- 为每个工具写明输入格式、适用场景、不适用场景、失败处理方式与返回示例
- 补齐超时、重试、限流与失败提示，避免链路静默失败，并把失败样例记录到日志
- 用诱导输入做越权、数据外泄与工具滥用测试，结果纳入上线评审材料与回归用例
常见坑
- 把协议当安全方案，服务端直接透传内部接口；越权与注入风险最终要由业务承担，事后追责也找不到清晰落点，合规评审很难通过。
- 一个服务端塞入全部系统，权限无法按系统拆分；一处故障影响所有调用，排查时也找不到具体责任环节，只能整体下线。
- 工具描述含糊，模型频繁选错；调用失败被归因于模型能力，真正的问题在接口设计，返工代价很高。
自检与验收清单
- 服务端是否按系统边界或数据敏感度拆分并登记
- 写操作工具是否单独隔离、限频，并做二次确认与回滚验证
- 工具描述是否写明适用边界、输入格式与失败处理
- 是否有超时、重试、限流与告警配置，且调用日志可查
- 上线前是否做过提示注入、越权与外泄测试并留档
常见问题
试点阶段要不要开放写操作？
建议先只读。写操作需要幂等设计、二次确认与回滚方案，试点期这些通常不具备。确有需要时，先选影响可逆、可人工核对的动作，并限制调用频率与时段，跑稳之后再扩大范围。
服务端数量多会不会更难管？
会多出配置工作，但换来权限可按系统拆分、故障影响面可控。可以用统一的服务端清单与配置模板降低管理成本，比把所有系统塞进一个入口更可持续，出问题时也更容易定位。
怎么验证有没有被提示注入？
准备一批含诱导指令的输入，观察模型是否会调用超出任务范围的工具或泄露无权限数据。测试应覆盖只读与写操作两类工具，并把结果纳入上线前的检查记录，作为复测基线。