用途：本技能用于设计智能体（Agent）工具、编写工具描述、实现 MCP 工具，并回答工具设计相关问题。核心观点是：工具是确定性系统与非确定性智能体之间的契约，工具设计不良造成的失败模式无法靠提示工程弥补。
主要能力与要点：
-
合并原则：若人类工程师都无法确定该用哪个工具，智能体更做不到。示例：用 schedule_event（查找可用时间并安排）替代 list_users、list_events、create_event 三个工具。
-
工具描述结构：回答四个问题——工具做什么、何时使用、接受什么输入、返回什么。
-
良好设计示例（节选）：get_customer(customer_id: str, format: str = "concise")，文档串中说明用途、使用时机、参数格式（"CUST-######"）与取值（concise/detailed）、返回值，以及错误 NOT_FOUND 与 INVALID_FORMAT。
-
反模式示例：def search(query): """Search the database."""，问题包括命名含糊、参数缺失、无返回说明、无使用上下文、无错误处理。
-
架构精简：生产证据显示，更少、更原始的工具可胜过复杂多工具架构。文件系统智能体模式直接提供文件系统访问，让智能体用 grep、cat、find 探索。适用条件：数据层文档完善、模型推理能力足够、专用工具反而形成限制、维护脚手架的时间超过改进收益。
-
MCP 工具命名：始终使用完全限定名，如 "Use the BigQuery:bigquery_schema tool..."，错误写法 "Use the bigquery_schema tool..." 可能失败。
-
响应格式优化：通过 format: str = "concise"，取值 "concise" | "detailed"，让智能体控制详细程度。
-
错误消息设计：便于智能体恢复，例如 {"error": "NOT_FOUND", "message": "Customer CUST-000001 not found", "suggestion": "Verify customer ID format (CUST-######)"}。
-
工具集合指南：多数应用 10-20 个工具；更大集合使用命名空间；确保每个工具用途无歧义；用真实智能体交互测试。
-
反模式：含糊描述、隐晦参数（x、val、param1）、缺少错误处理、命名不一致（id、identifier、customer_id）。
-
最佳实践：描述回答做什么、何时用、返回什么；用合并减少歧义；提供响应格式选项；为恢复设计错误消息；统一命名约定；用真实交互测试；审视工具是促进还是限制推理；为模型改进构建最小架构。
使用方式：资料未提供具体安装命令或代码调用步骤，暂未提供。
限制：本页内容侧重设计原则与示例，未说明支持平台、依赖、版本、性能数据或收费信息，均暂未提供。