Cartograph: Federated Tool Discovery with Operator-Attested Retrieval for AI Agents

Justice Owusu Agyemang; Michael Agyare; Kwame Opuni-Boachie Obour Agyekum; Kwame Agyeman-Prempeh Agyekum; Francisca Adoma Acheampong; Jerry John Kponyo

cs.CLSep 13, 2026

Cartograph: Federated Tool Discovery with Operator-Attested Retrieval for AI Agents

Authors: Justice Owusu Agyemang, Michael Agyare, Kwame Opuni-Boachie Obour Agyekum, Kwame Agyeman-Prempeh Agyekum, Francisca Adoma Acheampong, Jerry John Kponyo

Organizations: VIA Cybersecurity Lab, Kwame Nkrumah University of Science and Technology, Kumasi, Ghana · Quantum and Assistive Technologies Lab, Kwame Nkrumah University of Science and Technology, Kumasi, Ghana · Ghana Communication Technology University, Ghana

Abstract

The Model Context Protocol (MCP) enables AI agents to discover and call tools, but loading every definition becomes expensive as connected catalogs grow. We present Cartograph, a federated MCP proxy that changes agent-visible tool discovery from $O(n)$ catalog traversal to $O(k)$ progressive disclosure. Cartograph combines three mechanisms: (1) operator-attested capability cards, Ed25519-signed descriptions generated under the deploying operator's control rather than ranked publisher copy; (2) Rift, a three-layer confusable-cluster analysis comprising density clustering, query-margin analysis, and token diagnosis; and (3) two-stage retrieval, which ranks servers before tools. On a 22-server, 374-tool deployment, Cartograph exposes three proxy tools instead of 374 definitions. A 49-query author-constructed benchmark yields R@5 of 0.816, compared with 0.592 for a Jaccard keyword baseline, while a measured top-5 discovery exchange uses 475 tokens rather than 42,450 under the stated full-catalog accounting. Rift identifies 49 confusable clusters, including four HIGH-risk clusters in bootstrap-generated cards. An exploratory comparison of 119 LLM-generated descriptions removes the observed zero-distance cluster but shows that mixing card-generation regimes can reduce R@5. Gateway measurements over ten trials add 5ms mean latency (0.8%) relative to direct stdio MCP calls. Cartograph is complementary to code-execution approaches: it controls which tool descriptions are surfaced and records the provenance of the descriptions used for ranking for each query.

Figures & tables

System or line of work	Primary contribution	Difference from Cartograph
MCP / MCP Registry [ 10 , 11 ]	Tool interface and public server metadata	Cartograph adds per-query tool ranking and signed operator text
Code execution with MCP [ 6 ]	On-demand loading through local code and files	Cartograph supplies provider-neutral selection and provenance before loading
A2A [ 1 ]	Agent-card discovery and collaboration	Cartograph ranks tool descriptions, rather than agents or delegated tasks
Toolformer, Gorilla, ToolLLM, BFCL [ 16 , 13 , 14 , 18 ]	Model tool use, retrieval, or evaluation	Cartograph is a protocol-facing proxy, not a model or benchmark
SCITT [ 2 ]	Transparency for signed supply-chain statements	Cartograph applies operator signatures to retrieval descriptions and routes tools
Cartograph	Federated MCP tool discovery	Two-stage retrieval plus operator-attested capability-card text

Table 1: Positioning of Cartograph against adjacent protocols, tool-use research, and supply-chain attestation. The table distinguishes each line of work’s primary contribution from Cartograph’s deployment-level design.

Panel of Figure 1 — Figure 1: Cartograph separates the governance path (top) from the runtime path (bottom). Capability cards are attested and quality-gated before indexing; the agent exchanges discovery requests and top- $k$ schemas with the index, then forwards an execution call through the Gateway to the upstream server.

Component	Standard MCP	Cartograph	Savings
tools/list (fixed)	38,250	169	38,081
discover response	—	306	—
Agent reasoning (upper bound)	4,200	—	4,200
Total per task	42,450	475	41,975
Reduction	—	—	98.8%

Table 2: Token consumption per task cycle. The fixed tools/list cost is measured via the Claude tokenizer; the agent reasoning estimate is an upper bound based on 374 tool definitions in context.

Method	R@1	R@3	R@5	MRR	Mean R
Cartograph (two-stage)	0.449	0.755	0.816	0.596	1.78
Keyword (Jaccard)	0.388	0.531	0.592	0.463	1.69
Random (expected)	0.003	0.008	0.013	0.017	187.5

Table 3: Retrieval quality on the 49-query author-constructed benchmark. Results are descriptive, not a claim of general-purpose statistical superiority.

Panel of Figure 2 — Figure 2: Observed R@5 on the 49-query author-constructed benchmark.

Metric	Rift (3-layer)	Cosine ( $\tau$ =0.65)	Jaccard ( $J$ $>$ 0.25)
Total clusters detected	49	38	56
HIGH-risk clusters	4	—	—
MEDIUM-risk clusters	8	—	—
LOW-risk clusters	37	—	—
Tools in any cluster	136 (36.4%)	—	—
Within-server clusters	45 (91.8%)	—	—

