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
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
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.
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.
Figure 2: Observed R@5 on the 49-query author-constructed benchmark.
Metric
Rift (3-layer)
Cosine ( τ =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 Lexec is small relative to spawn cost; for longer-running tools, the overhead percentage is even lower.
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.
A multi-step agent task fails when a single tool it needs is missing, yet the tools an agent may need are too many to list: the roughly 8,200 tools on the platform we study have definitions that together exceed the context window of any model we evaluate. We present Tool Recommendation, a deployed system that gives an agent all of them, hundreds of times more than a typical MCP server exposes, through a fixed interface of three tools. It runs at the gateway between agent and tools, executing every call under the end user's own credentials and checking it against the user's consent for each service and the tools the agent may use. We evaluate it on both a public retrieval benchmark and billed end-to-end session cost. On ToolRet, Tool Recommendation places every tool a query needs in the top ten 57% more often than BM25, a lexical ranking that commercial tool search offers, and compares favorably with published systems up to nine times its size. In paired multi-step workflows, its first recommendation covered every required tool in 93% of Codex sessions, and against a fixed list of 100 tools it cut input tokens by 17% with Codex and 40% with Claude Code and the total bill in all 14 runs, by up to 40%, with no change in task completion.
The Model Context Protocol (MCP) has become a common interface for connecting large language model (LLM) agents to external tools, but its reliance on stateless, eager schema injection imposes a hidden per-turn overhead the MCP Tax or Tools Tax that practitioner reports place between roughly 10k and 60k tokens in typical multi-server deployments. This payload inflates the key-value cache, is associated with reasoning degradation as context utilization approaches published fracture points around 70%, and turns token budgets into a recurring operational cost. We introduce Tool Attention, a middleware-layer mechanism that generalizes the "Attention Is All You Need" paradigm from self-attention over tokens to gated attention over tools. Tool Attention combines (i) an Intent Schema Overlap (ISO) score from sentence embeddings, (ii) a state-aware gating function enforcing preconditions and access scopes, and (iii) a two-phase lazy schema loader that keeps a compact summary pool in context and promotes full JSON schemas only for top-k gated tools. We evaluate on a simulated 120-tool, six-server benchmark whose per-server token counts are calibrated to public audits of real MCP deployments. In this simulation, Tool Attention directly reduces measured per-turn tool tokens by 95.0% (47.3k -> 2.4k) and raises effective context utilization (a token-ratio quantity) from 24% to 91%. End-to-end figures for task success, latency, cost, and reasoning quality are reported as projections derived from the measured token counts combined with published deployment telemetry; they are not measured on live LLM agents, and we mark projected values explicitly throughout. Taken together, the results support a simple thesis: protocol-level efficiency, not raw context length, is a binding constraint on scalable gentic systems. The code for this work is accessible at https://github.com/asadani/tool-attention