When 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

Skills, plugins, MCP servers — whichever shape, a handful of them and the count of callable actions climbs fast. The tally below counts MCP servers, but the arithmetic is the same for any shape.

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.

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_THRESHOLD and TOOL_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 @name are 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.

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:

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?

2. What hurts more than cost when you have many tools?

3. Why is splitting into several tools better than one do-everything tool?

Next, when the danger is not the tool but the material it reads → When what it reads becomes a command