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