That night I was assembling memory for an agent, so it could remember what we discussed across days instead of forgetting every time the window closed. Then I came across a ready-made backend that connects through MCP in a single line, with everything bundled in: a place to store data, a member system, a place to keep files. So I wired it in, around 2am, watched it print Connected, and felt like the agent had picked up one more piece of armour for the night.
The next night I sat down to count how many tools the agent had connected by now. Fifty-something. The browser driver, the Discord connector, all the way down to the backend I'd been so pleased with the night before. So I measured the real thing: across the recent work, which ones did the agent actually reach for?
The result stopped me. Out of fifty-something, only six were ever called. The rest just sat there connected, including the backend from the night before. It had never been called a single time.
My first instinct was to keep it around, just in case I needed it someday. Leaving it connected can't hurt, right? But that's exactly the misread. A tool you wire up to an AI isn't free.
Part 1The night I added it, the night I pulled it
Back to that night: what made me wire that backend in almost on reflex was how easy it was. One line, everything included. All I thought at the time was "good to have, in case the agent's memory needs it." I never once asked whether it needed it right now.
The audit the next night made it clear. The tools that actually fired were a handful: the browser driver, the Discord connector, the memory layer I was already running myself. The rest were all connected "just in case," and most of those just-in-case tools never got their turn.
So I pulled that backend out, along with several others that never fired. It took under a minute. The thing is, it had done nothing wrong at all. It had simply done nothing.
Part 2Why "just connected" is negative value
Every time an AI sets out to do one piece of work, it first has to read the whole list of connected tools to see what's available to reach for. Fifty tools means fifty descriptions stuffed into the context window every single round, used or not. The ones that never fire still take up the room.
The hidden cost here stacks in two layers. The first is memory space (Token Overhead): the room unused tools take is room that should be left for the actual work. The second is heavier, Tool Confusion: stack five similar tools on top of each other and the odds the AI grabs the wrong one go up to match, its reasoning slows and turns more error-prone. An unused tool isn't neutral, then. It quietly interferes with the decision on every turn.
This is where people slip. We treat "more tools connected = more capable," so we keep stacking them up into a kind of Tool Bloat. But these aren't like things in a drawer that cost nothing to store. They charge rent every time the AI moves. Having more tools is not the same as having more capability. Sometimes it just means the AI is carrying dead weight.
The backend from that night has one more tail to it. In the end the agent's memory settled on a stack I run myself, a different one entirely, not the ready-made service I'd connected. Which means it was an option that lost at the design stage and was never called even once. It just sat there until the night I audited and found it.
Part 3Measure your own
The one rule to remember
If you remember one thing from this, make it this: don't count how many tools you connected. Count how many the AI actually called. Everything else is just detail about making that number visible.
A quick audit checklist
- Tell "connected" apart from "called." The list of connected tools looks busy, but the real thing is the number of times each gets reached for. Those two can be dozens of times apart.
- Open the actual logs. Don't guess which ones probably get used. Trace it from the real record of calls in the work you've already done.
- Anything that never fires across many tasks, pull it. Pulling it loses nothing; if you want it back someday it's one line to reconnect. Keep a backup before you pull, for peace of mind.
- Sweep up the leftovers a tool quietly leaves behind. Some, once connected, drop config files all over the place. The tool is gone but the litter stays.
As for the precise way to measure how many times each one truly fired: we count from the trace of where it was actually invoked, not from where it merely gets mentioned. Those two give numbers dozens of times apart (I've watched the loose count inflate the figure by roughly 50x). That part is what we're turning into a repeatable procedure: the outside interface stays fixed, the counting method inside is swappable. Pulling the logs to measure real execution rate has fiddly details that vary by the stack you run, so I'll dig into it separately in an Implementation / how-to piece.
Take one agent or AI tool you use, count what's connected to it, then honestly recall which ones you actually touched this past week. The gap between those two numbers is the cost you've been paying without noticing.