Sam Partee and colleagues at Arcade study whether assistants should find tools as needed or receive every definition up front. Their system offers search, execution and application listing over about 8,200 eligible tools. An additional authorization tool brings the visible interface to four tools and 993 tokens.
Search stays inside the gateway’s allowed scope. Execution separately checks user consent and tool permissions, keeping provider credentials outside the model’s conversation.
Two different kinds of evidence
- On the public ToolRet collection of 7,961 queries, every required tool appears in the top ten 45.2% of the time, versus 28.8% for keyword search.
- In paired workflows against a static list of 100 tools, input falls 17.2% with Codex and 39.6% with Claude Code. The equal-client-weighted bill falls 13.6% across 14 runs, with a 95% interval of 7.4–18.4%.
- The Codex bill reduction alone is 5.5%, with an interval that includes zero. Observed completion differences are statistically insignificant rather than proof of exact equivalence.
- Small catalogs can favor static lists. Fourteen short lookup tasks against eight to 37 tools use a median 22.0% more input with discovery, because each search adds another conversation turn.
Caveat: this is Arcade’s own platform study, and Claude Code’s discovery condition also shortens large tool results. Tool search alone cannot explain all the savings.
The public ranking test measures which definitions are found. The session experiment depends on Arcade’s runtime, seeded enterprise records and client behavior; it cannot be reproduced outside Arcade as described.
The operational lesson is to measure bills alongside token counts and search turns. Cached definitions are relatively cheap, while another search repeats the conversation. A small, stable tool set may already be the simpler and cheaper design.