SchemaRouter: Field-Aware Tool Routing for Efficient Heterogeneous Agentic RAG

# Field-Aware Tool Routing for Efficient Heterogeneous Agentic RAG
Source: [https://arxiv.org/html/2608.21375](https://arxiv.org/html/2608.21375)
###### Abstract

Heterogeneous agentic retrieval\-augmented generation \(RAG\) systems increasingly orchestrate many external APIs, internal databases, vector stores, and graph stores across domains as varied as commerce, media, enterprise, and science\. Exposing every tool description to an LLM agent, or retrieving tools by vector similarity, leads to two failure modes with real cost:*over\-fetching*\(selecting unneeded tools/fields inflates retrieval payload, tokens, and latency\) and*under\-fetching*\(missing required fields yields unanswerable retrievals\)\. We presentSchemaRouter, a lightweight routing layer that models tools, endpoints, parameters, response fields, domain concepts, units, provenance, and license as a*schema graph*, and emits an executable tool plan specifying exactly which tools and response fields to fetch\. A small LLM step extracts intent, domain concepts, and source constraints; field selection is then*deterministic*over the graph \(intent\-group projection∪\\cupconcept–field matching bridged by a domain\-concept alias layer\), guaranteeing valid, minimal, provenance\-annotated plans\. On a materials\-science benchmark \(N=110N\{=\}110\) we evaluate not only planning accuracy but downstream RAG effects: retrieved\-context tokens, end\-to\-end latency, final\-answer accuracy, and*answer trustworthiness*\(provenance/license attribution\)\. SchemaRouter attains answer accuracy of 0\.71—matching fetch\-everything within CI and above prompt\-all’s 0\.66 \(CIs overlap\)—at near\-minimal retrieved context \(227 tokens vs\. 2066 for fetch\-everything\) and∼\\sim2\.7×2\.7\\timeslower end\-to\-end latency than prompt\-all \(its routing prompt is schema\-independent\), with the best tool\-exact rate \(0\.93\) and parameter validity \(1\.0\)\. It further grounds schema\-sourced provenance and license in 62% of answers—including per\-database license strings a reader LLM cannot produce from parametric knowledge—versus≈\\approx0% for all baselines\. We further report a methodological finding: optimizing planning\-level*over\-fetch*is counterproductive\. Minimizing selected\-field count cuts downstream accuracy to 0\.56 at negligible token savings; a recall\-preserving projection recovers top accuracy\. Retrieved\-context tokens and downstream accuracy—not field\-count parsimony—are the objectives that matter\. We frame SchemaRouter’s contribution as*efficiency, schema\-independent scaling, and verifiable provenance/license\-grounded answers at competitive accuracy*\.

## 1Introduction

Modern agentic RAG systems for science route queries across many heterogeneous data sources—materials property databases, chemical databases, literature APIs, internal experiment stores\. As the tool inventory grows, the agent must decide not merely*which tool*to call, but*which endpoint*,*which parameters*, and*which response fields*it actually needs\. Two common strategies scale poorly\. Placing all tool/field descriptions in the prompt \(*prompt\-all*\) is accurate with a strong LLM but injects the entire schema into every routing call, inflating cost and latency and eventually exceeding context limits\. Retrieving tools by embedding similarity \(*vector\-only*\) does not reliably yield*executable*plans with valid parameters and fields\.

The motivation for this work is not accuracy in isolation but the*downstream cost of imprecise retrieval*\. Fetching tools and fields freely, or fetching everything, \(i\) slows retrieval, \(ii\) returns unnecessary data, \(iii\) enlarges the context the reader LLM must process, and \(iv\) risks diluting the answer with irrelevant information\. A middle layer that fetches only what is needed should save tokens, searches, and time while preserving answer quality\.

We proposeSchemaRouter, a schema\-graph routing layer that produces minimal, executable, provenance\-annotated tool plans\. The method is*domain\-independent by construction*: it assumes only a tool ecosystem whose endpoints expose typed parameters and response fields with attachable metadata \(units, source, license\)—a structural pattern present in commerce, media, enterprise, and scientific APIs alike\. In this paper we instantiate and evaluate it on a materials\-science tool set, where provenance and licensing are first\-class concerns; empirical cross\-domain evaluation is left to future work\. We nonetheless note that license/attribution metadata—our strongest answer\-level result—is a cross\-domain concern \(media rights, data\-use terms\), suggesting the mechanism is useful beyond scientific tools\.

Our contributions:

1. 1\.A*field\-aware*formulation of tool routing: selection at the response\-field granularity, not just tool granularity, with a domain\-concept alias layer that bridges the vocabulary gap between natural\-language queries and canonical schema field names\.
2. 2\.A*downstream\-centric*evaluation: beyond planning metrics, we measure retrieved\-context tokens, end\-to\-end latency, and final\-answer accuracy under a controlled fixture protocol\.
3. 3\.An honest characterization with a methodological finding\. Recall\-preserving SchemaRouter reaches the top group in answer accuracy at near\-minimal retrieved\-context cost, and grounds verifiable provenance and license that a reader LLM cannot recover from parametric knowledge\. Over\-fetching \(fetch\-all\) wastes cost without improving accuracy under a strong reader\. Conversely, minimizing planning\-level over\-fetch is counterproductive: it sacrifices downstream accuracy for a field\-count metric that barely affects token cost\.

## 2Related Work

Tool\-use LLMs\.Toolformer\[[10](https://arxiv.org/html/2608.21375#bib.bib1)\], Gorilla/APIBench\[[7](https://arxiv.org/html/2608.21375#bib.bib2)\], API\-Bank\[[4](https://arxiv.org/html/2608.21375#bib.bib3)\], and ToolLLM\[[9](https://arxiv.org/html/2608.21375#bib.bib4)\]study when and how LLMs call APIs and evaluate call correctness and hallucination\. We differ by explicitly evaluating*endpoint, parameter, and response\-field*selection after tool selection, and by measuring the downstream RAG consequences of that selection\.GraphRAG and graph\-based tool retrieval\.GraphRAG\[[1](https://arxiv.org/html/2608.21375#bib.bib5)\]builds knowledge graphs over the corpus for query\-time augmentation; Graph RAG\-Tool Fusion\[[5](https://arxiv.org/html/2608.21375#bib.bib6)\]and Agent\-as\-a\-Graph\[[6](https://arxiv.org/html/2608.21375#bib.bib7)\]model tool dependencies as a graph for retrieval\. SchemaRouter graphs the*tool/API schema itself*\(fields, units, provenance, license\) to produce executable, minimal plans, rather than retrieving knowledge or ranking tools by relevance\. In the production RAG system from which our benchmark’s tool inventory is drawn, the schema graph is maintained in an embedded property\-graph store\[[2](https://arxiv.org/html/2608.21375#bib.bib12)\];111The production RAG agent is a proprietary internal system and is not released with this paper\. To keep the evaluation harness self\-contained and reproducible, we serialize a frozen JSON export of the graph and read it directly—the released harness therefore does not depend on Kuzu at runtime\. All schema signals used by SchemaRouter \(nodes, edges, aliases, provenance, license\) are preserved in the export; see Appendix[A](https://arxiv.org/html/2608.21375#A1)for the isolated contribution of each signal\.the released evaluation harness reads a frozen JSON export of that graph so that all routers operate over an identical, versioned schema without a runtime graph\-DB dependency\.Schema linking and structured tool calling\.Field selection is a sibling problem to*schema linking*in text\-to\-SQL, where models align natural\-language mentions with columns of a target schema\. Early work coupled linking to the parser via relation\-aware attention\[[12](https://arxiv.org/html/2608.21375#bib.bib10)\]; more recent systems decouple linking from downstream generation with either an element\-level ranker\[[3](https://arxiv.org/html/2608.21375#bib.bib9)\]or a decomposed prompting pipeline\[[8](https://arxiv.org/html/2608.21375#bib.bib8)\]\. SchemaRouter transports this idea from a single\-database query compiler to a multi\-tool RAG router: it generalizes the target from columns of one schema to fields of many heterogeneous APIs, uses a deterministic \(non\-LLM\) selector once concepts are extracted, and adds a metadata layer \(unit, provenance, license\) absent in SQL settings\. On the tool\-planning side, model\-side function calling and task decomposition frameworks\[[11](https://arxiv.org/html/2608.21375#bib.bib11)\]let an LLM emit structured tool calls end\-to\-end\. These are complementary to, not competing with, a schema router: SchemaRouter is the layer that decides*which*tools and*which*fields the caller \(LLM or otherwise\) should target, and can serve as a retrieval front\-end for a function\-calling agent that then executes the plan\.Scientific RAG / materials informatics\.Our benchmark targets materials\-science APIs, where units, provenance \(calculated vs\. experimental vs\. literature\), and license constraints are first\-class\.

## 3Problem Definition

Given a natural\-language queryqqand an inventory of tools𝒯\\mathcal\{T\}, each toolttexposing an endpoint, parametersPtP\_\{t\}, and response fieldsFtF\_\{t\}\(with per\-field unit, provenance, and license metadata\), a router must output a*tool plan*: a set of\(t,params,fields⊆Ft\)\(t,\\text\{params\},\\text\{fields\}\\subseteq F\_\{t\}\)tuples\. We evaluate the plan directly \(planning\-level\), and then its downstream effect: the plan induces a retrieval whose result is passed to a reader LLM that must answerqq\. LetG​\(q\)G\(q\)be the gold plan; we measure tool/field precision–recall–F1F\_\{1\}, parameter validity, executable\-plan rate, over\-fetch ratio, and metadata completeness, plus downstream answer accuracy, retrieved\-context tokens, and latency\.

## 4Method: SchemaRouter

Schema graph\.Nodes:Tool,Endpoint,Parameter,ResponseField,DomainConcept,Unit,SourceType,LicensePolicy,FieldGroup,Intent\. Edges connect endpoints to their parameters and fields, fields to units/source\-type/concepts, and concepts to canonical fields \(MAPS\_TO\_CONCEPT/ALIASED\_AS\)\. The graph is exported once from the target system’s API registry and frozen for reproducibility\.

Routing\.\(1\) A small LLM step extracts \{intent, domain concepts, parameter values, source constraint, explicitly named tools\}\. \(2\) Candidate tools are selected by intent domain and required field groups; explicitly named tools force a selection; a source constraint filters by provenance \(experimental/calculated/literature\)\. When the query is ambiguous and no tool is named, candidates are ranked by concept\-match score \(exact field match weighted above substring\), then schema priority, then fewest total fields—never rewarding breadth\. \(3\)*Field projection is deterministic*: identifiers are always included; concept–field matches are added \(normalized, with a domain\-concept alias layer, so “bulk modulus”→\\tok\_vrh, “magnetic moment”→\\tototal\_magnetization\); the intent’s field groups are added as a recall safety net\. \(4\) Unit/provenance/license requirements are attached from the graph\.

This design makes plans valid by construction \(fields drawn fromFtF\_\{t\}, parameters fromPtP\_\{t\}\), minimal \(no whole\-catalog dumping\), and metadata\-complete, using only a small routing prompt\. Algorithm[1](https://arxiv.org/html/2608.21375#alg1)summarizes the procedure\.

Algorithm 1SchemaRouter \(per query\)1:query

qq; schema graph

GG; intent registry

ℐ\\mathcal\{I\}
2:tool plan

π\\pi\(list of

\(t,𝑝𝑎𝑟𝑎𝑚𝑠,𝑓𝑖𝑒𝑙𝑑𝑠,𝑚𝑒𝑡𝑎\)\(t,\\mathit\{params\},\\mathit\{fields\},\\mathit\{meta\}\)\)

3:

\(i,C,P,S,T\)←Understand​\(q\)\(i,C,P,S,T\)\\leftarrow\\textsc\{Understand\}\(q\)⊳\\trianglerightLLM: intent, concepts, params, source\-constraint, named tools

4:if

T≠∅T\\neq\\emptysetthen

5:

𝒯cand←\{Resolve​\(G,t\):t∈T\}\\mathcal\{T\}\_\{\\text\{cand\}\}\\leftarrow\\\{\\textsc\{Resolve\}\(G,t\):t\\in T\\\}⊳\\trianglerightexplicit tools override

6:else

7:

𝒯cand←\{t∈G\.tools:domain\(t\)∈ℐ\[i\]\.domains∧groups\(t\)∩ℐ\[i\]\.required≠∅\}\\mathcal\{T\}\_\{\\text\{cand\}\}\\leftarrow\\\{t\\in G\.\\text\{tools\}:\\text\{domain\}\(t\)\\in\\mathcal\{I\}\[i\]\.\\text\{domains\}\\land\\text\{groups\}\(t\)\\cap\\mathcal\{I\}\[i\]\.\\text\{required\}\\neq\\emptyset\\\}
8:if

S≠⊥S\\neq\\botthen

9:

𝒯cand←\{t∈𝒯cand:sourceType​\(t\)=S\}\\mathcal\{T\}\_\{\\text\{cand\}\}\\leftarrow\\\{t\\in\\mathcal\{T\}\_\{\\text\{cand\}\}:\\text\{sourceType\}\(t\)=S\\\}
10:endif

11:

𝒯cand←Rank​\(𝒯cand,C\)\\mathcal\{T\}\_\{\\text\{cand\}\}\\leftarrow\\textsc\{Rank\}\(\\mathcal\{T\}\_\{\\text\{cand\}\},C\)⊳\\trianglerightconcept\-match score; web deprioritized; priority; fewest fields

12:endif

13:

π←∅\\pi\\leftarrow\\emptyset
14:for all

t∈𝒯candt\\in\\mathcal\{T\}\_\{\\text\{cand\}\}do

15:

F←Identifiers​\(t\)F\\leftarrow\\textsc\{Identifiers\}\(t\)
16:for all

c∈Cc\\in Cdo

17:

F←F∪ConceptMatch​\(G,t,c\)F\\leftarrow F\\cup\\textsc\{ConceptMatch\}\(G,t,c\)⊳\\trianglerightnormalized name \+ alias layer

18:endfor

19:

F←F∪⋃g∈ℐ​\[i\]\.requiredFieldsOf​\(G,t,g\)F\\leftarrow F\\cup\\bigcup\_\{g\\in\\mathcal\{I\}\[i\]\.\\text\{required\}\}\\textsc\{FieldsOf\}\(G,t,g\)⊳\\trianglerightrecall safety net

20:

𝑚𝑒𝑡𝑎←AttachMeta​\(G,t,F\)\\mathit\{meta\}\\leftarrow\\textsc\{AttachMeta\}\(G,t,F\)⊳\\trianglerightunit, source\_type, license

21:

π\.append​\(\(t,P\|params​\(t\),F,𝑚𝑒𝑡𝑎\)\)\\pi\.\\text\{append\}\(\(t,\\ P\|\_\{\\text\{params\}\(t\)\},\\ F,\\ \\mathit\{meta\}\)\)
22:endfor

23:return

π\\pi

## 5Benchmark

The frozen tool inventory contains 19 heterogeneous tools—materials\-property databases \(Materials Project, OQMD, JARVIS, NOMAD, COD, and others\), chemistry \(PubChem\), literature APIs \(arXiv, Crossref, OpenAlex, PubMed, Europe PMC\), a business\-disclosure source \(DART\), and web/Q&A fallbacks—exposing 166 response fields in total\. We build a benchmark ofN=110N\{=\}110queries across nine categories: single\-tool property lookup \(36\), chemical lookup \(12\), provenance\-sensitive \(12\), multi\-field property lookup \(10\), literature search \(10\), cross\-source comparison \(8\), unit\-sensitive \(8\), negative queries with no suitable tool \(8\), and ambiguous single\-entity queries \(6\)\. The category mix is unbalanced \(single\-tool dominant\); we report both micro\- and category\-averaged results and caution that macro averages weight sparser categories equally\.

Gold plans are grounded in the frozen schema \(valid tools/fields by construction\)\. For the downstream study we use frozen fixtures: each tool record assigns deterministic ground\-truth values to every field; requested fields carry the answer, other fields act as distractors\. Answer correctness is judged by an LLM judge given the gold values \(robust to formatting\); negative queries require the reader to decline\.

## 6Experiments

Setup\.Self\-hosted vLLM \(Qwen\-3\.5, 122B, MoE\), temperature 0, reasoning disabled\. Baselines: prompt\-all, vector\-only \(TEI embeddings\), rule\-based, and fetch\-all \(all tools, all fields\)\. Retrieval is simulated over fixtures; context tokens and latency are measured from the reader call’s usage\.

Table 1:Planning metrics \(N=110N\{=\}110\)\. Over\-fetch lower is better\.SchemaRouter’s higher planning over\-fetch \(0\.46\) is*deliberate*: it selects intent\-relevant field*groups*for downstream recall, not field\-count\-minimal plans\. As §[6\.1](https://arxiv.org/html/2608.21375#S6.SS1)shows, this raises downstream accuracy from 0\.56 to 0\.71 at only188→227188\{\\to\}227retrieved\-context tokens—i\.e\. the over\-fetch*ratio*is a misleading proxy; actual token cost stays near\-minimal\.

Table 2:Downstream RAG \(N=110N\{=\}110, identical LLM judge, bootstrap 95% CI\)\. E2E = routing \+ answer latency\. Answer accuracy tracks field recall; top\-4 CIs overlap\.*no\-field\-projection*= SchemaRouter’s tool selection with*all*fields \(ablation\); its parity with SchemaRouter confirms recall\-preserving field selection captures the needed fields at lower token cost \(227 vs\. 321\)\.

Table 3:Answer trustworthiness \(N=110N\{=\}110, deterministic string check, non\-negative queries\)\. Schema\-only license strings \(e\.g\. per\-DB policies\) cannot be produced from the reader’s parametric knowledge\.Findings\.

- •*Over\-fetch wastes cost\.*Fetch\-all matches prompt\-all accuracy within CI while using∼\\sim9×9\\timesthe retrieved\-context tokens; on ambiguous multi\-source queries it further pollutes answers with conflicting values\.
- •*Under\-fetch harms\.*Vector\-only prunes and executes poorly; it is significantly worst \(0\.33, non\-overlapping CI\)\.
- •*Downstream accuracy is recall\-bound\.*Accuracy tracks field recall across routers\. With recall\-preserving field selection \(§[6\.1](https://arxiv.org/html/2608.21375#S6.SS1)\) SchemaRouter reaches0\.71, tied with the highest\-recall routers and above prompt\-all \(0\.66; CIs overlap\), at 227 retrieved\-context tokens \(9×9\\timesfewer than fetch\-all\) and∼\\sim2\.7×2\.7\\timeslower E2E than prompt\-all\.
- •*Trustworthiness is the answer\-level advantage\.*SchemaRouter grounds provenance and per\-database license in 62% of answers via schema\-sourced strings that baselines produce at≈\\approx0%—critical for verifiable answering \(scientific provenance; media/data\-use licensing\)\.

Scalability of routing cost\.The prompt\-all baseline places the full tool/field schema in*every*routing call: measured on our 19\-tool/166\-field inventory the schema segment is 5,042 characters \(≈\\approx1,260 tokens at 4 char/token\) per query, growing at≈\\approx66 tokens per additional tool \(≈\\approx6\.6k tokens at 100 tools,≈\\approx33k at 500 tools\) until it exceeds practical context budgets\. SchemaRouter’s routing prompt is schema\-*independent*: a fixed instruction listing the intent registry \(1,432 characters,≈\\approx360 tokens\) plus the query\. Growth in the routing prompt is proportional to the number of*intent categories*\(not tools\) and is negligible in practice\. This mechanism underlies the observed∼\\sim2\.7×2\.7\\timesE2E gap at 19 tools \(Table 2\); the extrapolation beyond 19 tools is analytical, not measured, and we flag it as such\.

*Could prompt caching close the gap?*Prefix / KV\-cache reuse can amortize a static schema segment across queries and reduce prompt\-all’s marginal cost for a*fixed*schema\. Two caveats: \(i\) the schema segment is not static in deployments where the tool inventory or per\-tool descriptions evolve \(typical for internal RAG systems where tools are added, deprecated, or re\-permissioned\); every change invalidates the prefix\. \(ii\) Even with a perfect cache, prompt\-all still pays the*decode\-time attention*cost over the full schema, so latency scales with inventory size even when input\-side cost does not\. SchemaRouter is orthogonal to prefix caching: any cache strategy that helps prompt\-all also helps SchemaRouter’s much smaller instruction prefix, so the relative gap is preserved\.

Is the trustworthiness comparison fair?Each router’s reader receives exactly the metadata its*own*plan carries\. Baseline plans carry none because they do not model provenance/license; SchemaRouter’s do, sourced from the graph\. One could also inject metadata into a prompt\-all reader—but that presupposes a source of per\-database license/provenance, which is precisely what the schema graph supplies\. The gap thus reflects a genuine capability difference, not a context\-construction artifact: the≈\\approx0% schema\-only\-license rate for baselines confirms a reader LLM cannot recover these strings from parametric knowledge\.

On the LLM judge\.Accuracy is judged by the*same*Qwen\-3\.5\-122B model that generates the answers, prompted with a stricter rubric \(see released harness\); this is a same\-family judge and we treat its absolute numbers with caution\. Two mitigations: \(i\) the trustworthiness axis \(Table 4\) does not use the judge—it is a deterministic regex check for schema\-only license/provenance strings, so the≈\\approx0% vs\. 62% gap is judge\-independent; \(ii\) we conducted a hybrid spot review on a stratified sample \(n=40n\{=\}40\) in which an independent LLM \(Claude, different family\) read the raw answers and qualitatively confirmed the direction of the trustworthiness result\. A fully blinded cross\-family judge over the entire benchmark remains future work\.

Ablation\.Table[4](https://arxiv.org/html/2608.21375#A1.T4)isolates each schema signal\. Removing field projection \(dump all fields of the selected tools\) more than doubles over\-fetch and halves fieldF1F\_\{1\}; removing the provenance layer drops provenance/license completeness to zero; removing source\-type routing degrades tool accuracy on provenance\-sensitive queries\. A naive “concept→\\towhole group” expansion crashed planning precision, whereas the surgical domain\-concept alias layer raised recall*and*precision, isolating the alias layer as the mechanism that resolves the query–schema vocabulary gap\. Figure[3](https://arxiv.org/html/2608.21375#A1.F3)visualizes the joint effect onF1F\_\{1\}, over\-fetch, and provenance completeness\.

### 6\.1Operating point: planning parsimony vs\. downstream accuracy

SchemaRouter’s field selection exposes a precision/recall knob\. The*minimal\-field*point minimizes planning over\-fetch \(ratio 0\.16, field\-F1F\_\{1\}0\.75\) but cuts downstream accuracy to 0\.56; the*recall\-preserving*point \(adding intent\-relevant field groups\) raises over\-fetch to 0\.46 yet lifts downstream accuracy to 0\.71—at only188→227188\{\\to\}227retrieved\-context tokens\. The two points share identical tool selection\. This exposes a tension:minimizing the planning over\-fetch*ratio*is the wrong objective; it trades away downstream answer accuracy for a field\-count metric that barely affects real token cost\. We adopt the recall\-preserving point and argue that retrieved\-context tokens plus downstream accuracy, not field\-count parsimony, are the objectives practitioners should optimize\.

02002004004006006008008001,0001\{,\}0001,2001\{,\}2001,4001\{,\}4001,6001\{,\}6001,8001\{,\}8002,0002\{,\}0002,2002\{,\}2000\.40\.40\.60\.6SchemaRouterfetch\-allprompt\-allrule\-basedvector\-onlyRetrieved\-context tokens \(mean\)Answer accuracyFigure 1:Answer accuracy vs\. retrieved\-context tokens \(N=110N\{=\}110\)\. SchemaRouter reaches top accuracy at near\-minimal context; fetch\-all matches accuracy at9×9\\timesthe tokens; under\-fetching routers collapse\.fetch\-allprompt\-allrule\-basedSchemaRouter00\.20\.20\.40\.40\.60\.61⋅10−21\\cdot 10^\{\-2\}000\.620\.62Schema\-only license citeFigure 2:Fraction of answers citing schema\-only license strings \(unavailable from parametric knowledge\)\. Only SchemaRouter propagates them, from the schema graph\.

## 7Discussion and Error Analysis

SchemaRouter’s residual answer errors decompose into two classes: tool\-selection misses \(ambiguous entities routed to a neighboring domain\) and reader errors\. The field\-recall misses that once dominated this decomposition are resolved by the alias layer plus the recall\-preserving intent\-group projection \(§[6\.1](https://arxiv.org/html/2608.21375#S6.SS1)\)\. Under a strong reader, precise \(recall\-preserving\) and bloated retrievals reach the same top accuracy, so over\-fetching buys nothing but cost; the informative axes become tokens, latency, scalability, and metadata fidelity—on all of which SchemaRouter leads or ties\. This equivalence may not hold for weaker readers, where the accuracy cost of bloat \(context pollution\) that our motivation anticipates could re\-emerge\.

## 8Threats to Validity and Limitations

Statistical\.N=110N\{=\}110; bootstrap 95% CIs overlap for the top routers, so we make*no*answer\-accuracy superiority claim—only efficiency \(non\-overlapping on tokens/latency\) and trustworthiness \(non\-overlapping,≈\\approx0% vs 62%\)\. Results are a single run; vLLM at temperature 0 still exhibits scheduler nondeterminism, so we avoid fine\-grained accuracy orderings\. Multi\-seed and multi\-model replication remain future work\.Reader strength\.A strong 122B reader resists distraction, so over\-fetching*wastes cost*without measurably*degrading*accuracy \(except on ambiguous multi\-source queries\); weaker readers or prose retrieval may surface the degradation our motivation anticipates\.Fixtures\.Downstream retrieval is simulated with frozen, structured \(key=value\) fixtures with deterministic ground\-truth values; this controls confounds and enables exact judging but understates the context pollution of real, unstructured document retrieval\. Absolute accuracy is therefore setup\-specific; cross\-router*comparisons*under the identical protocol are the intended reading\.Benchmark\.Gold plans are author\-constructed and partly template\-generated \(materials\-science centric, single annotator, no inter\-annotator agreement\); template uniformity makes the set larger but easier, so numbers are not comparable across benchmark versions\.Latency\.End\-to\-end latencies are measured on a shared, loaded self\-hosted server and are indicative rather than controlled; the routing\-cost*ratio*is the robust signal\.Method\.The domain\-concept alias layer is authored from domain vocabulary and needs maintenance as domains expand; the scalability argument beyond 19 tools is analytical\.

## 9Conclusion

SchemaRouter is a schema\-graph routing layer that fetches only the tools and fields a scientific query needs\. With recall\-preserving field selection it reaches downstream answer accuracy of 0\.71 \(tied with the highest\-recall routers, above prompt\-all; CIs overlap\) at near\-minimal retrieved\-context tokens and∼\\sim2\.7×2\.7\\timeslower end\-to\-end latency \(schema\-independent routing\), and grounds verifiable provenance and per\-database license in its answers, which baselines cannot supply from parametric knowledge\. We further show that optimizing planning\-level over\-fetch is counterproductive: field\-count parsimony sacrifices downstream accuracy at negligible token savings, so retrieved\-context tokens and answer accuracy are the objectives that matter, and over\-fetching \(fetch\-all\) buys no accuracy over prompt\-all at∼\\sim10×10\\timesthe tokens\. We position schema\-aware, field\-aware routing as a practical mechanism for*cost, latency, scale, and answer verifiability*in heterogeneous agentic RAG \(evaluated on scientific tools\), and release the harness, benchmark, and fixtures for reproducibility\.

## Reproducibility

The evaluation harness, the frozen 19\-tool schema inventory \(JSON export of the production graph\), theN=110N\{=\}110benchmark queries with gold plans, the deterministic downstream fixtures, and the six router implementations \(four evaluated \+ fetch\-all \+ three ablations\) are released at[https://github\.com/JDeun/SchemaRouter\_research](https://github.com/JDeun/SchemaRouter_research)\. All results in this paper are reproducible with a single command sequence documented in the repositoryREADME\.md\. The production RAG agent that maintains the Kuzu\-backed schema graph is a proprietary internal system and is not released; the frozen JSON export in the harness preserves every schema signal \(nodes, edges, alias layer, provenance, license\) used by SchemaRouter\.

## Acknowledgements

Inference was performed on a self\-hosted vLLM deployment \(Qwen\-3\.5\-122B\-A10B\) and TEI embedding service operated by KailosLab\. We thank the maintainers of the open\-source materials\-science and chemistry APIs whose public schemas motivated the benchmark design\.

## Use of AI Tools

The author used large language models \(Claude, Anthropic\) as writing assistants for prose editing, LaTeX formatting, and consistency checking during manuscript preparation\. All research contributions —problem formulation, method design, benchmark construction, experiment design, execution, and analysis—as well as the interpretation of results and all substantive claims are the author’s\. Every citation was independently verified against arXiv; the released harness reproduces every numerical result reported in this paper\.

## Appendix AAblation Detail

Table[4](https://arxiv.org/html/2608.21375#A1.T4)reports the full planning metrics under each ablation of SchemaRouter’s schema signals \(N=110N\{=\}110\)\. Tool\-exact and executable\-plan rates are preserved by all variants \(all≥\\geq0\.87,≥\\geq0\.93\); the deltas concentrate on field\-level precision, over\-fetch, and RQ5 metadata completeness\. The*no\-field\-projection*row shows the collapse when field\-aware selection is disabled \(over\-fetch0\.16→0\.730\.16\{\\to\}0\.73,F1F\_\{1\}0\.59→0\.310\.59\{\\to\}0\.31\)\. The*no\-provenance*row confirms that source\-type and license attachment is purely a schema\-graph artifact \(both drop to0with no other metric change\)\. The*no\-source\-routing*row shows the smaller but non\-trivial cost to source\-aware tool routing on provenance\-sensitive queries\.

Table 4:SchemaRouter ablation on planning metrics \(N=110N\{=\}110\)\.Fullno\-fieldno\-provno\-src00\.50\.5110\.590\.590\.310\.310\.750\.750\.710\.710\.460\.460\.730\.730\.160\.160\.190\.191111011valueFieldF1F\_\{1\}Over\-fetch↓\\downarrowProv\. Compl\.Figure 3:Ablation of SchemaRouter schema signals \(N=110N\{=\}110\)\. Field projection controls over\-fetch and precision; the provenance layer alone drives metadata completeness \(RQ5\)\.
## Appendix BCategory\-wise Results

Table[5](https://arxiv.org/html/2608.21375#A2.T5)reports FieldF1F\_\{1\}by category\. SchemaRouter is strongest on provenance\-sensitive queries—the RQ5 target—and competitive on chemical, literature, and multi\-field lookups\. It underperforms on ambiguous single\-entity queries, where its concept–field matcher cannot decide the intended source without a name; on those, prompt\-all’s whole\-schema view wins\. Negative queries \(no suitable tool\) evaluate toF1=0F\_\{1\}\{=\}0for all routers by construction: the metric denominator is the empty gold\-field set\. Executable\-plan rate and tool accuracy on negatives are the meaningful signals there \(both routers correctly return empty plans in most cases; details in the released harness\)\.

Table 5:Category\-wise FieldF1F\_\{1\}\(N=110N\{=\}110; PO=prompt\-all, VO=vector\-only, RB=rule\-based, SR=SchemaRouter\)\.nn= queries per category\.Table[6](https://arxiv.org/html/2608.21375#A2.T6)reports the RQ5 metadata completeness \(unit / provenance / source\-type match / license\) aggregated across queries whose gold requires each field\. Provenance and license completeness are where the schema graph is decisive: full SchemaRouter reaches1\.001\.00on both against≈\\approx0for every baseline; unit completeness and source\-type match are already high for prompt\-all because the reader can often infer them from field names alone—the graph adds a small margin only\.

Table 6:RQ5: Unit, Provenance, Source\-type match, and License completeness \(N=110N\{=\}110\)\.
## Appendix CRouting\-cost Scaling

Figure[4](https://arxiv.org/html/2608.21375#A3.F4)contrasts routing prompt size for prompt\-all versus SchemaRouter as the tool inventory grows\. Prompt\-all injects the entire schema into every routing call, so cost grows≈\\approx66 tokens per additional tool \(measured on our 19\-tool inventory:≈\\approx1,260 tokens\)\. SchemaRouter’s routing prompt is a fixed instruction plus the query, so it isO​\(1\)O\(1\)in inventory size\. The extrapolation is analytical \(from measured per\-tool cost\); the crossover with practical context budgets occurs well before catalogs of a few hundred tools\.

050501001001501502002002502503003003503504004004504505005000112233⋅104\\cdot 10^\{4\}8k context budget\# tools in inventoryrouting prompt tokensprompt\-all \(≈\\approx66 tok/tool\)SchemaRouter \(schema\-independent\)Figure 4:Routing prompt token cost vs\. inventory size\. Prompt\-all grows linearly with the catalog and saturates practical context budgets past a few hundred tools; SchemaRouter is inventory\-independent\. Measured at 19 tools \(≈\\approx1,260 vs\.≈\\approx360\), extrapolated linearly\.
## Appendix DUnderstand\-step Prompt

SchemaRouter’s single LLM call \(line 1 of Algorithm[1](https://arxiv.org/html/2608.21375#alg1)\) uses the prompt shown below\. In practice we deploy it in Korean; we give the English translation here and note that the released harness \(§[Reproducibility](https://arxiv.org/html/2608.21375#Sx1)\) contains the exact deployed text\. The prompt is fixed—schema\-independent except for the intent list—and does not carry any tool or field descriptions\.

> You are the query\-understanding module of a science/materials retrieval agent\. Analyze the user query and output only the following JSON \(do not select tools/fields outside the schema\): \{"intent": <intent name or null\>, "domain\_concepts": \[<concrete property/field concepts needed for the answer; never empty\>\], "parameters": \{<param\_name: value, e\.g\. formula: "LiFePO4"\>\}, "target\_apis": \[<specific DB/sources named by the user; empty otherwise\>\], "source\_constraint": <"calculated" \| "experimental" \| "literature" \| null\>\} Rules: - •domain\_concepts is never empty\. List short English keys close to schema field names \(band gap→\\toband\_gap, formation energy→\\toformation\_energy\_per\_atom, paper title/abstract→\\totitle, summary\)\. Prefer individual field concepts to group names\. - •If the user names a DB \(arXiv, Materials Project, OQMD, PubChem, COD, Crossref, OpenAlex, DART, …\), put it in target\_apis\. For comparison/cross\-check, list all named DBs\. - •source\_constraint: mark provenance restrictions if the query specifies them \("measured experimentally"→\\toexperimental, "DFT/first\-principles"→\\tocalculated, "from literature"→\\toliterature\); else null\. - •Even ambiguous queries about a specific material/compound/paper \("about graphene", "titania properties", "caffeine info"\) are classified into the property/structure/literature intent, not general web info; put the entity into domain\_concepts/parameters\. - •If no tool is suitable \(live sensors, weather, email, calendar, images, …\) return intent=null, target\_apis=\[\], domain\_concepts=\[\]\. Available intents: \{intents\}\. Output JSON only\.

The list\{intents\}is populated from the frozen inventory \(13 intents in the released harness\)\. The remainder of SchemaRouter \(candidate selection, field projection, metadata attachment\) is deterministic Python code operating on the schema graph\.

## References

- \[1\]D\. Edge, H\. Trinh, N\. Cheng, J\. Bradley, A\. Chao, A\. Mody, S\. Truitt, and J\. Larson\(2024\)From local to global: a graph RAG approach to query\-focused summarization\.arXiv preprint arXiv:2404\.16130\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[2\]Kùzu Development Team\(2023\)Kùzu: an embeddable property graph database management system\.Note:[https://kuzudb\.com](https://kuzudb.com/)Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[3\]H\. Li, J\. Zhang, C\. Li, and H\. Chen\(2023\)RESDSQL: decoupling schema linking and skeleton parsing for text\-to\-SQL\.InAAAI,Vol\.37,pp\. 13067–13075\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[4\]M\. Li, Y\. Zhao, B\. Yu, F\. Song, H\. Li, H\. Yu, Z\. Li, F\. Huang, and Y\. Li\(2023\)API\-Bank: a comprehensive benchmark for tool\-augmented LLMs\.arXiv preprint arXiv:2304\.08244\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[5\]E\. Lumer, P\. H\. Basavaraju, M\. Mason, J\. A\. Burke, and V\. K\. Subbiah\(2025\)Graph RAG\-Tool fusion\.arXiv preprint arXiv:2502\.07223\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[6\]F\. Nizar, E\. Lumer, A\. Gulati, P\. H\. Basavaraju, and V\. K\. Subbiah\(2025\)Agent\-as\-a\-graph: knowledge graph\-based tool and agent retrieval for LLM multi\-agent systems\.arXiv preprint arXiv:2511\.18194\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[7\]S\. G\. Patil, T\. Zhang, X\. Wang, and J\. E\. Gonzalez\(2023\)Gorilla: large language model connected with massive apis\.arXiv preprint arXiv:2305\.15334\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[8\]M\. Pourreza and D\. Rafiei\(2023\)DIN\-SQL: decomposed in\-context learning of text\-to\-SQL with self\-correction\.arXiv preprint arXiv:2304\.11015\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[9\]Y\. Qin, S\. Liang, Y\. Ye, K\. Zhu, L\. Yan, Y\. Lu, X\. Cong, X\. Tang, B\. Qian, S\. Zhao,et al\.\(2023\)ToolLLM: facilitating large language models to master 16000\+ real\-world APIs\.arXiv preprint arXiv:2307\.16789\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[10\]T\. Schick, J\. Dwivedi\-Yu, R\. Dessì, R\. Raileanu, M\. Lomeli, L\. Zettlemoyer, N\. Cancedda, and T\. Scialom\(2023\)Toolformer: language models can teach themselves to use tools\.arXiv preprint arXiv:2302\.04761\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[11\]Y\. Shen, K\. Song, X\. Tan, D\. Li, W\. Lu, and Y\. Zhuang\(2023\)HuggingGPT: solving AI tasks with ChatGPT and its friends in Hugging Face\.arXiv preprint arXiv:2303\.17580\.Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.
- \[12\]B\. Wang, R\. Shin, X\. Liu, O\. Polozov, and M\. Richardson\(2020\)RAT\-SQL: relation\-aware schema encoding and linking for text\-to\-SQL parsers\.InACL,Cited by:[§2](https://arxiv.org/html/2608.21375#S2.p1.1)\.