Tool Search and Deferred Schema Loading — Tool Use, Function Calling & MCP

Lesson 02 established that every tool definition you hand the model becomes part of the prompt on every single call — a `name`, `description`, and `input_schema` for each tool, priced and processed whether or not that turn ever uses it. Lesson 07 showed the second cost stacking on top of the first: once a library grows past a few dozen tools, the model has to discriminate among a crowded field of similarly-shaped options, and selection accuracy degrades as the field grows. Neither cost is caused by usage. Both are caused by the size of the set sitting in the `tools` array, whether the request needs three of those tools or thirty.

Most requests to a well-stocked agent only need a handful of tools. A customer-support agent might carry sixty tools across billing, shipping, inventory, and account management, but a single ticket about a delayed shipment touches four of them at most. The other fifty-six are dead weight for that call — schema tokens the model pays for and options the model has to rule out — yet they sit in the same `tools` array as the tools that matter, indistinguishable from the model's point of view until it has read all of them.

Tool search is the structural fix for both costs at once. Instead of asking the model to hold every tool's full schema in view at all times, you give it a small always-loaded core plus a way to search for the rest on demand. The tools it hasn't asked for don't disappear — they exist as `defer_loading: true` entries the model can discover mid-conversation, load only when relevant, and never pay for otherwise.

Analogy🏏Cricket

🏏 Think of it like cricket: Mumbai Indians walk into an IPL season with a full contracted squad of 25 players, but on any given match day only 11 take the field, plus one Impact Player waiting on the bench. If the team's analytics desk insisted on pulling up a detailed scouting report for all 25 players before every single delivery — Bumrah's death-over economy, a net bowler's figures from a trial match nobody remembers, a reserve batter who hasn't played since the last Ranji season — the broadcast truck's data feed would choke on information nobody at the crease needs right now. What actually happens is leaner: the scorer's table keeps a live card only for the 11 in the XI, because they are guaranteed to matter this match. Everyone else's dossier sits in the archive, untouched, until a specific situation calls one up — say, when Tilak Varma is brought on as the Impact Player and the broadcast pulls his form data on demand, mid-match, without redoing the whole team sheet. The cost of holding every dossier open scales with the size of the squad, not with how many players actually bat or bowl today. Keep the XI's data loaded because you know you need it, and fetch the rest only when the situation asks for it — that is the entire idea behind a small always-loaded core plus search for everything else.