Amazon AWS respalda MCP sin estado, pero la compatibilidad es ahora la verdadera prueba

Amazon AWS añadió compatibilidad con MCP 2026-07-28 a AgentCore Gateway dos días después de que la mayor revisión arquitectónica de la especificación llegara a su versión estable. Una llamada a UpdateGateway puede habilitar la nueva versión del protocolo en un gateway existente. Sin embargo, este sencillo cambio en el plano de control oculta una transición más compleja para clientes, servidores y equipos de seguridad empresarial.

La nueva revisión de Model Context Protocol elimina las sesiones a nivel de protocolo y hace que cada solicitud describa su propia versión y capacidades del cliente. MCP es un estándar abierto para conectar aplicaciones de IA con herramientas, fuentes de datos y otros servicios. Su diseño sin estado debería facilitar la escalabilidad, el enrutamiento y la recuperación de los gateways.

Ese beneficio viene acompañado de una prueba de compatibilidad. Los clientes deben adoptar nuevos metadatos de solicitud, los servidores deben implementar descubrimiento y las antiguas suposiciones sobre sesiones dejan de aplicarse. Amazon Bedrock AgentCore Gateway se sitúa ahora entre esas dos eras del protocolo, traduciendo servicios empresariales en herramientas MCP mientras aplica controles de acceso en un único endpoint gestionado.

Por tanto, la verdadera historia es más amplia que una casilla de versión. Amazon AWS apuesta a que un gateway gestionado puede absorber los cambios del protocolo antes de que alcancen a cada equipo de aplicaciones. Que funcione o no depende de la negociación de versiones, la corrección de la autorización y el comportamiento de flotas de clientes mixtas.

Amazon AWS convierte una gran reescritura de MCP en una única actualización de gateway

AWS ha reducido el paso de infraestructura a una operación de API, pero las aplicaciones aún deben comunicarse correctamente con el protocolo revisado.

Los mantenedores de MCP lanzaron la especificación estable 2026-07-28 el 28 de julio, tras un periodo de versión candidata que comenzó en mayo. La versión estable de MCP reemplaza varias suposiciones establecidas durante el crecimiento inicial del protocolo.

AWS incorporó después soporte en Amazon Bedrock AgentCore Gateway. Según la actualización de AgentCore de la compañía, los propietarios de gateways pueden añadir la nueva revisión mediante UpdateGateway. La solicitud actualiza la configuración del protocolo MCP del gateway y su lista de versiones compatibles.

El objeto relevante del plano de control es protocolConfiguration.mcp.supportedVersions. AWS documenta ese campo como una matriz de versiones de MCP que el gateway puede utilizar. UpdateGateway devuelve el estado HTTP 202 cuando el servicio acepta una actualización, tras lo cual el gateway pasa por un estado de actualización.

Esta distinción importa desde el punto de vista operativo. Que se acepte una llamada no significa que todos los clientes conectados hayan completado una solicitud correctamente. Los equipos deben esperar a que el gateway vuelva a su estado listo y, después, ejecutar pruebas de conformidad y de carga de trabajo contra el endpoint real.

El cambio no exige que las organizaciones reconstruyan cada función Lambda, servicio OpenAPI o servicio Smithy detrás de su gateway. AgentCore Gateway ya convierte esos recursos en herramientas compatibles con MCP. También admite destinos MCP remotos y otros servicios HTTP, según la configuración del destino.

Esta arquitectura permite a AWS cambiar la capa orientada al protocolo sin requerir cambios idénticos en cada servicio empresarial descendente. Una API de atención al cliente puede seguir siendo una API, por ejemplo, mientras el gateway expone sus operaciones como herramientas para agentes compatibles.

AgentCore Gateway también gestiona la autenticación entrante, las credenciales salientes, el descubrimiento de herramientas, el enrutamiento y la aplicación de políticas. Estos controles adquieren mayor valor cuando un endpoint da acceso a servicios propiedad de varios equipos internos.

Sin embargo, la llamada a UpdateGateway solo modifica la compatibilidad declarada del gateway. Un cliente que use la revisión de 2026 debe seguir enviando los metadatos y encabezados requeridos. Un cliente más antiguo debe negociar una revisión mutuamente compatible o utilizar una ruta alternativa compatible.

Esa es la primera limitación detrás del sencillo mensaje de actualización de AWS. El servicio gestionado puede reducir el trabajo de plataforma, pero no puede hacer que un SDK desactualizado emita un nuevo formato en la red.

