Too many MCP tools: why 100 tools hurt an...

TL;DR: Every MCP tool you connect costs tokens and attention before the agent reads your first question, and a crowded menu makes the model pick wrong or burn its budget on definitions. Keep the menu short and specific, connect one job per session, and measure the cost before you add the next server.

Buyers love long tool lists. A vendor who connects to a hundred things sounds more powerful than one who connects to twenty.

Our angle in this post is the opposite. Past a modest size, every extra MCP tool makes your agent slower, costlier and less accurate, and the cost arrives before any work begins.

If MCP is new to you, read what MCP is in plain terms first. The short version is that a connected server hands the model a menu of tools, and the model reads that whole menu before it answers you.

That reading has a price. A menu is text, text is measured in tokens, and tokens fill the finite working space the model has for your task.

There is a second price that is harder to see. A model choosing among a hundred similar-sounding tools makes more wrong choices than a model choosing among ten distinct ones.

Anthropic's engineers say this plainly in their guide to building tools for agents.

"Too many tools or overlapping tools can also distract agents from pursuing efficient strategies."

Anthropic Engineering, "Writing effective tools for AI agents," September 11, 2025 (source)

Sales teams feel this as sluggish, expensive and erratic agents. They blame the model, when the real culprit is often a menu that grew without anyone counting.

This post gives you the arithmetic, the failure modes and a routine for trimming. It also connects to which tools an agent should get, because a shorter menu is both cheaper and safer.

#What a tool definition costs

A tool definition is the package of text that describes one tool to the model. It holds the tool's name, a description of what it does and a schema that lists every field it accepts.

The model reads all of it, for every tool, at the start of every session. You do not see this reading, but you pay for it in tokens, in time and in room left for your actual task.

Anthropic quantified the weight in its engineering post on advanced tool use. It reports that tool definitions can consume large amounts of context, giving the example of roughly 72,000 tokens for 50-plus MCP tools before any work begins.

The same post notes that a single large server can be heavy on its own. It cites one project-tracking server at about 17,000 tokens, and a case where definitions reached 134,000 tokens before Anthropic optimized them.

Those are Anthropic's figures for its own setups, so treat them as examples of order of magnitude, not promises about your stack. Your vendor's descriptions may be shorter or much longer.

A token is a small chunk of text, a few characters on average. The practical rule is that more words in tool descriptions means more tokens in every session.

Two things drive cost. One is how many tools there are, and the other is how verbose each description and schema is.

A tool with twenty optional fields costs far more than a tool with two. Long enum lists, nested objects and pasted examples all add up.

So when you assess a server, count both the tools and the words. A server with fifteen heavy tools can cost more than one with thirty light ones.

#The token math, step by step

You can estimate your own cost with ordinary arithmetic. We use Anthropic's published figures as the anchor and do the division ourselves.

Anthropic reports about 72,000 tokens for more than 50 tools. Divide 72,000 by 50 and you get roughly 1,440 tokens per tool, which is our own calculation from their numbers, not a figure they published.

Now apply that average to different menu sizes. The table below is an illustration of scale, since real tools vary widely.

Tools connected	Tokens at about 1,440 each	What it means
10	about 14,400	Fits comfortably in most sessions
21	about 30,200	Noticeable but manageable
50	about 72,000	A large share of working space gone
100	about 144,000	Close to the 134,000 case Anthropic observed

The 21-tool row matches the size of the FirstSales product menu we saw in a connected session, though its tools may be lighter or heavier than the average. Measure your own rather than trusting our division.

The bigger lesson is the shape of the curve. Cost grows in a straight line with tool count, while the model's ability to choose does not improve in a straight line.

A recent paper makes a related point from the other side. The authors of "Tool Attention Is All You Need" describe a "Tools Tax" of roughly 10,000 to 60,000 tokens and report a 95% reduction in a simulated 120-tool benchmark.

Be careful with that number. It comes from a simulation in a research paper, so it shows a promising direction and not a result you will see in production.

Anthropic's own fix produced a clearer figure. Its Tool Search Tool brought definitions for a large library down to about 8,700 tokens, an 85% reduction in the example it describes.

Notice what these numbers share. Everyone who measures the cost finds it large enough to engineer around.

For a sales team the takeaway is plain. Before you add another server, ask what it costs per session, in tokens and in dollars.

Cost is only half the story. A crowded menu also changes behavior, and the failures come in three recognizable shapes.