Table 4: Rift results on 374 tools. Rift provides risk stratification that neither baseline can produce.

Configuration	HIGH-risk	MEDIUM-risk
Rift (full 3-layer)	4	8
Rift (no margin analysis)	0	0

Table 5: Ablation: margin analysis is the component that assigns Rift’s HIGH and MEDIUM risk labels.

Server	Tools	Identical	LLM summary (excerpt)
daedalus	43	0/43	“Container orchestration server providing…”
lattice	26	0/26	“Persistent knowledge graph tracking entities…”
resilient-write	20	0/20	“Atomic, verified writes with safety checks…”
phoenix	12	0/12	“Task execution server with checkpointing…”
resilient-read	7	0/7	“Chunked file reading with byte-range, line-based…”
gen-pilot	7	0/7	“Generation planning and template management…”

Table 6: Card quality: bootstrap vs. LLM-generated. LLM cards produce 100% distinct per-tool summaries, eliminating the degenerate zero-distance cluster.

Configuration	R@1	R@5	MRR	Failures (/49)
Bootstrap (all 22)	0.449	0.816	0.596	9
LLM-only (7 servers)	0.204	0.429	0.306	28
Hybrid (LLM + bootstrap)	0.490	0.776	0.609	11

Table 7: Retrieval quality by card configuration. Hybrid improves R@1 but creates centroid imbalance that degrades R@5, showing that uniform card quality is essential.

Metric	Direct MCP	Gateway	Overhead
Mean latency	676	681	5 (0.8%)
Median latency	677	678	1 (0.1%)
StdDev	6	8	—
Min	662	673	—
Max	682	696	—

Table 8: Gateway latency overhead (10 trials, milliseconds). The 0.8% overhead applies to tools where

L_{\text{exec}}

is small relative to spawn cost; for longer-running tools, the overhead percentage is even lower.

LLM Tool Use

Large language model tool use studies how models select, call, and coordinate external tools to extend their reasoning and take actions.

See all 295 papers

Hybrid Semantic Tool Discovery for Enterprise MCP Gateway: Architecture and Implementation
Aug 25, 2026Olympia Saha, Amy Wang, Srinivasan ManoharanTool Discovery for LLM Agents LLM Tool Use
PayPal, Inc.
Tool Recommendation for Multi-Step Agents: Finding Every Tool a Task Needs
Oct 16, 2026Sam Partee, River Stevens, Thierry Damiba +1Tool Selection for Language Model Agents Tool Discovery for LLM Agents
Tool Attention Is All You Need: Dynamic Tool Gating and Lazy Schema Loading for Eliminating the MCP/Tools Tax in Scalable Agentic Workflows
Apr 23, 2026Anuj Sadani, Deepak KumarGated Attention LLM Tool Use

Aug 25, 2026J/K move · Enter open · S save

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

Olympia Saha, Amy Wang, Srinivasan Manoharan

PayPal, Inc.

Tool Discovery for LLM Agents LLM Tool Use LLM Context Management Model Context Protocol

Open paper AskPDF arXiv

Large language model (LLM) agents invoke external tools to retrieve and reason over information beyond pretrained knowledge. The Model Context Protocol (MCP) standardizes how such tools are surfaced, and a proxy MCP server aggregates many backend servers behind a single endpoint providing a secure, governable chokepoint for authentication, policy enforcement, and observability. This architecture creates two compounding challenges: a context-engineering bottleneck where full tool schemas saturate the model context window before any user query, and a tool discoverability barrier where users and agents cannot identify the best tool among 2,000+ indexed tools across 200+ MCP servers. Prompt caching reduces reprocessing cost but neither frees context capacity nor improves accuracy. We present SCOUT (Selective Context Optimization for Universal Tooling), which reframes tool exposure as a context-selection problem, injecting only tools relevant to the current step. SCOUT surfaces two MCP meta-tools -- tool_search and execute_tool -- where tool_search performs hybrid retrieval, fusing BM25 sparse matching with dense vector search via Reciprocal Rank Fusion to return the top-k relevant tools. Backed by zero-downtime catalog update pipelines, SCOUT resolves both context saturation and tool discovery challenges. In production at PayPal, SCOUT reduces MCP tool-token consumption from 140.2k tokens (70.1% of context) to 1.3k tokens (0.8%), a 99% reduction, cutting per-query inference cost at enterprise scale. Because SCOUT is surfaced as standard MCP tools, it is model-agnostic and requires no client-side modifications.

Abstract

LLM Tool Use

Explore similar work

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

Tool Recommendation for Multi-Step Agents: Finding Every Tool a Task Needs

Tool Attention Is All You Need: Dynamic Tool Gating and Lazy Schema Loading for Eliminating the MCP/Tools Tax in Scalable Agentic Workflows