El Protocolo de Contexto del Modelo ha experimentado su revisión arquitectónica más grande desde su lanzamiento. MCP se introdujo inicialmen...
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 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:
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:
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:
Los mantenedores de MCP concluyeron que estos requisitos estaban demasiado acoplados al protocolo en sí.
La nueva revisión elimina esta suposición.
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.
initialize se elimina del nuevo formato en líneaEl 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.
Los identificadores visibles tienen varias ventajas.
El modelo puede:
El servidor puede:
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.
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:
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.
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:
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.
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 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:
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.
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.
La revisión también documenta la propagación del contexto de rastreo W3C.
Claves como:
traceparenttracestatebaggagepueden 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.
El protocolo también está cambiando la forma en que evolucionan las funciones opcionales.
El marco actual otorga a las extensiones:
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.
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:
MCP Apps ya es compatible con varios hosts, incluidos Claude y otros productos de desarrollo que admiten MCP.
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.
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.
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.
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 trabajo central de autorización también ha recibido varias mejoras de seguridad.
Las respuestas de autorización pueden incluir el parámetro de emisor iss.
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.
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 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
Busque código que dependa de:
Mcp-Session-IdDetermine 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.
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.
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.
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.
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.
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.
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.
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.
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.
Como mínimo, mida:
Los sistemas sin estado son más fáciles de escalar, pero los sistemas distribuidos aún necesitan buena observabilidad.
El servidor almacena objetos de informe en memoria:
sessions[session_id]["report"] = report
La siguiente llamada de herramienta espera llegar al mismo proceso.
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
Posiblemente, pero no automáticamente.
Las implementaciones sin estado pueden reducir la complejidad de la infraestructura:
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.
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:
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.
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.
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:
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.
Para sistemas de producción, evite las migraciones tipo "día del cambio".
Un proceso más seguro es:
2026-07-28.Esto es especialmente importante porque la nueva revisión modifica intencionalmente el comportamiento central del ciclo de vida.
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.
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.
Las extensiones se negocian y el soporte varía según el host.
La extensión actual de Tasks es diferente de las implementaciones experimentales anteriores.
Roots, Sampling y Logging seguirán disponibles durante el período de deprecación.
2026-07-28La adopción de SDK y productos avanza a ritmos diferentes.
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.
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.
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.
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.
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.
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.
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.
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.
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.
io/): infraestructura oficial de registro para descubrir servidores MCP ya publicados.
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.
Empieza con una sola frase y obtén un sitio completo en minutos.