La segunda limitación implica pruebas. Los propietarios de gateways deben verificar el listado de herramientas, las llamadas a herramientas, los fallos de autenticación, el comportamiento de streaming y los controles de caché en cada versión compatible. El éxito con un cliente moderno no establece la compatibilidad en toda una flota empresarial.

Por tanto, un despliegue práctico comienza con un inventario. Los equipos deben identificar qué aplicaciones de agentes se conectan al gateway, qué versiones de SDK utilizan y si esos SDK admiten MCP 2026-07-28.

Las organizaciones que mantienen decisiones técnicas y evidencias de pruebas en una base de conocimiento de ingeniería consultable pueden registrar resultados por cliente y versión de protocolo. Ese registro se vuelve importante cuando un fallo aparece solo en un framework o canal de despliegue.

AWS ha reducido la acción del plano de control. La verificación a nivel de aplicación sigue siendo el verdadero proyecto de migración.

Por qué MCP sin estado cambia la ecuación del gateway

MCP sin estado traslada la información de compatibilidad a cada solicitud, simplificando el enrutamiento horizontal mientras obliga a que cada mensaje sea autónomo.

Las revisiones anteriores de MCP utilizaban un intercambio de inicialización para establecer los detalles y capacidades del protocolo. Un cliente enviaba initialize, el servidor respondía y el cliente completaba la secuencia con notifications/initialized. Streamable HTTP también podía usar un encabezado Mcp-Session-Id para asociar el tráfico posterior con una sesión a nivel de protocolo.

Los cambios clave de MCP eliminan ese ciclo de vida en la nueva revisión. También eliminan el identificador de sesión a nivel de protocolo. Los servidores que necesiten mantener estado entre llamadas deben emitir identificadores explícitos que los clientes pasen como argumentos normales de herramientas.

Cada solicitud de nuevo estilo lleva su versión de protocolo y las capacidades del cliente dentro de _meta. Los clientes también deben identificarse allí. Los servidores devuelven su identidad dentro de los metadatos del resultado, haciendo que cada intercambio sea más descriptivo por sí mismo.

Un nuevo método server/discover permite a un cliente inspeccionar las versiones compatibles, capacidades e identidad del servidor antes de comenzar otro trabajo. Un servidor que use la revisión 2026-07-28 debe implementar esta llamada a procedimiento remoto.

Este diseño cambia lo que un gateway necesita recordar. Ya no tiene que depender de un intercambio de inicialización completado mediante una conexión ni asociar el tráfico posterior del protocolo con una sesión MCP opaca.

Un balanceador de carga puede enrutar solicitudes separadas sin preservar afinidad a nivel de protocolo. Una instancia de gateway que recibe la décima llamada puede inspeccionar la misma información esencial de compatibilidad que recibió la primera instancia.

Este modelo es adecuado para un gateway gestionado en la nube. Los servicios sin estado pueden escalar entre trabajadores, sustituir capacidad no saludable y distribuir el tráfico sin restaurar un registro de sesión MCP antes de interpretar cada solicitud.

También reduce una incómoda discrepancia entre la infraestructura efímera de la nube y el comportamiento de protocolo orientado a conexiones. Las funciones sin servidor y los gateways distribuidos generalmente funcionan mejor cuando las solicitudes contienen la información necesaria para un procesamiento independiente.

Sin embargo, sin estado no significa que el trabajo del agente carezca de estado. Un flujo de compras podría seguir requiriendo información de aprobación, una referencia de transacción o datos recopilados durante un intercambio anterior. La especificación traslada ese estado a identificadores explícitos a nivel de aplicación en lugar de ocultarlo dentro de la sesión de transporte.

Este cambio puede mejorar la visibilidad. Los argumentos de herramientas y los identificadores emitidos por el servidor crean límites de propiedad más claros que el estado inferido a partir de una conexión. También exigen un diseño cuidadoso porque los clientes pueden reintentar solicitudes o presentar identificadores antiguos.

La nueva revisión elimina la reanudabilidad de Streamable HTTP mediante Last-Event-ID e identificadores de eventos enviados por el servidor. Si un flujo de respuesta se interrumpe durante una solicitud, el cliente debe enviar una nueva solicitud con un nuevo ID de solicitud.

Esta regla plantea una importante cuestión operativa. Si una herramienta realiza un efecto secundario antes de que falle el flujo, un reintento a ciegas podría repetir la acción, salvo que la aplicación implemente idempotencia.

