MCP 中的“工具”是什么（以及它为何比你想象的更重要）

Source: Dev.to

工具

如果 MCP 是系统，那么工具就是让它 有用 的东西。

简单定义

工具是模型可以选择执行的 结构化动作。

👉 如果模型想要 做点什么，它就会使用工具。

重要说明

工具 不仅仅是一个函数。
它是一个带有：

• 明确名称
• 明确目的
• 已定义输入

的函数。这种结构让模型能够理解并使用它。

工具的样子

get_user_orders(user_id, limit)

这个工具告诉模型：

• 它的功能 → 获取用户订单
• 它需要的参数 → user_id、limit

模型如何使用工具

用户提问： “显示我最近的 3 条订单”

1. 模型查看可用工具

   • get_user_orders
   • cancel_order
   • search_products

2. 模型决定
   “这看起来是订单相关的请求 → 使用 get_user_orders”

3. 模型生成工具调用

   {
     "tool": "get_user_orders",
     "arguments": {
       "user_id": "123",
       "limit": 3
     }
   }

4. 系统执行 – MCP 服务器运行逻辑并返回数据。

5. 模型响应 – 将结果转换为用户友好的答案。

关键洞察

模型 看不到你的代码。它只看到：

• 工具名称
• 描述
• 输入结构

👉 这就是它用来决定的依据。

为什么工具设计很重要

不清晰的工具会导致系统崩溃。

糟糕的工具

process_data(data)

问题

• 它到底做什么？
• 何时应该使用？
• “data” 指的是什么？

👉 模型会感到困惑。

良好的工具

get_user_orders(user_id, limit)
cancel_order(order_id)
search_products(query)

现在每个工具都有明确的目的，模型可以轻松选择合适的工具。

设计工具的黄金规则

1. 一工具 = 一动作
   避免将多个职责合并在一起。

2. 使用清晰的命名
   推荐：get_user_orders、create_order
   避免：handle_data、process_request

3. 明确输入

   糟糕的写法

   { "data": "string" }

   好的写法

   { "user_id": "string", "limit": "number" }

4. 为清晰而设计，而非便利
   你的后端可能支持复杂操作，但工具应当 简单且易懂。

更好的工具思考方式

把工具视为 模型可用的动作集合。
如果没有相应的工具，模型就无法执行该动作。

常见错误

• 创建太多工具 → 难以选择
• 工具过于通用 → 用途不明确
• 给单个工具过度负载 → 引起混淆

为什么这个概念如此重要

工具设计直接影响：

• 模型的表现水平
• 决策的准确性
• 系统的可扩展性

接下来

既然我们已经了解了工具，下一步是探讨 这些工具实际存放在哪里以及谁来执行它们。我们将拆解 MCP 服务器——将决策转化为真实动作的组件。