I read Philipp Schmid’s piece “Why Agents Are Soon Only Going to Have 1 Tool” this morning, and I’ll admit my first reaction was a slightly defensive “hang on a minute”. I’ve spent a good chunk of this year building an MCP server with more than 30 tools for Calendrz, so an article telling me agents are about to throw all of that away and keep a single exec tool got my attention, to put it mildly 🙂

Having read it twice (and gone back to my own code in between), I think he’s right about the direction. I also think most people will draw the wrong conclusion from it. Let me explain.

What Code Mode Actually Is

The idea (Cloudflare popularised it as “Code Mode”, and Anthropic wrote about the same pattern as code execution with MCP) goes like this. Instead of handing the model a catalogue of tools and letting it call them one at a time, one per turn, with every raw result piped back into its context, the harness gives it a single exec(code) tool. The tool schemas get compiled into compact TypeScript declarations, the model writes a short script that calls tools.whatever(...), and that script runs in a sandbox. It can chain calls, loop, filter, fan out with Promise.all and only hand back the bit the model actually needs.

His Linear example says it best: a script lists projects, fetches issues and archives the unassigned ones. The sandbox makes 55 API calls, and the model sees exactly one line: “Archived 42 unassigned issues across 12 projects.” He also quotes Factory, who moved their Droid agent to Code Mode, picked up 3.5 points on Terminal-Bench and cut model spend by 15%. Not bad for what is, at heart, “let the model write a for loop”.

And it makes perfect sense when you think about it. Models nowadays are trained on mountains of code; asking them to drive an API one JSON blob at a time is a bit like asking a seasoned developer to work only through a REPL that forgets everything after each line. Why would you?

Where I Felt the Pain Myself

The Calendrz Smart Scheduler is a classic tool-calling agent. You type “find me 30 minutes with Alice next Tuesday morning” and it looks Alice up, finds the free slots, proposes a time, waits for your “yes” and books the meeting. Each of those steps is a separate tool call, a separate round trip to the model, and a separate chunk of tokens. The loop is capped at 10 iterations, simply because I didn’t want a confused agent burning quota in circles at 3am. Even so, a good part of the work on it went into collapsing round trips: tightening the prompt so the first reply proposes a time AND the account to use, turning a four-turn confirmation dance into two, and moving the default model to Haiku because, as it turns out, a scheduling chat doesn’t need a big model to do its job.

That’s exactly the overhead Code Mode removes. Look up the attendee, check availability, pick the earliest mutual slot and create the event: that’s four lines of script, not four trips through the model.

The other pain was even more telling. The MCP clients calling the Calendrz tools kept guessing the parameter names for get_events: timeMin/timeMax, time_min/time_max, start_date/end_date, plain start/end, you name it. The validator rejected them (correctly) with an error that only said what was wrong, which gave the agent nothing to correct against. The fix was to append the full list of accepted parameters, with types and descriptions, to every validation error, so the agent can retry with the right names. Validation stays strict; the error message just became useful.

Why One Tool Makes Your Tools More Important, Not Less

Here’s the thing: Code Mode doesn’t delete your tools. It moves them behind the sandbox. The model still needs to know what tools.calendrz.find_free_slots takes and what it returns, which is why Schmid points out that MCP servers increasingly ship an outputSchema next to the inputSchema. The TypeScript declarations the model codes against are generated from your names, your types and your descriptions. If those are vague, the agent now writes a confidently wrong script and runs all 55 calls of it before anyone notices (as opposed to one wrong call at a time, which was at least slow enough to spot).

So no, I’m not ripping out the Calendrz tools. If anything, the bar for them just went up. I’ve said before that agent experience is replacing user experience as the metric that matters, and Code Mode is the clearest case for it yet: your tool descriptions and return types are now the API documentation a model programs against, and the model won’t phone your support line when they’re ambiguous.

Keep the Private Stuff Below the Bridge

The bit of the article I’d underline twice is the “structured bridge”: every tools.* call from the sandbox crosses back to the host, which can inject OAuth tokens outside the sandbox, validate the input and pause for confirmation before anything destructive. That’s where your policy lives, and it’s also where your privacy has to live.

Calendrz is a good example of why. When you ask the scheduler for a slot with someone who also uses Calendrz, their busy times get folded into the search on the server, and the tool returns only the mutually free slots. The agent never sees anyone else’s calendar, so it literally has nothing to leak, whatever the prompt says; there’s a rule in the system prompt too, but that’s defence in depth, not the defence. (As it happens, a sandbox that keeps intermediate data out of the model’s context is the same principle, arrived at for cost reasons rather than privacy ones.) Bear that in mind before you hand an agent an exec tool and a pile of raw APIs: “the model only sees what the script returns” is a nice property, but it’s the script the model itself wrote. Don’t rely on it to keep someone else’s diary private. Put that contract in the tool.

So What Now?

If I were running an engineering team that ships an API or an MCP server, here’s what I’d do on Monday morning:

• Read your tool names, parameter names and descriptions as if you were a model seeing them for the first time, and fix the ones that only make sense to the person who wrote them.
• Add output schemas. A script that knows what comes back can chain calls; one that has to guess will guess wrong.
• Make your errors tell the caller how to get it right, not just that it got it wrong.
• Enforce permissions, confirmations and data boundaries in the tools and the host, never in the prompt alone.

Schmid himself hedges on whether every agent ends up with exactly one tool (“Not necessarily”, in his words), and I agree: for a one-shot “what’s on my calendar today?” a plain tool call is perfectly fine. But for anything with three or more dependent steps, my bet is that Code Mode becomes the default within a year, and the products that win will be the ones whose tools are a pleasure to program against.

Bottom line: the agent may be down to one tool, but it’s your tools it’s calling. Make them worth calling 😉