Conectaste tu agente de IA — un programa que actúa por su cuenta, llamando herramientas externas para hacer el trabajo — a una docena de servidores MCP (Model Context Protocol — un estándar universal de conexión para herramientas de IA, como USB pero para datos). Lo probaste. La demo salió genial. Lo mandaste a producción, donde los sistemas reales se rompen de formas reales.

Entonces llegó el primer timeout de herramienta. Tu agente reintentó la misma llamada fallida nueve veces, quemó $12 en tokens (pedazos de texto que la IA procesa y te cobra por uso), y alucinó un resultado falso. Porque nada — literalmente nada en el protocolo — le dijo que el error era permanente.

Cuatro prioridades, cero sobre errores

El 19 de abril, el proyecto MCP publicó su hoja de ruta 2026. Cuatro prioridades: evolución del transporte, comunicación entre agentes, gobernanza, preparación empresarial. Taxonomía de errores — lo que revienta todo agente en producción — no apareció en la lista. Ni mencionada. Ni planeada. Ni en el radar de nadie.

Esto no es un descuido que puedas ignorar. La especificación oficial de MCP (revisión actual: 25 de noviembre de 2025) define los errores de ejecución de herramientas como isError: true más una cadena de texto libre en inglés — la misma estructura que una respuesta exitosa, pero con un booleano cambiado. Sin campo de código de error. Sin header de retry-after. Sin nivel de severidad. La spec literalmente dice que los errores de herramientas contienen "retroalimentación accionable que los modelos de lenguaje pueden usar para autocorregirse". Esa "retroalimentación accionable" es una oración en inglés sin estructura que el LLM tiene que leer e interpretar por su cuenta.

HTTP — el protocolo que usa tu navegador — resolvió esto hace más de treinta años. 404 significa "no existe". 429 significa "bájale". 503 significa "intenta después". Tres dígitos. Una tabla de búsqueda. MCP le pide a un modelo de lenguaje probabilístico que haga lo que debería hacer un if-statement.

Cada quien arma su propio parche con cinta adhesiva

Alexey Tyurin publicó un MCP Reliability Playbook el 9 de marzo de 2026, a través de Google Cloud Community. Tuvo que inventar su propia taxonomía de errores — CircuitOpenError, TimeoutError, RateLimitError — como errores tipados personalizados, porque el protocolo no ofrece ninguno. Circuit breaker con umbral de error del 50%, backoff exponencial con jitter. 317 tests solo para que las herramientas no le tumbaran el agente. Todo custom. Todo por servidor. Todo incompatible con la cinta adhesiva de todos los demás.

Mientras tanto, investigadores de Polytechnique Montreal analizaron 407 bugs específicos de MCP en 385 repositorios (publicado el 5 de marzo de 2026) y encontraron que el manejo de respuestas de herramientas era la categoría de fallos más frecuente — el 66.7% de los profesionales encuestados lo habían sufrido. Y un bug de Claude Code del 11 de marzo mostró al protocolo rompiéndose de una forma aún más básica: cuando las herramientas MCP devolvían datos en el campo content sin structuredContent, Claude Code percibía una respuesta vacía y reintentaba infinitamente. El agente no sabía que ya estaba recibiendo la respuesta correcta.

Los números no mienten

Investigación de AWS Heroes del 18 de marzo cuantificó el daño: el 97.1% de las herramientas MCP tienen al menos un problema de calidad en su descripción, y las llamadas encadenadas de herramientas con 95% de éxito individual entregan solo 85.7% de confiabilidad total. Sumale el manejo de errores sin estructura a esa cadena, y estás tirando los dados con tráfico de producción.

El AAIF MCP Summit del 19 de abril en Nueva York reunió a 1,200 asistentes y al CEO de la Linux Foundation, Jim Zemlin, llamando a MCP "el Linux de los agentes". Comparación atrevida — Linux trajo códigos de error desde el día uno.

Lo que deberías hacer ahora mismo

Hasta que Anthropic — el dueño del protocolo — publique una revisión de la spec de MCP con tipos de error legibles por máquinas, envuelve tus herramientas MCP con sobres de error estructurados: un string error_type, un booleano is_retryable, y un numérico retry_delay_seconds. Pon un presupuesto estricto de reintentos por herramienta del lado del cliente. Tres intentos máximo. Después, falla ruidosamente.

El ecosistema de herramientas para agentes está repitiendo el caos de manejo de errores de la web temprana a 10x de velocidad. En algún punto entre "error de herramienta" y "$12 quemados en tokens", hay un código de estado de tres dígitos esperando ser inventado. La plataforma que lo lance primero será dueña de la capa de confiabilidad de la que todos dependen — de la misma forma que 200 OK se volvió infraestructura invisible en la que nadie piensa.

Mientras tanto, tu agente está adivinando. Y no es muy bueno adivinando.