Failure one: the wrong tool. When several tools have similar names, the model can pick the one that sounds right but does something else. "Update campaign" and "update workflow" are an easy mix-up.

In outbound the wrong pick is expensive. A model that edits the wrong object changes what real prospects might receive.

Failure two: the wasted loop. With many options, a model may try several tools in sequence to answer one question, each call adding results to the working space. The session gets slower and the answer gets no better.

Anthropic describes ways to keep this under control. Its guide to building agents notes that stopping conditions such as a maximum number of iterations help maintain control of an agent loop.

Failure three: the buried instruction. A long menu pushes your own instructions further from the part of the context the model attends to most. Your careful rules about not touching live campaigns share space with thousands of tokens of unrelated tool text.

This is an inference from how context works, not a measured effect we can quote. It matches what practitioners report, so we treat it as a risk to test in your own setup.

All three failures get worse as tools overlap. Overlap is common when you connect several servers that each cover part of the same job.

Picture one server for your customer records, another for your outbound platform and a third for your inbox. All three may offer a "search" tool and a "list" tool.

The model must now decide which search to use for which question. Anthropic recommends namespacing, meaning a clear prefix that groups tools by service, so names tell the model where each belongs.

Our own tool names follow that idea. The tools we saw begin with the object they act on, such as campaigns_ or blocked_domains_, which keeps similar actions close together and distinct from other areas.

#What the research says

Evidence here is still young, and honest writers should say so. Several sources agree on the direction, and few agree on the exact numbers.

Anthropic's engineering posts are the strongest primary sources. They describe context cost, overlap and the fixes the company ships, and they ground this entire article.

The MCP community's own growth raises the stakes. The project's maintainers report more than 10,000 active servers and 97 million monthly SDK downloads, so the temptation to connect many of them is real.

Anthropic's own accuracy numbers show what tool search changes. On MCP evaluations with large tool libraries, Anthropic reports that Opus 4 improved from 49% to 74%, and Opus 4.5 from 79.5% to 88.1%, with its Tool Search Tool enabled.

When you see numbers like these repeated online, go back to that page. Note the model version and the evaluation before you repeat them in a board deck.

Academic work such as the Tool Attention paper models the problem and proposes selection methods. It is a useful map of ideas, but simulations do not tell you how your campaigns will behave.

A fair summary is this. The cost side is well documented by the people who build the models, and the accuracy side is plausible and partly measured but not settled.

That is enough to act. You do not need a perfect benchmark to conclude that fewer, clearer tools are a safer bet than a pile of overlapping ones.

#What 100 tools looks like in sales

It helps to picture a real stack. An ambitious team connects a customer records server, an outbound platform, an inbox, a calendar, a document store, a data provider and a chat tool.

Each of those servers might offer between ten and thirty tools. Add them up and a hundred tools arrive without anyone deciding to build a monster.

Here is how that menu plays out against a simple request: "Pause the campaign for the founders list and tell me how many replies came in."

Question for the menu	Ten focused tools	A hundred mixed tools
Is the right tool obvious?	✓	✗
Are names unique across services?	✓	✗
Is the token cost low?	✓	✗
Can I review every tool before connecting?	✓	✗
Is the blast radius of a mistake small?	✓	✗
Is one person able to explain the whole menu?	✓	✗

The last row matters more than it looks. If nobody on the team can explain the whole menu, nobody can review it for risk.

That review burden connects to security. A hundred tools means a hundred descriptions that could change, and our post on MCP security for outbound explains why unreviewed descriptions are an attack surface.

Simon Willison's warning about combining capabilities applies with force here.

"If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker."

Simon Willison, "The lethal trifecta for AI agents," June 16, 2025 (source)

A hundred-tool menu nearly guarantees that all three features are present at once. A focused menu lets you keep them apart.

So the sales case against a giant menu has three legs. It costs more, it chooses worse and it is harder to secure.

#How Anthropic suggests fixing it

The vendors of models have noticed the problem and shipped fixes. You do not need to implement them yourself, but understanding them helps you ask better questions.

Tool search. Instead of loading every definition up front, the model first searches for the tools it needs and loads only those. Anthropic's example cut the cost of a large library by 85%, as noted above.

Namespacing. Group tools under clear prefixes so the model can tell services apart and so that similar tools do not collide.

Tighter responses. Return only the fields a task needs. The writing-tools guide encourages designing outputs that give the model meaningful context without flooding it.

