先记住这个答案
参数名称应直接表达业务对象、动作相关含义和必要单位，描述补充值从哪里来、何时提供、允许范围以及与相近字段的差别。timeout_ms 比没有单位的 time 更容易消除歧义，document_id 也应说明它来自哪个查询结果，不能只写“文档”。这些文字会参与模型理解工具契约，因此可能影响传参正确率，但效果必须用固定任务样本验证，不能承诺改个名字就必然提升。名称和描述帮助选值，类型、范围和权限仍由执行端检查。
- 名称表达对象与单位，描述补足来源与边界
- 用真实歧义样本验证修改效果
- 描述中的承诺必须与实际执行逻辑一致
先解决会改变动作含义的歧义
时间字段可能表示绝对时间、持续时间或超时；id 可能属于用户、项目或文件。若这些信息只能从工具的内部实现猜到，模型很容易拿相邻结果中的错误值填入。字段名尽量表达稳定含义，描述再提供不能简洁放入名称的条件。
例如“读取文档”的 document_id 可以说明它必须取自文档搜索结果的 id，而不是标题或 URL。timeout_ms 应说明单位为毫秒、它限制哪一段操作，以及超时后是否可能已经产生副作用。这样调用者才能决定是否继续查询执行状态。
描述需要与参数规则保持同一口径
范围已经由 minimum 和 maximum 表达时，描述可以解释为何有上限以及超出需求如何分批处理，不必重复一整段 JSON 规则。枚举字段则应说明各个值的选择条件，避免只有三个名字却不知道什么时候该用哪一个。
如果 description 写“默认查最近一天”，执行代码却在省略字段时查询全部时间，工具契约就是矛盾的。改描述不能代替修复实现。评审应对照默认值、空值、边界值和错误返回，确认文字承诺与真实行为一致。
怎样判断新名称确实减少了错误
选择包含真实歧义的任务，例如用户说“五秒内返回”、给出文档标题但没有标识、或同时提到创建时间与更新时间。对比旧契约和新契约的字段错误率、错误类别、修正次数及最终任务成功率，控制模型和其他提示条件。
还要保留未参与修改的任务验证泛化，避免为了几条样本写进过度具体的暗示。字段改名属于接口变化，旧调用方、日志指标和测试夹具需要同步。外部工具描述也属于输入来源，不能因为文字清楚就允许其越过宿主系统的权限边界。
容易答错的地方
- 参数描述越长模型就越不会填错
- 冗长描述可能埋掉核心区别并增加相互矛盾的规则；优先写对象、单位、值来源和重要边界，其他背景放在适合的位置。
- 把内部数据库列名原样暴露最准确
- 内部缩写可能只有维护者认识，且未必代表调用者需要的概念；可以使用清楚的外部字段名，由工具实现完成受控映射。
面试官还会怎么问？
示例值应该放进描述吗？
当格式确实容易误解时可以提供少量正确示例，但应标明是格式示意，避免模型反复照抄同一个真实标识或把示例当成默认值。
用户身份能否靠 user_id 描述说明必须填自己？
不能，用户身份应由可信会话或凭证确定。模型输入中的标识只能描述被操作对象，不能自行证明调用者具有对应权限。
同一个字段在不同工具中必须同名吗？
语义、单位和来源相同通常应一致，便于复用；如果含义不同，应明确区分，不能为了表面统一让同名字段在两个工具中采用不同单位。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。