从认知到实践：AI 友好的 MCP 工具构建指南

配图 by doubao ai

1. MCP 诞生记：为什么 AI 工具生态需要一场标准化革命

工具：AI 能力边界的突破点

人类文明的每次飞跃都离不开工具的进步。望远镜让我们观测宇宙，显微镜让我们探索微观世界，计算机让我们处理复杂运算。对于 AI Agent 而言，工具同样是突破能力边界的关键因素。

一个纯粹的语言模型无法获取实时信息、操作外部系统或处理私有数据。只有通过工具，AI 才能从"纸上谈兵"变成真正解决实际问题的助手。这种依赖关系在企业级应用中表现得尤为明显——没有工具支撑的 Agent 就像没有现代外设的计算机，功能严重受限。

预定义时代的技术债务

在 MCP 出现之前，我们主要通过 预定义 Function Call 来为 Agent 提供工具能力。简单来说，就像是给 AI 提供了一个"工具箱"，里面有各种预设好的工具，比如"查天气"、"发邮件"、"计算数学"等功能。AI 可以根据用户需求选择合适的工具来完成任务。

但这种方式有个致命问题：就像每次想用新电器都要重新装修房子一样，每当你想给 AI 添加一个新工具，或是修改工具的参数，就必须修改核心代码，重新编译整个应用。 想象一下，如果你的手机每次安装新 App 都需要刷机，那会是多么痛苦的体验。

更麻烦的是扩展性问题。如果你想让 AI 同时支持 百度地图、Lark、Gitlab 等多个工具，你需要在代码中预定义每一个工具的接口调用。当工具数量增加到几十个时，代码会变得异常复杂且难以维护。而且每个工具的 API 格式可能都不一样，开发者需要为每个工具写一套专门的适配代码，导致整个代码库变得臃肿且脆弱。

MCP：标准化的必然选择

因此，正如 USB 接口让我们可以随意插拔各种设备而不需要改造电脑主板，Agent 生态也迫切需要一个类似的"万能接口"——一个让工具可以随插随用的标准协议。正是基于这样的需求，MCP 协议 （Model Context Protocol） 在 2024 年底发布后迅速成为了当前 LLM 应用层最火热的话题。

正如 USB 标准让外设可以即插即用，MCP 协议为 AI 工具生态建立了统一标准。它的核心价值在于解耦——将工具实现与应用逻辑分离，让开发者可以专注于业务价值而非技术集成。

这种架构变革的意义远超技术层面。它将工具开发从"定制化作坊"模式推向"标准化工业"模式，催生了一个共享的生态系统。你开发的 Notion 连接器，其他开发者可以直接使用；别人做的数据分析工具，你也能无缝集成到自己的项目中。当每个开发者都能贡献和复用工具时，整个社区的创新效率将得到指数级提升。

2. 何时选择 MCP：架构决策的平衡艺术

不是银弹：理性看待 MCP 的适用边界

尽管 MCP 有诸多优势，但并非所有场景都需要它。 Anthropic 倡导："优先选择最简单的解决方案，只有在必要时才增加复杂性。"过度工程化往往比问题本身更麻烦。

在决定是否使用 MCP 之前，我们需要回答两个关键问题：这个场景真的需要 Agent 吗？如果需要，MCP 是最佳选择吗？

Workflow vs Agent：选择合适的架构范式

从架构角度看，LLM 应用可分为两大类：

Workflow 应用 采用预定义流程，适合路径明确、结果可预期的场景。比如电商订单处理系统：检查库存 → 计算价格 → 生成订单，每个步骤都有明确的输入输出。这类场景类似工厂流水线，用传统的工程化方法就能很好地解决，根本不需要 Agent 的动态决策能力。

Agent 应用 则适合开放性、不可预测的任务。比如智能客服需要根据用户问题动态选择查询订单、处理退款或转接技术支持。这种场景下，传统的固定流程无法应对，因为每个用户的需求都可能触发不同的处理路径，而且这些路径往往需要根据中间结果进行动态调整。

