四条原则
一、少而准
工具越多，模型选错的概率越高。优先做「职责单一、命名直白」的工具；能合并的相似工具就合并（例如一个带 channel 参数的发送工具，而不是六个 send_x）。
二、参数要有约束
- 枚举优于自由文本（能选就不要填）；
- 必填与选填分清，选填要有安全默认值；
- 参数名与描述写用途与边界，不只写类型（「时间范围，最长 90 天」比「string」有用得多）。
三、写操作要有边界
- 影响范围要小：能改一行就不要写一个批量接口；
- 幂等：同样的请求重复执行结果一致（否则重试就会重复扣款、重复发信）；
- 可回滚：留撤销手段或反向接口；
- 高风险操作必须二次确认，且确认信息要展示给真人看（人看得懂才叫确认）。
四、错误要能自解释
返回结构化错误（错误码 + 人类可读原因 + 建议动作），而不是一句「失败」。模型会据此改参数重试，否则它只会反复撞墙。
三个反面例子
- 万能工具：一个能发任意 HTTP 请求的工具——等于把系统权限交给模型；
- 隐式副作用：读接口里顺手写日志或更新统计，让「只读」变成不可预测；
- 无上限批量：删除接口接受任意长度列表，一次失误清空一批数据。
常见的参数设计对照
- 不好：一个任意表达式字符串；好：关键词字符串 + 上限 1~50；
- 不好：任意文件路径；好：从可选文档列表里挑一个；
- 不好：一个任意对象；好：明确字段与类型。
上线前的检查
- 每个工具问一句：它被误用时最坏会怎样？ 答不上来就先别接；
- 写操作逐个确认幂等性与回滚方案；
- 统计工具调用失败率与「模型选错工具」的比例，按数据精简工具集——这通常比加工具更能提升完成率。