我构建了一个小型健康食品MCP服务器，主要教训是智能体需要枯燥的工具表面

Reddit r/AI_Agents 工具
mcp agents tool-design llm api-design structured-data food

摘要

作者构建了一个健康食品MCP服务器，并发现智能体使用多个狭窄、受限的工具比使用一个灵活的工具表现更好，强调需要一个枯燥的工具表面来减少大语言模型的幻觉。

我最近构建了一个小型健康食品MCP服务器。表面上听起来很简单：向智能体暴露食谱内容。但有趣的部分不是食品数据。有趣的部分是意识到MCP服务器需要提供多少结构，智能体才能变得有用。如果你只给LLM食谱文本，它可以总结，但它也会开始编造结构、混淆类别、猜测营养字段，或者返回看起来正确但难以复用的内容。所以我尝试让工具表面变得枯燥且受限： * 列出高级热量类别 * 列出饮食/餐次/宏量营养素分组 * 列出可用食谱文件及预览 * 通过slug获取完整的结构化食谱 * 通过关键词搜索食谱文档 目标不是让智能体“更聪明”。目标是减少它需要猜测的内容。我注意到以下几点： 1. 小型工具比一个大型的“万能”工具更容易让模型正确使用。 2. 稳定的slug比让模型从自由文本中记住名称更有用。 3. 服务器应该拥有内容模型。智能体应主要负责选择、获取、比较和解释。 4. 技能/提示有帮助，但当MCP工具已经围绕任务设计时，它们的表现会好得多。 这让我认为MCP更多是关于为智能体设计一个干净的交互表面，而不是向LLM暴露API。好奇其他人是如何思考的：当你构建MCP服务器时，你更喜欢许多狭窄的工具，还是更少但参数更灵活的大工具？
查看原文

相似文章