Code execution. Anthropic has also described letting agents work with MCP tools through code, so the model does not need every definition and intermediate result in its working space.

These fixes live in clients and platforms, which means you benefit only if your client supports them. Claude Code, for example, can refresh a server's tools when it announces a change, as its MCP documentation describes.

You can ask a simple question of any vendor or client. "How do you keep the tool list from swamping the working space?"

A good answer mentions tool search, namespacing or a deliberately small menu. A weak answer says the model is smart enough to cope.

Even with those fixes, a short menu is still the cheapest fix. It needs no new feature, only a decision to connect less.

#A trimming routine for your team

Trimming is a process you run, not a one-time cleanup. The routine below takes about an hour the first time and fifteen minutes each month after that.

Step one: list everything. Export the live tool list from each connected server. Count the tools and note the total.

Step two: tag each tool with a job. Use plain labels such as "report on campaigns", "edit sequence steps" or "manage blocked domains". Tools with no clear job are candidates for removal.

Step three: find overlaps. Look for tools that do nearly the same thing across servers. Keep the one closest to your system of record and drop the rest.

Step four: count usage. Check which tools the agent called in the last month. Tools never called are costing tokens for nothing.

Step five: remove or scope. Remove unused tools if the vendor allows it. If it does not, narrow the grant or leave that server out of the session.

Step six: re-measure. Record the new tool count and the approximate token cost, and note any change in speed or accuracy.

Step seven: write it down. Keep the register from the permissions guide, and add a "last used" column.

Teams usually find that a third to a half of connected tools were never used. That figure is our rule of thumb from reviewing menus, not a published statistic, so measure yours.

If you want a worked example of the register, the tool permissions guide includes a copyable template. It pairs well with the audit habits in our outbound process audit.

#One job per session

A trimmed menu is good. A menu matched to one job is better.

Instead of one session with every server connected, open separate sessions for separate jobs. A reporting session connects only read tools, and an editing session connects only the tools that edit sequences.

This pattern gives you three wins at once. Each session carries a small menu, each session has a narrow blast radius, and each session's history stays clean for review.

Here is a simple map for an outbound team.

flowchart LR
    A[Morning check] --> B[Reporting session: read tools only]
    C[Copy change] --> D[Editing session: workflow tools, paused campaigns]
    E[List hygiene] --> F[List session: contacts and blocked domains]
    G[Launch] --> H[CLI by a person: readiness, test email, start]
    B --> I[Notes saved by a human]
    D --> I
    F --> I
    H --> I

Notice that launch is not a chat session at all. Starting a campaign is a human step, run in the terminal after the readiness check and a test email.

On FirstSales, firstsales campaigns create makes the campaign, and MCP is then used to edit and watch it. We found no MCP tool that creates a campaign, so creation belongs to the CLI.

The reporting session pairs well with the habits in the daily outbound standup in one prompt and asking Claude how your campaign is doing. Both stay in the read tier and need very few tools.

Session discipline costs you a little convenience. It buys you cheaper runs, fewer surprises and cleaner audits.

#Keep the CLI for the rest

Not every job needs MCP. A command-line interface does not load a tool menu into the model's working space at all, because the agent calls commands as it needs them.

The FirstSales CLI, installed with npm i -g @firstsales.io/cli, groups work under commands such as campaigns, contacts, domains and inbox. Its README recommends a simple agent loop: check who you are with whoami, read state, plan the smallest mutation, preview with --dry-run, use --confirm only when intended, and verify afterward.

That loop has a quiet advantage for token cost. The agent learns commands as it uses them, and the CLI exposes a local command registry through firstsales commands --json.

CLI commands also carry built-in guards. The --dry-run flag prints the method, URL and redacted headers with no network call, and destructive commands stop unless --confirm is present.

Use MCP where conversation helps, such as asking questions and editing steps. Use the CLI where precision, scripts and guards help, such as imports, domain setup and launches.

Our post on which interface fits which job draws the line in detail. For terminal-first teams, running outbound from the terminal shows the full approach.

A useful rule of thumb follows. If a task can be a single command with a clear result, give it to the CLI and keep it off the MCP menu.

Numbers beat opinions, so measure. You do not need special tools, only a before-and-after habit.

Count the tools. Ask the client to list the tools it sees for each server and add them up. Write the total in your register.

Estimate the cost. Copy the live tool descriptions into a text file and count the words. As a rough guide, one English word is a little more than one token, so a word count gives you a floor for the token cost. Treat the result as an estimate.

