Conectaste una docena de servidores MCP a tu agente de IA. GitHub, Slack, Linear, Postgres, S3, búsqueda web — el buffet completo. Tu agente en teoría puede tocar todo tu stack. Te sientes poderoso. El agente no.
Empezó a fallar en tareas que antes clavaba. Eligiendo la herramienta equivocada. Alucinando parámetros que no existen. Olvidando contexto que literalmente acabas de escribir. No rompiste nada — solo le pusiste demasiados menús para leer antes de que pudiera empezar a cocinar.
Las Matemáticas Que Nadie Te Advirtió
El 14 de abril, Cloudflare publicó una Arquitectura de Referencia MCP Empresarial que puso números reales al problema. MCP (Model Context Protocol) es un estándar universal de conexión para herramientas de IA — como USB, pero para conectar agentes a servicios externos. Cada herramienta MCP viene con un schema que le dice al modelo qué hace y qué parámetros necesita. En cada turno, el modelo lee todos.
Como desglosamos en el artículo de ayer Tool-Calling Is Dead, el propio portal de Cloudflare quemaba ~9,400 tokens solo en descripciones de herramientas — antes de que el agente tocara tu problema real. El servidor MCP de GitHub (94 herramientas) se comía ~42,000 tokens. Los números vale la pena repetirlos solo porque nada cambió entre entonces y ahora. La gente simplemente siguió enchufando servidores.
Un benchmark del 6 de marzo ya había documentado el colapso de precisión: la selección de herramientas cayó de ~95% con 4 herramientas enfocadas a ~71% con 46 herramientas. Seis semanas después, Cloudflare confirmó el mismo problema a escala empresarial. El protocolo no cambió. La cantidad de servidores sí.
Todos Lo Están Arreglando, Nadie Se Pone de Acuerdo
Cloudflare lanzó Code Mode el 16 de abril — eliminando la guía telefónica de herramientas y reemplazándola con una API tipada. Dos puntos de entrada en lugar de 2,500+. Los tokens bajaron 99.9%. Brillante. También atado exclusivamente a Cloudflare Workers. Resolvieron el problema del estándar abierto con una solución propietaria. Clásico.
Atlassian tomó la ruta de compresión. Su proyecto open-source mcp-compressor, publicado el 29 de marzo, comprime las 94 herramientas del MCP de GitHub de 17,600 tokens a 500 con compresión máxima (97% de reducción). Piensa en minificar la documentación de tu API hasta que ni tú puedas leerla. El modelo de alguna forma todavía puede — pero el tradeoff es real. Los propios benchmarks de Atlassian muestran que la compresión máxima reduce la fidelidad de restricciones de parámetros: herramientas complejas con schemas de objetos anidados pierden las pistas de validación que los modelos necesitan para invocaciones correctas. Su documentación recomienda compresión media (80% de reducción, ~3,500 tokens) para producción y reserva la máxima para "exploración solamente". La versión honesta: estás cambiando precisión por espacio y rezando para que el modelo llene los huecos.
Anthropic fue por un camino completamente distinto. El 8 de abril lanzaron Managed Agents a $0.08/hora — sub-agentes especializados con kits reducidos de 5–10 herramientas en vez de un generalista ahogándose en 50. Cada sub-agente carga solo sus propias herramientas por turno, recortando el overhead por agente aproximadamente 85%. ¿La solución para demasiadas herramientas? Más agentes con menos herramientas cada uno. Recursión como servicio.
Y después están los equipos que se saltaron la optimización y directamente empezaron a borrar cosas. El 12 de marzo, el equipo de ingeniería de GitHub Copilot compartió resultados de reducir sus herramientas de 40 a 13 — mejora de 2–5 puntos en benchmarks, 400ms menos de latencia. En febrero, Block reconstruyó su servidor MCP de Linear tres veces, reduciéndolo de 30+ herramientas a 2. El 3 de abril, Phil Schmid (Hugging Face) destiló el patrón en una sola regla: "Curar sin piedad. 5 a 15 herramientas por servidor. Un servidor, un trabajo." Sin algoritmos de compresión. Sin capas de descubrimiento. Solo disciplina.
El Problema Real Es el Protocolo
Lo que ninguna de estas soluciones arregla: cada una es propietaria, específica de plataforma, o un parche para un hueco en el propio MCP.
Cloudflare Code Mode corre en Workers. Managed Agents corre con Claude. El compressor de Atlassian es la opción más portable — y aun así es cinta adhesiva sobre un protocolo que salió al mundo sin índice.
Anthropic presentó MCP como el estándar universal. El conector único para dominarlos a todos. En cambio, estamos construyendo capas de descubrimiento específicas por vendor encima del estándar universal para que realmente funcione a escala.
Ya vimos esta misma película antes. CORBA en los '90 — un protocolo "universal" de objetos que generó toda una industria de bridges específicos por vendor solo para hacerlo usable. El Interface Repository prometía descubrimiento dinámico; en la práctica, cada fabricante de ORB envió el suyo. SOAP en los 2000 — el "estándar" empresarial que todos silenciosamente esquivaron con REST porque los archivos WSDL crecían hasta convertirse en monstruosidades ilegibles. Módulos de JavaScript — AMD, CommonJS, UMD, una década entera de fragmentación antes de que llegaran los ES modules. El patrón nunca cambia: el estándar abierto sale incompleto, los vendors llenan los huecos con capas propietarias, el ecosistema se fragmenta hasta que alguien arregla el estándar o lo mata.
MCP está en la fase de los vendors tapando agujeros. Cloudflare, Anthropic, Atlassian y una docena de jugadores más chicos — cada uno construyendo su propia respuesta a la misma feature faltante: descubrimiento dinámico de herramientas. El protocolo necesita manejar esto nativamente. No lo hace. Entonces tenemos seis soluciones competidoras y lo llamamos ecosistema.
La lectura optimista: la competencia impulsa la innovación, el mejor enfoque gana, el estándar lo absorbe. La lectura realista — a la que yo le apuesto — es que los grandes proveedores de modelos integran su descubrimiento preferido en los frameworks de agentes por defecto, y "universal" silenciosamente empieza a significar "funciona con Claude" o "funciona con GPT" pero no con ambos. USB-C con protocolos de carga propietarios, otra vez la misma historia.
Qué Hacer Hoy en la Práctica
Audita tus conexiones MCP. Elimina servidores que tu agente no haya llamado en una semana. Agrupa las herramientas restantes por dominio de tarea. Mide el uso de tokens antes y después — te va a sorprender cuánto espacio recuperas.
MCP no necesita más servidores. Necesita su momento package manager — descubrimiento dinámico y lazy loading que trate las herramientas como imports, no como variables globales metidas a la fuerza en cada prompt. Hasta entonces, menos es literalmente más. Y los agentes que mejor rindan no serán los que tengan más herramientas — serán los que aprendieron a decir que no.




