可靠的 MCP 工具应具有边界清晰的任务名称、受约束的输入、结构化输出、稳定错误、下游授权和安全的写入行为。工具需要作为一个整体接受测试，因为工具选择失败往往源于两项各自有效的定义相互重叠。
先从仅测试选择行为的评估开始。这样可以在错误调用触碰后端前发现歧义。
每项工具只负责一件事
使用符合用户任务的动词和宾语。get_order_status 比 query_order_service 更清晰。除非确实需要提供范围广泛且严格受限的能力，否则应避免 execute、manage、process 或 run_query 等宽泛名称。
描述应该回答：
- 工具会生成什么结果？
- 模型何时应该使用它？
- 模型何时应该使用其他工具，或不使用任何工具？
- 工具可能产生什么外部影响？
任务级 API 指南并排展示了较弱和较强的契约。
保持输入精简且受约束
使用 JSON Schema 表达必填字段、enum、格式、长度和数值范围。如果用户或上一项工具已经确定资源，应优先使用稳定的资源 ID，而不是自由文本描述。
不要要求模型提供服务端可以从已验证上下文推导出的值。租户 ID、用户 ID 和提供商凭据通常属于会话或服务端，不应作为工具参数。
对于变更操作，如果后端契约有要求，应接收操作键或幂等键。自动重试时不要在内部生成新键，否则重试会变成一项新操作。
返回能够支持下一步决策的结果
当前 MCP 工具规范支持可选输出 schema 和 structuredContent，并建议同时返回文本形式，以兼容不同客户端。
返回范围明确的结构，其中只包含 agent 下一步需要的权威字段：
{
"deploymentId": "dep_1842",
"state": "pending",
"statusUrl": "/deployments/dep_1842",
"retryAfterSeconds": 10
}
默认情况下不要返回完整的提供商响应，其中往往包含不稳定字段、内部标识符、过多文本或密钥。
区分协议错误与业务错误
如果 MCP 请求本身无效或服务器无法处理，应使用协议错误。如果工具已经执行，但业务操作失败，则返回 isError: true 和稳定的业务错误。
实用的业务错误会告诉调用方下一步怎么做：
| 错误 | 下一步操作 |
|---|---|
invalid_resource_id |
修正参数 |
not_authorized |
停止并请求访问权限 |
approval_required |
向用户展示需要审批的确切操作 |
operation_in_progress |
轮询返回的操作 |
rate_limited |
等待到返回的时间 |
upstream_unavailable |
仅在操作契约允许时重试 |
模型可见的错误绝不能包含 stack trace、数据库消息或凭据。
在工具背后强制执行授权
服务器应验证客户端及其代表用户的身份。下游 API 应针对租户、资源和操作授权该身份。工具列表不是访问控制列表。
MCP 身份验证指南介绍了受 audience 约束的 access token 和独立上游凭据。
确保写入能够安全重复
对于每项创建、更新、发送、付费或删除工具：
- 定义一个逻辑操作标识符；
- 保存或核对操作结果；
- 拒绝参数冲突的键复用；
- 记录超时后结果未知的情况；
- 在执行高影响操作前取得审批；
- 后端支持时优先采用可恢复的删除方式。
客户端重试和服务端重试可能会相互叠加。明确由哪一层负责重试，并将所有尝试记录在同一项操作下。
将 annotation 视为展示提示
MCP 工具 annotation 可以说明工具是只读、具有破坏性、幂等或会访问开放环境。客户端不得信任来自不受信任服务器的 annotation。它们可以改善展示效果，但相同规则仍必须在代码中执行。
分别评估工具选择与执行
工具选择测试应固定模型可见的工具集，再询问模型要调用哪项工具，其中应包含：
- 每项工具明确的正向任务；
- 最相似工具对的近似任务；
- 缺少必需上下文的请求；
- 不应调用任何工具的请求；
- 检索数据中包含的对抗性内容。
执行测试使用有效、无效、未授权、重复和中断的请求调用选定工具。记录工具名称、脱敏后的参数、策略决策、操作 ID、结果类别和持续时间。
工具选择错误调试指南介绍了选择测试失败时如何使用这些追踪记录。
从完整工具列表开始
按照模型实际看到的内容导出完整工具列表。逐个阅读工具文件会掩盖冲突。根据共享的名词、动词、描述和参数结构对工具对进行排序，再为最相似的一对编写近似任务。
下方的提示词会在不调用任何工具的情况下生成这组评估用例。