More connectors, worse agent: the tool-overload trap and how to escape it
There's a counter-intuitive failure mode in agent design: adding tools past a point makes the model less reliable, not more. Here's why it happens, the numbers behind it, and the progressive-disclosure pattern that lets a workspace run dozens of connectors without paying for it.
Here’s a result that surprises people the first time they hit it: past a certain number of tools, adding more makes your agent worse. Not slower, not pricier: worse at the actual job of picking the right tool and calling it correctly.
It runs against every instinct. More capability should mean a more capable agent. But an agent isn’t capable in proportion to what it can do; it’s capable in proportion to what it can keep straight while doing it. And a context window full of tool definitions is a context window with less room to think.
Where the tokens go
Every MCP tool carries a definition the model must read: name, description, a JSON schema for inputs, per-field docs, enums, examples. The going rate is 550–1,400 tokens per tool, and it’s charged on every request, whether the model uses that tool or not.
Multiply that across a few servers and the bill is startling:
One developer profiling their own setup with seven servers active reported 67,300 tokens, or 33.7% of a 200K budget, before a single word of conversation. That’s one machine’s readout rather than a study, but it lines up with Anthropic’s number, and it’s the shape everyone recognises once they go looking.
That’s the visible cost. The invisible one is worse.
The “lost in the middle” tax
Loading definitions doesn’t just cost tokens; it degrades judgement. When the model has to attend across a huge window, the signal from the real task competes with noise from dozens of tools it doesn’t need right now. Research on the “lost in the middle” effect shows accuracy drops sharply when the relevant material is buried among irrelevant material.
So there are two failure modes stacking:
- Selection error. With 60 similarly-named tools in view, the model picks a plausible-but-wrong one more often.
- Dilution. The definitions crowd out the reasoning space the task actually needs.
The uncomfortable conclusion: an endpoint that proudly exposes everything is optimising for a demo, not for reliability. The measure of a good tool surface isn’t how much it offers; it’s how little the model has to hold to do the next thing.
Three ways out
The industry converged on a small set of answers in 2026, and they compose well:
1. Progressive disclosure
Don’t show the model everything. Show it a way to find things, and reveal definitions on demand. This is what deferred tools and the Tool Search Tool do at the individual-tool level: mark tools deferred, let the model search, load only the three-to-five it actually reaches for. The same 50-tool setup that cost ~72K tokens loaded eagerly drops to under 9K.
2. Code execution (“code mode”)
Let the agent write code that calls tools and processes results in an execution environment, so only the final answer returns to the model, not every intermediate payload. Anthropic’s much-quoted example describes a cross-system data workflow dropping from 150,000 tokens to 2,000. Treat that as an illustration of a constructed scenario rather than a measured result: every figure we’ve seen from someone actually running code mode lands nearer 30–40%. Good for high-volume data movement; it trades context for the operational cost of a sandbox.
3. Scoped surfaces
Give each unit of work a lean toolset instead of the combined superset. Namespace tools by system, expose one domain at a time, and let a coordinator route between them. Total tokens per operation fall, because no single context ever loads the whole library.
How FloConnector applies this
A connector platform is the worst-case setting for tool overload (the entire point is breadth), so the exposure model is a first-class design problem, not an afterthought. Three rules do most of the work:
- Expose only what’s live. A workspace’s endpoint surfaces tools for the vendors it has actually connected and is entitled to, not the full catalog. Entitlement is broad; exposure is narrow.
- Namespace by vendor. Every tool is prefixed by its platform (
gmail_,slack_,hubspot_), so the model never confuses “send a message” in one platform for “send a message” in another, and search stays precise. - Keep large reads out of context entirely. Bulk data doesn’t travel through the model at all: it lands in an ephemeral in-memory analytics session, and the model queries it with SQL and gets back the aggregate. A 50,000-row question costs a few hundred tokens.
Designed and not yet shipped: disclosing vendors progressively, via a server-side enable_vendor meta-tool plus MCP’s notifications/tools/list_changed, so a workspace with many platforms brings one vendor’s tools into view at a time. Deferred loading is the client’s call, not the server’s; this one is a lever a server can pull on its own, which is exactly why it’s on the roadmap. It isn’t in the product today, and we’ll say so when it is.
We deliberately don’t impose a hard cap on tool count: the catalog bounds exposure organically, and a cap would just be a blunt instrument standing in for the real fix. Instead the interface stays informational. It shows the live tool count and nudges when a workspace is fanning out wide, while the disclosure machinery keeps the model’s working set small underneath.
Underpinning all of it is a bias toward thin, predictable tools over sprawling ones. Most connectors are delivered as lean, model-facing tools; we only graduate a workflow into a heavier composite when the payoff clearly justifies the context it costs. The default is restraint.
The principle
Tool overload is what happens when you treat the model’s context like storage instead of attention. Storage rewards having everything on hand. Attention rewards having exactly the next thing on hand and nothing else.
Build for attention. Expose a way to find capabilities rather than the capabilities themselves; keep each working set small; and let breadth live in the catalog, where it’s free, instead of in the context window, where it very much isn’t.
Keep reading
More from the blog
Code mode needs a sandbox. Query mode doesn't.
Context engineering for MCP has two named answers: deferred loading for too many tools, code execution for too much data. Code execution buys its savings with an agent sandbox. Here's the third answer I built FloConnector on instead, why I think it's the right default, and where it loses.
What is an MCP server? A plain-English guide
An MCP server is the piece that lets an AI like Claude actually do things in your other software: read a spreadsheet, send an email, raise an invoice. Here's what that means, how it works, and why you probably shouldn't build one yourself.
How FloConnector keeps 50+ connectors out of your context window
Loading every tool a business might need costs ~72K tokens before the model reads a word. Deferred tools flip that: the model pays only for what it reaches for. How it works, why it isn't part of MCP, and what a server can actually do about its own context cost.