Function Call vs MCP：工具选择的权衡

确定需要 Agent 后，下一个决策是工具调用方式。

预定义 Function Call 在以下场景仍有其价值：

• 工具数量 固定 且较少（通常少于 10 个）

• 实现简单，调试方便，性能开销小

• 团队对分布式架构设计经验不足

  
  

但当面临以下需求时，MCP 的价值开始显现：

1. 多工具协同的复杂工作流：数据分析助手可能在一次任务中先调用数据库查询工具获取销售数据，然后调用图表生成工具制作可视化图表，接着调用邮件工具发送报告，最后调用日程管理工具安排后续会议。这种场景下，Agent 需要根据每一步的结果动态选择下一个工具，而且工具的组合方式无法预测。

2. 动态变化的工具生态：企业环境中，工具和服务经常发生变化。新的数据源上线、旧的 API 下线、参数修改、权限变更等都是常见情况。MCP 的动态发现能力让 Agent 能够自动适应这些变化，无需每次都修改代码和重新部署。

3. 跨平台的工具复用需求：如果需要在多个 AI 应用（比如自定义 Coze Bot、Aily Bot、Trae 等）上使用相同的工具集，MCP 的标准化优势就显得尤为重要。通过 MCP，你只需要实现一次工具集成，就能在所有支持 MCP 的平台上使用。

4. 大规模工具管理：当系统需要管理数十个甚至上百个工具时，预定义方式的维护成本会急剧上升。

决策框架：经验总结

1. 任务复杂度评估：固定流程选择 Workflow，动态决策选择 Agent

2. 工具规模预估：少量固定工具考虑 Function Call，大量或频繁变化的工具选择 MCP

3. 复用需求分析：单平台使用 Function Call 可能足够，跨平台需求倾向于 MCP

技术选择的根本目标是解决业务问题，而非追求技术的先进性。只有在高度动态、工具需求复杂多变、需要跨平台复用的情况下，MCP 的解耦优势才真正体现出价值。

3. 深入 MCP 调用机制：从请求到响应

理解 MCP 的工作原理对于设计优秀的工具至关重要。让我们通过一个完整的调用过程来剖析其内部机制，这就像人类使用工具一样——先了解有什么工具可用，然后选择合适的工具，最后使用工具完成任务。

工具发现阶段：AI 的"入职培训"

当 AI 应用启动时，它首先需要"认识"所有可用的工具。这个过程就像新员工入职时熟悉办公室的各种设备一样。MCP Client（比如 Claude Desktop、Cursor、Trae 等）会向所有已连接的 MCP Server 发送 list_tools 请求，每个 Server 返回自己能提供的工具列表，包括工具名称、功能描述、需要的参数等详细信息。

需要明确的是，MCP 的核心价值在于提供标准化的工具发现和管理机制。当所有工具通过 MCP 协议统一暴露给 AI 后，真正的循环决策和调用能力仍然来自于模型的 Function Call 机制。

决策与调用阶段：AI 的"思考"过程

当用户向 AI 提出请求时，比如"帮我分析一下昨天的销售数据"，基于 Function Call 机制，AI 会进行复杂的推理过程。

AI 首先分析用户的真实意图：用户想要什么？需要什么数据？期望什么样的输出格式？在这个例子中，AI 理解到用户需要获取昨天的销售数据并进行分析。然后，AI 会从已知的工具清单中选择合适的工具，就像工匠在工具箱中寻找合适的工具一样。

假设工具清单中有 database_query（查询数据库）、excel_reader（读取 Excel 文件）、chart_generator（生成图表）等工具，AI 会在内部进行复杂的匹配和筛选过程。它会根据每个工具的名称、描述信息以及参数要求来判断哪个工具最适合当前任务。比如，看到用户需要"昨天的销售数据"，AI 会识别到 database_query 工具的描述中提到了"查询指定日期的业务数据"，参数中包含 date（日期）和 table（数据表）等字段，这与当前需求高度匹配。

