--- title: "¿MCP ahora es stateless? Migración de servidores 2026" canonical: https://wavect.io/es/blog/mcp-stateless-server-migration-2026/ language: es description: "MCP es stateless desde 2026-07-28. Audita sesiones, headers, discovery, state handles, caché y compatibilidad en tu servidor MCP." image: "https://wavect.io/img/blog/headers/header_mcp-stateless-server-migration-2026.png" --- [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min de lectura · 31 de julio de 2026 Última revisión 31 de julio de 2026 [**Siguiente**](/es/blog/yc-application-technical-readiness-checklist/) # ¿MCP ahora es stateless? Qué cambiar en tu propio servidor MCP Resumen Sí. La especificación MCP 2026-07-28 convierte el núcleo del protocolo en stateless: elimina el handshake initialize e initialized, elimina Mcp-Session-Id y exige que cada petición incluya su versión, la información del cliente y sus capacidades. Streamable HTTP usa un POST por mensaje, con los headers MCP-Protocol-Version y Mcp-Method, además de Mcp-Name para llamadas a herramientas, recursos y prompts. Esto no vuelve stateless los datos de tu aplicación. Los flujos duraderos deben usar handles explícitos y autenticados, la extensión Tasks, requestState para entradas en varios round trips y almacenamiento normal. En un servidor remoto existente, localiza el estado oculto de sesión, añade server/discover, valida la paridad entre headers y body, devuelve listas deterministas y cacheables, conserva una ruta legacy probada durante la migración y ejecuta pruebas de conformidad, autorización, replay y balanceo round-robin. **Sí. MCP es stateless en la capa de protocolo desde la especificación `2026-07-28`.** Desaparecen el handshake initialize y `Mcp-Session-Id`. Cada petición lleva su versión, la identidad del cliente y sus capacidades. Una petición remota puede llegar a cualquier instancia sana sin sticky routing. Hay un matiz importante: MCP sin estado no significa software sin estado. Tu carrito, sesión de navegador, aprobación u orden de pago pueden seguir necesitando datos duraderos. La diferencia es que ese estado debe ser explícito, direccionable y seguro dentro de tu aplicación, no memoria oculta en una sesión de transporte MCP. Esta guía se centra en transporte y migración. Para permisos y aislamiento entre tenants, consulta nuestra [arquitectura de autorización MCP empresarial](/es/blog/enterprise-mcp-authorization-architecture/). Para decidir dónde aplicar la protección, lee por qué [MCP no es el límite de seguridad completo](/es/blog/mcp-security-boundary-data-level-access-control/). Cuando el contrato ya esté listo, usa nuestra [guía MCP Cloud vs Manufact Cloud](/es/blog/mcp-cloud-vs-manufact-cloud/) para comparar despliegue gestionado, gobierno, precios y salida. ## ¿Cuál es la respuesta directa? **MCP 2026-07-28 es un protocolo de peticiones stateless y autocontenidas. Desaparece el estado del protocolo, pero el estado de aplicación sigue permitido y suele ser necesario.** La especificación oficial define las peticiones autocontenidas y la negociación de capacidades por petición como propiedades del protocolo base. En Streamable HTTP, cada mensaje es un POST nuevo. La respuesta es un objeto JSON o un stream SSE limitado a esa petición. El antiguo stream GET, la sesión de protocolo, `Mcp-Session-Id` y la reanudación de SSE ya no forman parte de esta revisión. ## ¿Qué cambió en MCP 2026-07-28? | Tema | 2025-11-25 y versiones anteriores | 2026-07-28 | | --- | --- | --- | | Inicio | `initialize` y después `notifications/initialized` | Sin handshake; `server/discover` es opcional para el cliente | | Sesión de protocolo | El servidor puede emitir `Mcp-Session-Id` | No existe sesión ni identificador de sesión | | Contexto | Versión y capacidades negociadas una vez | Versión, client info y capacidades viajan en `_meta` en cada petición | | Routing HTTP | Puede necesitar afinidad o un almacén de sesiones compartido | Cualquier instancia puede procesar una petición autocontenida | | Metadatos HTTP | El gateway suele inspeccionar el body JSON | `MCP-Protocol-Version`, `Mcp-Method` y a veces `Mcp-Name` son obligatorios | | Entrada del cliente | El servidor podía enviar peticiones por SSE | Devuelve `input_required`; el cliente reintenta con `inputResponses` y `requestState` opcional | | Trabajo largo | Tasks experimental dentro del core | Extensión Tasks oficial con handles duraderos | | Listados | Notificaciones de cambio y polling | Orden determinista, `ttlMs` y `cacheScope` | El [changelog oficial de MCP 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog) contiene la lista completa de cambios incompatibles. También documenta `resultType`, el fin de la reanudación de streams, JSON Schema 2020-12, nuevos códigos de error y la deprecación de Roots, Sampling, Logging y HTTP+SSE. ## ¿Un servidor MCP stateless puede recordar algo? Sí. Lo que no puede hacer es depender de memoria invisible asociada a la sesión del protocolo. Imagina que una herramienta abre un navegador y otra continúa la automatización. La primera respuesta puede devolver un `browser_id` opaco y aleatorio. El cliente lo entrega en la siguiente llamada. El servidor lo resuelve en un Durable Object, una base de datos u otro almacén después de validar identidad y expiración. El flujo mantiene estado, pero cada petición MCP se entiende por sí sola. - **Una petición:** conserva el estado en variables locales y devuelve el resultado final. - **Varios round trips inmediatos:** devuelve `requestState` protegido con `input_required`. Vincúlalo al usuario autenticado, la operación original y una expiración. - **Trabajo de larga duración:** usa la [extensión MCP Tasks](https://modelcontextprotocol.io/extensions/tasks/overview) y un `taskId` duradero. - **Entidades de negocio:** devuelve un handle como `order_id`, `basket_id` o `document_id` y vuelve a autorizar cada uso. - **Notificaciones de cambios:** usa `subscriptions/listen`. El SSE abierto pertenece a una petición, no restaura una sesión. No incluyas secretos ni estado modificable dentro de un handle legible. Prefiere identificadores opacos o tokens de estado autenticados y cifrados con límites estrictos de tamaño, audiencia y expiración. ## ¿Todos los servidores MCP necesitan migración? Todas las implementaciones necesitan una auditoría, pero no el mismo trabajo. | Servidor actual | Trabajo probable | Prioridad | | --- | --- | --- | | stdio local sin funciones de sesión | Actualizar SDK, schemas, metadatos por petición y discovery | Media | | Streamable HTTP remoto sin sesiones almacenadas | Añadir contrato moderno, headers, validación, result types, caché y pruebas de compatibilidad | Alta | | Servidor remoto con `Mcp-Session-Id`, sticky routing o mapa de sesiones | Externalizar estado, crear una ruta dual-era y retirar sesiones después de migrar clientes | Máxima | | HTTP+SSE legacy | Migrar a Streamable HTTP y preparar el corte stateless | Máxima | | Sampling, Roots o logging del protocolo | Diseñar sustitutos porque estas funciones están deprecadas | Alta | Un servidor puede ser stateless en operación y hablar un protocolo legacy. También puede usar el protocolo nuevo y conservar datos duraderos. Audita el comportamiento en la red y el ciclo de vida de los datos por separado. ## ¿Qué debes cambiar en tu propio servidor MCP? 1. **Localiza estado oculto.** Busca mapas de sesión, sticky cookies, `Mcp-Session-Id`, transportes reutilizados, listas de herramientas por conexión y almacenes de eventos SSE. Clasifica cada elemento como estado de protocolo, de petición o de negocio. 2. **Implementa discovery moderno.** El servidor debe soportar `server/discover`. Devuelve versiones, capacidades, server info, instrucciones, `ttlMs` y `cacheScope`. Nunca tomes decisiones de seguridad basadas en server info autodeclarada. 3. **Valida metadatos por petición.** Exige versión y datos del cliente en `_meta`. En HTTP, exige `MCP-Protocol-Version`, `Mcp-Method` y `Mcp-Name` cuando corresponda. Si header y body difieren, rechaza con `HeaderMismatch`. 4. **Moderniza y cachea resultados.** Añade `resultType: "complete"` a respuestas normales. Mantén `tools/list` en orden determinista. Configura valores reales de `ttlMs` y `cacheScope`, sobre todo cuando la autorización cambia las herramientas visibles. 5. **Sustituye estado implícito por handles.** Deben ser impredecibles, vinculados al usuario, limitados y revocables. Las mutaciones deben ser idempotentes para que un reintento no cobre, envíe o borre dos veces. 6. **Soporta ambas eras de forma deliberada.** Un servidor dual-era atiende peticiones modernas sin sesión y conserva `initialize` para clientes antiguos. Aísla esa ruta, mide su uso y define una fecha de retirada. 7. **Prueba la arquitectura.** Envía llamadas consecutivas a instancias distintas detrás de round-robin real. Prueba headers ausentes o diferentes, versiones no soportadas, handles caducados, replay, cancelación, reintentos y acceso entre tenants. La [especificación de Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) define los headers y el comportamiento ante diferencias. Antes de elegir un corte directo, revisa la [matriz oficial de versiones y compatibilidad](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning). ## ¿Qué cambiamos en nuestro propio MCP de Wavect? Aplicamos este checklist a nuestra Cloudflare Pages Function el 31 de julio de 2026 y completamos un corte directo porque no necesitábamos conservar clientes legacy. - **Stateless en proceso y protocolo:** el handler no mantiene un mapa de sesiones en memoria y ahora solo acepta peticiones autocontenidas `2026-07-28`. - **El estado de negocio es explícito:** las herramientas de comercio usan quote IDs, order IDs, access tokens e idempotency keys. - **Discovery moderno está activo:** `server/discover` devuelve versión, capabilities, server info, instrucciones y metadatos de caché. - **El contrato HTTP se aplica:** las peticiones requieren `MCP-Protocol-Version`, `Mcp-Method` y `Mcp-Name` en llamadas de herramientas, con paridad entre header y body y validación explícita del origen. - **Las respuestas usan la forma 2026:** discovery, listados y llamadas incluyen `resultType`; los listados deterministas añaden metadatos de caché veraces. - **El lifecycle legacy desapareció:** `initialize`, `ping` y `notifications/initialized` devuelven método no encontrado en lugar de mantener un contrato antiguo. Por eso “no guardamos sesiones MCP” no basta como prueba. La topología, la versión del protocolo y el schema de respuesta pueden estar en niveles distintos. En nuestro caso, el rediseño del estado de negocio fue pequeño. El contrato de red, los controles de seguridad y las pruebas de conformidad fueron el trabajo principal. ![Kevin Riedl](/img/team/kevin.webp) "MCP stateless elimina memoria oculta del transporte, no los flujos duraderos. Haz que el estado sea explícito, autenticado y seguro ante reintentos." ## ¿Cómo debe ser el despliegue en producción? 1. Registra versiones de clientes, transportes, funciones de sesión y tasa de errores. 2. Añade pruebas de conformidad para peticiones y resultados modernos antes de cambiar tráfico. 3. Despliega un endpoint dual-era o uno moderno separado según el control que tengas sobre los clientes. 4. Mueve clientes internos y canary a la ruta nueva. Fuerza instancias distintas en llamadas consecutivas. 5. Observa errores de versión, diferencias de headers, reintentos, latencia, efectos duplicados y fallos de autorización. 6. Publica una fecha de migración y una ventana de rollback. No borres storage legacy tras una sola prueba. 7. Retira sticky routing y sesiones solo cuando la telemetría confirme que ya no existe dependencia legacy. Cloudflare documenta un handler stateless y una transición gradual para funciones con sesión en su [guía de migración a MCP SDK v2](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/). El mismo modelo sirve aunque uses otro runtime. ## ¿Qué debes preguntar a un proveedor de desarrollo MCP? - ¿Qué versiones y eras de cliente soportará el servidor en producción? - ¿Qué estado vive en la petición, cuál es duradero y cuál depende de una sesión? - ¿Cómo se vinculan los handles con identidad, tenant, operación y expiración? - ¿Cómo evita la idempotencia pagos, escrituras y efectos duplicados? - ¿Puede el equipo demostrar dos llamadas seguidas en instancias diferentes? - ¿Cómo valida el gateway y el origen los headers contra el body JSON? - ¿Qué se cachea, cuánto tiempo y cómo se evita que una lista privada llegue a caché compartida? - ¿Qué funciones deprecadas quedan y cuál es su sustitución? - ¿Qué evidencia permite cerrar la ruta legacy: telemetría, inventario, rollback y fecha? Si una propuesta solo dice “actualizar el SDK”, está incompleta. El entregable debe incluir inventario de estado, decisión de compatibilidad, threat model, pruebas de migración, evidencia canary y plan de rollback. ## Preguntas frecuentes ### ¿MCP es completamente stateless ahora? El núcleo 2026-07-28 es stateless. Las aplicaciones pueden mantener datos duraderos con handles explícitos, storage, Tasks y request state. ### ¿Sigue existiendo Streamable HTTP? Sí. Sigue siendo el transporte remoto estándar, pero cada mensaje es un POST propio y ya no existen el stream GET ni la sesión de protocolo. ### ¿Debo seguir enviando initialize? No en peticiones modernas. Usa metadatos por petición y, si te conviene, `server/discover`. Un servidor dual-era puede responder a `initialize` para clientes legacy. ### ¿Sigo necesitando Redis o Durable Objects? No para sesiones del protocolo MCP. Sí pueden ser necesarios para jobs, órdenes, navegadores, locks, rate limits y otros datos de aplicación. ### ¿Puedo quitar sticky sessions de inmediato? Solo después de probar llamadas modernas en instancias diferentes y confirmar por telemetría que ningún cliente soportado depende de la ruta antigua. ## Reflexiones finales MCP ahora es stateless donde importa para escalar: no hay lifecycle initialize, Mcp-Session-Id ni memoria de conexión oculta necesaria para entender una petición. Tu producto puede conservar estado. Muévelo detrás de handles explícitos y autorizados; adopta discovery, headers obligatorios, resultados modernos y caché; conserva una ruta de compatibilidad medible; y demuestra la migración con round-robin antes de retirar la infraestructura legacy. ## Fuentes primarias - [Especificación Model Context Protocol 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28) - [Cambios y deprecaciones de MCP 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog) - [Transporte MCP Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) - [Discovery de servidores MCP](https://modelcontextprotocol.io/specification/2026-07-28/server/discover) - [Herramientas MCP, caché y resultados multi round-trip](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) - [Extensión MCP Tasks](https://modelcontextprotocol.io/extensions/tasks/overview) - [Soporte del servidor MCP de GitHub para el protocolo stateless](https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/) - [Migración de Cloudflare a handlers MCP stateless](https://developers.cloudflare.com/agents/model-context-protocol/guides/migrate-to-mcp-sdk-v2/) ## También te puede gustar.. [**MCP no es un límite de seguridad** Aplica identidad, políticas de datos y autorización en controles que un agente no pueda evitar.](/es/blog/mcp-security-boundary-data-level-access-control/) [**Arquitectura de autorización MCP empresarial** Diseña OAuth, audience binding, acceso delegado y aislamiento de tenants para un servidor MCP en producción.](/es/blog/enterprise-mcp-authorization-architecture/) Ingeniería de agentes ## Continúa por este clúster Agentes de código, MCP, contexto, evaluación y controles para automatización fiable. [Empieza por el artículo fundamental**Ingeniería de grafos para agentes de IA: ¿Cuándo compensa un knowledge graph?**](/es/blog/graph-engineering-ai-agents/) - [TrueForge: análisis del agent harness open source para producción](/es/blog/trueforge-agent-harness-review/) - [Webs legibles por agentes: llms.txt, espejos en Markdown y qué se rompe](/es/blog/agent-readable-website-llms-txt-markdown-mirrors/) - [Las URLs traducidas rompen hreflang: usa un solo slug en inglés](/es/blog/english-slugs-vs-localized-urls-hreflang/) - [¿Puede un agente de IA usar tu producto, o solo leer sobre él?](/es/blog/can-an-ai-agent-use-your-product/) - [Graft Review 2026: ¿el mapa del repo debe ir en Git?](/es/blog/graft-review-agent-repo-map/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/es/team/kevin-riedl/) [Kevin Riedl](/es/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min de lectura · 31 de julio de 2026 Última revisión 31 de julio de 2026 [**Siguiente**](/es/blog/yc-application-technical-readiness-checklist/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/mcp-stateless-server-migration-2026/#webpage", "@type": "WebPage", "dateModified": "2026-08-01", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-01", "url": "https://wavect.io/es/blog/mcp-stateless-server-migration-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Sí. La especificación MCP 2026-07-28 convierte el núcleo del protocolo en stateless: elimina el handshake initialize e initialized, elimina Mcp-Session-Id y exige que cada petición incluya su versión, la información del cliente y sus capacidades. Streamable HTTP usa un POST por mensaje, con los headers MCP-Protocol-Version y Mcp-Method, además de Mcp-Name para llamadas a herramientas, recursos y prompts. Esto no vuelve stateless los datos de tu aplicación. Los flujos duraderos deben usar handles explícitos y autenticados, la extensión Tasks, requestState para entradas en varios round trips y almacenamiento normal. En un servidor remoto existente, localiza el estado oculto de sesión, añade server/discover, valida la paridad entre headers y body, devuelve listas deterministas y cacheables, conserva una ruta legacy probada durante la migración y ejecuta pruebas de conformidad, autorización, replay y balanceo round-robin.", "articleBody": " Resumen del blog/IA y agentes/Ingeniería de agentes ¿MCP ahora es stateless? Qué cambiar en tu propio servidor MCP Resumen Sí. La especificación MCP 2026-07-28 convierte el núcleo del protocolo en stateless: elimina el handshake initialize e initialized, elimina Mcp-Session-Id y exige que cada petición incluya su versión, la información del cliente y sus capacidades. Streamable HTTP usa un POST por mensaje, con los headers MCP-Protocol-Version y Mcp-Method, además de Mcp-Name para llamadas a herramientas, recursos y prompts. Esto no vuelve stateless los datos de tu aplicación. Los flujos duraderos deben usar handles explícitos y autenticados, la extensión Tasks, requestState para entradas en varios round trips y almacenamiento normal. En un servidor remoto existente, localiza el estado oculto de sesión, añade server/discover, valida la paridad entre headers y body, devuelve listas deterministas y cacheables, conserva una ruta legacy probada durante la migración y ejecuta pruebas de conformidad, autorización, replay y balanceo round-robin. Sí. MCP es stateless en la capa de protocolo desde la especificación 2026-07-28. Desaparecen el handshake initialize y Mcp-Session-Id. Cada petición lleva su versión, la identidad del cliente y sus capacidades. Una petición remota puede llegar a cualquier instancia sana sin sticky routing. Hay un matiz importante: MCP sin estado no significa software sin estado. Tu carrito, sesión de navegador, aprobación u orden de pago pueden seguir necesitando datos duraderos. La diferencia es que ese estado debe ser explícito, direccionable y seguro dentro de tu aplicación, no memoria oculta en una sesión de transporte MCP. Esta guía se centra en transporte y migración. Para permisos y aislamiento entre tenants, consulta nuestra arquitectura de autorización MCP empresarial. Para decidir dónde aplicar la protección, lee por qué MCP no es el límite de seguridad completo. Cuando el contrato ya esté listo, usa nuestra guía MCP Cloud vs Manufact Cloud para comparar despliegue gestionado, gobierno, precios y salida. ¿Cuál es la respuesta directa? MCP 2026-07-28 es un protocolo de peticiones stateless y autocontenidas. Desaparece el estado del protocolo, pero el estado de aplicación sigue permitido y suele ser necesario. La especificación oficial define las peticiones autocontenidas y la negociación de capacidades por petición como propiedades del protocolo base. En Streamable HTTP, cada mensaje es un POST nuevo. La respuesta es un objeto JSON o un stream SSE limitado a esa petición. El antiguo stream GET, la sesión de protocolo, Mcp-Session-Id y la reanudación de SSE ya no forman parte de esta revisión. ¿Qué cambió en MCP 2026-07-28? Tema2025-11-25 y versiones anteriores2026-07-28 Inicioinitialize y después notifications/initializedSin handshake; server/discover es opcional para el cliente Sesión de protocoloEl servidor puede emitir Mcp-Session-IdNo existe sesión ni identificador de sesión ContextoVersión y capacidades negociadas una vezVersión, client info y capacidades viajan en _meta en cada petición Routing HTTPPuede necesitar afinidad o un almacén de sesiones compartidoCualquier instancia puede procesar una petición autocontenida Metadatos HTTPEl gateway suele inspeccionar el body JSONMCP-Protocol-Version, Mcp-Method y a veces Mcp-Name son obligatorios Entrada del clienteEl servidor podía enviar peticiones por SSEDevuelve input_required; el cliente reintenta con inputResponses y requestState opcional Trabajo largoTasks experimental dentro del coreExtensión Tasks oficial con handles duraderos ListadosNotificaciones de cambio y pollingOrden determinista, ttlMs y cacheScope El changelog oficial de MCP 2026-07-28 contiene la lista completa de cambios incompatibles. También documenta resultType, el fin de la reanudación de streams, JSON Schema 2020-12, nuevos códigos de error y la deprecación de Roots, Sampling, Logging y HTTP+SSE. ¿Un servidor MCP stateless puede recordar algo? Sí. Lo que no puede hacer es depender de memoria invisible asociada a la sesión del protocolo. Imagina que una herramienta abre un navegador y otra continúa la automatización. La primera respuesta puede devolver un browser_id opaco y aleatorio. El cliente lo entrega en la siguiente llamada. El servidor lo resuelve en un Durable Object, una base de datos u otro almacén después de validar identidad y expiración. El flujo mantiene estado, pero cada petición MCP se entiende por sí sola. Una petición: conserva el estado en variables locales y devuelve el resultado final. Varios round trips inmediatos: devuelve requestState protegido con input_required. Vincúlalo al usuario autenticado, la operación original y una expiración. Trabajo de larga duración: usa la extensión MCP Tasks y un taskId duradero. Entidades de negocio: devuelve un handle como order_id, basket_id o document_id y vuelve a autorizar cada uso. Notificaciones de cambios: usa subscriptions/listen. El SSE abierto pertenece a una petición, no restaura una", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-31", "datePublished": "2026-07-31", "description": "Sí. La especificación MCP 2026-07-28 convierte el núcleo del protocolo en stateless: elimina el handshake initialize e initialized, elimina Mcp-Session-Id y exige que cada petición incluya su versión, la información del cliente y sus capacidades. Streamable HTTP usa un POST por mensaje, con los headers MCP-Protocol-Version y Mcp-Method, además de Mcp-Name para llamadas a herramientas, recursos y prompts. Esto no vuelve stateless los datos de tu aplicación. Los flujos duraderos deben usar handles explícitos y autenticados, la extensión Tasks, requestState para entradas en varios round trips y almacenamiento normal. En un servidor remoto existente, localiza el estado oculto de sesión, añade server/discover, valida la paridad entre headers y body, devuelve listas deterministas y cacheables, conserva una ruta legacy probada durante la migración y ejecuta pruebas de conformidad, autorización, replay y balanceo round-robin.", "headline": "¿MCP ahora es stateless? Checklist para migrar tu servidor", "image": "https://wavect.io/img/blog/headers/header_mcp-stateless-server-migration-2026.svg", "inLanguage": "es", "keywords": "servidor MCP stateless, migración MCP 2026-07-28, Streamable HTTP", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/mcp-stateless-server-migration-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/mcp-stateless-server-migration-2026/", "wordCount": 2204 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/ai-agents/", "name": "IA y agentes", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/agent-engineering/", "name": "Ingeniería de agentes", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/mcp-stateless-server-migration-2026/", "name": "¿MCP ahora es stateless? Migración de servidores 2026 | ", "position": 5 } ] } ```