How Many Tools? Diagnosing Over-Tooling in Your AI Stack

The most common mistake builders make when deploying AI agents is not under-equipping them.

It is drowning them in options.

The Over-Tooling Trap

Every tool you give an agent costs something. Not in dollars — in context.

Each MCP server registers its capabilities in the agent's context window before the first token of your actual task gets processed. A modest tool description runs 150-250 tokens. Forty tools means 6,000-10,000 tokens of overhead — consumed before the agent has read a single line of your codebase, your prompt, or your instructions.

Tool overhead is not a rounding error. It is a structural tax on every session.

And the cost is not just tokens. It is decision quality. An agent with 40 available tools spends cognitive budget enumerating options. It second-guesses tool selection. It calls Tool A when Tool B was the obvious right answer — because 38 other options diluted the signal.

Five Signals You Are Over-Tooled

Diagnosis before surgery. Here is what over-tooling looks like in practice.

The agent calls the wrong tool. You ask it to analyze code and it reaches for web search. You ask it to write a file and it queries a database. Tool selection accuracy degrades as option count grows — this is not a model failure, it is a design failure.

Tool invocations appear where they add no value. The agent searches the web for information it already has in context. It calls an external API for data it retrieved three messages ago. The agent is not reasoning about tool necessity — it is pattern-matching on availability.

Context windows fill before the task completes. When tool schemas and tool call results are consuming your context budget, complex tasks get truncated. You start seeing half-finished implementations, cut-off analyses, incomplete outputs. The tools are eating the workspace.

You cannot explain what half your MCPs do. This is the clearest signal. Open your MCP config right now. Can you state in one sentence what each server does and when you last needed it? If you hesitate on more than one, you have a problem.

You have tools you added "just in case." The most dangerous category. These tools never get used — but they always get loaded.

The Stack Audit: Seven Servers, Zero Waste

Here is the current production stack and the exact justification for each server.

openclaw-bridge is the gateway to the entire OpenClaw platform. Sessions, events, state, search — this is the integration layer between Claude Code and the persistent 24/7 agent. Removing it severs the stack.

excalidraw (26 tools) handles architecture diagrams. System design sessions happen weekly. There is no alternative for programmatic diagram creation in this workflow.

Notion manages knowledge base read and write. The team's second brain lives here. Every research output, every reference doc, every structured note.

Asana is the task management layer. Tickets live here. Kanban sync runs against this. Agent task claiming happens through this server.

mcp-image generates images via Gemini. The content pipeline — blog-autopilot, rewired-minds — needs programmatic image generation. This is the only server that handles it.

Veo generates video for the content flywheel. Short-form video content creation runs through this.

Grok-search provides real-time X/Twitter signal. No other model or API gives you live social data from X. For crypto narratives, trending topics, and social sentiment — this is the only answer.

Seven servers. Each one used in active production workflows. None of them speculative.

The strength of an army, like the power in mechanics, is estimated by multiplying the mass by the rapidity; a rapid march augments the morale of an army, and increases all the chances of victory.

— Napoleon Bonaparte · Maxims of War

The same principle applies to agent tooling. A lean, fast, purposeful stack outperforms a bloated one — every time.

The Three-Question Audit

Every tool in your stack must pass all three questions. Fail any one of them and the tool gets cut.

Question 1: Frequency. Have I needed this tool in the last 30 days? Not "could I imagine needing it" — have I actually needed it? If the answer is no, it is on notice.

Question 2: Uniqueness. Can something already in the stack do this? If two servers overlap in capability, keep the better one and remove the other. Duplication is waste dressed as optionality.

Question 3: Clarity. Can I explain in one sentence what this tool does and when to use it? If you need a paragraph to justify a tool's presence, the tool does not have a clear job. Clear jobs get clear selection. Ambiguous jobs get skipped or misused.

If a tool fails any of these, remove it. Not "disable temporarily." Remove it.

Tool Sprawl vs. Tool Intentionality

There is a pattern among junior engineers: download everything, configure everything, keep everything. The logic is that having more options is safer than having fewer. This is wrong.

A senior engineer's toolkit is defined as much by what is not in it as what is. Every tool excluded is a decision made. Every server removed is cognitive budget reclaimed.

The difference between a senior's stack and a junior's stack is not capability — it is intentionality.

The right number of tools is not the most you can fit. It is not the fewest you can survive with. It is exactly the set that covers your actual workflows, with no overlap, no speculation, and no "just in case."

Build the stack that earns its tokens.

---

Drill

List every MCP server and tool integration in your current AI stack. For each one, run the three-question audit:

1. Used in the last 30 days? (Yes / No)
2. Unique capability — nothing else in the stack can do this? (Yes / No)
3. Can you explain it in one sentence? (Yes / No)

Any tool that answers "No" to any of these gets removed. Report how many you cut.

---

Bottom Line: Tool count and agent capability are positively correlated — up to a threshold. Past that threshold, they are inversely correlated. The builders who build effective agents are not the ones with the most integrations. They are the ones who know exactly why each integration is there.