因此，AI 会判断首先需要使用 database_query 来获取数据，并在内部准备具体的调用参数，比如将"昨天"转换为具体的日期格式、确定需要查询的数据表名等。这个选择过程的准确性很大程度上取决于工具的描述是否清晰、参数定义是否完整——这也是为什么后面我会重点讨论工具设计原则的原因。

我们能看到的第一个实际输出是 AI 产生的工具调用意图，包含工具名称、工具 ID 和具体参数：

执行与反馈阶段：实际的工具操作

MCP Client 接收到工具调用意图后，会向对应的 MCP Server 发送请求，Server 执行具体的数据库查询操作。执行完成后，Client 将结果包装成工具执行结果消息返回给 AI：

循环决策：AI 的"连续思考"

最关键的是，AI 会根据工具返回的结果来决定下一步行动。看到查询结果后，AI 可能会继续发起新的 Function Call，调用 chart_generator 工具制作可视化图表，或者调用 data_analyzer 工具计算趋势。如果任务已经完成，AI 会整理结果回复用户；如果还需要更多信息或操作，这个循环会继续下去。

这种循环决策能力完全来自于 Function Call 机制——它让 AI 能够根据每次工具调用的结果动态决定下一步行动，而 MCP 则确保 AI 能够便捷地接入各种工具和数据源。

MCP 与 Function Call 的协作关系

MCP 的价值在于让 AI 能够"看见"更多样化的工具选择，而 Function Call 则提供了使用这些工具的能力。这就像一个标准化的工具仓库：MCP 负责整理和展示所有工具，确保工具的接入标准化和动态更新；Function Call 则是工匠使用工具的手艺——无论仓库里有什么工具，AI 都能用统一的方式进行调用和操作。

通过这种分工协作，开发者只需要关注业务逻辑和工具实现，而不用为每个 AI 平台重复开发接入代码，真正实现了"一次开发，处处可用"的理想状态。

4. MCP 工具设计范式：从接口思维到任务思维

重新理解"工具"的概念

在深入 MCP 工具设计之前，我们需要先澄清一个重要概念：MCP 中的"工具"（Tool）并不等同于传统意义上的 API 接口。

很多开发者在初次接触 MCP 时，习惯性地将其与微服务架构中的 RESTful API 进行类比，认为每个 API 端点就应该对应一个 MCP 工具，包括 Faas 平台也提供了一键转换的能力。这种理解是错误的，也是导致许多 MCP 工具设计不当的根本原因。

MCP 工具的粒度应当比单个 API 接口要粗得多，它更像是一个"功能单元"或"业务操作"，类似 DDD 中的一个聚合，而不是技术层面的接口调用。举个例子：

• ❌ 错误理解：为 GitHub 的每个 API 都创建对应工具，如 create_github_issue、update_github_issue、close_github_issue、add_github_comment、assign_github_user

• ✅ 正确理解：创建一个 manage_github_issue 工具，通过参数来指定是创建、更新、关闭议题，还是添加评论等操作

再比如文件管理场景：

• ❌ 错误理解：read_file、write_file、delete_file、copy_file、move_file、get_file_info

• ✅ 正确理解：manage_files 工具，通过 action 参数来指定具体操作类型

从 AI 视角思考工具设计

为什么？关键是要站在 AI 的角度思考问题。AI 不会像程序员那样思考"我需要调用哪个具体的 API"，而是会思考"我需要完成什么任务"。因此，设计工具时，需要任务导向，而非技术导向。

从技术导向到任务导向

技术导向的设计关注的是"系统提供了哪些接口"，而任务导向的工具设计关注的是"用户想要达成什么目标"。

让我们通过一个邮件系统的例子来理解这种差异：

技术导向的设计（不推荐）：

任务导向的设计（推荐）：

在任务导向的设计中，send_email 工具内部会处理所有技术细节（SMTP 连接、模板渲染、队列管理等），AI 只需要理解"我要发送邮件"这个业务概念。

