MCP 客户端接入：为什么工具可见不等于工具可执行

本文讨论客户端接入策略，示例为通用工程模板，不代表某个真实生产系统的权限配置。

当客户端连上 MCP Server 后，通常会先发现服务端提供了哪些工具。这个过程很容易让人误以为：模型看见了工具，就应该能够直接执行。实际上，工具发现、用户授权和实际执行是三件不同的事。

Server 声明能力
       ↓
Client 按当前身份筛选与展示
       ↓
模型提出调用建议
       ↓
用户确认（按风险需要）
       ↓
Server 再次鉴权并执行

任何一层都不应替代下一层。尤其是最后的服务端鉴权，不能因为客户端曾经展示过工具就被跳过。

为工具设置风险等级

客户端可以将工具按影响范围分为三类，并匹配不同交互：

等级	典型能力	建议交互
低	读取公开或已授权的状态信息	可直接执行，并展示来源
中	检索内部资料、生成草稿、创建待审核事项	执行前展示数据范围或创建结果
高	发送消息、修改记录、删除数据、变更权限	必须明确确认，必要时走审批

风险等级是客户端体验设计的输入，不是安全授权本身。最终是否允许，仍由服务端根据用户身份、资源归属和业务规则决定。

确认界面要说人话

对于有副作用的操作，确认弹窗不应只显示“允许调用工具”。用户需要知道：

• 哪个 Server 提供这项能力。
• 将调用哪个 Tool，以及它会做什么。
• 会影响哪些对象或哪些人。
• 传入了哪些关键参数。
• 是否可撤销，以及执行失败时的处理方式。

例如，把“调用 send_notification”翻译成“向项目负责人发送一条异常提醒”，同时展示接收范围和预览内容，用户才有能力真正作出判断。

不要把模型输出当作可信指令

模型可能误解用户意图，也可能被不可信内容诱导调用不合适的工具。因此客户端需要把工具调用视为一个待验证的建议，而非命令。

实操上可以遵循以下规则：

1. 只连接用户明确启用、来源可识别的 MCP Server。
2. 按会话、用户或项目授予最小化工具范围。
3. 对外部写入操作始终要求明确确认，不使用含糊的“一键全部允许”。
4. 不把用户输入中的链接、网页文字或文档说明自动转化为执行权限。
5. 将调用结果与失败原因展示给用户，并保留安全的审计记录。

调试时也要保持边界

开发阶段常见的捷径，是让客户端把所有调试信息、所有工具参数和所有服务端结果直接打印出来。这样虽然方便，但极易把隐私资料或凭据带进日志。

更稳妥的方式是：日志记录工具名称、调用时间、结果状态、耗时和脱敏后的关键字段；只有在受控诊断环境里，才临时扩大日志范围，并在排查结束后关闭。

接入验收清单

• 断开一个 Server 后，相关工具是否立即不可用？
• 切换身份或项目后，工具列表是否按权限重新获取？
• 高风险调用是否有清晰、可取消的确认步骤？
• 服务端是否能拒绝客户端错误放行的请求？
• 失败结果是否能指导用户重试、改参数或发起审批？
• 日志、聊天记录和错误提示中是否不存在敏感原文？

MCP 客户端做得好，用户感受到的是更顺畅的工具协作；系统获得的则是可解释、可收回、可审计的执行边界。

延伸阅读

• MCP 官方架构说明 (opens new window)
• MCP Python SDK 文档 (opens new window)