你的 MCP 服务不需要 40 个工具

MCP 演示通常会一次性展示所有内容。它们展示每一个端点和每一个数据库表。它们声称智能体（agent）可以调用任何东西。

这在最初的十分钟里感觉很强大。但随后模型就会失败。它会调用错误的工具。它会以错误的格式传递参数。它会向搜索端点请求图表。它会重试一个具有破坏性的操作。

问题不在于 MCP。问题在于将 MCP 视为后端的一个“万能适配器”。

MCP 服务不仅仅是让你的 API 能够被智能体访问。它是一个面向极其“字面化”且极其“容易分心”的用户的产品界面。而那个用户，正是语言模型。

如果你给模型 40 个类似的工具，你并没有赋予它力量。你只是给了它 40 种“差一点就对了”的方式。

停止镜像你的 API 路由。人类可以阅读文档并理解上下文。模型则是通过名称和描述进行模式匹配（pattern-match）。

围绕用户意图来构建你的 MCP 层。

不要镜像每一个路由，而是将它们分组到清晰的边界中：

  • 一个用于市场摘要的工具
  • 一个用于发布日历的工具
  • 一个用于特定数据快照的工具
  • 一个用于历史指标的工具

API 路由说：如果你发送这个请求，服务器就会响应。 MCP 工具应该说：使用我来完成这项确切的工作，使用这些确切的输入，并期待这个特定的结果。

优秀的工具描述是路由逻辑，而不是营销文案。

错误示例： name: get_data description: Gets data from the API.

更好的做法： name: lookup_release_calendar description: Return scheduled economic events for one currency and date range. Use this before answering questions about upcoming macro events.

遵循以下规则以获得更好的智能体表现：

  1. 使用枯燥的名字。 开发者喜欢像 fetch 或 query 这样简洁的名字。模型则需要像 search_docs 或 check_deployment_status 这样具体的名称。模糊的名称代价高昂。

  2. 控制响应结构。 不要返回巨大的嵌套对象。返回能支持该任务的最小化结构。如果模型看到太多数据，它会使用错误的字段或产生幻觉（hallucinate）。

  3. 为失败而设计。 生产级质量取决于你如何处理错误。不要只返回 500 错误或空数组。要告诉模型它为什么失败了。如果没有匹配的记录，告诉模型建议用户扩大日期范围。

最好的智能体工具不是功能最强大的那个，而是模型无法误解的那个。

Source: https://dev.to/roberttidball/your-mcp-server-doesnt-need-40-tools-2ig1

Optional learning community: https://t.me/GyaanSetuAi