编程开发 编辑复核
MCP 服务工具接口规格
把一项内部能力整理成模型能正确调用的工具规格，明确命名、参数、返回结构和破坏性操作标注。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名MCP 工具接口设计者。请把给定的内部能力拆成边界清晰、模型不会误用的工具规格。
先把已知事实、合理假设和待核验信息分开；资料不足时写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 按模型要完成的任务而不是内部接口切分工具，并给每个工具取动词加对象的名称
2. 为每个工具写一句用途说明，注明返回什么、什么时候该用、什么时候不该用
3. 定义扁平的参数结构，逐字段说明取值范围、默认值和必填条件
4. 标注只读还是有副作用、是否可重放、是否需要用户确认
5. 给出成功与失败的返回示例，失败返回要带错误码和可执行的下一步
6. 列出应当触发该工具的示例问法，用于验证模型是否选对工具
输入变量：
- 能力范围（{{capability_scope}}）：说明要暴露给模型的内部系统能力和边界。
- 现有接口（{{existing_api}}）：粘贴现有接口的路径、参数和返回结构。
- 调用场景（{{caller_context}}）：说明谁在用、在什么对话场景下调用。
约束：保留原始上下文和限定条件；每个结论都说明依据；涉及个人资料、合同、财务、医疗或安全信息时先提示脱敏和人工复核。HOW TO USE
使用说明
- 工具数量宁少勿多，说明和参数都会占用上下文并影响选择准确率。
- 把认证方式、分页上限和速率限制写进说明，模型才会传对参数。
WHEN IT FITS
适用判断
适合这些情况
- 要把已有系统接给 AI 助手，但不知道该怎么切分工具。
- 模型经常调错工具或漏传参数。
- 需要一份可直接交给后端实现的工具规格。
换个做法更好
- 只是内部服务之间调用：用普通 API 契约设计，不必套工具结构。
- 能力边界还没定型：先确认业务范围，再暴露给模型。
- 涉及高危写操作：先设计审批与回滚路径，再考虑开放为工具。
FAILURE MODES
常见翻车与修正
- 工具描述写得像内部接口文档，模型选不出该用哪个。
改成以任务为中心的一句话说明，补上适用与不适用场景，并用示例问法回测命中率。
- 参数嵌套太深，模型经常构造出非法结构。
把嵌套对象拆成扁平参数或拆成多个更窄的工具，并为每个字段写取值示例。
ACCEPTANCE
怎么判断输出合格
- 每个工具有明确的任务边界，职责不重叠。
- 参数与返回结构可直接转成 JSON Schema。
- 破坏性操作有显式标注和确认要求。
- 每个工具都有示例问法可用于验证选择准确率。
SAFETY BOUNDARY
使用边界
- 删除、支付、发送和发布类操作要标为破坏性，并在服务端要求人工确认。
- 工具返回内容属于不可信输入，落库或再次执行前要做过滤与人工复核。