Conectaste tu agente de IA a una docena de herramientas MCP — Slack, GitHub, Jira — lo probaste, lo pusiste en producción, y seguiste con tu vida. MCP (Model Context Protocol) es el estándar universal de conexión para herramientas de IA: piensa en USB-C, pero para conectar tu IA con servicios externos. Escribiste tus prompts, el agente llamó sus herramientas, todo bien.

Entonces una de esas herramientas actualizó su schema — el contrato que define qué parámetros acepta una herramienta y qué devuelve — renombró un campo de query a search_query, y tu agente empezó a fallar silenciosamente en cada tercera petición. Sin error. Sin notificación. La IA simplemente alucinó alrededor del input roto como si nada hubiera pasado. Como documentó el desarrollador Mike en un caso de estudio en DEV Community el 18 de marzo: "La amabilidad del modelo es el amplificador que convierte un bug menor de integración en una falla invisible."

Esto no es un caso hipotético. Es el estado por defecto de todo el ecosistema.

La escala del desastre sin versionar

A abril de 2026, MCP alcanzó 97 millones de descargas mensuales del SDK, con más de 17,000 servidores públicos y más de 300 clientes. Eso es un crecimiento del 2,250% en siete meses. Y en todo eso — cero estándar de versionado.

Cada otra dependencia en tu stack tiene gestión de versiones. npm tiene lockfiles — archivos que fijan versiones exactas de dependencias para que nada cambie sin tu aprobación. Docker tiene digests de imagen. Las APIs tienen specs de OpenAPI con avisos de deprecación. ¿Pero los schemas de herramientas MCP? Un autor de servidor puede renombrar parámetros, cambiar tipos de retorno o eliminar endpoints en cualquier momento sin ninguna señal al ecosistema. Sin semver (el sistema de numeración "1.2.3" que te dice si un cambio va a romper tu código). Sin lockfile. Sin changelog.

La única propuesta para arreglar esto — SEP-1575 en GitHub, que agregaría un campo version a las definiciones de herramientas — lleva estancada en draft desde septiembre 2025. ¿Versionado a nivel de servidor vs. a nivel de herramienta? Siguen debatiendo. Dieciocho meses después de que MCP se lanzó.

Mientras tanto, según la investigación de KushoAI, el 41% de las APIs experimentan cambios de schema no documentados dentro de 30 días. Ahora aplica eso a 17,000 servidores MCP.

El drift de modelos fue noticia. El drift de herramientas ni se registra.

El 16 de abril, Anthropic cambió el alias flotante opus para que resolviera a Claude Opus 4.7 — lo que significó que cada herramienta usando ese alias silenciosamente obtuvo un modelo diferente con un tokenizador que puede incrementar los costos por token hasta un 35%. Eso fue noticia. La gente se dio cuenta porque los modelos son visibles.

¿Los schemas de herramientas? Nadie los monitorea. Ninguna plataforma rastrea cambios en 17,000 servidores. Tu agente se rompe, le echas la culpa a tu prompt, le echas la culpa al modelo, te pasas tres días debuggeando — y la causa real fue un parámetro renombrado en una herramienta que no tocaste en semanas.

AWS lanza el primer golpe

El 17 de abril, AWS lanzó Agent Registry en preview como parte de Amazon Bedrock AgentCore. Es un catálogo centralizado para agentes de IA, herramientas y servidores MCP con — por fin — seguimiento de versiones. Los registros siguen un ciclo de vida de draft → aprobación pendiente → descubrible. Cualquier actualización resetea el estado a draft, forzando una re-revisión.

Es el primer gran proveedor de nube que lanza algo que se parezca a conciencia de versiones para herramientas MCP. Justin Bundick, VP de IA en Southwest Airlines, lo llamó una solución al "desafío crítico de descubribilidad."

Pero acá está la brecha: es un catálogo, no un lockfile. Rastrea que las versiones existen — no previene que los cambios que rompen todo lleguen a tu agente. Todavía no puedes fijar una herramienta a un snapshot específico de schema como fijarías [email protected] en package.json. Y el ADK 1.0 de Google — que lanzó soporte estable de MCP el 30 de marzo — ni siquiera menciona versionado de herramientas en su documentación.

Qué puedes hacer hoy en la práctica

Si tu agente se rompió esta semana y no encuentras el bug en tu prompt ni en tu modelo, revisa si alguna herramienta cambió su schema. No tienes forma automatizada de saberlo — pero al menos ahora sabes dónde buscar.

Las opciones prácticas son feas: hacer fork y self-host de tus servidores MCP (lo cual mata el propósito), construir una capa de proxy que tome snapshots de schemas (complejidad que nadie presupuesta), o usar herramientas comunitarias como mcpdiff para hacer diff manual de las definiciones de herramientas entre ejecuciones. Ninguna escala. Todas son cinta adhesiva.

El stack de agentes ahora tiene dos dependencias sombra sin versionar — modelos y herramientas. Anthropic al menos te deja fijar versiones de modelos con identificadores completos como claude-opus-4-7. Los schemas de herramientas no tienen equivalente. La primera plataforma que lance detección real de cambios que rompen cosas — no un catálogo, sino un lockfile real con integración CI — captura la capa de package manager de la era de agentes.

Hasta entonces, estás desplegando agentes de producción sobre dependencias que pueden cambiar bajo tus pies en cualquier momento, sin notificación, sin diff y sin rollback. npm sin lockfile. En 2026. Para IA en producción.

Dulces sueños.