Your client or provider may also report token use per session. If it does, compare a session with the server connected to one without it.

Time a standard task. Pick a fixed request, such as "summarize progress for one campaign", and time it with the full menu and with a trimmed one. Run each three times to smooth out noise.

Check correctness. Verify the agent's answer against the app. Count how often it chose the right tool on the first try.

Record the cost of mistakes. Note any case where the model chose a wrong tool, even if it caused no harm. Near misses are the early warning.

After one round of this you will have your own data. That beats any vendor claim, including ours.

Keep one caution in mind. Measurement in a single session is noisy, so trust trends over weeks more than a single run.

#A budget for a hypothetical outbound agent

Here is an illustration with invented round numbers, not a measurement. It shows how the pieces add up so you can run the same sum with your real figures.

Say your working space holds a fixed amount of text. Your instructions take a slice, the tool definitions take a slice, the data the tools return takes a slice, and the model's own reasoning and answer take the rest.

Tool definitions are the only slice that is spent before you type a word. The other slices grow as the work proceeds.

If the definitions take a large share, two things shrink at once. There is less room for the records your tools return, and less room for the model to think.

That is why a heavy menu feels like a dull agent. The model has not become less capable, but it has less room to be capable in.

Now picture the trimmed alternative. A reporting session loads six read tools, perhaps 9,000 tokens at our rough average, and leaves most of the space free for campaign data and analysis.

The same team's full menu of a hundred tools would take more than ten times as much. The reporting task did not need ninety-four of those tools.

You can run the sum in your own spreadsheet in five minutes. List the servers, count the tools, multiply by your measured average and compare the result with the space your client offers.

Do this for each job, not just once. The reporting session, the editing session and the list session each have their own right-sized menu.

#Questions to ask a vendor about tool count

When a vendor says "we support hundreds of tools", you can respond with a short list of questions. The answers tell you how much of that claim is good news.

Can I connect only a subset? A server that forces you to take the whole catalog hands the cost to you. A server with scoped grants lets you pay only for what you use.

How long are your tool descriptions? Ask for the average word count. Very long descriptions raise cost, and very vague ones raise error rates.

Do you namespace your tools? Clear prefixes help the model tell tools apart, especially when you connect more than one server.

Do you return compact results? A tool that returns fifty fields when the task needs three fills your working space with noise.

How do you handle changes? Ask how you will learn about new, renamed or removed tools. Silent changes are a security matter as well as a cost matter.

What do you recommend for large teams? A good vendor has an answer about roles, grants and session design.

Compare this with the buyer questions in what MCP is in plain terms. The earlier list asks whether you can see the menu, and this one asks how big the menu should be.

If you are evaluating vendors across the whole stack, where FirstSales fits in your outbound stack and the cold outbound tech stack for 2026 give wider context.

#Writing good tool descriptions if you build your own

Some teams build their own MCP servers around internal data. If that is you, the advice from Anthropic's engineers applies directly, and it keeps your menu small and clear.

Give each tool one clear job. A tool that does five things is harder for the model to use correctly than five tools that each do one.

Use names that say what the tool does and what it touches. Prefix them by object, so related tools sort together.

Write descriptions as if explaining the tool to a new colleague. State what it returns, what it needs and what it must never be used for.

Limit the fields. Every optional field adds tokens and adds a way for the model to guess wrong.

Return only what the next step needs. Long raw records waste working space and can carry text you did not intend to show.

Mark write tools plainly, and keep them few. Pair them with the tiering approach in the tool permissions guide so a person approves risky calls.

Test with real prompts. Anthropic's guide encourages running evaluations on realistic tasks, which is also how you catch overlapping tools before users do. Our post on building an eval set for outbound AI shows the same discipline for email quality.

#A note on cost control for outbound teams

Tokens are money, and agents that run all day can run up a bill that surprises people. Treat tool count as a line item.

Set a monthly review of agent cost next to your sending costs. If cost rises while volume stays flat, look at menu size first.

Be wary of agents that run on a schedule with a full menu. A nightly report job that loads a hundred tools every run pays that overhead every night.

The better pattern moves scheduled work out of chat. The CLI can run on a timer, as shown in weekly campaign reports with cron and the CLI, and it keeps the model's menu out of the picture.

Also watch for credit-based pricing on the platform side. The product menu includes read tools for credit balance and usage, which let you track spend without touching anything.

