Tool Routing Tables

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Locate validateEmail with a host offering retrieval/read and chat. Teaching names code_search(symbol)/source_read(path) illustrate routing, not guaranteed registered current tools; verify the actual inventory.

Mechanism

Map operation, supported interface, input and evidence type. Source lookup retrieves paths/content then reads candidates to validate symbols. Chat may explain but is not location evidence. Missing tools use a supported repository adapter with scope/provenance rather than invented names.

Bad example

Ask chat where validateEmail lives and call a plausible generated path retrieved source. Guess unavailable tool identifiers.

Good example

Verify current interfaces, route lookup to supported source retrieval for validateEmail and read actual returned paths to inspect definition/location. Chat is not evidence. Use documented local search/read fallback where supported, reporting scope; uninspected candidates do not establish definition and unregistered tools are not called.

Why the change matters

Routing connects capability to interface/evidence and separates generating an answer from retrieving source. Reading verifies paths beyond search candidates.

Observable expectation

An illustrative trace contains verified tool/query/path/definition. No matches/read failures retain their state without chat-generated replacements.

Inspect current identifiers and repository scope; no real tool is called.

Limits

Hosts/repositories may prefer indexes/CLIs/other readers. Verify routing and incomplete definition coverage. Provenance remains unconfirmed; capability grants no extra access.