Recoleta Item Note

Giving MCP servers a voice in tool selection

这篇文章提出一种针对 MCP（Model Context Protocol）工具选择的轻量改进：让服务器通过一个约定俗成的 _tool_gating 工具参与每轮工具筛选。其目标是减少无关工具进入提示词、降低误选概率，并在确定性命令场景下直接跳过模型调用。

mcptool-selectiontool-gatingagent-infrastructurecontext-optimization

Summary

这篇文章提出一种针对 MCP（Model Context Protocol）工具选择的轻量改进：让服务器通过一个约定俗成的 _tool_gating 工具参与每轮工具筛选。其目标是减少无关工具进入提示词、降低误选概率，并在确定性命令场景下直接跳过模型调用。

MCP 服务器目前只能注册工具并提供 schema，但无法影响模型如何选工具；结果是无关工具也会被一并加载进上下文，浪费 token 并增加误选风险。
当工具数量增多时，LLM 的工具选择准确率会明显下降；文中引用研究称：超过约 20 个工具后性能显著变差，而“全部工具都加载”的朴素基线准确率可低至约 14%。
这很重要，因为多服务器 MCP 生态下工具数量会快速膨胀；作者举例一个 weather MCP 就会带来 20,000 tokens 的额外上下文，既贵又拖慢响应。

核心机制非常简单：服务器暴露一个约定名称的工具 _tool_gating；客户端若在 tools/list 中发现它，就在每次请求、构建给模型的工具列表之前先调用它。
_tool_gating 返回两类裁决：exclude（本轮把某些工具从模型上下文中移除）和 claim（服务器声明该请求应由某个工具直接处理，客户端可跳过模型直接调用该工具）。默认未提及的工具即 include。
该方案不需要修改 MCP 规范、不需要 capability flag，仅依赖已有的 tool 机制和少量客户端逻辑改造。
作者原型实现中，服务器侧采用基于关键词/模式的简单规则而非 ML：例如精确匹配 /projects、/list 直接 claim；识别只读意图时排除 notes_write、notes_edit、project_new；无 archive 意图时排除 project_archive。
客户端流程为：连接时探测 _tool_gating；每轮先向所有支持 gating 的服务器请求裁决；若有 claim 则直接调用工具并返回；否则对工具列表做 exclude 过滤后再发送给模型。若 claim 失败，还可回退到正常 LLM 路径。

作者在自己的 Python MCP 服务器 pman-mcp 和 Rust 客户端 chell 上做了原型验证；在只读请求场景下，能够从每轮候选中移除 4 个工具。
上述过滤带来约 318 tokens/turn 的节省，这是文中给出的直接实测数字。
对于 slash commands（如 /projects、/new ...），系统可通过 claim 机制完全不调用模型，从而以更确定、更低延迟的方式完成命令；文中未给出具体时延数字。
作者认为这是“小而稳”的优化，但若被更多工具和客户端采用，潜在收益可扩展到数千甚至数百万 tokens 的节省；这一点是前瞻性主张，未提供系统性大规模实验数据。
与 OpenAI Agents SDK tool_filter、Google ADK、Portkey embedding-based filter、STRAP megatool 等方案相比，本文最强的具体主张是：过滤判断应尽量由最了解工具能力的服务器端来做，而不是完全放在客户端或外部框架中。

Built with Recoleta

Turn arXiv, Hacker News, OpenReview, Hugging Face Daily Papers, and RSS into local Markdown, Obsidian notes, Telegram digests, and a public site.