This article explains directly why expanding tool catalogs for agents can complicate more than it helps. Have you wondered what happens when many agents and many services try to collaborate without a common language? Here is the story, the risks, and practical solutions, without technobabble that gets in the way.
¿Qué es MCP y por qué importa ahora?
MCP (Model Context Protocol) is a specification that lets models and agents discover and call remote tools in a standard way. In 2025, MCP stopped being a technical curiosity and became an active market with thousands of servers and catalogs, opening the door to an "agent society" where heterogeneous services try to cooperate. (microsoft.com)
That openness is good: it enables integrating capabilities (web search, GitHub, command execution, etc.) without designing everything vertically. But it also brings unexpected side effects when many agents and tools coexist without coordination. (microsoft.com)
¿Qué es la «tool-space interference»?
The authors call tool-space interference the situations where reasonable tools, when placed together, reduce final effectiveness. How does that show up? More steps in a flow mean more fragility to errors, wrong choices about which tool to use, or complete task failures. The problem arises because an agent may pick the wrong tool or receive responses that break its context. (microsoft.com)
A concrete example: imagine an orchestrator agent that can use a browser agent, another agent that runs git commands in a terminal, and also an MCP server for GitHub. Each keeps its own state and permissions, so changing the branch in the browser does not update the terminal nor reflect authorization in GitHub. The result: friction, extra debugging, or a failed task. (microsoft.com)
¿Qué encontró la investigación práctica?
Microsoft Research cataloged and started servers listed in public registries. After filtering invalid servers, they formed a catalog of 1,470 servers and developed a tool called MCP Interviewer to automatically inspect tools, schemas, and responses. That sampling revealed real limits: tool counts, response lengths, parameter complexity, name collisions, and poorly signaled errors. (microsoft.com)
Some relevant findings:
-
Many servers are small, but there are outliers with tens or hundreds of tools; the largest server reported 256 tools and several exceed 100. This can degrade model performance. (microsoft.com)
-
Tool outputs vary hugely in size: although the median was small, some responses average more than half a million tokens, enough to overflow context windows of popular models. That complicates chaining calls in agents. (microsoft.com)
-
Parameter complexity can be extreme: nested schemas up to 20 levels make it harder for a model to choose and call a function correctly. (microsoft.com)
-
Name collisions are common: 775 tools with repeated names were detected across servers (for example, "search" appears in many sources), which makes disambiguation difficult. (microsoft.com)
-
Errors are not always reported reliably: many responses contain error messages but do not flip the protocol error flag, leaving the agent without a clear signal that something went wrong. (microsoft.com)
The central thesis is simple: more quantity and diversity of tools increases capabilities, but also creates frictions that erode end-to-end effectiveness. (microsoft.com)
Recomendaciones prácticas para cada actor
This is not just theory; there are specific, useful steps different actors can take today to mitigate interference.
Para desarrolladores de protocolos
- Add mechanisms for clients to provide resources (for example, local files) to remote servers.
- Define formal namespaces to avoid name collisions and allow hierarchical grouping of tools. These measures help make large catalogs manageable. (microsoft.com)
Para desarrolladores de servidores
- Publish a server "data sheet" that describes runtime characteristics: expected response size, latency, models or agents it was tested with, test cases and known limitations. That transparency makes integration easier. (microsoft.com)
Para desarrolladores de clientes y agentes
- Implement schema caching, pagination or summarization of long responses, and generate namespaces from server names to avoid confusion.
- Test servers with probe agents to rewrite or improve broken prompts. In the study, an approach like this improved task completion times by 40% in a cited experiment. (microsoft.com)
Para mercados y registries
- Create configurations optimized per model or agent, and serve schema versions tailored to concrete capabilities (similar to how some marketplaces adjust packages by operating system). This could centralize best practices and reduce incompatibilities. (microsoft.com)
¿Qué significa esto para ti como usuario o creador de IA?
If you use agents in production or are building solutions that chain tools, you should take this seriously. It is not just an academic issue: these are practical failures that increase costs, introduce fragility, and hurt the end user experience.
Good news? Many solutions are pragmatic and achievable: better specs, transparency from servers, and improved client strategies. And there are open tools like MCP Interviewer to audit servers starting today. (microsoft.com)
Reflexión final
We are at the stage where interoperability can speed up innovation or complicate it. As with any new infrastructure, early steps require clear standards and honest documentation. If we do it well, MCP can be the foundation of a robust agent society; if not, we will multiply frictions instead of solutions.
The practical recommendation for any team is to start with small compatibility contracts: document, test, and limit. Sound obvious? It is. And yet, in distributed systems, the obvious is often the easiest to overlook. (microsoft.com)