文章目录 / 点击展开
MCP 工具接入的难点不在于让模型“看见一个函数”，而在于明确它在什么条件下可以调用、能读取或修改哪些数据、失败时会发生什么。任何能查询真实系统、发送消息或写入数据的工具，都应按权限系统来设计，而不是把它当作普通提示词能力。
先定义工具的业务边界
每个工具先回答四个问题：解决什么任务，输入来自哪里，允许访问什么资源，产生什么副作用。把“查询订单”拆成查询哪个组织、哪些字段、什么时间范围；把“发送通知”拆成允许的收件人、模板、频率和是否需要审批。
不应创建一个“万能数据库工具”或“任意 HTTP 请求工具”。工具越宽泛，提示注入、越权和误操作的影响越大，也越难审计。
第一步：设计结构化输入和输出
输入 schema 应限制字段、类型、长度、允许值和默认值，服务端再次验证。模型生成的参数是外部输入，不能直接拼接为 SQL、路径、URL 或命令。输出同样应结构化，并限制返回行数、字段和敏感信息。
工具：查询项目状态
输入：project_id、requested_fields、date_range
校验：project_id 必须属于当前组织；requested_fields 只能取允许字段；date_range 最长 90 天
输出：状态、负责人、更新时间、风险摘要schema 是第一层防护，不代表工具可以跳过业务权限验证。
第二步：把身份和权限带到服务端
工具调用必须携带经过验证的用户、组织和角色上下文，由服务端根据真实权限判断。不要只相信模型在提示词中写的“当前用户是管理员”，也不要让一个共享 API Key 代表所有用户。
凭据采用最小权限并按环境隔离。读取、写入、删除和管理员操作使用不同能力；高风险工具最好使用独立服务账号和额外审批。
第三步：防止提示注入驱动越权
文档、网页、邮件和用户输入都可能含有试图改变工具行为的文本。把它们当作数据，不当作系统指令。模型可以根据内容提出工具调用建议，但工具权限、参数范围和审批条件必须由代码和策略层决定。
对可写操作显示目标、参数摘要、影响范围和是否可回滚。涉及外部发布、资金、账号和删除时保留人工确认。具体审批编排可参考 n8n AI 审批工作流。
第四步：设计幂等、超时与失败恢复
为有副作用的调用使用业务唯一键，避免网络超时后重复创建、重复发送或重复扣费。区分临时网络错误、权限拒绝、参数错误和业务冲突，为每类错误定义是否重试、重试次数和人工接管方式。
工具不应把内部堆栈和密钥回传给模型或用户。返回可行动的错误代码、请求标识和安全说明，详细诊断进入受控日志。
第五步：从低风险场景开始测试
先在隔离环境中测试只读、模拟或无副作用工具，再逐步开放写入能力。测试覆盖正常参数、越权资源、超长输入、未知枚举、重复调用、超时、工具不可用和恶意文本诱导。
让 AI 生成测试场景可以提高覆盖面，但权限预期和副作用验证必须由真实服务完成。安全评审步骤见 AI 代码安全审查工作流。
第六步：审计、监控与回收权限
记录谁在何时通过哪个工作流请求调用了什么工具、传入的结构化参数摘要、结果状态、耗时、成本和审批记录。日志需脱敏，并限制谁能查看原始数据。
定期检查未使用工具、过度宽泛的 scope、失败率、重复调用和异常高频调用。可观测性字段与预算护栏可继续使用 AI Agent 可观测性教程 建立。
MCP 接入检查清单
- 工具是否只解决一个明确的业务任务。
- 输入输出是否有服务端验证的结构化 schema。
- 是否按真实用户、组织和角色做权限判断。
- 高风险写操作是否需要人工确认和可回滚设计。
- 是否测试提示注入、越权、重复调用和超时。
- 错误信息是否避免泄露内部细节和凭据。
- 是否保留脱敏审计日志、监控和权限回收机制。
常见问题
MCP 工具需要给模型多少权限
只给完成当前任务所需的最小权限。读取与写入分开，高风险操作使用独立工具和审批，不要使用全能凭据。
提示词中写了限制，还需要服务端校验吗
需要。提示词不能作为安全边界，所有权限和参数限制都必须在工具服务端执行。
工具返回的数据能全部交给模型吗
不应默认全部交给模型。按任务选择必要字段，过滤敏感数据、限制数量并记录访问用途。