Advanced Tool Calling That Cut My AI Agent Costs in Half

Every conversation about AI agent costs starts with model pricing and ends without mentioning the thing that actually sets the bill: the calling pattern. An agent with sixty tools loaded pays for sixty tool schemas on every single turn, whether it uses them or not, and an agent that loops over a dataset with one tool call per item pays for every intermediate result to sit in context forever. I build MCP-heavy agents and spend my working days inside exactly this kind of environment — my own Claude Code sessions have dozens of connected MCP servers exposing hundreds of tools — so this isn't a benchmark curiosity for me. It's the difference between sessions that stay sharp all day and sessions that drown by lunch.

Two patterns fix most of it: deferred tool loading (tool search) and programmatic tool calling. Both shipped as first-class features in Anthropic's platform in late 2025, and both are really architecture patterns you can apply on any stack. Here's how they work, what I've learned running inside them daily, and where each one stops paying.

Why tool count quietly wrecks agents

The failure curve is predictable. A prototype with 8 tools works beautifully: clean context, accurate selection. Then integrations accumulate — GitHub, Slack, calendar, a database server, a browser automation server — and somewhere past 30 or 40 tools the agent develops a personality disorder. It picks near-miss tools, hallucinates parameter formats, and burns thousands of tokens of definitions before reading the user's first sentence.

Three separate costs stack up:

1. Definition overhead. Every loaded tool schema is input tokens on every turn. A single chatty MCP server can ship tens of thousands of tokens of definitions; multiply by a handful of servers and you've spent a meaningful slice of your context window on a menu.
2. Selection accuracy. Choosing between 12 tools is a different cognitive task than choosing between 60. Anthropic's own evaluations of the tool search feature showed large accuracy gains on MCP-heavy benchmarks simply from not front-loading every definition — less noise, better signal.
3. Intermediate output pollution. Serial call chains dump every raw response into context. By item forty of a loop, the model is paying attention tax on the first thirty-nine.

You cannot prompt your way out of any of these. They're architectural.

Pattern 1: Defer the tools, load on demand

Tool search inverts the default. Instead of loading all definitions upfront, the agent starts with a small always-loaded core plus one special tool: the search tool itself. Deferred tools exist as names only. When the agent needs a capability, it searches — by keyword, or by exact name with a select: prefix — and only the matched schemas load into context, where they then stay for the rest of the session.

I don't just recommend this pattern; I live inside it. My daily sessions run with the Claude connector ecosystem — Figma, Slack, Supabase, browser automation, and more — almost entirely deferred. Hundreds of tools exist as a name list; the handful each task needs get loaded when needed. Two operational lessons from the consumer side of that experience, which no feature announcement will tell you:

• Batch your schema loads. Loading tools one at a time costs a full round trip each. The select: form takes a comma-separated list, so a task that obviously needs five browser tools should load all five in one call. Well-behaved MCP servers now put this instruction in their setup notes because agents that load lazily one-by-one feel sluggish even when they're cheap.
• Tune the always-loaded set from usage, not intuition. Defer too aggressively and the agent starts every conversation searching for tools it needs 90% of the time — latency and tokens spent on ceremony. My project-scoped setup for this site is the counterexample done right: the Laravel Boost MCP server rides in the repo's .mcp.json with a tight, single-purpose toolset (database schema, tinker, route listing, docs search) that's worth keeping resident, because on a Laravel codebase those fire constantly. Resident tools should earn residency the way lines earn their place in a CLAUDE.md: by being used this week.

The economics of deferral also change how you shop for MCP servers. A server's real price is its definition payload, and the spread between a lean server and a bloated one doing the same job can be an order of magnitude. I treat "tokens of schema per useful capability" as a primary selection criterion now — more on that calculus in my agent cost optimization playbook.

Pattern 2: Write a loop, not a call chain

Serial tool calling turns iteration into a token bonfire. The canonical shape: fetch a list of N items, then make two more calls per item, with every raw response accumulating in context. Beyond a handful of items you're paying three ways — tokens for data the model only needed transiently, latency for each round trip, and accuracy, because models attend poorly to the middle of long contexts and item 14 of 15 gets processed worse than item 1.