Considere un agente que crea un ticket de soporte. El servicio de tickets podría almacenar correctamente el registro mientras el flujo de respuesta desaparece. Un reintento debería incluir una clave de idempotencia a nivel de aplicación o consultar la operación anterior antes de crear otro ticket.

AWS no puede resolver todos los problemas de idempotencia descendentes en el límite del protocolo. Los registros y trazas del gateway pueden mostrar las llamadas repetidas, pero el servicio de destino debe definir un comportamiento seguro de reintento.

La revisión también reemplaza las llamadas separadas iniciadas por el servidor con solicitudes de múltiples viajes de ida y vuelta. Bajo este patrón, un servidor devuelve un resultado input_required que describe la información que aún necesita. El cliente reintenta la solicitud original con las respuestas solicitadas.

Este enfoque mantiene el control dentro de una secuencia de solicitud y reintento. Evita que una solicitud independiente de servidor a cliente llegue a través de una conexión que otra instancia del gateway podría no poseer.

Todos los resultados incluyen ahora un resultType, normalmente complete o input_required. Los clientes que se comuniquen con servidores antiguos deben tratar un valor omitido como un resultado completado, preservando un puente de compatibilidad limitado.

El mecanismo favorece claramente la infraestructura distribuida. La contrapartida es que los SDK y las aplicaciones deben adoptar metadatos, lógica de reintento y gestión de estado más explícitos.

La presión recae sobre los SDK y las flotas de clientes mixtas

AgentCore Gateway puede admitir dos eras de protocolo, pero cada organización debe demostrar que sus clientes negocian la correcta.

El objetivo inmediato de la presión no es una API oculta detrás del gateway. Es el software cliente que se conecta al endpoint MCP.

Un cliente que declara la revisión 2026-07-28 debe enviar la versión del protocolo y sus capacidades en cada solicitud. Debe comprender server/discover, los tipos de resultado requeridos y el manejo revisado de las interacciones de varios pasos.

Los clientes HTTP también deben utilizar los encabezados de solicitud MCP estándar, incluidos Mcp-Method y Mcp-Name. Estos encabezados permiten que la infraestructura inspeccione y enrute el tráfico sin analizar cada cuerpo JSON-RPC.

Este cambio es útil para gateways, sistemas de observabilidad y controles de seguridad. También crea otro punto de validación donde clientes incompletos pueden fallar antes de que se ejecute una herramienta.

MCP define errores específicos para este nuevo límite. Las discrepancias de encabezados usan el código -32020, las capacidades requeridas del cliente ausentes usan -32021 y las versiones de protocolo no compatibles usan -32022.

Estos códigos proporcionan a los equipos de plataforma una taxonomía de fallos más clara. Un aumento de respuestas -32022 indica problemas de negociación de versiones, mientras que -32020 apunta a un desacuerdo entre los encabezados HTTP y la solicitud incluida.

La transición de los SDK no ocurrirá simultáneamente en todos los lenguajes. Las implementaciones oficiales pueden adoptar una especificación estable en calendarios distintos, y las aplicaciones suelen fijar versiones de bibliotecas mucho después de que aparezca una nueva versión.

Las empresas también tienen clientes que no controlan por completo. Un empleado podría utilizar un asistente de escritorio aprobado, un agente interno de línea de comandos y una extensión de IDE creada por otro equipo. Cada uno puede negociar MCP de forma diferente.

La lista de versiones compatibles de AgentCore ofrece un puente para esta flota mixta. El gateway puede anunciar más de una revisión en lugar de obligar a todos los clientes a adoptar el nuevo formato en la red de inmediato.

Ese soporte debe tratarse como un mecanismo de migración, no como prueba de un comportamiento idéntico. Las funciones eliminadas del núcleo de 2026 aún existen en flujos de protocolo anteriores. Una prueba que supera la negociación de una revisión anterior dice poco sobre la ruta sin estado.

Roots, Sampling y Logging ahora están obsoletos, en lugar de eliminarse de inmediato de toda la especificación. Las nuevas implementaciones deben evitar adoptarlos, mientras que las existentes reciben un período de transición definido.

La nueva política de ciclo de vida de funciones de MCP establece un período mínimo de obsolescencia de 12 meses. Este cambio de gobernanza ofrece a los implementadores un aviso más predecible que el lenguaje informal de desuso.

El protocolo propone alternativas. Las aplicaciones pueden pasar directorios mediante parámetros de herramientas o identificadores de recursos en lugar de Roots. Los servidores pueden llamar directamente a las API de los proveedores de modelos en lugar de depender de Sampling. Las implementaciones pueden usar OpenTelemetry o flujos de error estándar en lugar de Logging del protocolo.

