详细内容或原文请订阅后点击阅览
MCP 工具设计：实用方法和权衡
在这篇文章中，我们展示了 MCP 工具设计的错误所在以及如何使用实际的上下文工程方法来修复它。
来源:亚马逊云科技 _机器学习当模型上下文协议 (MCP) 工具表现不佳时，原因很少是协议本身，而是工具设计。许多团队首先按原样公开现有 API，并信任代理来解决其余问题。这是将 API 扩展到代理系统和生成式 AI 编码工具的自然方式。对于简单的用例，它可以工作。但通常情况并非如此。
您必须针对大型语言模型 (LLM) 和代理系统的工作方式设计工具。如果没有这个，您将面临工具调用失败、参数值错误以及重试的风险，从而浪费上下文并降低性能。在这篇文章中，我们将展示 MCP 工具设计的错误所在以及如何使用实际的上下文工程方法来修复它。
大多数失败背后都有两个问题。第一个是浮肿。无论是否使用该工具，工具定义都会在每次调用时加载到 LLM 的上下文中。在用户提出单个问题之前，多个连接的 MCP 服务器可能会消耗大量上下文。当上下文被填满时，法学硕士的推理能力可能会下降，并导致会议效率降低。
第二个是混乱。随着推理能力的下降，法学硕士会做出更糟糕的选择，调用错误的工具并选择错误的参数。随后的重试会进一步加剧膨胀，从而使问题变得更加复杂。工具之间的语义相似性、太多的选项以及不明确的命名也会导致混乱。常见的解决方案是通过更清晰的定义、自然语言映射和使用示例来丰富工具描述。这确实有助于缓解混乱。但所有增加的东西都有可能加剧膨胀，并使你正在努力解决的问题变得更加复杂。
以下部分探讨了解决这些问题的方法和权衡。为了使它们具体化，我们构建了几个示例，使用 MCP 协议公开模拟的 K-12 内容搜索 API。您将在本地运行它们并使用 Kiro CLI 与它们交互，以便自己比较差异。