任务导向的工具设计更容易写出良好的描述及名称，同时也更加符合 AI 完成场景任务的需求。

认知负荷与工具数量

AI 模型在选择工具时面临着类似人类的认知负荷问题。当可选项过多时，决策质量会下降。 研究表明，随着模型的可用工具数量上升，模型的工具选择准确率会显著降低。

这就像你走进一个有 100 种菜品的餐厅，可能会比在一个有 10 种经典菜品的餐厅更难做决定。因此，减少工具数量、提高单个工具的通用性是 MCP 工具设计的重要原则。

设计原则：CRAFTS 框架

基于对 AI 认知特点的深入理解，我们提出 MCP 工具设计的 CRAFTS 框架。这个框架涵盖了从工具定义到结果返回的完整设计考量。

C - Clear（清晰明确）

工具的名称和描述必须清晰明确，让 AI 能够准确理解工具的用途和适用场景。

✅ 好的示例：

❌ 不好的示例：

R - Robust（健壮容错）

工具应该能够优雅地处理各种边界情况，提供有意义的错误恢复建议，并在可能的情况下提供部分结果。

✅ 好的示例：

❌ 不好的示例：

A - Adaptive（灵活适应）

单个工具应该能够处理一类任务的多种变体，通过参数来控制具体行为，而不是为每种细微差别创建独立工具。

✅ 好的示例：

❌ 不好的示例：

F - Functional（完整功能）

每个工具应该完成一个完整的业务操作，避免让 AI 需要协调多个步骤才能完成一个逻辑任务。

✅ 好的示例：

❌ 不好的示例：

T - Thoughtful（逻辑合理）

参数设计要符合业务逻辑，参数之间的关系要清晰，便于 AI 正确构造调用请求。

✅ 好的示例：

❌ 不好的示例：

S - Smart（智能处理）

工具应该返回经过智能处理的结果，而不是原始数据堆。好的返回结果能减少 AI 的认知负荷并提供可操作的洞察。

✅ 好的示例：

❌ 不好的示例：

5. 未来展望：从工具过载到智能选择的演进之路

MCP 协议的快速发展让我们看到了 AI 工具生态的无限可能，但同时也让我们面临一个新的挑战：当工具数量从几十个增长到成百上千个时，如何让 AI 准确选择和使用这些工具？

传统方法的天花板：AI 的“选择困难症”

无论是预定义的 Function Call、提示注入，还是我们深入讨论的 MCP 协议，都遵循着相同的逻辑：将所有可用工具的完整信息塞进 AI 的上下文中，然后让模型从中做选择。这种方法在工具数量较少时运行良好，但随着规模扩大，我们遇到了 AI 版本的“选择困难症”。

研究表明，当面对海量工具时，即便是最先进的模型，其选择准确率也可能骤降至不足 14%。这不仅仅是一个技术问题，更反映了当前方法的根本局限性。

想象一下，如果你走进一个有 500 种工具的五金店，店员把每样工具的说明书都塞给你，然后说"自己挑吧"。即使你是经验丰富的工匠，也很难在短时间内做出最优选择。AI 面临的正是同样的困境：信息过载导致决策困难。

具体来说，主要有三个问题：

1. 提示膨胀（Prompt Bloat）：将上百个工具的详细说明书全部塞给模型，就像让一个刚入职的员工一天内背下整家人力、行政、财务、法务的所有规章制度。这不仅会迅速耗尽宝贵的 Token 预算，更会让模型“消化不良”，抓不住重点。

2. 选择模糊性 (Choice Ambiguity)：当工具箱里有十几个功能相似但应用场景各异的“数据查询”工具时，模型很容易混淆，就像我们在超市面对一整墙功能相近的洗发水一样，难以做出最优决策。

3. 调用幻觉 (Hallucinated Calls)：最危险的情况是，模型在压力之下开始“凭空想象”，调用一个根本不存在的工具，或者以一种完全错误的方式组合现有工具，这无异于让厨房新手试图用微波炉来烧水，用洗碗机来烤面包，结果只会是一团糟。