Estas sustituciones cambian la arquitectura, no solo la sintaxis. Un servidor que antes solicitaba muestreo de modelos a través de su cliente MCP puede necesitar una integración directa con el proveedor, credenciales separadas y una nueva política de control de costes.

Por tanto, la presión se extiende a los equipos de seguridad y finanzas. Trasladar el acceso al modelo desde una capacidad del cliente al servidor cambia dónde residen las credenciales y dónde aparece el uso.

Los responsables de gateways deben clasificar a los clientes en tres grupos. El primero es plenamente compatible con la revisión de 2026. El segundo funciona únicamente con una versión estable anterior. El tercero presenta un comportamiento incierto y necesita aislamiento hasta completar las pruebas.

Las pruebas deben abarcar más que tools/list. Una matriz útil incluye descubrimiento, llamadas a herramientas autenticadas, ámbitos rechazados, transmisión de respuestas, solicitudes interrumpidas, almacenamiento en caché de listas y aplicaciones que requieren información adicional del usuario.

Los equipos también deben verificar la versión negociada en la telemetría. Sin esa señal, una solicitud exitosa podría ocultar una degradación inesperada al protocolo anterior.

La migración tiene éxito cuando la nueva ruta soporta cargas de trabajo representativas de producción. No tiene éxito simplemente porque el gateway acepte un campo supportedVersions actualizado.

La autorización se vuelve más estricta a medida que las extensiones salen del núcleo

MCP 2026-07-28 reduce la ambigüedad de las credenciales al tiempo que traslada las capacidades opcionales a un sistema de extensiones gobernado y negociado.

Las reglas de autorización revisadas se centran en límites de identidad que se vuelven riesgosos cuando los agentes se conectan a muchos servidores. Un cliente MCP puede obtener credenciales de varios servidores de autorización, cada uno protegiendo distintas herramientas y datos.

La especificación ahora indica que los clientes deben vincular las credenciales almacenadas al emisor que las creó. Un cliente no debe reutilizar credenciales con otro servidor de autorización y debe registrarse de nuevo cuando cambie el emisor.

Esta regla aborda la confusión de credenciales. Nombres de servidor similares, redirecciones o metadatos cambiantes no deberían provocar que las credenciales de cliente de un servicio viajen a otro límite de autorización.

Los servidores de autorización también deben incluir un valor iss en sus respuestas de autorización. Cuando ese campo esté presente, los clientes deben validarlo frente al emisor registrado antes de intercambiar el código de autorización.

Esa validación sigue RFC 9207, un estándar del Internet Engineering Task Force diseñado para prevenir ataques de confusión de servidores de autorización. La comprobación importa cuando un cliente interactúa con varios emisores o descubre metadatos de autorización dinámicamente.

El registro dinámico de clientes también recibe directrices más estrictas. Los clientes MCP deben especificar un tipo de aplicación adecuado, lo que reduce los conflictos en torno a las reglas de URI de redirección para aplicaciones nativas y web.

Estos requisitos no hacen que cada despliegue sea seguro automáticamente. Las opciones de los SDK aún necesitan una configuración correcta, los registros de credenciales almacenadas requieren una indexación adecuada y los proveedores de identidad deben devolver información coherente sobre el emisor.

AgentCore Gateway ofrece un punto de aplicación útil porque puede autenticar a los llamantes entrantes y gestionar por separado las credenciales salientes. La documentación de AWS indica que el servicio admite autorización personalizada con JSON Web Token, AWS Identity and Access Management y otros modos de autorización configurados.

Esa separación es esencial. La identidad autorizada para invocar un gateway no debería recibir automáticamente credenciales sin restricciones para cada destino detrás de él.

AgentCore también puede asociar un motor de políticas a un gateway. El motor evalúa las llamadas a herramientas de los agentes y decide si cada acción se permite o se deniega según las políticas configuradas.

El modelo de gateway no elimina la necesidad del principio de mínimo privilegio. Una credencial de destino con ámbitos amplios sigue teniendo ámbitos amplios incluso cuando se almacena en un servicio de identidad gestionado.

Los equipos deben probar los casos negativos con tanto cuidado como las llamadas exitosas. Un cliente con un ámbito insuficiente debe recibir una respuesta de autorización controlada, no un error de protocolo ajeno ni acceso a una herramienta vecina.

