小红书精读：Hybrid Semantic Tool Discovery for Enterprise MCP Gateway: Architecture and Implementation

把2000个工具塞进0.8%上下文？

各位算法同学们，当你的 MCP 网关挂了 2000 多个工具，每次对话光工具 schema 就要吃掉 70% 上下文，这 Agent 还怎么做？今天这篇 PayPal 的工程论文，直接告诉你不用改客户端、不用换模型，就能把工具注入从 140k token 砍到 1.3k。

📄 Hybrid Semantic Tool Discovery for Enterprise MCP Gateway: Architecture and Implementation

🔧 技术创新点：把“全量工具注入”重构成“上下文选择问题”，只暴露当前步骤相关的工具。具体有三点： 🔧 搞出两个 MCP 元工具 tool_search 和 execute_tool，先搜后执行，Agent 按需拉取，而不是每次全量灌入。 🔧 检索用混合策略，BM25 稀疏匹配 + 稠密向量检索，再用 Reciprocal Rank Fusion 融合 top-k，兼顾精确匹配和语义相似。 🔧 索引更新支持无停机插入删除，还带用户级权限过滤，直接在企业访问控制边界内做检索。

📊 实验效果：在 PayPal 生产环境，MCP 工具 token 消耗从 140.2k（占上下文 70.1%）降到 1.3k（占 0.8%），减少 99%。 ✅ 这 99% 的降幅直接降低每查询推理成本，企业规模下收益非常可观。 ✅ 兼容六种 MCP 客户端，包括 Claude Code、ChatGPT、Copilot、Cursor 等，无需改客户端。

总结：这篇思路很务实，适合被工具膨胀折磨的工程团队参考。坑在于工具检索的召回质量会直接影响最终准确率，得自己攒一套高质量的工具描述和 embedding 数据。别指望开箱即用，但架构方向值得抄作业。

原文：AlphaXiv