为了解决这个“认知过载”问题，社区也在开始探索一种更智能的范式。依个人总结，其演进路径可以分为两个阶段：

第一阶段：从“全部告知”到“按需推荐” (RAG-MCP)

RAG-MCP 解决方案的灵感，其实来自于我们处理海量文档的成熟经验。我们问自己：在需要模型基于一个庞大知识库（比如公司的所有内部文档）进行问答时，我们是怎么做的？我们显然不会把数万份文档全部塞进模型的提示词里，因为这不仅会撑爆上下文窗口，还会因信息噪音过大而严重影响回答质量。

我们采用的正是 检索增强生成（RAG）的范式——在模型生成回答前，先从知识库中检索出与用户问题最相关的那几段内容，作为精准、小而美的上下文提供给模型。

这个思路给了我们一个清晰的启示：既然能对“知识”进行检索，我们当然也能对“工具”进行检索。 问题的本质是共通的：面对信息过载，无论是海量文档还是海量工具，最佳策略都不是让模型“硬读”所有内容，而是通过智能检索，将一个“大海捞针”的难题，转化为一个“按图索骥”的简单任务。

这正是 RAG-MCP (Retrieval-Augmented Generation for MCP) 的核心思想。我们不再一次性向 AI 展示工具库里的所有工具，而是像一个经验丰富的项目经理那样，根据当前任务，先从庞大的工具库中检索出两三个最相关的工具，然后才将这份精心筛选过的“候选清单”递交给 AI。

这种方法的效果立竿见影：Token 使用量减少超过 50%，工具选择准确率从 13.62% 飙升到 43.13%，同时响应速度显著提升。 这好比将一个在杂乱无章的巨型仓库里大海捞针的工人，带到了一个为他当前任务量身定制、摆放整齐的工具推车前。

第二阶段：从“推荐工具”到“推荐工具组合” (Graph RAG-Tool Fusion)

单纯的按需推荐虽然高效，但忽略了一个关键事实：工具之间并非孤立存在，它们拥有自己的“社交网络”。许多任务需要一套工具组合，而非单一工具。

例如，当用户说“帮我查一下苹果公司的股价”时，一个完整的操作流需要：

1. 先调用 get_stock_code 工具，将“苹果公司”这个自然语言输入转换为标准股票代码“AAPL”。

2. 再将“AAPL”作为参数，调用 query_stock_price 工具来获取实时价格。

传统的向量检索可能只会找到 query_stock_price 这个最相关的工具，却忽略了它所依赖的前置工具，导致任务失败。

Graph RAG-Tool Fusion 这篇论文提出了一个更智能的方案：将工具及其依赖关系建模为知识图谱：

• 节点 (Nodes)：代表不同类型的工具，如可复用的“核心工具”（如 get_current_time）和具体的“业务工具”（如 query_stock_price）。

• 边 (Edges)：代表工具间的依赖关系，如“必须先调用”、“建议配合使用”或“参数来源于”。

检索时采用两步走策略：

1. 向量检索：首先，通过语义相似度找到最核心的那个工具（“关键先生”）。

2. 图遍历：然后，沿着知识图谱的边，将所有与它直接或间接相关的依赖工具（“团队成员”）一并找出，形成一个完整的、可执行的工具链。

Graph RAG-Tool Fusion 的效果看起来也是相当立竿见影：在论文中提到的 ToolLinkOS（573个工具）和 ToolSandbox 基准测试中，Graph RAG-Tool Fusion 比朴素 RAG 分别提升了 71.7% 和 22.1%。

我们有理由相信，未来的 AI Agent 将不再是那个面对庞大工具库手足无措的新手，而是一位能够根据任务需求，动态组建一支“精英工具团队”的专家。它将具备近乎人类的工具驾驭能力——不是通过蛮力尝试所有可能，而是通过智慧地理解和编排工具间的关系来解决问题。

而这一切，可能比我们想象的来得更快。