El sistema de extensiones crea un cambio de gobernanza paralelo. Las funciones opcionales ahora pueden desarrollarse fuera del protocolo central mientras utilizan identificadores estandarizados, declaraciones de capacidades y negociación.

Según el marco de extensiones, los identificadores oficiales utilizan el prefijo io.modelcontextprotocol. Los terceros deben utilizar un dominio invertido de su propiedad, lo que reduce las colisiones entre funciones no relacionadas.

Los clientes anuncian las extensiones compatibles dentro de sus capacidades por solicitud. Los servidores anuncian las suyas mediante server/discover. Ambas partes deben aceptar explícitamente, y las extensiones permanecen desactivadas de forma predeterminada.

Las extensiones oficiales incluyen Tasks asíncronas, MCP Apps interactivas, credenciales de cliente OAuth y autorización gestionada por la empresa. El núcleo ya no necesita absorber cada función especializada antes de que los implementadores puedan usarla.

Esta estructura puede limitar la complejidad del núcleo. También crea una matriz de soporte que los equipos de plataforma deben seguir entre clientes, servidores, gateways y versiones de SDK.

Un cliente compatible con una extensión de interfaz interactiva debería seguir manejando una respuesta de texto significativa cuando el servidor pueda degradarse correctamente. Un servidor que requiera una extensión de autorización concreta puede rechazar en su lugar a un cliente incompatible.

La primera obligación de AgentCore Gateway es un comportamiento correcto del protocolo central. El soporte para la revisión de 2026 no debe interpretarse como soporte universal para todas las extensiones presentes o futuras.

Esa es una incertidumbre clave en el anuncio de AWS. El gateway puede transportar información de capacidades de extensión, pero los clientes necesitan documentación y pruebas explícitas para cualquier extensión de la que dependa su flujo de trabajo.

Los cambios de autorización y el marco de extensiones comparten un principio. Las suposiciones ocultas se están haciendo explícitas, ya se refieran a emisores de credenciales, capacidades de cliente o comportamiento opcional.

Esa explicitud es buena para el control empresarial. También significa que una configuración incompleta fallará de forma más visible que bajo una integración permisiva.

Lo que los clientes de Amazon AWS aún deben demostrar

Las tres señales siguientes son la telemetría de versiones negociadas, la calidad de los fallos de autorización y el soporte de extensiones bajo cargas de trabajo reales.

La primera señal es si los clientes de producción realmente negocian MCP 2026-07-28. La configuración del gateway por sí sola no puede responder a esa pregunta.

Los equipos deben supervisar los metadatos de las solicitudes y los errores relacionados con el protocolo tras un despliegue gradual. Deben comparar los resultados por nombre de cliente, versión de cliente, framework y canal de despliegue.

Una disminución en la tasa de errores de versión no compatible y de discrepancia de encabezados reforzaría el argumento de migración gestionada de AWS. Errores persistentes demostrarían que la adopción de SDK de clientes, y no la disponibilidad del gateway, sigue siendo el cuello de botella.

Las degradaciones merecen la misma atención. Un cliente que vuelve silenciosamente a una revisión anterior puede mantener un flujo de trabajo operativo mientras oculta un problema de migración sin resolver.

Las organizaciones deben definir la revisión esperada para cada cliente probado. Las alertas podrán entonces distinguir una alternativa de compatibilidad aprobada de una degradación no intencionada.

La segunda señal es cómo se comportan los fallos de autorización entre múltiples proveedores de identidad y destinos. Los equipos deben probar cambios de emisor, valores iss no válidos, tokens caducados, ámbitos insuficientes e intentos de reutilización de credenciales.

El resultado más seguro es una denegación precisa antes de que se ejecute el destino. Los registros deben identificar la política o el límite de autorización implicado sin exponer secretos al llamante.

Pruebas negativas limpias respaldarían la afirmación de que AgentCore reduce el trabajo de seguridad personalizado. Fallos confusos o un manejo incoherente de emisores la debilitarían, especialmente para gateways que abarcan varias unidades de negocio.

La tercera señal es la interoperabilidad de extensiones. Un flujo de trabajo que use Tasks, MCP Apps o una extensión de autorización debe verificar las capacidades antes de invocar comportamiento específico de extensiones.

Las pruebas deben incluir una degradación correcta. Un cliente sin soporte de interfaz de usuario debería seguir recibiendo contenido central útil cuando el servidor prometa una alternativa.

El caso contrario también importa. Si una extensión es obligatoria para una operación segura, el servidor debe rechazar claramente la solicitud en lugar de intentar un flujo de trabajo parcial.

