导语：MCP工具能不能被AI稳定调用，很大程度取决于工具描述是否清楚。名称太抽象、参数没有示例、错误返回不统一，都会让模型在选择工具和填写参数时产生误判。
工具名称要表达动作和对象
工具名称最好让人一眼看出“对什么对象做什么动作”。例如get_article、search_resources、publish_article比run_task、handle_data更容易被正确选择。名称统一使用项目约定的命名风格，不要同一类工具一会儿用动词开头，一会儿用名词开头。
描述里要写适用和不适用场景
工具描述不只是介绍功能，还应该告诉模型什么时候使用、什么时候不要使用。查询文章详情的工具不应该被用来搜索关键词，发布工具也不应该承担草稿生成。把边界写出来，能减少工具误选。
- 说明工具解决的具体问题；
- 说明必须提供哪些前置条件；
- 说明哪些请求应该交给其他工具。
输入Schema要限制类型和范围
输入Schema中要明确类型、必填项、长度、枚举值和默认行为。对于ID、分页、日期和状态字段，不要只写成宽泛的字符串。字段描述还可以补充格式示例，帮助模型生成更符合接口要求的参数。
{
"type": "object",
"required": ["resource_id"],
"properties": {
"resource_id": {"type": "integer", "minimum": 1},
"mode": {"type": "string", "enum": ["preview", "publish"]}
}
}有副作用的工具要显式标注
读取工具和写入工具的风险不同。删除、发布、发送通知、修改配置等操作，都应该在描述和接口层明确标注副作用。必要时增加preview或dry_run模式，让模型先展示将要执行的动作，再等待确认。
错误返回要让模型知道下一步
错误信息不能只有“操作失败”。建议使用稳定的错误码，并说明是参数错误、权限不足、资源不存在、限流还是服务暂时不可用。对于可恢复错误，返回建议动作；对于不可恢复错误，明确告诉模型不要继续重试。
权限边界必须在服务端执行
不能因为工具描述写了“只能操作当前用户资源”，就认为权限已经完成。服务端必须重新校验调用身份、资源归属、允许的字段和操作范围。模型提供的用户ID、角色和权限信息都不能直接作为可信依据。
发布前做四类测试
工具上线前至少测试正常参数、缺少必填项、错误类型、越权资源和重复调用。把这些测试固化成接口测试或契约测试，后续修改Schema时才能及时发现兼容问题。
总结
MCP工具描述写得好，模型才更容易选对工具、填对参数、理解错误并及时停止。名称讲清动作和对象，Schema限制输入，服务端落实权限，工具调用的稳定性才有基础。
评论 0