直接回答：工具是 Agent 与世界交互的唯一通道，模型对工具的理解决定了行为质量。核心原则：工具职责单一且幂等、名字与描述用模型能懂的语言写清“什么时候用、参数什么含义、返回什么”、参数 schema 尽量收敛（枚举优于自由字符串）、错误返回结构化且可读（告诉模型错因与建议的下一步，而不是抛堆栈）、控制工具数量（超过二三十个后选择准确率明显下降，要分组或动态加载）。
展开解析：常见反模式：把内部 API 直接包一层扔给模型——字段名晦涩、需要多步拼参数，模型必然用错；返回大段原始 JSON 不做裁剪，浪费上下文还干扰判断。正确做法是为模型设计“语义化”接口：比如不给“查询数据库”，而给“查询某用户最近订单”。失败处理要区分可重试错误（限流、超时，提示稍后重试）与不可重试错误（参数非法，提示如何修正）。还要给危险操作加确认或 dry-run 模式。最后用评测集回归：每改一次工具描述就跑一遍典型任务，量化选择准确率的变化，凭感觉调 prompt 式描述不可靠。
追问方向：工具结果太长如何压缩进上下文？多步工具调用如何防串味？MCP 对工具设计有什么约束？
（约 460 字）