Existen señales operativas más amplias bajo estas tres prioridades. Los equipos deben vigilar las llamadas con efectos secundarios interrumpidas en busca de acciones duplicadas, porque la nueva revisión elimina la reanudación de flujos.

También deben examinar el almacenamiento en caché. Los resultados de listas y recursos ahora incluyen ttlMs, una indicación de frescura medida en milisegundos, y cacheScope, que separa la capacidad de almacenamiento en caché pública de la privada.

El orden determinista de las herramientas puede mejorar el almacenamiento en caché del lado del cliente y de las instrucciones de los modelos. Sin embargo, las descripciones obsoletas de herramientas pueden hacer que un agente invoque un esquema desactualizado, por lo que el comportamiento de caché necesita pruebas durante las actualizaciones de destinos.

La observabilidad debe incluir contexto de trazas distribuidas. La especificación documenta convenciones de _meta para traceparent, tracestate y baggage, que ayudan a los equipos a seguir el trabajo entre clientes, gateways y destinos.

Ese trazado resulta especialmente útil durante los reintentos. Los operadores necesitan conectar el flujo original fallido con la nueva solicitud emitida sin tratarlos como un único ID de solicitud JSON-RPC.

El mayor valor del gateway gestionado aparece cuando convergen estas preocupaciones. Un único endpoint puede autenticar a los llamantes, aplicar políticas, traducir tráfico de protocolo, seleccionar herramientas, inyectar credenciales de destino y generar evidencia de auditoría.

Su principal riesgo también aparece ahí. Un gateway se convierte en un punto de control de gran influencia, por lo que un error de configuración puede afectar a muchos agentes y servicios simultáneamente.

Un despliegue cuidadoso debe comenzar con un gateway no crítico o un grupo limitado de clientes. Los equipos pueden añadir la nueva versión compatible, esperar al estado de preparado y ejecutar una suite de pruebas específica para esa versión.

La siguiente etapa debe introducir flujos de trabajo con estado representativos utilizando identificadores explícitos. Debe incluir una solicitud interrumpida y un efecto secundario reintentado de forma segura.

Las pruebas de autorización deben continuar con llamadas exitosas y denegadas. Los flujos de trabajo dependientes de extensiones deben incorporarse al final, después de que el comportamiento del protocolo central sea estable.

La planificación de reversión sigue siendo necesaria. Mantener la revisión estable anterior en la lista de versiones compatibles proporciona una alternativa a los clientes compatibles mientras los equipos investigan defectos.

Sin embargo, la alternativa no debe convertirse en una ambigüedad permanente. Las organizaciones necesitan una fecha para revisar los clientes anteriores restantes y un plan para las funciones obsoletas que aún utilizan.

Los desarrolladores deberían preocuparse porque la revisión cambia dónde almacenan el estado y cómo realizan reintentos. Los equipos de plataforma deberían preocuparse porque la compatibilidad se vuelve observable en el límite del gateway.

Los compradores empresariales deberían preocuparse porque el soporte de protocolo gestionado puede reducir la infraestructura duplicada. Aun así, deberían preguntar qué extensiones, SDK, regiones, configuraciones de identidad y tipos de destino han completado la validación en producción.

Los trabajadores del conocimiento experimentarán el resultado de forma indirecta. Sus asistentes podrían conectarse a más herramientas con menos fallos de conexión, pero solo si la identidad y el consentimiento siguen siendo claros en todas ellas.

Amazon AWS ha hecho que la primera acción de migración sea inusualmente pequeña. La cuestión más importante es si los equipos pueden hacer que cada solicitud sea autosuficiente sin perder seguridad, compatibilidad ni visibilidad.

Durante los próximos uno a tres meses, observe los datos de versión negociada, la calidad de las denegaciones de autorización y la conformidad de las extensiones en los principales SDK. Estas señales mostrarán si MCP sin estado se ha convertido en un estándar de producción o si sigue siendo una función de gateway a la espera de sus clientes.

Para los equipos que ya ejecutan AgentCore Gateway, la siguiente acción práctica es una auditoría de compatibilidad controlada. Actualice un gateway, pruebe cada cliente compatible, registre la revisión negociada y fuerce los casos de error antes de ampliar el acceso.

Esa evidencia importa más que la aparente sencillez de una llamada a la API. Amazon AWS ahora proporciona el puente hacia MCP 2026-07-28, pero cada organización debe demostrar que sus agentes pueden cruzarlo de forma segura.