You plug a new server into your agent and it gains sixty-eight tools at once. Search, create, update, delete, across half a dozen services you might need someday. The task you actually run touches two of them. It finishes fine, and it costs more than the same task cost yesterday — not because of the two tools you used, but because of the sixty-six you didn’t. Before the model chose anything, it was handed the whole list: every name, every description, every argument of every tool. Then it was handed the same list again on the next turn, and the one after that.

Everything you pack gets carried every mile

That list has a name. It is the manifest: the block of text that tells the model which tools exist, and for each one gives a name, a sentence or two about what it does, and the shape of the arguments it takes, usually written as a schema — a structured description of each field and its type. The manifest is not sent when a tool is called. It sits in front of the model on every turn, because the model cannot choose from a list it cannot see.

So the manifest is a pack you shoulder before setting out. Weight in a pack is not paid when you use something. It is paid at every step, by everything you brought. One measured tool server makes the arithmetic visible: its full profile exposes sixty-eight tools and spends roughly six thousand tokens on the manifest alone, before a word of your actual task is read. A trimmed profile keeps fifteen and spends about fifteen hundred. A minimal one keeps a single tool and spends around three hundred. Part of that saving is not fewer tools but thinner descriptions of the same tools — cutting schema fields that were never load-bearing took forty-four percent off the manifest by itself. Which is also the other half of the job. A tool the model can’t tell apart from its neighbour costs full weight and buys nothing.

Cutting the list also cuts the mistakes

The economy is not only about money. A long list makes the choice harder, and a model choosing badly among forty options is a worse agent than a model choosing well among five. One harness narrowed the tools visible in each phase of a task from more than forty down to roughly five, and two local models went from two passing runs out of ten to ten out of ten. Same tasks, same hardware, same weights. The only thing that changed was what the model was shown.

Once something is in the pack, a second question opens: what it can do once it’s out. A tool called Bash is one item on the list, but it holds a blade. The same entry that reads a log file can also delete a directory recursively, redirect output over a file, or start a Python interpreter that writes whatever it likes. Treating Bash as a single permission is treating a multi-tool as a spoon. A careful harness allows the tool but still inspects the command, blocking in-place edits and interpreters during phases where writing files isn’t part of the job. What the model sees and what the model may do are two different dials.

You can leave most of it behind

The obvious move, once weight is real, is to stop carrying the catalogue. Instead of loading hundreds of schemas at the start, you give the agent a handful of meta-tools — one to search for a capability, one to connect an account, one to run what it found — and the relevant tools arrive during the session, when the work asks for them. Reading email means fetching the mail toolkit mid-run, not shipping every SaaS action from the first turn. The discipline it demands is checking, at pickup, that the account is actually connected and the permission actually granted, because a tool discovered is not a tool authorised.

None of this changes what happens when a tool is finally called. The model still only writes a request and hands it off to a program that does the real work. What changes is everything before that moment: which requests are even writable, and how clearly. Designing a tool is not asking what your agent could possibly need. It is asking what you are willing to carry on every step of every run.