# 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
A handful of MCP servers and the tool count climbs fast.
```
Slack server → 12 (send message, list channels, search, ...)
GitHub server → 25 (issues, PRs, commits, files, ...)
Google Drive → 15
Internal ERP → 30
──────────────────────
Total 82
```
Four servers, 82 tools. Two problems follow.
## Problem 1 — they take up space
**Every tool definition goes into the [context](/guide/ai-context-window).**
Name, description, argument spec, all of it.
```
Roughly 100–200 tokens per tool
82 × 150 = about 12,000 tokens
```
**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](/guide/ai-context-overflow) | 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.
```
search (Slack)
search (GitHub)
search_docs (Drive)
get_data (ERP)
unified_search (intranet)
```
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.**
```
✗ attach everything attachable and tidy up later
✓ turn on only what this workspace actually uses
```
That is why [Connect](/guide/cn-agents-intro) 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.**
```mermaid
graph TD
A["140 tools"] --> B["First request in the thread:
'find last year's contract'"]
B --> C["Narrow to tools close to the request"]
C --> D["Only the top N nearest
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.
```
✗ A tool that "was not there before" never appears mid-conversation
✓ Need a different tool → start a new thread
```
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.
| 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](/guide/cn-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](/guide/mcp-prompt-injection)