La quinta revisión del Model Context Protocol se publicó a finales de julio y Claude fue el primer cliente grande en anunciar soporte el mismo día. Un mes después, con el despliegue ya rodando por las aplicaciones de Claude, la plataforma, Claude Code y Cowork, toca mirar qué cambia de verdad para quien mantiene un servidor MCP. Y el cambio es de los que se notan en la factura de infraestructura: el protocolo abandona el modelo bidireccional con estado y adopta uno de petición y respuesta.
La dimensión del asunto se entiende con un número: MCP ha superado los 400 millones de descargas mensuales de sus SDK, cuatro veces más que a principios de año. Lo que empezó como una propuesta de Anthropic para conectar agentes con herramientas se ha convertido en la capa de integración por defecto del sector, y una revisión de este calado no es un detalle de documentación.
Sin estado quiere decir que tu servidor puede desaparecer entre llamadas
Hasta esta revisión, un servidor MCP era una conversación: se abría una conexión, se mantenía viva y cliente y servidor se hablaban en ambas direcciones mientras durara la sesión. Eso obliga a tener un proceso corriendo todo el tiempo, con su memoria, su gestión de reconexiones y su factura de servidor encendido aunque nadie lo use.
El modelo de petición y respuesta rompe esa atadura. Cada llamada se basta a sí misma, así que un servidor MCP puede desplegarse en infraestructura serverless o en el edge: una función que se levanta, responde y se apaga. Para quien mantiene integraciones propias, esto cambia la aritmética por completo. Un servidor MCP que exponga tus utilidades internas deja de ser algo que hay que hospedar y vigilar, y pasa a ser algo que se despliega como cualquier otra función y que solo cuesta cuando se usa.
El coste de mantener un servidor MCP propio acaba de bajar de «un proceso siempre encendido» a «una función que responde cuando la llaman».
Hay una consecuencia menos obvia y más importante para la fiabilidad: un servidor sin estado se escala horizontalmente sin coordinación. Si dos agentes llaman a la vez, atienden dos instancias y nadie tiene que ponerse de acuerdo sobre quién guarda qué. Los problemas de sesiones colgadas, reconexiones a medias y estados inconsistentes —el tipo de fallo que aparece justo cuando el flujo lleva tres semanas funcionando— dejan de existir por construcción, no por haberlos arreglado.
La autorización deja de ser un apaño
El segundo cambio grande es el que desbloquea el uso corporativo. La autorización de MCP se alinea con despliegues reales de OAuth 2.0 y OIDC, de modo que un servidor MCP se conecta a los sistemas de identidad que ya usa una empresa —Entra, Okta— sin soluciones a medida.
Quien haya intentado montar un conector para un cliente corporativo sabe por qué esto importa más que cualquier función nueva. El bloqueo nunca estaba en el protocolo ni en el modelo: estaba en la reunión con el departamento de sistemas, donde había que explicar por qué esa integración necesitaba un mecanismo de autenticación propio en vez de pasar por el proveedor de identidad de la casa. Con OAuth y OIDC estándar, esa conversación se vuelve rutinaria.
💡 Dónde se nota primero: en los conectores que ahora mismo llevas con un token estático en una variable de entorno. Eso funciona mientras el cliente sea pequeño y deja de funcionar en cuanto alguien de seguridad pregunta cómo se revoca ese acceso cuando un empleado se va. Con autorización estándar, la respuesta es «como todo lo demás».
Apps y Tasks salen del núcleo y entran en extensiones versionadas
La tercera pieza es organizativa y marca cómo va a evolucionar el protocolo. MCP Apps —interfaces interactivas renderizadas dentro de la propia conversación— y MCP Tasks —trabajos de larga duración— pasan a vivir bajo un marco de extensiones versionadas, en lugar de crecer dentro del núcleo.
Es una decisión de arquitectura con efecto directo en la estabilidad de lo que construyes. Un núcleo pequeño y estable, con capacidades opcionales que se versionan por separado, significa que la próxima función ambiciosa del protocolo no obliga a revisar todos los servidores existentes. También significa que puedes adoptar Tasks sin adoptar Apps, y que cada extensión declara su versión, así que la compatibilidad se negocia en vez de suponerse.
De las dos, Tasks es la que más encaja en un flujo de automatización real. Los trabajos de larga duración eran hasta ahora el punto débil del patrón: una herramienta que tarda cuatro minutos en devolver algo rompe la conversación con el agente y obliga a inventar mecanismos de sondeo. Tener eso resuelto en el protocolo, y no en cada integración, es lo que separa una demostración de algo que se pone en producción.
Qué mirar en tus servidores MCP esta semana
El soporte en Claude se ha desplegado de forma progresiva por las distintas superficies, así que lo primero es no dar por hecho que todo tu entorno está en la misma versión. A partir de ahí, tres revisiones que compensan.
- Comprueba qué versión de la especificación habla cada servidor tuyo. Los que dependan del modelo con estado siguen funcionando, pero ya no están en la línea principal de evolución del protocolo. Saber cuáles son es el primer paso para planificar.
- Revisa dónde vive cada servidor y cuánto cuesta tenerlo encendido. Si tienes uno corriendo permanentemente para atender unas pocas llamadas al día, ahora hay una alternativa más barata que además se escala sola.
- Mira los conectores que expones a clientes. Cualquiera que autentique con un secreto compartido es candidato a migrar a autorización estándar, y ese cambio te quita de encima la parte más incómoda de vender una integración a una empresa con departamento de seguridad.
La lectura de fondo es que MCP está haciendo el recorrido que hicieron en su día los protocolos que acabaron siendo infraestructura invisible: empieza flexible y conversacional, y termina simple, sin estado y aburrido. Aburrido, en este contexto, es el mayor elogio posible. Significa que dentro de un año nadie hablará de la especificación y todo el mundo tendrá servidores corriendo sin pensar en ellos, que es exactamente donde quieres que esté una pieza de la que dependen tus automatizaciones.
