MCP ya tiene release candidate stateless: por que esto cambia despliegue, tasks largas y auth de agentes

El 21 de mayo de 2026 los maintainers de Model Context Protocol publicaron el release candidate de la especificacion 2026-07-28. La nota oficial lo define como la revision más grande desde el lanzamiento, y por una vez no suena a exageracion de roadmap. El paquete junta varias piezas que pegan directo en despliegue real: core stateless, Tasks para trabajo largo, MCP Apps, cambios de autorizacion más alineados con OAuth/OIDC y una política formal de deprecaciones.

Para equipos que ya usan MCP en serio, la noticia no es de sintaxis. Es de arquitectura.

El punto de fondo: salir del cuello de botella stateful

El blog oficial ya venia preparando esto desde el roadmap de marzo. La friccion estaba clara: a medida que MCP se movió de local tooling a despliegues remotos y corporativos, las conexiones stateful empezaron a chocar con patrones normales de infraestructura.

Traducido a builder:

• balancear trafico se vuelve más incomodo;
• escalar horizontalmente duele más;
• y meter MCP dentro de plataformas gestionadas exige más pegamento del deseable.

Por eso el cambió a un core stateless importa tanto. No es solo elegancia de protocolo. Es la diferencia entre algo que vive bonito en demos y algo que coopera mejor con HTTP corriente, balanceadores y servicios remotos de verdad.

Tasks deja de ser idea linda y se vuelve pieza operativa

La descripcion del RC también remarca long-running work through the Tasks extension. Eso merece atencion porque muchos agentes ya no caben en la logica de “tool call sincrona y respuesta inmediata”.

Hay trabajo que toma minutos u horas:

• scraping largo;
• evals con muchas corridas;
• compilaciones grandes;
• análisis sobre muchos documentos;
• o handoffs donde el humano vuelve después.

Si MCP quiere ser capa común entre clientes y servidores, necesitaba una forma más sería de hablar de trabajo largo. El RC deja claro que esa pieza ya no va como idea lateral.

Auth más cercana a como trabajan las empresas

Otra parte que parece aburrida y no lo es: la autorizacion alineada más de cerca con OAuth y OpenID Connect.

Esto importa porque una parte enorme del valor de MCP esta en conectar agentes con sistemas reales. Y en cuanto tocas sistemas reales, auth deja de ser detalle técnico para volverse requisito de adopcion.

Si el protocolo se acerca mejor a flujos que las empresas ya entienden y operan, baja la friccion para:

• proveedores de plataformas;
• equipos de seguridad;
• y builders que no quieren inventar auth custom para cada servidor remoto.

No viene solo: Apps y deprecaciones también pesan

El mismo RC amarra otras dos senales fuertes.

La primera es que MCP Apps ya no parece experimento aislado, sino parte del mismo empuje para que el protocolo soporte experiencias más completas que solo texto y JSON.

La segunda es la política formal de deprecaciones. Puede sonar administrativa, pero en un protocolo que ya esta por todas partes es exactamente el tipo de disciplina que separa crecimiento sano de ruptura constante.

Que haria yo si ya opero MCP

No esperaria al release final de julio para pensar el impacto. Este RC ya sirve como checklist:

1. revisar donde tu stack depende de estado de sesion;
2. identificar tools o jobs que merecen moverse a Tasks;
3. mapear si tu auth actual se alinea con el camino nuevo;
4. y decidir que partes del producto piden UI via Apps y cuales siguen bien solo con texto.

Eso no significa migrar todo hoy. Significa evitar que el equipo se sorprenda cuando la especificacion finalice.