When an AI Agent Has 1,000 MCP Tools: Selection, Context and Skills
Connecting agents to many MCP servers creates tool explosion, bloated context and bad picks. Why discovery, Skills and gateways may matter more than raw access.
This article is published in English.
More tools for an AI agent sounds like pure upside, right up until the count hits 1,000. At that point the question shifts. It stops being "can the agent do this?" and becomes "can the agent find the right tool and use it correctly?" That's where MCP gets interesting.
MCP makes exposing tools easy
A major strength of the Model Context Protocol is that capabilities reach agents through one common interface. A SaaS product might publish create_customer, get_customer, update_customer, create_invoice, refund_payment and search_orders. Another MCP server could cover GitHub, a third Slack, a fourth an internal database. Each is fine alone. The trouble begins when one agent connects to many servers and the total climbs quickly. Ten tools is nothing, a hundred starts to bite, and a thousand is a different kind of problem.
The tool explosion
Put yourself in the agent's position with 1,000 tools in hand. You'd need to work out what each one does, which are related, which to use, what parameters each takes, which should run first and whether several do the same job. The agent can technically reach everything, but access isn't usability. More tools mean more capability and also more choices, and more choices can make selection harder.
Context fills up
Every tool needs a description. For one tool, that might be a name:
create_invoice
and a short definition:
Creates an invoice for a customer.Parameters:
- customer_id
- amount
- currency
- due_date
Multiply that by 1,000. Even small descriptions add up to a large amount of context, so tokens get spent just telling the model what it could do, and most of those tools have nothing to do with the task at hand. If a user asks about the status of an order, there's no reason for the agent to digest 500 billing, GitHub, CRM and deployment tools.
Picking the right tool is the real difficulty
Suppose the agent sees these:
get_customer
get_customer_details
lookup_customer
search_customer
find_customer
They all sound alike. Which one should it call? Now spread that across hundreds of tools. The model can call tools perfectly well. What's hard is choosing one from a huge toolbox. It's like dropping 10,000 functions on a developer and wishing them well. Possible, but not pleasant.
More tools, more mistakes
Selection often isn't binary, because several tools might work:
search_orders
get_order
list_orders
find_order_by_customer
An agent can pick a valid tool and use it inefficiently, call several where one would do, or call them in the wrong order. The whole chain runs from tool availability to selection, then sequencing, then execution. MCP mostly helps with the first link. The rest depends on the agent and the architecture around it.
Should agents get fewer tools?
Not necessarily. The aim isn't to limit what an agent can do. It's to avoid forcing it to understand everything at the same moment. A person fixing a payment problem doesn't open every internal tool and read the documentation. They pull out the payment-related ones. Agents could work the same way. The pattern of loading everything and then choosing could give way to discovering, selecting, loading and executing, which is a more interesting design.
Where Skills fit
Skills tie in directly. A skill can supply context for one kind of task. A customer billing skill, for example, might tell the agent to find the customer, check the subscription, look at outstanding invoices, decide on the correct billing action, ask for approval when needed and then run the appropriate tool.
The agent no longer reasons over every tool in the system. It gets a smaller, more relevant set for the job. Instead of this:
Agent
↓
1,000 tools
the flow could be this:
Agent
↓
Relevant Skill
↓
Relevant tools
↓
MCP
↓
API / System
Skills don't replace MCP, since they address different problems. MCP connects the agent to capabilities, and skills can teach it how to use them. The idea of skills over MCP is still experimental and evolving, so it's better read as an emerging direction than a settled architecture.
Gateways may matter too
Another direction is the MCP gateway. Rather than wiring an agent straight to dozens of MCP servers, a gateway sits in between:
Agent
↓
MCP Gateway
↓
MCP Servers
↓
APIs / Systems
A gateway could potentially take on authentication, routing, access control, observability, tool discovery and the management of many servers. That grows more valuable as MCP deployments get bigger.
The real problem is irrelevance
The worry isn't 1,000 tools as such. It's 1,000 irrelevant tools. If a task truly needs a thousand, so be it. If it needs twelve and the agent has to process a thousand to find them, that's needless complexity. The principle: agents don't need access to everything, only to what matters right now.
That will likely become a central concern in MCP architecture as agents connect to more systems. MCP settled the first question, how to give agents standardized access to tools. The next one is how to manage all those tools intelligently, and that looks considerably harder. Giving agents tools got easy. Giving them the right tools at the right time is the work ahead.