HyperTeamsWhen you have too many tools
What you will learn The two problems that appear as tools multiply, and the practical fixes.
It becomes dozens quickly
A handful of MCP servers and the tool count climbs fast.
Four servers, 82 tools. Two problems follow.
Problem 1 — they take up space
Every tool definition goes into the context. Name, description, argument spec, all of it.
Nothing has happened yet and a large part of the context is full. And it repeats on every request — every turn resends all 82 descriptions.
| Consequence | |
|---|---|
| Cost | you pay that much more per request |
| Headroom | less room left for the actual work |
| Being pushed out | long jobs fill up faster |
Problem 2 — it picks the wrong one (more important)
This one hurts more in practice.
With 82 tools, some of them start to resemble each other.
Ask "find last year's contract" and which one should be called? The model is confused too.
People also pick the wrong tool more often from a bench holding 200 of them. Reducing the candidate set is not only cost saving — it raises selection accuracy.
Fix 1 — turn on only what you need
The simplest and most effective. Turn off the tools you do not use.
That is why Connect lets you turn tools on and off per workspace. There is no reason for development tools to be on in a sales workspace.
Fix 2 — pass only what matches the request
Rather than passing everything, narrow to what looks needed for this request.
graph TD
A["140 tools"] --> B["First request in the thread:<br/>'find last year's contract'"]
B --> C["Narrow to tools close to the request"]
C --> D["Only the top N nearest<br/>go to the model"]
D --> E["Easier selection · context saved"]
E --> F["The same set is used all conversation"]Connect turns tool descriptions into vectors and narrows to the nearest ones.
Even inside the top N, anything too far away is dropped
(TOOL_SELECTION_MIN_SIMILARITY, 0.3 by default).
But this mechanism does not always run. It only engages when the tool count exceeds a threshold (100 by default). Below that, every enabled tool is passed through as-is — which makes turning off unused tools more important, not less. The threshold and the number kept are adjusted with
TOOL_SELECTION_THRESHOLDandTOOL_SELECTION_TOP_K.
Chosen once, kept for the whole conversation
It does not re-choose on every message. The set picked on the thread's first turn is reused as-is.
Tool definitions are rendered at the very front of the prompt, so if the tools change between messages, the cache for the instructions and the conversation history behind them is invalidated too. Pinning is far cheaper.
In practice that means one thing.
Change the workspace's tool set and it does re-choose at that point.
What you name always gets in. Tools belonging to an agent you called with
@nameare included regardless of similarity. If you think a tool you need was left out, naming it directly is the surest fix.
Fix 3 — split tools well
This is a design-stage matter.
| Bad design | Good design |
|---|---|
one get_data(kind, criteria) for everything | split into check_stock / check_order / check_customer |
| several similar names | distinguishable from the name alone |
| one-line descriptions | when to use it and what to watch for |
One do-everything tool looks convenient, but the model gets its arguments wrong often. Splitting is better.
How many is reasonable
There is no fixed number, but the practical feel is:
| Tool count | State |
|---|---|
| ~10 | no problem |
| 10–30 | fine if names and descriptions are good |
| 30–50 | a narrowing mechanism helps |
| 50+ | accuracy degradation is visible without one |
That is the general industry feel. Connect's automatic narrowing only engages above 100, so in the 30–100 range you have to reduce the count yourself in workspace tool settings.
Common misconceptions
"Won't better models fix this?"
Partly. But the context-occupancy problem is unchanged. If tool definitions are 12,000 tokens, no model however good frees that space.
"If it narrows, won't it miss a tool I need?"
It can. So do not set the narrowing too tight. In practice you keep it generous. Connect's default is a top 100, deliberately wide — cut too narrow and needed tools drop out.
Check yourself
1. With 82 tools attached, why is the context already full before anything happens?
Answer
Because every tool definition — name, description, arguments — goes into the context. At 100–200 tokens each, 82 tools exceed 10,000 tokens, and it repeats on every request.
2. What hurts more than cost when you have many tools?
Answer
Picking the wrong one. With several similar tools the model gets confused about which to call. Reducing the candidate set saves cost and raises selection accuracy at the same time.
3. Why is splitting into several tools better than one do-everything tool?
Answer
Because a combined tool makes the model get its arguments wrong often.
Splitting get_data(kind, criteria) into check_stock / check_order makes
them distinguishable from the name alone, so selection is accurate.
Next, when the danger is not the tool but the material it reads → When what it reads becomes a command