Este artículo explica de forma directa por qué la expansión de catálogos de herramientas para agentes puede complicar más de lo que ayuda. ¿Te has preguntado qué pasa cuando muchos agentes y muchos servicios intentan colaborar sin un lenguaje común? Aquí tienes la historia, los riesgos y las soluciones prácticas, sin tecnicismos que entorpezcan.
¿Qué es MCP y por qué importa ahora?
MCP (Model Context Protocol) es una especificación que permite que modelos y agentes descubran y llamen herramientas remotas de forma estándar. En 2025, MCP dejó de ser una curiosidad técnica y se volvió un mercado activo con miles de servidores y catálogos, lo que abre la puerta a una «sociedad de agentes» donde servicios heterogéneos intentan cooperar. (microsoft.com)
Esa apertura es buena: permite integrar capacidades (búsqueda web, GitHub, ejecución de comandos, etc.) sin diseñar todo de manera vertical. Pero también trae efectos secundarios inesperados cuando muchos agentes y herramientas conviven sin coordinarse. (microsoft.com)
¿Qué es la «tool-space interference»?
Los autores llaman tool-space interference a las situaciones en que herramientas razonables, al estar juntas, reducen la efectividad final. ¿Cómo se manifiesta eso? Por más pasos en un flujo, mayor fragilidad ante errores, decisiones equivocadas sobre qué herramienta usar, o simplemente fallas completas en la tarea. El problema surge porque un agente puede elegir la herramienta equivocada o recibir respuestas que rompen su contexto. (microsoft.com)
Un ejemplo concreto: imagina un agente orquestador que tiene a su disposición un agente que navega por el navegador, otro que ejecuta comandos git en terminal, y además un servidor MCP para GitHub. Cada uno mantiene su propio estado y permisos, así que cambiar la rama en el navegador no actualiza el terminal ni refleja autorización en GitHub. El resultado: fricción, debugging extra, o tarea fallida. (microsoft.com)
¿Qué encontró la investigación práctica?
Microsoft Research catalogó y arrancó servidores listados en registros públicos. Tras filtrar servidores no válidos, formaron un catálogo de 1,470 servidores y desarrollaron una herramienta llamada MCP Interviewer para inspeccionar automáticamente herramientas, esquemas y respuestas. Ese muestreo reveló límites reales: conteos de herramientas, longitudes de respuesta, complejidad de parámetros, colisiones de nombres y errores mal señalizados. (microsoft.com)
Algunos hallazgos relevantes:
-
Muchos servidores son pequeños, pero hay outliers con decenas o cientos de herramientas; el servidor más grande reportó 256 herramientas y varios superan las 100. Esto puede degradar el rendimiento de los modelos. (microsoft.com)
-
Las salidas de herramientas varían muchísimo en tamaño: aunque la mediana fue pequeña, algunas respuestas promedian más de medio millón de tokens, suficientes para desbordar ventanas de contexto de modelos populares. Eso complica el encadenamiento de llamadas en agentes. (microsoft.com)
-
La complejidad de los parámetros puede ser extrema: esquemas anidados de hasta 20 niveles hacen más difícil que un modelo elija y llame correctamente a una función. (microsoft.com)
-
Las colisiones de nombres son comunes: se detectaron 775 herramientas con nombres repetidos entre servidores (por ejemplo, "search" aparece en muchas fuentes), lo que dificulta la desambiguación. (microsoft.com)
-
Los errores no siempre se reportan de forma fiable: muchas respuestas contienen mensajes de error pero no activan la bandera de error del protocolo, dejando al agente sin una señal clara de que algo salió mal. (microsoft.com)
La tesis central es simple: mayor cantidad y diversidad de herramientas amplía capacidades, pero también crea fricciones que erosionan la efectividad de extremo a extremo. (microsoft.com)
Recomendaciones prácticas para cada actor
No es solo teoría; hay pasos específicos y útiles que distintos actores pueden tomar hoy para mitigar la interferencia.
Para desarrolladores de protocolos
- Agregar mecanismos para que los clientes puedan proporcionar recursos (por ejemplo, archivos locales) a servidores remotos.
- Definir namespaces formales para evitar colisiones de nombres y permitir agrupación jerárquica de herramientas. Estas medidas ayudan a que catálogos grandes sean manejables. (microsoft.com)
Para desarrolladores de servidores
- Publicar una "ficha" del servidor que describa características en tiempo de ejecución: tamaño esperado de respuestas, latencia, modelos o agentes con los que se probó, casos de prueba y limitaciones conocidas. Esa transparencia facilita la integración. (microsoft.com)
Para desarrolladores de clientes y agentes
- Implementar caching de esquemas, paginación o resumen de respuestas largas, y generar namespaces desde nombres de servidor para evitar confusiones.
- Testear servidores con agentes de prueba para reescribir o mejorar prompts defectuosos. En el estudio, una aproximación así mejoró tiempos de finalización de tareas en 40% en un experimento citado. (microsoft.com)
Para mercados y registries
- Crear configuraciones optimizadas por modelo o agente, y servir versiones de esquemas adaptadas a capacidades concretas (similar a cómo algunos mercados ajustan paquetes según sistema operativo). Esto podría centralizar buenas prácticas y reducir incompatibilidades. (microsoft.com)
¿Qué significa esto para ti como usuario o creador de IA?
Si usas agentes en producción o estás construyendo soluciones que encadenan herramientas, conviene tomarlo en serio. No es solo un problema académico: son fallas prácticas que aumentan costos, introducen fragilidad y afectan la experiencia final.
¿La buena noticia? Muchas soluciones son pragmáticas y alcanzables: mejores especificaciones, transparencia por parte de servidores, y mejores estrategias de cliente. Y hay herramientas abiertas como MCP Interviewer para auditar servidores desde hoy. (microsoft.com)
Reflexión final
Estamos en la fase donde la interoperabilidad puede acelerar la innovación o complicarla. Como en cualquier infraestructura nueva, los primeros pasos requieren normas claras y documentación honesta. Si lo hacemos bien, MCP puede ser la base de una sociedad de agentes robusta; si no, multiplicaremos fricciones en lugar de soluciones.
La recomendación práctica para cualquier equipo es empezar por pequeños contratos de compatibilidad: documentar, probar y limitar. ¿Suena obvio? Lo es. Y sin embargo, en sistemas distribuidos, lo obvio suele ser lo más fácil de pasar por alto. (microsoft.com)