🚀 当 AI Agent 从“回答问题”走向“执行任务”，工具调用就成为关键能力。MCP（Model Context Protocol）的价值，在于用统一方式让模型发现、理解并调用外部工具，例如查数据库、调 API、读文件或执行计算。官方规范中，MCP 工具由唯一名称、描述信息和 inputSchema 组成，并通过 tools/list 发现、tools/call 调用，适合构建可扩展的 AI 工具生态 官方工具规范。
一、能力描述不是“介绍文案”，而是模型的决策依据 🧭
在 MCP 工具调用中，能力描述的第一目标不是给人看的漂亮说明，而是帮助模型判断“什么时候该用这个工具”。一个好的 description 应该明确说明工具能解决什么问题、不能解决什么问题、输入条件是什么、输出结果是什么。比如“查询订单状态”比“订单工具”更清晰，而“根据订单号查询订单当前状态，不负责创建、取消或退款”则更适合模型做边界判断。
能力描述建议遵循动词 + 对象 + 场景 + 限制的结构。动词说明动作，例如查询、创建、更新、删除；对象说明数据范围，例如客户、合同、库存；场景说明适用意图，例如售后查询、财务核对；限制说明不可用范围，例如不处理敏感字段、不执行支付、不修改历史记录。这样可以减少模型误调用，也能降低工具之间的语义冲突。
二、工具命名要稳定、可读、可维护 🛠️
MCP 工具通常通过 name 唯一标识，名称应当短、稳定、语义明确。推荐使用小写英文加下划线，例如 get_order_status、search_customer、create_support_ticket。不要使用含糊名称，如 process_data、handle_request，也不要频繁变更名称，因为调用方、日志、权限策略和测试用例都可能依赖这个标识。
如果系统中存在多个相似工具，可以通过领域前缀区分，例如 crm_search_customer、erp_query_inventory、finance_get_invoice。这样不仅便于模型识别，也方便开发者进行权限隔离、监控统计和故障排查。工具名负责“识别”，description 负责“解释”，两者不要互相替代。
三、Schema 设计的核心是“约束清楚” 📐
inputSchema 是 MCP 工具调用质量的核心。官方示例中，工具参数使用 JSON Schema 描述，包括 type、properties、required 等字段 Schema 参考。Schema 不只是参数格式说明，更是模型生成参数时的边界。约束越清楚，模型越容易生成可执行、可验证、可追踪的调用参数。
1. 参数字段要“少而准”
每个字段都应有明确用途。不要把多个意图塞进一个 query 字段，也不要设计过多可选参数让模型猜。比如查询订单状态时，order_id 通常应设为 required；如果允许手机号查询，则可以增加 phone，但要说明二者至少提供一个，并在服务端实现校验。
2. 类型要具体，枚举要优先
能用 enum 的地方尽量不要只写 string。例如 ticket_priority 可以限制为 low、medium、high、urgent，而不是让模型自由生成“非常紧急”“最高”“P0”等不一致值。对于日期、金额、邮箱、URL 等字段，建议在 description 中写明格式要求，例如“使用 YYYY-MM-DD 格式”或“单位为人民币元，最多两位小数”。
3. 必填字段体现最小可执行条件
required 不等于“业务上重要”，而是“没有它工具无法可靠执行”。如果一个字段缺失时服务端可以推断，就不一定必填；如果缺失会导致歧义、误操作或安全风险，就必须必填。设计 required 时，应站在执行系统角度，而不是表单完整性角度。
四、能力描述与 Schema 要互相校验 🔍
很多工具调用问题并不是模型能力不足，而是 description 和 Schema 互相打架。例如描述写“按客户名称查询”，Schema 却只允许 customer_id；描述写“可以创建订单”，Schema 却没有商品、数量、收货地址字段。上线前应逐项检查：描述中的能力是否都能由参数支持，Schema 中的字段是否都能在描述中找到业务意义。
实用检查法：让一名不了解实现细节的同事只看工具 name、description 和 inputSchema，判断他是否能准确说出工具何时使用、需要哪些参数、调用后会发生什么。如果不能，模型大概率也会困惑。
五、为安全和可控性设计工具边界 🛡️
MCP 工具可以连接真实系统，因此安全设计必须前置。官方规范强调，服务端应验证所有工具输入、实施访问控制、限制调用速率并清理工具输出；客户端则应在敏感操作前向用户确认，并记录工具使用情况 安全建议。这意味着 Schema 不能只考虑“能不能调通”，还要考虑“会不会误调、越权或泄露”。
- 读写分离：把 get、search、list 与 create、update、delete 分成不同工具，避免一个工具承担过多权限。
- 敏感操作显式化：删除、付款、发邮件、改权限等操作，应在描述中标明需要用户确认。
- 输出最小化：工具返回模型需要的信息即可，不要默认返回身份证号、密钥、完整日志等敏感内容。
- 错误可解释：工具执行失败时返回清晰原因，例如参数非法、权限不足、资源不存在，而不是只返回“失败”。
六、推荐的设计流程 ✅
- 先写用户意图：列出用户会如何表达需求，例如“帮我查一下订单到哪了”。
- 再定义工具边界：明确工具只负责查询状态，不负责退款、改地址或催发货。
- 设计最小参数：确定完成任务所需的最少字段，例如 order_id。
- 补充字段约束：加入类型、枚举、格式、默认值和字段说明。
- 编写失败场景：考虑参数缺失、权限不足、系统超时、数据不存在等情况。
- 用真实提示测试：让模型在多种自然语言表达下选择工具并生成参数，观察是否稳定。
七、一个简化示例 🌰
以“查询订单状态”为例，能力描述可以写为：根据订单号查询订单当前履约状态，包括已创建、已支付、已发货、已签收或已取消；不支持修改订单、取消订单或处理退款。 对应 Schema 中可以设置 order_id 为必填字符串，并在字段说明中要求传入系统订单号。这样的设计既告诉模型“何时使用”，也告诉模型“如何正确调用”。
总结
AI MCP 协议工具调用的设计重点，不在于把工具数量做多，而在于让每个工具都能被模型准确理解、稳定调用、安全执行。能力描述负责表达业务语义，Schema 负责提供参数约束，安全策略负责控制真实影响。实践中，坚持命名清晰、描述具体、参数最小、约束明确、边界可审计，就能显著提升 MCP 工具调用的可靠性，也能为后续扩展更多 Agent 能力打下坚实基础。✨