Finally, keep humans in the loop for large actions regardless of cost. Our posts on human-in-the-loop cold email and unsupervised AI outbound explain where review belongs.

You can often tell before you measure. Watch for these signs in daily use.

The agent asks you which tool to use. It should decide on its own among a handful of clear options.

The agent calls several tools to answer a simple question. A good menu gets a simple answer in one or two calls.

Sessions feel slower to start. Loading definitions takes time, and the delay is a hint.

Costs creep up with no change in your usage. Heavier menus raise the bill quietly.

Nobody can recite what a server does. If the team cannot explain a connection in a sentence, it is probably unused or redundant.

Your security reviewer groans. A menu that is too long to review is too long to trust.

If three or more of these ring true, trim before you do anything else. Trimming is the cheapest improvement on this list.

#Frequently asked questions

#Why do too many MCP tools hurt an agent?

Each tool definition costs tokens before any work begins, and a crowded menu makes wrong choices more likely. Both effects grow as the menu grows.

#How many MCP tools is too many?

There is no universal number. Anthropic reports about 72,000 tokens for more than 50 tools, so a menu in that range already takes a large share of working space.

#What is a tool definition?

It is the text that describes one tool to the model: a name, a description and a schema listing its fields. The model reads every definition at the start of a session.

#How much does a tool cost in tokens?

It varies widely. Dividing Anthropic's 72,000 tokens by 50 tools gives roughly 1,440 per tool, which is our own arithmetic and only a rough average.

#What is the Tool Search Tool?

It is an Anthropic feature that lets the model search for the tools it needs instead of loading all definitions up front. Anthropic reports an 85% reduction in one example.

#Do all clients support tool search?

No. Support depends on the client and platform, so ask your vendor how the tool list is kept from swamping the working space.

#What is namespacing for tools?

It means giving tools clear prefixes, such as the object or service they belong to. Anthropic recommends it to help agents tell similar tools apart.

#Does a longer tool list make an agent less accurate?

Anthropic says overlapping tools can distract agents from efficient strategies. Exact accuracy numbers vary by source, so test your own setup.

#Are the accuracy numbers I see online reliable?

Be careful. Some figures come from secondary summaries that we could not trace to a primary page, so ask for the benchmark and model version before you repeat them.

#What is the Tools Tax?

It is a term from an academic paper for the token overhead of tool definitions, estimated at about 10,000 to 60,000 tokens. The paper's 95% reduction comes from a simulation.

#How many tools does the FirstSales product MCP expose?

We saw 21 tools in one connected session on October 8, 2026. Your list may differ, because the live tools/list response depends on tenant and grant.

#Can MCP create a campaign on FirstSales?

We did not confirm a tool that does. Use firstsales campaigns create, then use MCP to edit and watch the campaign.

#Should I connect every server I can?

No. Connect the servers each job needs, and open separate sessions for separate jobs. Fewer connections mean lower cost and smaller risk.

Yes. Fewer tools mean fewer descriptions that can change and fewer ways to combine the three lethal-trifecta features.

#When should I use the CLI instead of MCP?

Use the CLI for single, precise commands such as imports, domain setup and launches. It adds no menu to the model's working space and has guards like --dry-run and --confirm.

#How do I find unused tools?

Review which tools the agent called over the past month. Tools that were never called are candidates for removal.

#How often should I review my tool list?

Monthly, and after any vendor update. Compare the live list with your register and investigate every difference.

#What is the first thing to trim?

Trim overlapping tools across servers, then tools nobody has called. Keep the tool nearest your system of record.

#Does tool count affect cost in dollars?

Yes, because definitions are billed as tokens in every session. A heavier menu raises the cost of each run, even before the agent does useful work.

#What is one habit that fixes most of this?

Open one session per job, with only the tools that job needs. It lowers cost, limits risk and makes review simple.

#Conclusion

A bigger MCP menu is not a stronger agent. Every tool costs tokens before work starts, overlapping tools invite wrong picks, and a menu nobody can review is a menu nobody can secure.

Keep four things in mind. Measure your own menu, trim overlaps and unused tools, run one job per session, and hand precise tasks to the CLI.

Your next step is small. Export the live tool list from each connected server, count the tools, and remove or scope everything the agent did not use last month.

Then read MCP security for outbound to see why a short menu is also easier to defend. If you are mapping the whole system, the five layers of an AI outbound agent stack shows where tools fit, and human-in-the-loop cold email shows where the people belong.