Al implementar servidores Model Context Protocol (MCP) en producción, las empresas necesitan un control de acceso detallado entre servidores, observabilidad de qué equipos usan qué herramientas, garantías de seguridad contra la filtración de datos y administración de credenciales centralizada, todo a escala. Amazon Bedrock AgentCore Gateway se ubica entre los servidores MCP y los clientes que los consumen, centralizando la administración de credenciales, la observabilidad y la conectividad segura en un único punto de entrada confiable.
Hoy, estamos ampliando AgentCore Gateway con nuevas capacidades que fortalecen aún más el soporte para implementaciones de MCP empresariales. Esta publicación cubre el soporte extendido del esquema de la herramienta MCP, las indicaciones de MCP y los recursos de MCP como primitivos de primera clase, listado dinámico para el descubrimiento en tiempo de ejecución de servidores MCP, transmisión y administración de sesiones para interacciones con estado en tiempo real, obtención de solicitudes de entrada a mitad de ejecución e intercambio de tokens en nombre de OAuth 2.0 para autenticación delegada. Para ver ejemplos prácticos, visite el repositorio de ejemplos de GitHub.
Unir servidores MCP para empresas a través de AgentCore Gateway
Sin una puerta de enlace centralizada, cada servidor MCP que construya su organización debe manejar de forma independiente las credenciales, la aplicación de políticas, la conectividad privada y el registro. Esto significa que el servidor MCP de revisión de contratos de su equipo legal, el servidor MCP de recuperación de datos de su equipo financiero y el servidor MCP de respuesta a incidentes de su equipo de operaciones conllevan la misma carga de infraestructura. Los equipos de seguridad revisan cada servidor individualmente, los desarrolladores esperan las aprobaciones y nadie tiene una visión unificada de cómo se utiliza la infraestructura MCP en toda la organización.
AgentCore Gateway ayuda a evitar esta duplicación al establecer un punto de entrada único por el que fluye el tráfico MCP. El siguiente diagrama muestra las características principales de AgentCore Gateway que permiten la gobernanza y el control centralizados.
Cada equipo crea únicamente la lógica empresarial para su servidor MCP. AgentCore Gateway se encarga de todo lo demás. Agrega capacidades en diferentes tipos de objetivos, incluidos servidores MCP, API REST, funciones AWS Lambda y más. Las políticas basadas en recursos (RBP) controlan quién puede invocar AgentCore Gateway, por ejemplo, restringiendo la invocación a una nube privada virtual de Amazon (Amazon VPC). Las políticas de control de servicios (SCP) rigen cómo se mantiene AgentCore Gateway dentro de su organización de AWS.
Para el aislamiento de la red, AgentCore Gateway admite AWS PrivateLink para operaciones del plano de control y del plano de datos, de modo que el tráfico permanezca dentro de los límites de su Amazon VPC. También puede conectarse a puntos finales de API privados o servidores MCP a través del modo de recursos de VPC administrado. Los registros centralizados de aplicaciones e identidades le ayudan a gestionar los requisitos de auditoría y cumplimiento.
Con capacidad de interceptor, las funciones de AWS Lambda pueden personalizar solicitudes y respuestas, lo que permite un control de acceso detallado, desinfección, lógica de autorización personalizada y más. La integración con AgentCore Policy (versión preliminar) proporciona barreras de seguridad agentes definidas en torno a sus herramientas para la aplicación de políticas deterministas en un plano centralizado. AgentCore Gateway también ayuda a facilitar el flujo del código de autorización OAuth 2.0, donde el agente se autentica en nombre de un usuario antes de invocar las herramientas.
Ahora, analizará las nuevas capacidades que estamos agregando a AgentCore Gateway para fortalecer aún más el soporte de MCP empresarial.
Descubra las primitivas de su servidor MCP a través de una única puerta de enlace
AgentCore Gateway se convierte en un único punto final MCP que agrega capacidades de cada servidor MCP de su organización. Los clientes ven un catálogo de herramientas unificado, una biblioteca de mensajes y un espacio de nombres de recursos, no 20 conexiones separadas para administrar. En su interior, AgentCore Gateway admite las tres primitivas de MCP: herramientas, indicaciones y recursos. Las definiciones de herramientas en MCP incluyen un esquema de salida opcional para definir la estructura de salida esperada y anotaciones que describen propiedades de comportamiento, como si una herramienta es de solo lectura o destructiva, junto con el nombre, los íconos, la descripción y el esquema de entrada estándar. La puerta de enlace también admite indicaciones, recursos y plantillas de recursos a través de su conjunto completo de métodos MCP: herramientas/lista, herramientas/llamada, indicaciones/lista, indicaciones/obtener, recursos/lista, recursos/lectura y recursos/plantillas/lista. El siguiente diagrama de arquitectura muestra cómo AgentCore Gateway facilita las llamadas de lista e invocación.
En el modo de listado predeterminado, AgentCore Gateway descubre y almacena en caché herramientas, solicitudes y recursos de los destinos del servidor MCP conectado. Esta caché se actualiza implícitamente cada vez que llama a CreateGatewayTarget o UpdateGatewayTarget y se puede actualizar explícitamente mediante la API SynchronizeGatewayTargets. Cuando los clientes realizan llamadas a listas como herramientas/lista, solicitudes/lista o recursos/lista, AgentCore Gateway devuelve la respuesta directamente desde este caché sin invocar el destino del servidor MCP. La interacción real con el objetivo del servidor MCP solo ocurre durante las operaciones de invocación: herramientas/llamada, indicaciones/obtención y recursos/lectura. En ese momento, AgentCore Gateway enruta la solicitud al destino correcto.
Las herramientas y mensajes devueltos por AgentCore Gateway tienen como prefijo el nombre del objetivo utilizando el formato targetName___. A diferencia de las herramientas y los mensajes, los URI de recursos se devuelven sin un prefijo de nombre de destino; se pasa el URI original del servidor MCP descendente. Al crear un destino de servidor MCP que expone recursos, opcionalmente puede especificar un valor de ResourcePriority (1–1000) para controlar cómo AgentCore Gateway resuelve los conflictos cuando varios destinos exponen el mismo URI de recurso. Si no se define ninguna prioridad, se aplica un valor predeterminado de 1000. Cuando ocurre un conflicto, AgentCore Gateway devuelve el recurso del destino con el valor de ResourcePriority más bajo. Si dos recursos en conflicto comparten la misma prioridad, se devuelve el recurso del destino que se sincronizó primero.
Debido a que los URI de recursos los proporciona el destino del servidor MCP descendente y AgentCore Gateway no los valida ni los desinfecta, tenga cuidado con los destinos que no son de confianza. Un servidor MCP malicioso o comprometido podría devolver URI que apunten a puntos finales internos o rutas del sistema de archivos local. Valide y desinfecte los URI de recursos antes de seguirlos, y no obtenga ni represente automáticamente URI de destinos de servidores MCP que no sean de confianza.
Listado dinámico para flexibilidad en tiempo de ejecución
Algunos servidores MCP personalizan sus capacidades por usuario. Un servidor con reconocimiento de permisos podría exponer aprov_expense solo a los administradores, o un servidor multiinquilino podría mostrar herramientas compatibles con HIPAA solo para clientes de atención médica. El listado dinámico le permite conservar el control de acceso del lado del servidor mientras sigue enrutando a través de AgentCore Gateway.
Al crear un objetivo, elige entre dos modos de listado: predeterminado y dinámico. En el modo de listado predeterminado, AgentCore Gateway invoca el servidor MCP durante las operaciones CreateGatewayTarget o UpdateGatewayTarget para descubrir y almacenar en caché herramientas, indicaciones y recursos. Esta caché se puede actualizar explícitamente mediante la API SynchronizeGatewayTargets. Cuando los clientes realizan llamadas de lista, AgentCore Gateway entrega la respuesta directamente desde este caché sin contactar al servidor backend. En el modo de listado dinámico, AgentCore Gateway no invoca el servidor MCP durante las operaciones CreateGatewayTarget o UpdateGatewayTarget. En cambio, las llamadas de lista se reenvían en vivo al servidor MCP en el momento de la solicitud, utilizando la identidad del usuario que llama. En ambos modos, invoque operaciones como herramientas/llamada, mensajes/obtener y recursos/lectura de ruta directamente al destino del servidor MCP. El siguiente diagrama de arquitectura ilustra cómo ambos modos funcionan juntos.
MCP Server 1 está configurado con el modo de listado dinámico, mientras que MCP Server 2 y 3 usan el modo de listado predeterminado. La caché de AgentCore Gateway contiene solo las capacidades de los servidores en modo predeterminado. Durante las llamadas a listas, la respuesta se pagina; las primitivas en caché y MCP Server 1 se devuelven en páginas diferentes. Debido a que las primitivas no están indexadas en AgentCore Gateway para objetivos de listado dinámico, no se puede utilizar la capacidad de búsqueda de la herramienta semántica.
Esta arquitectura de modo dual también le brinda flexibilidad para múltiples inquilinos y control de acceso detallado (FGAC). Para ambos modos de listado, puede aplicar políticas de forma centralizada utilizando AgentCore Policy o interceptores de respuesta de AWS Lambda para filtrar capacidades según la identidad del inquilino. Por ejemplo, puede restringir a un inquilino para que solo vea herramientas de solo lectura. Para el modo de listado dinámico, puede administrar el control de acceso directamente en el servidor MCP, ya que las operaciones de lista se ejecutan bajo la identidad del usuario final y el destino del servidor MCP devuelve solo las capacidades a las que el usuario está autorizado a acceder.
Streaming, gestión de sesiones y obtención
Muchos flujos de trabajo de MCP empresariales van más allá de las sencillas llamadas a herramientas de solicitud-respuesta. Es posible que un servidor MCP necesite transmitir actualizaciones de progreso mientras genera un informe, pausar a mitad de la ejecución para solicitar la aprobación de un usuario antes de realizar una acción sensible o mantener el contexto a lo largo de una conversación de varios pasos que abarca varias invocaciones de herramientas. AgentCore Gateway admite transporte HTTP Streamable, gestión de sesiones MCP y obtención, que permiten interacciones humanas en el circuito con estado, en tiempo real.
HTTP transmitible
Sin transmisión, una llamada a una herramienta que dura 45 segundos no devuelve nada hasta que se completa y el usuario mira fijamente una ruleta. Con la transmisión, ven el progreso de los eventos en tiempo real. Cuando un cliente envía una solicitud de llamada/herramientas con Aceptar: aplicación/json, texto/secuencia de eventos, AgentCore Gateway abre una secuencia SSE y reenvía eventos desde el destino del servidor MCP en tiempo real, incluidas notificaciones de progreso, mensajes de registro y el resultado final de la herramienta. Los clientes que envían solo Aceptar: aplicación/json continúan recibiendo una única respuesta JSON, preservando la total compatibilidad con versiones anteriores.
Cuando la transmisión de respuestas está habilitada en AgentCore Gateway, el comportamiento del interceptor de respuestas cambia y debe verificar el campo isStreamingResponse en gatewayResponse para distinguir entre respuestas de transmisión y no transmisión. El interceptor de respuestas se invoca para eventos que contienen un campo de identificación JSON-RPC. El interceptor de respuestas no se invoca para notificaciones/progreso, notificaciones/mensajes y pings. Para habilitar la transmisión, configure el bloque enableResponseStreaming durante la llamada a la API CreateGateway o UpdateGateway.
Cuando piense en casos de uso de streaming con AgentCore Gateway, tenga en cuenta lo siguiente. AgentCore Gateway determina el código de estado HTTP del primer evento en la secuencia. Si se produce un error a mitad de camino, se entrega como un objeto de error JSON-RPC dentro de un marco SSE en lugar de como un código de estado HTTP, ya que el estado ya se envió. Los errores previos a la transmisión, como errores de autenticación, limitaciones o errores de validación, se devuelven como respuestas de error JSON-RPC estándar sin marco SSE.
Gestión de sesiones
La gestión de sesiones introduce flujos de trabajo de múltiples turnos con estado en AgentCore Gateway. Cuando habilita sesiones, AgentCore Gateway genera un Mcp-Session-Id en la primera solicitud de inicialización y lo devuelve como encabezado de respuesta. El cliente incluye este encabezado en solicitudes posteriores, lo que permite a AgentCore Gateway rastrear las interacciones del cliente, mantener asignaciones a sesiones de servidor MCP posteriores y correlacionar solicitudes de obtención entre llamadas de herramientas.
Para habilitar sesiones, agregue un bloque sessionConfiguration durante la llamada a la API CreateGateway o UpdateGateway. Puedes configurar el tiempo de espera de la sesión desde un mínimo de 15 minutos hasta un máximo de 8 horas. El valor predeterminado es 1 hora.
Las sesiones están dirigidas al usuario autenticado. AgentCore Gateway deriva la identidad del usuario del contexto de autorización, el token de portador JWT para el ingreso de OAuth o las credenciales de IAM para el ingreso de AWS_IAM, y valida que cada solicitud dentro de una sesión se origine en el mismo usuario. Esto ayuda a evitar el secuestro de sesión, donde un cliente intenta utilizar el identificador de sesión de otro cliente. AgentCore Gateway devuelve HTTP 400 si una puerta de enlace habilitada para sesión recibe una solicitud sin un encabezado Mcp-Session-Id y HTTP 404 para sesiones caducadas o inexistentes.
Detrás de escena, AgentCore Gateway conserva el ID de la sesión en un almacén duradero totalmente administrado para administrar las sesiones entre solicitudes. Cuando AgentCore Gateway recibe la primera llamada a la herramienta para un destino de servidor MCP determinado dentro de una sesión, inicializa una conexión a ese destino, negocia capacidades en nombre del cliente y almacena el identificador de sesión de destino. Las llamadas de herramientas posteriores al mismo destino dentro de la sesión reutilizan esta asignación, evitando la sobrecarga de inicialización repetida. Debido a este comportamiento, AgentCore Runtime no necesita iniciar en frío una nueva micro-VM en cada solicitud, lo que resulta en tiempos de respuesta más rápidos.
Cuando piense en sesiones para su AgentCore Gateway, tenga en cuenta lo siguiente. Habilitar sesiones es un requisito previo para la elicitación. Si está utilizando la propagación de encabezados para reenviar Mcp-Session-Id a los destinos hoy, no puede habilitar simultáneamente la administración de sesiones porque la puerta de enlace debe ser propietaria del ciclo de vida de la sesión. Si una sesión del servidor MCP descendente expira antes del tiempo de espera de la sesión de la puerta de enlace, la puerta de enlace reinicializa el destino de forma transparente y continúa atendiendo al cliente.
Sonsacamiento
La obtención permite a los servidores MCP detrás de AgentCore Gateway pausar la ejecución y solicitar información del usuario final. Esto es particularmente valioso para operaciones de alto riesgo donde el servidor necesita confirmación explícita del usuario, recopilación de datos estructurados o autenticación fuera de banda antes de continuar.
AgentCore Gateway admite los siguientes modos de obtención. En el modo de formulario, el servidor MCP envía un esquema JSON plano que describe los campos que necesita y el cliente genera un formulario para que el usuario lo complete. En el modo URL, el servidor envía una URL que el cliente abre para el usuario, normalmente una pantalla de consentimiento de OAuth o un flujo de trabajo de aprobación externo. En el modo de excepción de URL, el servidor devuelve URLElicitationRequiredError que contiene una URL, lo que solicita al cliente que redirija al usuario y vuelva a intentar la llamada a la herramienta después de que el usuario complete el flujo externo.
Así es como funciona la obtención del modo formulario a través de AgentCore Gateway. Los pasos 1 a 6 cubren la inicialización de la sesión y el descubrimiento de herramientas. Después de eso, el cliente envía una solicitud de llamada/herramientas con el encabezado Mcp-Session-Id. AgentCore Gateway reenvía la llamada de la herramienta al destino del servidor MCP. El objetivo abre una secuencia SSE y envía una solicitud de obtención/creación. AgentCore Gateway reenvía la solicitud de obtención/creación al cliente en la secuencia SSE. El cliente presenta el formulario al usuario y recoge la respuesta. Luego, el cliente envía la respuesta de obtención (acción: aceptar o rechazar) utilizando el mismo Mcp-Session-Id. AgentCore Gateway reenvía la respuesta al destino del servidor MCP, que reconoce HTTP 202 aceptado. El objetivo continúa procesando la solicitud con la nueva información.
La obtención requiere que tanto la transmisión como las sesiones estén habilitadas en su puerta de enlace. AgentCore Gateway respeta la negociación de capacidades; solo declara soporte de obtención a un servidor MCP descendente cuando el cliente que se conecta ha declarado soporte para él durante la inicialización. Esto significa que si un cliente no admite la obtención, el servidor MCP no intentará enviar solicitudes de obtención, evitando comportamientos inesperados. AgentCore Gateway también admite múltiples elicitación activa por sesión, por lo que un cliente puede tener llamadas de herramientas simultáneas, cada una con su propia elicitación pendiente.
Cuando piense en la obtención de su puerta de enlace AgentCore, tenga en cuenta lo siguiente. El tiempo de espera de obtención se rige por el tiempo de espera de la conexión de AgentCore Gateway. Si un usuario tarda más que el tiempo de espera de la conexión en responder a un formulario o completar un flujo de URL, la solicitud caduca. Planifique el tiempo de espera de su conexión en consecuencia para los flujos de trabajo que involucran interacción humana. Si la conexión entre el cliente y AgentCore Gateway se interrumpe durante una obtención, AgentCore Gateway no admite la reanudación de esa llamada de herramienta específica. El cliente debe volver a intentar las herramientas/solicitud de llamada originales. La puerta de enlace admite transferencia de obtención solo para destinos de servidor MCP. Para tipos de objetivos que no son MCP, como API REST o funciones de AWS Lambda, la obtención no es aplicable ya que esos objetivos no inician solicitudes de obtención.
Intercambio de tokens en nombre de OAuth 2.0
Cuando sus agentes necesitan acceder a recursos posteriores en nombre de usuarios autenticados, AgentCore Gateway admite el intercambio de tokens en nombre de (OBO) OAuth 2.0 a través de AgentCore Identity. Esto permite un modelo de autenticación de confianza cero en el que la identidad del usuario original se conserva y se propaga a través de cada salto en la cadena de solicitud, mientras que cada capa recibe un token dirigido precisamente a su audiencia prevista.
El cliente MCP se autentica en AgentCore Gateway con JWT A, con alcance para la audiencia de la puerta de enlace (aud: gw), a través de la conexión HTTP transmitible /mcp. Cuando AgentCore Gateway necesita llamar a un destino de servidor MCP descendente, llama a AgentCore Identity para intercambiar JWT A por JWT B, ahora con alcance a la audiencia del servidor MCP (aud: mcp). Si, a su vez, el servidor MCP necesita llamar a otra API descendente, puede usar GetResourceOAuth2Token para obtener JWT C con alcance para la audiencia de API descendente (aud: api). En cada salto, la identidad del usuario original (sub: X) se mantiene, por lo que los servicios posteriores pueden aplicar una autorización detallada por usuario sin activar flujos de consentimiento adicionales. Las afirmaciones utilizadas en este flujo son estrictamente a modo de ejemplo y solo deben usarse para comprender este diagrama.
AgentCore Identity actúa como intermediario de tokens central para todo este flujo. Proporciona una bóveda de tokens segura para almacenar credenciales de OAuth y secretos de clientes, de modo que ni AgentCore Gateway ni los servidores MCP necesiten administrar las credenciales directamente, y la identidad de la carga de trabajo para la autenticación de servicio a servicio utilizando la identidad de la carga de trabajo de AWS en lugar de secretos de larga duración. Admite el intercambio de tokens estándar (RFC 8693) o la concesión de autorización JWT (RFC 7523), según el proveedor de identidad.
Conclusión
Con esta versión, puede crear flujos de trabajo de agentes de múltiples turnos con estado con transmisión de progreso en tiempo real, puertas de aprobación humana que pausan y reanudan la ejecución y propagación de identidades de confianza cero, a través de un único punto final administrado. Sin tiendas de sesiones personalizadas, sin infraestructura de transmisión manual, sin credenciales de cuentas de servicios compartidas. Sus servidores MCP permanecen centrados en la lógica empresarial. AgentCore Gateway se encarga del resto: descubrimiento, transmisión, estado, identidad y política, gobernado de forma centralizada y adoptable de forma incremental.
Para comenzar, revise la documentación de Amazon Bedrock AgentCore Gateway para obtener detalles de configuración sobre cada característica que se trata en esta publicación. Para ver ejemplos prácticos, visite el repositorio de ejemplos de GitHub. Si ya está ejecutando servidores MCP detrás de AgentCore Gateway, puede adoptar estas capacidades de forma incremental sin cambios en su AgentCore Gateway existente o en las configuraciones de destino.
Sobre los autores
Anagh Agrawal
Anagh es ingeniero de software en Amazon Bedrock AgentCore, donde crea una infraestructura de puerta de enlace central que impulsa experiencias de IA agente. Anteriormente trabajó en Amazon Bedrock Agents y aporta la experiencia en sistemas distribuidos y servicios criptográficos de su tiempo en AWS Key Management Service. Tiene una maestría en Ciencias de la Computación de la Universidad Stony Brook. Fuera del trabajo, Anagh es un músico que toca el piano y el ukelele, y un ávido excursionista al que le encanta todo lo que esté al aire libre.
Eashan Kaushik
Eashan es arquitecto de soluciones especializado en IA/ML en Amazon Web Services. Se centra en la creación de soluciones de IA generativa y, al mismo tiempo, prioriza un enfoque de su trabajo centrado en el cliente. Antes de ocupar este cargo, obtuvo una maestría en Ciencias de la Computación de la Escuela de Ingeniería Tandon de la Universidad de Nueva York. Fuera del trabajo, le gustan los deportes, levantar pesas y correr maratones.
Ke Ma
Ke es ingeniero de software en Amazon Bedrock AgentCore Gateway, una plataforma diseñada para proporcionar una forma sencilla y segura para que los desarrolladores creen, implementen, descubran y se conecten a múltiples capacidades de IA agente a escala. Antes de ocupar este cargo, obtuvo una maestría en Ingeniería Informática de la Universidad de California, Irvine.
Kyungna Kim
Kyungna es ingeniera de software en Amazon Bedrock AgentCore Gateway, donde crea infraestructura para que los desarrolladores conviertan las API y los servicios en herramientas seguras y reconocibles para los agentes de IA a escala. Antes de ocupar este puesto, trabajó en Amazon Bedrock Agents, ayudando a los desarrolladores a crear agentes autónomos para orquestar modelos básicos.
Tejas Dastane
Tejas es un ingeniero de software experimentado en Amazon Bedrock AgentCore Gateway, donde construye una infraestructura central para crear puertas de enlace de servidores MCP utilizadas por agentes de IA. Anteriormente, trabajó en la infraestructura agente para Amazon Bedrock Agents y también tiene experiencia trabajando con aplicaciones de robótica en la nube y servicios informáticos como AWS Batch.