Programmatic tool calling replaces the chain with generated code. The agent writes a script; the script runs in a sandbox, makes all the tool calls internally, does the comparisons and filtering in actual code, and returns only the conclusion to the conversation. A for-loop has no attention degradation. The fifteenth iteration executes exactly like the first.

This is also my lived practice, not just a platform feature I read about. When my content pipelines need to process dozens of database rows — the batch jobs that rewrote and re-translated large chunks of this blog — the session doesn't call a database tool once per row. It writes one PHP script that fetches everything, transforms it in a loop, and reports a summary. The conversation context holds the plan and the result, never eighty intermediate payloads. Same principle, self-hosted.

Two honest caveats from doing this repeatedly:

• Code generation is iterative. First attempts have bugs — a wrong key, a missing null check. The sandbox errors, the model reads the error, fixes, reruns. That loop is a feature (it's how humans code too), but budget for two to four iterations on nontrivial scripts.
• It has a floor. For two or three tool calls, generating and executing code costs more than just making the calls. My threshold is around five sequential calls or any per-item iteration; below that, plain tool calling is simpler and usually cheaper.

If you're running this in production with model-generated code, isolation is non-negotiable: sandboxed execution, no host credentials inside the sandbox, tool calls proxied through a bridge that holds the secrets. The generated script should never be able to see an API key even if it tries.

Pattern 3: Make each tool definition earn its tokens

The third layer is unglamorous: the definitions themselves. Having authored a lot of tool and skill definitions — and having watched agents misread plenty of them — my working rules:

• Descriptions are for disambiguation, not documentation. The model needs enough to choose correctly between your tools, not a man page. Move background into the tool's output or an on-demand resource.
• One usage example per non-obvious parameter format. Dates, enums, nested objects. A single example like {"date": "2026-01-15"} collapses the space of plausible-but-wrong formats an agent will otherwise explore at your expense. Test the example against the real API first — a wrong example is worse than none, because the model will follow it faithfully.
• Kill redundant variants. Three near-identical tools with overlapping descriptions are an accuracy tax on every selection. Consolidate behind parameters.

This is the same discipline as pruning skills and trimming system prompts: everything the agent carries is a recurring charge. I've written before about why context beats configuration — tool definitions are just configuration that bills you per turn.

These are patterns, not vendor features

Tool search is lazy loading. Programmatic calling is code-generation-and-execution. Neither concept is Claude-specific, even though Anthropic shipped the most polished implementations. On LangChain, a custom framework, or anything else: keep a registry of tools with lightweight metadata, give the agent a search function over it, load schemas on selection; and for data-heavy workflows, have the agent emit a script that runs against your tool layer in a sandbox and returns conclusions only. The MCP ecosystem is trending the same direction — retrieval over tools instead of tools-in-context — which I dug into when I looked at what's replacing the load-everything MCP pattern.

The deeper shift is mental: stop thinking of an agent as a chatbot that uses tools, and start thinking of it as an orchestration system that happens to include an LLM. Then the design question stops being "which tools should I add?" and becomes "what should be resident, what should be discoverable, and what should be a script?" Design for the 500-tool future now — the tool count only goes up — and long sessions stop degrading, which is half the battle I describe in my context rot playbook.

Adoption order

1. Over ~15-20 tools: defer. Small resident core, search for the rest, batch your loads.
2. Any workflow with 5+ sequential calls or per-item loops: go programmatic. Conclusions in context, data in the sandbox.
3. Every tool with a non-obvious parameter: add one tested example.
4. Audit definitions quarterly. Servers update; payloads bloat back.

I design and build MCP-heavy agent systems — tool architecture, server selection, sandboxed execution, the works — for teams whose agent bills or error rates have stopped making sense. If yours is at that stage, describe what your agent does and where it hurts and I'll tell you honestly which of these layers will move your numbers.