Cartograph：让 AI Agent 更高效地发现 MCP 工具

导语

MCP 让 AI Agent 能够发现并调用外部工具，但工具数量增长后，另一个问题会变得突出：Agent 是否需要在每次任务开始时读取整个工具目录？Cartograph 试图把 MCP 的工具发现从全量目录浏览改造成按需检索，让模型先看到少量入口，再逐步获取相关工具的定义。

核心做法

• 联邦代理层：在 22 个服务器、374 个工具的部署中，Cartograph 对 Agent 暴露的是 3 个代理工具，而不是全部 374 个定义。系统先根据任务检索服务器，再在候选服务器内检索工具，形成两阶段流程。
• 运营者签名能力卡：能力卡由部署工具的运营者生成或控制，并使用 Ed25519 签名。与单纯依赖发布者排名或描述相比，这种设计强调描述的来源和完整性，同时为后续检索保留出处信息。
• Rift 相似性分析：Rift 由密度聚类、查询边界分析和令牌诊断三层组成，用于找出名称或能力容易混淆的工具。实验中识别出 49 个相似簇，其中 4 个由引导生成的能力卡形成的簇被标为高风险。
• 渐进式上下文加载：论文报告的一次 Top-5 发现交互使用 475 个 token，而按其全目录计算方式加载全部定义需要 42,450 个 token。这说明代理层可以把上下文开销从目录规模相关，转向与候选数量相关。

评测结果与限制

在作者自行构建的 49 条查询基准上，Cartograph 的 Recall@5 为 0.816，Jaccard 关键词基线为 0.592。另一个包含 119 条大语言模型生成描述的探索性比较，消除了观察到的零距离聚类，但混合不同生成机制的能力卡反而可能降低 R@5。因此，描述质量、生成流程一致性和检索策略之间存在联动，不能只用更长或更自然的描述解决问题。

性能方面，网关相较直接的 stdio MCP 调用平均增加约 5 毫秒，论文报告的相对增幅为 0.8%。不过，现有结果主要来自单个 22 服务器部署和作者构建的查询集，尚不足以证明它在更大规模、更多样的工具生态中同样稳定。

意义与影响

Cartograph 的价值不只是节省 token，也在于把工具发现变成一个可审计的检索过程：系统能够记录每次排序所使用的描述来源，并通过相似簇分析提示潜在的工具误选风险。这对拥有大量内部 API、插件或第三方 MCP 服务的组织尤其有意义。

它并不取代代码执行方案。代码执行关注 Agent 如何组合和调用能力，Cartograph 则控制哪些工具描述先进入上下文，以及这些描述从何而来。两者结合，可能成为降低 Agent 上下文成本、提升工具选择可解释性的互补路径。当前更稳妥的结论是：Cartograph 展示了一种有潜力的 MCP 检索架构，但仍需要更广泛的数据集、独立基准和真实生产负载验证。

来源：arXiv