Introducción
El Protocolo de Contexto de Modelo (Model Context Protocol) ha experimentado la revisión arquitectónica más grande desde su publicación.
Cuando MCP fue introducido inicialmente, era una forma universal de permitir que las aplicaciones de IA conectaran modelos con herramientas, API, fuentes de datos, archivos y sistemas externos. En menos de dos años, ha evolucionado de un proyecto de integración liderado por Anthropic a un protocolo de código abierto más amplio, con su propio proceso de gobernanza, ecosistema de SDK, grupos de trabajo, extensiones e implementaciones en numerosos productos de IA.
La revisión 2026-07-28 se centra en los problemas que surgen cuando MCP sale de las computadoras portátiles de los desarrolladores y entra en entornos de producción a gran escala.
El cambio principal se puede resumir de la siguiente manera:
MCP se está volviendo sin estado a nivel de protocolo.
Este cambio elimina el handshake de sesión e inicialización a nivel de protocolo del nuevo formato en línea, permitiendo que los servidores MCP remotos se implementen más fácilmente detrás de balanceadores de carga comunes, infraestructura serverless, nodos de computación en el borde y arquitecturas de escalado horizontal.
Pero el transporte sin estado es solo una parte de esta actualización.
Esta revisión también formaliza un marco de extensiones, rediseña las tareas de larga duración, introduce solicitudes de ida y vuelta múltiple, añade encabezados HTTP enrutables y sugerencias de caché, refuerza los mecanismos de autorización, amplía el soporte de JSON Schema y establece una política formal de deprecación de funciones.
Más allá del protocolo en sí, el ecosistema MCP está añadiendo aplicaciones interactivas, autorización alojada a nivel empresarial, túneles de red privada y herramientas de desarrollo más potentes.
Es en este punto donde MCP comienza a parecerse menos a un conector conveniente para agentes y más a infraestructura de nivel de producción.
El ritmo de adopción de MCP está creciendo rápidamente
El informe fuente destaca la velocidad de crecimiento del uso de MCP.
Según el anuncio para desarrolladores de Claude citado en el artículo fuente:
- Las descargas mensuales de los SDK de MCP han superado los 400 millones.
- El uso mensual de los SDK se ha multiplicado aproximadamente por cuatro en el año.
- Las descargas acumuladas de los SDK de TypeScript y Python han superado hitos muy importantes.
- Cientos de integraciones de MCP están disponibles a través del ecosistema de conectores de Claude.
Estos datos específicos de finales de julio pertenecen a métricas del anuncio, no a cifras publicadas en la especificación principal.
Un anuncio oficial anterior de Anthropic proporciona un punto de referencia útil: en enero de 2026, Anthropic indicó que MCP había alcanzado 100 millones de descargas mensuales.
Esto significa que, antes del rediseño del protocolo en julio, el ecosistema ya era bastante grande.
Por lo tanto, la importancia de esta actualización no radica en que MCP intente ser útil en el futuro, sino en que los mantenedores están rediseñando el protocolo en torno a problemas que ya se han manifestado a escala de producción.
Estos problemas incluyen:
- Sesiones adhesivas.
- Almacenamiento de sesiones compartido.
- Escalado horizontal.
- Implementaciones serverless.
- Enrutamiento de puertas de enlace.
- Complejidad de autenticación.
- Operaciones de agentes de larga duración.
- Interfaces interactivas.
- Compatibilidad hacia atrás.
- Evolución del protocolo.
Por qué el diseño con estado anterior se convirtió en un desafío de escalado
Las implementaciones remotas tempranas de MCP podían mantener estado de sesión a nivel de protocolo.
El cliente normalmente inicializaba una
conexión y obtenía un identificador de sesión. Las solicitudes posteriores necesitaban mantener asociación con esa sesión.
Un flujo simplificado de 2025-11-25 se veía así:
POST /mcp HTTP/1.1
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
Después de la inicialización, las llamadas posteriores podían incluir:
Mcp-Session-Id: 1868a90c-3a3f-4f5b
Este enfoque funcionaba para muchas aplicaciones, pero imponía ciertos requisitos a nivel de infraestructura.
Las implementaciones de producción podían requerir:
- Enrutamiento de balanceador de carga con sesiones adhesivas.
- Almacenamiento de sesiones compartido.
- Replicación de sesiones.
- Lógica de expiración de sesiones.
- Manejo de conmutación por error.
- Observabilidad consciente de la conexión.
- Manejo especial para reinicios del servidor.
Los mantenedores de MCP concluyeron que estos requisitos estaban demasiado acoplados al protocolo en sí.
La nueva revisión elimina esta suposición.
MCP ahora es sin estado a nivel de protocolo
En el diseño del protocolo 2026-07-28, cada solicitud incluye toda la información que el servidor necesita para procesarla.
El ejemplo oficial es el siguiente:
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "otters"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}
Ya no hay Mcp-Session-Id a nivel de protocolo.
Ya no hay una sesión de conexión obligatoria que vincule las solicitudes a una única instancia del servidor.
Cualquier instancia de servidor compatible puede procesar la solicitud.
Esto es una mejora significativa para las implementaciones en la nube.
Los servidores MCP remotos ahora pueden adaptarse a arquitecturas tradicionales:
Cliente
↓
Puerta de enlace API / Balanceador de carga
↓
Instancia de servidor MCP A
Instancia de servidor MCP B
Instancia de servidor MCP C
Las solicitudes ya no necesitan volver a una instancia específica porque una solicitud anterior cayó en esa instancia.
El handshake initialize se elimina del nuevo formato en línea
El rediseño sin estado también elimina el ciclo de vida anterior de initialize / initialized del formato en línea 2026-07-28.
La información que antes se transmitía solo una vez durante la inicialización ahora se envía con cada solicitud a través de metadatos.
Cuando el cliente desea descubrir las capacidades del servidor por adelantado, puede usar el nuevo método server/discover.
Esto no significa que los clientes antiguos dejen de funcionar inmediatamente.
La documentación actual del SDK incluye notas sobre el comportamiento de compatibilidad con versiones anteriores del protocolo. Por ejemplo, el SDK de C# puede admitir el nuevo camino sin estado
mientras continúa negociando el comportamiento basado en sesiones anteriores con clientes que usan el protocolo 2025-11-25.
La diferencia clave de migración es:
2026-07-28:
Modelo de solicitudes sin estado, sin sesión de protocolo.
Versiones anteriores:
El handshake de inicialización y el comportamiento sensible a la sesión pueden seguir siendo compatibles
mediante negociación de versiones y rutas de compatibilidad del SDK.
Los desarrolladores deben probar ambos extremos de la integración, en lugar de solo actualizar el servidor y suponer que todos los clientes entenderán la nueva versión.
## Un protocolo sin estado no significa una aplicación sin estado
Uno de los errores más fáciles de cometer es interpretar este cambio como:
> Las aplicaciones MCP ya no pueden mantener estado.
Eso no es lo que significa la especificación.
La **capa de protocolo** no tiene estado.
Las aplicaciones aún pueden mantener estado donde sea útil.
Supongamos que una herramienta de compras crea una cesta.
El servidor puede devolver:
```JSON
{
"basket_id": "basket_8472"
}
El modelo puede pasar ese valor en llamadas posteriores:
{
"basket_id": "basket_8472",
"item_id": "item_123"
}
Esto hace que el estado de la aplicación sea visible como datos normales de la herramienta, en lugar de ocultarlo en metadatos de transporte.
El mismo patrón puede usarse para sesiones de navegador, tareas de informes, carritos de compra, IDs de flujo de trabajo, IDs de despliegue, estado de edición de documentos y tareas de análisis de larga duración.
Por qué los identificadores explícitos pueden ser mejores
Los identificadores visibles tienen varias ventajas.
El modelo puede:
- Pasarlos entre herramientas relacionadas.
- Razonar a qué tarea pertenece cada identificador.
- Incluirlos en registros.
- Recuperarlos tras un reintento.
- Entregarlos al siguiente paso del flujo de trabajo.
El servidor puede:
- Validar el identificador.
- Hacer que expire.
- Vincularlo a un usuario o inquilino.
- Rechazar estado caducado.
- Almacenar el estado real en una base de datos.
Por lo tanto, un MCP sin estado traslada la gestión de estado desde la capa de transporte hacia un diseño explícito de la aplicación.
La informática sin servidor y la escalado horizontal se vuelven mucho más fáciles
El artículo original destacó los despliegues sin servidor, uno de los resultados más prácticos del nuevo protocolo.
Cuando las solicitudes son autocontenidas, los servidores MCP pueden ejecutarse más fácilmente en entornos como:
- AWS Lambda.
- Cloudflare Workers.
- Vercel.
- Otras funciones sin servidor.
- Plataformas de autoescalado de contenedores.
- Despliegues comunes de Kubernetes sin estado.
- Entornos perimetrales.
Esto no significa que cada carga de trabajo de MCP funcione automáticamente en toda plataforma sin servidor.
Los desarrolladores aún deben considerar la duración de ejecución, la compatibilidad con streaming, el arranque en frío, el estado persistente de la aplicación, las claves, la red saliente, las tareas de larga duración, los requisitos del sistema de archivos y las conexiones a bases de datos.
El protocolo ya no impone una arquitectura de sesión, y eso elimina un obstáculo importante.
El balanceo de carga round-robin se convierte en una opción natural por defecto
Un servidor con escalado horizontal ya no necesita vincular a un cliente individual a una sola instancia a nivel de protocolo.
Esto significa que un balanceador de carga round-robin simple puede distribuir solicitudes entre varias instancias.
Esto mejora:
- El autoescalado.
- La sustitución de instancias.
- La recuperación ante fallos.
- Los despliegues progresivos.
- El enrutamiento multirregión.
- La simplicidad de la infraestructura.
También cambia la forma de pensar de los autores de servidores respecto al estado oculto en memoria.
Si una herramienta funciona correctamente solo porque una solicitud anterior llenó un diccionario dentro de un proceso, esa implementación puede fallar cuando la siguiente solicitud llegue a otra instancia.
Una buena prueba de migración es:
Si cada llamada a una herramienta cayera en un proceso de servidor distinto, ¿el mismo flujo de trabajo podría continuar?
Si la respuesta es no, el servidor contiene una dependencia de estado de la aplicación que debe volverse explícita o migrarse a un almacenamiento compartido persistente.
Las solicitudes de múltiples rondas reemplazan las conexiones persistentes durante la llamada
El diseño sin estado todavía necesita una forma de que el servidor solicite más información al cliente.
Ejemplos incluyen confirmación del usuario, parámetros adicionales, preguntas guiadas, respuestas generadas por el modelo o valores relacionados con el espacio de trabajo.
El nuevo mecanismo son las solicitudes de múltiples rondas (Multi Round-Trip Requests, MRTR).
Una herramienta puede devolver un resultado incompleto:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "¿Eliminar 3 archivos?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}
El cliente recopila las respuestas necesarias.
Luego repite la llamada original utilizando inputResponses y el requestState devuelto.
Como el estado se transporta en el flujo de la solicitud, otra instancia del servidor puede gestionar la siguiente ronda.
Esto es mucho más compatible con una arquitectura sin estado que exigir una conexión persistente de servidor a cliente.
El enrutamiento basado en cabeceras hace que MCP sea más amigable para puertas de enlace
El nuevo formato HTTP Streamable añade metadatos de operación directamente a las cabeceras HTTP.
Las cabeceras importantes incluyen:
Mcp-Method: tools/call
Mcp-Name: search
Esto es importante para la infraestructura de producción.
Las puertas de enlace de API, los firewalls de aplicaciones web, los limitadores de velocidad o las capas de observabilidad pueden identificar la operación sin analizar el cuerpo JSON.
Los usos posibles incluyen:
- Enrutar todas las herramientas de búsqueda al mismo grupo.
- Aplicar límites más estrictos a operaciones destructivas.
- Registrar la latencia por nombre de herramienta.
- Medir el uso por método.
- Bloquear herramientas no permitidas en la puerta de enlace.
- Crear políticas de fiabilidad independientes.
La especificación también exige coherencia entre las cabeceras y el cuerpo JSON-RPC.
El servidor debe rechazar solicitudes en las que ambos no coincidan.
Las operaciones de listado y lectura admiten caché
Los clientes MCP solicitan a menudo metadatos relativamente estables, como listas de herramientas, recursos, listas de indicaciones y lecturas de recursos.
Obtener repetidamente la misma información desperdicia tráfico de red y capacidad del servidor.
La nueva revisión introduce metadatos de caché, como:
ttlMs
cacheScope
Estos valores permiten al servidor indicar durante cuánto tiempo debe considerarse fresco el resultado y si este puede compartirse entre usuarios o contextos.
Esto es similar a los principios del almacenamiento en caché HTTP normal.
Para agentes con muchas herramientas, esto puede reducir la carga repetida de metadatos.
El rastreo distribuido está estandarizado
La revisión también documenta la propagación del contexto de rastreo W3C.
Claves como:
traceparenttracestatebaggage
pueden propagarse a través de los metadatos de MCP.
Esto permite que un único rastreo distribuido siga el trabajo a través de la cadena:
Aplicación host
→ Cliente MCP
→ Puerta de enlace MCP
→ Servidor MCP
→ API descendente
→ Base de datos
Esto es importante para despliegues empresariales, porque cuando los equipos pueden ver dónde ocurre realmente la latencia, las llamadas lentas a herramientas son mucho más fáciles de depurar.
Las extensiones se convierten en una característica de protocolo de primera clase
El protocolo también está cambiando la forma en que evolucionan las funciones opcionales.
El marco actual otorga a las extensiones:
- Identificadores DNS inversos.
- Negociación de capacidades.
- Control de versiones independiente.
- Repositorios de código dedicados.
- Mantenedores delegados.
- Una vía formal de extensión en el proceso SEP.
Esto es importante porque el protocolo central no necesita absorber todas las ideas nuevas.
Una función puede primero madurar como extensión, y las capacidades validadas pueden luego acercarse al núcleo.
MCP Apps: UI interactivas dentro de la conversación
Una de las extensiones de MCP más visibles son las MCP Apps.
Las herramientas MCP tradicionalmente devuelven texto, JSON estructurado o recursos.
Algunas tareas requieren una interfaz.
Ejemplos incluyen paneles, gráficos, mapas, formularios, tableros de tareas, paneles de configuración, lienzos de diseño y reproductores de video.
MCP Apps permite que el servidor declare un recurso de UI que se renderiza en un iframe aislado.
![La imagen muestra el flujo interactivo de MCP Apps. El usuario envía al agente la instrucción "show me analytics" y el agente renderiza una aplicación interactiva en el chat. La aplicación interactúa con el servidor MCP a través de llamadas a herramientas, el servidor devuelve entradas/resultados de herramientas y el resultado se envía a la aplicación.]
El usuario interactúa con la aplicación, la aplicación solicita una llamada de herramienta, el servidor devuelve datos actualizados y la aplicación se actualiza con los nuevos datos. Este diagrama está estrechamente relacionado con el contexto y muestra visualmente el proceso completo de interacción de MCP Apps, desde la instrucción del usuario hasta la actualización de la aplicación.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)
El flujo simplificado es el siguiente:
- La herramienta declara un recurso de UI.
- El modelo invoca dicha herramienta.
- El host carga la UI en el sandbox.
- Los datos de la herramienta se transfieren a la interfaz.
- El usuario interactúa con la aplicación.
- La aplicación puede solicitar llamadas de herramienta adicionales a través del host.
- El host mantiene control de permisos y auditoría sobre estas operaciones.
MCP Apps ya es compatible con varios hosts, incluidos Claude y otros productos de desarrollo que admiten MCP.
Instalación básica de MCP Apps
El paquete oficial de extensión se puede instalar con el siguiente comando:
npm install -S @modelcontextprotocol/ext-apps
El repositorio oficial de código de ejemplo se puede ejecutar localmente:
git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start
Estos comandos provienen de la documentación oficial de MCP Apps y pueden variar a medida que la extensión evoluciona.
Tasks: Trabajos de larga duración que no bloquean la conexión
Cada vez más, las herramientas de agentes inician trabajos que no pueden completarse durante una única solicitud HTTP ordinaria.
Algunos ejemplos incluyen pipelines de CI, tareas de procesamiento de datos a gran escala, despliegues en la nube, tareas de investigación prolongadas, renderizado de video y flujos de aprobación humana.
La extensión MCP Tasks permite que el servidor devuelva un identificador de tarea persistente, en lugar de bloquearse esperando a que la operación se complete.
Los métodos definidos por la extensión oficial incluyen:
tasks/get
tasks/update
tasks/cancel
Las tareas pueden transicionar entre los siguientes estados:
working
input_required
completed
cancelled
failed
El cliente puede realizar polling a tasks/get.
Si el servidor necesita entrada del usuario, la tarea puede pasar al estado input_required.
El cliente puede enviar la entrada mediante tasks/update.
Este diseño funciona incluso en escenarios de desconexión y no requiere una conexión de larga duración.
Nota importante de compatibilidad
La funcionalidad de tareas existió como característica experimental en la especificación principal del 2025-11-25.
La nueva extensión Tasks no es una simple copia renombrada de la API anterior.
La documentación oficial del SDK advierte que la extensión Tasks más reciente no es compatible a nivel de protocolo de red con las implementaciones experimentales anteriores.
Las aplicaciones que usen la funcionalidad antigua de Tasks deben migrar y no asumir compatibilidad automática.
Autorización de gestión empresarial
Los problemas de autorización en despliegues empresariales son diferentes a los de las integraciones de consumo.
Una empresa puede tener miles de empleados y decenas de servidores MCP aprobados.
No quiere que cada empleado autorice cada conector de forma independiente.
La extensión de Autorización de gestión empresarial permite que las organizaciones centralicen el control de acceso a través de un proveedor de identidad.
Los modos de IdP empresarial compatibles pueden incluir productos como Microsoft Entra ID, Okta y sistemas de SSO empresarial.
Las organizaciones pueden decidir qué empleados tienen acceso a qué servidores MCP y cuándo se debe revocar el acceso.
Los empleados se autentican con su identidad empresarial, sin necesidad de completar aprobaciones OAuth por separado para cada servidor MCP.
La documentación oficial de MCP describe la autorización de gestión empresarial como una extensión, no como una funcionalidad habilitada por defecto en todos los clientes.
Tanto el cliente como la infraestructura de identidad de la organización deben ser compatibles con esta extensión.
El mecanismo de autorización se está reforzando más ampliamente
El trabajo central de autorización también ha recibido varias mejoras de seguridad.
Verificación del emisor RFC 9207
Crea un sitio de presentacion y capta leads en minutos
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
Las respuestas de autorización pueden incluir el parámetro de emisor iss.
El cliente verifica el emisor antes de canjear el código de autorización.
Esto ayuda a prevenir ataques de confusión de servidores de autorización.
Las credenciales de cliente permanecen vinculadas a su emisor
Las credenciales de cliente registradas no deben reutilizarse entre servidores de autorización no relacionados.
Cuando los recursos se transfieren a otros emisores, el cliente debe registrarse adecuadamente ante ese emisor.
Registro mejorado para escritorio y CLI
Esta revisión aclara el comportamiento de application_type durante el registro dinámico de clientes.
Esto ayuda a evitar que los servidores de autorización traten aplicaciones CLI nativas o de escritorio como clientes web y rechacen URIs de redirección locales.
CIMD es la nueva guía de registro de clientes
El proyecto de autorización de MCP ha estado avanzando hacia los Documentos de Metadatos de ID de Cliente (Client ID Metadata Documents, CIMD) para nuevas implementaciones, manteniendo la compatibilidad con DCR donde sea necesario.
La recomendación práctica es seguir la documentación de autorización actual, en lugar de implementar el registro de clientes basado en tutoriales más antiguos de MCP.
Esquema JSON Schema 2020-12 completo para herramientas
Los esquemas de herramientas también se han vuelto más expresivos.
inputSchema y outputSchema admiten todas las características de JSON Schema 2020-12.
Los esquemas de entrada pueden utilizar:
oneOf
anyOf
allOf
$ref
$defs
declaraciones condicionales
Los esquemas de salida ya no se limitan a una única forma estrecha de objeto.
structuredContent puede representar cualquier valor JSON que admita el esquema.
Esto permite que las herramientas MCP describan con mayor precisión cuando la API tiene tipos unión, campos condicionales, definiciones reutilizables anidadas, múltiples formas de salida, resultados en arrays o escalares.
Roots, Sampling y Logging quedan obsoletos
Tres capacidades centrales más antiguas han sido oficialmente obsoletas:
| Función | Dirección recomendada |
|---|---|
| Roots | Parámetros de herramienta, URI de recurso o configuración del servidor |
| Sampling | Integración directa con proveedores de LLM |
| Logging | Uso de stderr para stdio; OpenTelemetry para observabilidad estructurada |
La obsolescencia no implica una eliminación inmediata.
La nueva política de ciclo de vida establece que las funciones obsoletas deben tener un período de transición de al menos doce meses antes de permitir su eliminación.
Los SDK actuales pueden continuar admitiendo estas capacidades para mantener la compatibilidad.
La política de obsolescencia formal cambia el riesgo de actualización de MCP
El rediseño sin estado incluye cambios disruptivos.
Los mantenedores indican que no desean que este nivel de interrupción se convierta en la norma.
El nuevo ciclo de vida de funciones define las siguientes etapas:
Activa (Active)
Obsoleta (Deprecated)
Eliminada (Removed)
Las funciones obsoletas reciben un período mínimo de soporte antes de su eliminación.
Las extensiones también pueden evolucionar de forma independiente al núcleo.
Esto proporciona a los equipos una planificación de migración más predecible.
Los túneles MCP resuelven un problema empresarial diferente
La revisión del protocolo hace que los servidores MCP públicos remotos sean más fáciles de escalar.
Las empresas a menudo enfrentan el problema opuesto: simplemente no quieren exponer sus servidores públicamente.
La función de túneles MCP de Anthropic aborda este caso de uso para agentes alojados en Claude y flujos de trabajo compatibles con la plataforma Claude.
Un gateway ligero se ejecuta dentro de la red empresarial y establece conexiones salientes.
Anthropic describe este patrón como:
- Sin endpoints MCP públicos.
- Sin reglas de firewall de entrada.
- Sin necesidad de IP pública.
- Tráfico cifrado de extremo a extremo.
Las bases de datos internas, sistemas ERP, API privadas, bases de conocimiento y sistemas de tickets pueden permanecer dentro del perímetro de la red empresarial.
Los túneles MCP siguen siendo una función de producto de Claude, no un requisito del protocolo MCP central.
Anthropic actualmente lo describe como una vista previa de investigación.
Las aplicaciones MCP y los túneles no deben confundirse
Ambas funciones mejoran MCP en entornos de producción, pero resuelven problemas diferentes.
| Función | Problema que resuelve |
|---|---|
| Aplicaciones MCP | Interfaces interactivas enriquecidas dentro de hosts MCP |
| Tareas | Operaciones de herramientas persistentes de larga duración |
| Autorización empresarial administrada | Políticas de acceso corporativas centralizadas |
| Túneles MCP | Acceso a servidores MCP privados sin exposición pública |
| Núcleo MCP sin estado | Transporte de protocolo escalable |
| MRTR | Entrada del cliente durante una llamada sin sesiones de protocolo prolongadas |
Los servidores pueden usar una, varias o todas estas funciones.
¿Qué necesitan cambiar los desarrolladores de servidores MCP existentes?
Si el servidor ya funciona con clientes MCP más antiguos, los desarrolladores no tienen que reescribir todo de inmediato.
Deben realizar una migración estructurada.
Paso 1: Inventariar las dependencias ocultas de sesión
Busque código que dependa de:
Mcp-Session-Id- Diccionarios por sesión en memoria
- Enrutamiento persistente (sticky routing)
- Estado de cliente local a la conexión
- Almacenamiento de capacidades solo de inicialización
- Afinidad de instancia de servidor
Determine si cada dependencia es estado de protocolo, estado de aplicación, estado de autenticación o estado de ejecución temporal.
Mueva el estado de la aplicación a identificadores explícitos o almacenamiento persistente adecuado.
Paso 2: Probar el manejo de solicitudes sin estado
Utilice versiones de SDK que admitan la revisión 2026-07-28.
Luego pruebe con múltiples instancias de servidor.
Una configuración de prueba útil es:
Cliente
↓
Balanceador de carga round-robin
↓
Servidor A / Servidor B / Servidor C
Envíe un flujo de trabajo de múltiples pasos y confirme que las solicitudes consecutivas puedan llegar a diferentes instancias sin interrumpir la tarea.
Paso 3: Agregar identificadores de estado explícitos
Para flujos de trabajo que requieren estado, devuelva un identificador estable:
{
"job_id": "job_7f18c9"
}
Exija que las llamadas posteriores incluyan ese identificador:
{
"job_id": "job_7f18c9",
"action": "continue"
}
Valide cada identificador en el lado del servidor.
Un buen identificador debe tener alta entropía, vinculación al inquilino, verificación de autorización, tiempo de expiración, mecanismo de revocación y manejo claro de errores.
Paso 4: Actualizar las reglas del gateway
Si utiliza Streamable HTTP, aproveche los siguientes encabezados:
Mcp-Method
Mcp-Name
Agregue enrutamiento, límites de tasa, métricas, políticas WAF y registros de acceso.
Paso 5: Agregar soporte de caché
Para respuestas de listado y lectura apropiadas, siga o genere:
ttlMs
cacheScope
No comparta contenido de caché sensible específico de un usuario entre diferentes usuarios.
Paso 6: Migrar tareas antiguas
Si la aplicación utiliza la API experimental de Tareas 2025-11-25, actualícela al ciclo de vida de extensiones.
Pruebe:
tasks/get
tasks/update
tasks/cancel
Así como el estado input_required.
Paso 7: Revisar funciones obsoletas
Busque Roots, Sampling y MCP Logging.
Planifique la migración a parámetros de herramienta explícitos o URI de recursos, llamadas directas al proveedor de modelos, y stderr u OpenTelemetry.
Paso 8: Volver a probar la autorización
Verifique la validación del emisor, URI de redirección, registro de clientes, tokens de actualización, manejo de alcances y compatibilidad con el proveedor de identidad.
Las implementaciones empresariales deben evaluar si EMA es aplicable.
Paso 9: Probar clientes antiguos
La compatibilidad hacia atrás es un problema del ecosistema, no solo del servidor.
Mantenga una matriz de pruebas:
| Cliente | Revisión del protocolo | Resultado |
|---|---|---|
| Cliente actual | 2026-07-28 | Ruta sin estado esperada |
| Cliente antiguo | 2025-11-25 | Ruta de compatibilidad |
| Cliente no compatible | Versión antigua/desconocida | Falla de negociación clara |
No asuma silenciosamente que todos los clientes se actualizan al mismo tiempo.
Paso 10: Agregar observabilidad antes de producción
Como mínimo, mida:
- Número de solicitudes.
- Nombres de herramientas.
- Latencia.
- Tasa de errores.
- Duración de las tareas.
- Frecuencia de entradas requeridas.
- Tasa de aciertos de caché.
- Número de fallos de autenticación.
- Latencia de API descendente.
- ID de seguimiento.
Los sistemas sin estado son más fáciles de escalar, pero los sistemas distribuidos aún necesitan buena observabilidad.
Ejemplo: Comparación antes y después de la migración
Antes de la migración
El servidor almacena objetos de informe en memoria:
sessions[session_id]["report"] = report
La siguiente llamada de herramienta espera llegar al mismo proceso.
Después de la migración
El servidor almacena estado persistente:
report_id = save_report(report)
return {"report_id": report_id}
La siguiente herramienta recibe:
{
"report_id": "report_123"
}
Cualquier instancia de servidor puede cargar ese informe.
El cambio importante está a nivel de arquitectura:
Estado de sesión de transporte oculto
→ Estado de aplicación explícito
¿MCP sin estado significa menor costo?
Posiblemente, pero no automáticamente.
Las implementaciones sin estado pueden reducir la complejidad de la infraestructura:
- Sin almacenamiento compartido de sesiones MCP.
- Menos necesidad de enrutamiento persistente.
- Escalado automático más fácil.
- Implementación serverless más sencilla.
- Conmutación por error simplificada.
El caché también puede reducir llamadas de metadatos duplicadas.
Sin embargo, el estado de la aplicación sigue teniendo un costo.
Si los flujos de trabajo requieren estado persistente, los desarrolladores pueden necesitar Redis, bases de datos SQL, almacenamiento de objetos, colas de tareas o motores de flujo de trabajo.
El nuevo diseño permite a los desarrolladores elegir la arquitectura de almacenamiento, en lugar de que la sesión del protocolo imponga una específica.
¿Se está convirtiendo MCP en el "HTTP del ámbito de la IA"?
El artículo original utiliza esta analogía.
La analogía es útil, pero no debe interpretarse literalmente.
HTTP es el estándar de transporte web fundamental, utilizado en casi todos los sistemas de internet.
MCP es un protocolo especializado que conecta clientes y agentes de IA con herramientas, recursos, indicaciones, interfaces y servicios externos.
Lo que captura esta analogía es la dirección del desarrollo:
- Una interfaz estándar.
- Numerosos servidores independientes.
- Numerosos clientes compatibles.
- Convenciones compartidas.
- Infraestructura capaz de enrutar y observar solicitudes de manera universal.
El rediseño del 2026-07-28 refuerza esta analogía, ya que el tráfico de MCP ahora se adapta de manera más natural a la infraestructura HTTP tradicional sin estado.
Si MCP alcanzará un nivel de adopción similar al de HTTP sigue siendo una cuestión abierta.
El ecosistema es más amplio que Claude
MCP se originó en Anthropic, pero ahora se gobierna como un proyecto de protocolo de código abierto más amplio.
El ecosistema incluye mantenedores independientes, grupos de trabajo, propuestas de mejora de especificación, SDK en múltiples lenguajes, aplicaciones MCP, tareas, extensiones de autorización empresarial, registros e implementaciones en múltiples productos de IA.
Por ejemplo, las aplicaciones MCP se desarrollan en colaboración con contribuyentes de la comunidad MCP, así como con participantes de Anthropic, OpenAI y MCP-UI.
Esto es importante porque el valor de un protocolo aumenta cuando tanto clientes como servidores pueden implementarlo sin depender de un único proveedor.
Panorama actual de los SDK
El proyecto oficial de MCP mantiene o reconoce implementaciones de SDK en varios lenguajes.
Los repositorios principales incluyen SDK para TypeScript, Python, Go, C# y otros ecosistemas.
Junio de 2026
El anuncio de la versión candidata destacó especialmente el soporte beta de cuatro SDK de primer nivel:
- TypeScript.
- Python.
- Go.
- C#.
Para finales de julio, la documentación actual de los SDK ya incluye el comportamiento del 2026-07-28.
Dado que la adopción de los SDK se realiza de forma independiente, consulte siempre las notas de la versión del lenguaje y la versión exacta que esté utilizando.
Una estrategia de migración más segura
Para sistemas de producción, evite las migraciones tipo "día del cambio".
Un proceso más seguro es:
- Actualizar el entorno de desarrollo.
- Ejecutar pruebas de conformidad.
- Probar clientes
2026-07-28. - Probar clientes de versiones anteriores.
- Habilitar la implementación sin estado en el entorno de preproducción.
- Añadir varias instancias de servidor.
- Forzar la distribución de solicitudes entre instancias.
- Probar la autenticación.
- Probar tareas de larga duración.
- Probar los identificadores de estado de la aplicación.
- Supervisar la latencia y los errores.
- Desplegar gradualmente.
Esto es especialmente importante porque la nueva revisión modifica intencionalmente el comportamiento central del ciclo de vida.
Lo que no se debe asumir
No asuma que cada servidor se vuelve automáticamente serverless
El protocolo admite de manera más natural implementaciones serverless.
Su aplicación puede seguir necesitando bases de datos, ejecutores de tareas persistentes, almacenamiento de archivos o tiempos de ejecución más largos.
No asuma que todo el estado desaparece
Solo el estado de sesión a nivel de protocolo se elimina del nuevo modelo en línea.
El estado de la aplicación sigue siendo responsabilidad de la propia aplicación.
No asuma que las aplicaciones MCP se ejecutan en todos los clientes
Las extensiones se negocian y el soporte varía según el host.
No asuma que las tareas son retrocompatibles
La extensión actual de Tasks es diferente de las implementaciones experimentales anteriores.
No asuma que la obsolescencia implica inoperancia
Roots, Sampling y Logging seguirán disponibles durante el período de deprecación.
No asuma que todos los clientes ya admiten 2026-07-28
La adopción de SDK y productos avanza a ritmos diferentes.
No asuma que "protocolo abierto" significa "sin necesidad de trabajo de seguridad"
MCP puede ejecutar herramientas potentes.
La autorización, el consentimiento del usuario, el aislamiento en sandbox, el diseño de herramientas, la gestión de secretos y la auditoría siguen siendo fundamentales.
Preguntas frecuentes
¿Qué es MCP 2026-07-28?
MCP 2026-07-28 es la mayor revisión arquitectónica del Model Context Protocol desde su lanzamiento. Sus principales cambios incluyen un núcleo de protocolo sin estado, la eliminación del handshake de sesión en el nuevo formato en línea, extensiones de primer nivel, aplicaciones MCP, Tasks rediseñado, MRTR, autorización más sólida, metadatos de caché y una política formal de deprecación.
¿MCP ahora es completamente sin estado?
La capa de protocolo 2026-07-28 está diseñada para ser sin estado. Las aplicaciones aún pueden mantener estado mediante identificadores explícitos, bases de datos, sistemas de flujo de trabajo u otro almacenamiento persistente.
¿Qué ocurrió con Mcp-Session-Id?
El formato en línea de 2026-07-28 elimina el mecanismo Mcp-Session-Id a nivel de protocolo. Los SDK actuales pueden seguir admitiendo el comportamiento basado en sesiones al negociar revisiones anteriores del protocolo para garantizar la retrocompatibilidad.
¿Puedo implementar servidores MCP en AWS Lambda o Cloudflare Workers?
El protocolo sin estado facilita las implementaciones serverless y en el borde, ya que las solicitudes ya no requieren afinidad de sesión a nivel de protocolo. Su servidor aún debe cumplir con las limitaciones de ejecución, red, almacenamiento y duración del entorno de ejecución.
¿Qué es una aplicación MCP?
Una aplicación MCP es una extensión oficial
que permite a las herramientas devolver interfaces interactivas, como paneles, formularios, gráficos y otras experiencias HTML, dentro de hosts MCP compatibles. La interfaz se ejecuta en un iframe aislado y se comunica a través del host MCP.
¿Qué son las tareas MCP?
La funcionalidad de tareas permite a los servidores devolver identificadores de tareas asíncronas persistentes para trabajos de larga duración. Los clientes pueden consultar el estado con tasks/get, proporcionar la entrada necesaria con tasks/update o cancelar la operación con tasks/cancel.
¿Qué es la autorización empresarial gestionada?
La autorización empresarial gestionada es una extensión de MCP que permite el control de acceso centralizado a través del proveedor de identidad de la organización. Permite a los administradores de TI gestionar el acceso a los servidores MCP según las políticas de identidad de la empresa, sin que cada usuario tenga que autorizar cada servidor individualmente.
¿Debo migrar inmediatamente desde la versión anterior de MCP?
No necesariamente. Los SDK admiten revisiones anteriores del protocolo mediante negociación de versiones, y las funciones obsoletas reciben una ventana de soporte explícita. Los equipos de producción deberían comenzar a realizar pruebas, ya que el diseño sin estado cambia los supuestos en torno a las sesiones, las operaciones de larga duración y la infraestructura.
Herramientas relacionadas
- Model Context Protocol: Documentación oficial de la especificación MCP, arquitectura, SDK, extensiones y guía para desarrolladores.
- MCP TypeScript SDK: Implementación oficial de TypeScript para clientes y servidores MCP.
- MCP Python SDK: SDK oficial de Python para el desarrollo de MCP y ejemplos.
- MCP Go SDK: Implementación oficial de Go, que actualmente admite la ruta del protocolo sin estado.
- MCP C# SDK: SDK oficial de .NET, con documentación detallada sobre modos sin estado, tareas y compatibilidad.
- MCP Apps: Documentación oficial y SDK para interfaces interactivas dentro de hosts MCP.
- MCP Tasks: Documentación oficial para operaciones asíncronas de larga duración en MCP.
- [MCP Registry](https://registry.modelcontextprotocol.
io/): infraestructura oficial de registro para descubrir servidores MCP ya publicados.
Enlaces relacionados
- Resumen de la versión candidata de MCP del 28 de julio de 2026: explicación oficial de los mantenedores sobre la refactorización sin estado, extensiones, cambios de autenticación, caché y elementos obsoletos.
- Lanzamientos del repositorio de especificaciones de MCP: historial oficial de lanzamientos en GitHub de las revisiones del protocolo.
- Hoja de ruta de MCP 2026: hoja de ruta oficial que cubre escalabilidad de transporte, comunicación entre agentes, gobernanza y preparación empresarial.
- Documentación oficial de MCP Apps: especificaciones, SDK, ejemplos y guías para desarrolladores de aplicaciones MCP interactivas.
- Extensión de tareas de MCP: especificación oficial de tareas, ciclo de vida, modelo de seguridad y métodos compatibles.
- Autorización gestionada empresarial: documentación oficial sobre el acceso a MCP basado en proveedores de identidad centralizados.
- Túnel MCP de Anthropic: documentación de Anthropic sobre conexiones MCP de redes privadas en agentes gestionados por Claude.
Resumen
La revisión de MCP del 28 de julio de 2026 lleva el protocolo hacia patrones de infraestructura ya ampliamente adoptados en grandes sistemas web. Las solicitudes se vuelven autocontenidas, las sesiones a nivel de protocolo desaparecen del nuevo formato en línea, el enrutamiento entre pasarelas se simplifica y el escalado horizontal ordinario ya no requiere sesiones MCP con afinidad.
Mientras tanto, el ecosistema también avanza. Las aplicaciones MCP incorporan interfaces interactivas, las tareas admiten trabajo asíncrono persistente, la autorización gestionada empresarial centraliza los accesos corporativos y los túneles MCP ofrecen a los usuarios de la plataforma Claude una vía de acceso a servidores privados internos.
La migración no consiste simplemente en "eliminar el ID de sesión". Los equipos deben identificar dependencias de estado ocultas, migrar el estado de la aplicación a identificadores explícitos o almacenamiento persistente, probar MRTR y tareas, actualizar la autorización, mantener la compatibilidad con clientes antiguos y añadir una observabilidad adecuada.
El cambio más importante es a nivel de arquitectura: MCP está pasando de un modelo de integración de agentes orientado a la conexión a un protocolo sin estado y escalable que se adapta de forma más natural a la infraestructura moderna en la nube.
