Bedrock AgentCore Gateway y MCP: qué revisar antes de conectar

Esta guía explica qué hay que revisar antes de poner el MCP remoto de EveryInfra detrás de Amazon Bedrock AgentCore Gateway. No desplegamos Gateway: todos los comandos y plantillas de AWS de este artículo son ejemplos de configuración escritos a partir de docs.aws.amazon.com, sin ejecutar en AWS; cada número de EveryInfra sale de llamadas reales del 10-11-2026, entre las 00:17 y las 00:43 (hora de Singapur). En dinero, Gateway casi no cuesta nada. Según la página de precios de AWS que leímos ese día, Gateway cobra 0,005 USD por cada 1000 invocaciones. Las mismas 1000 llamadas a reddit/search de EveryInfra cuestan 0,556 USD, así que Gateway supone el 0,89 % del gasto en datos. Lo difícil está en otra parte, y lo vimos en las respuestas en bruto de esas llamadas.

Hay tres hallazgos que cambian el diseño. Primero, tools/list de EveryInfra no pide clave: que Gateway sincronice las herramientas y marque el destino como READY no demuestra que la API key sea correcta. Segundo, por MCP el límite de frecuencia, un parámetro inválido y la falta de clave llegan como HTTP 200 con isError; un interceptor que solo mire el código de estado contará fallos como éxitos. Tercero, una página de Reddit ordenada por lo más reciente cubrió solo 72 minutos, así que el agente tiene que consultar cada hora.

Este artículo responde a un caso concreto. Una agencia de comunicación gestiona la reputación de varias marcas y ya ejecuta agentes en AWS con AgentCore. Ahora quiere un agente que lea lo que se dice de cada marca en Reddit, X, YouTube, Threads y noticias. Las herramientas vienen del MCP remoto de EveryInfra (https://api.everyinfra.com/mcp).

El equipo de seguridad pone tres condiciones. Cada persona entra con la identidad de la empresa. La clave de EveryInfra no aparece en el código ni en los prompts. Cada cliente de la agencia tiene un tope diario de gasto en datos. AgentCore Gateway cubre las tres en un solo sitio: valida el token de entrada, añade la clave de salida y ejecuta código propio antes y después de cada llamada (los interceptores).

Lo que se dice sobre cómo trata Gateway una solicitud (quitar el prefijo de la herramienta, añadir la cabecera con la clave) viene de la documentación de AWS. Lo que se dice sobre qué devuelve o cobra EveryInfra viene de nuestras pruebas. El código de los interceptores lo ejecutamos en local, con el formato de carga que describe AWS y las respuestas reales como entrada.

Qué es AgentCore Gateway a finales de 2026

AWS presentó AgentCore en versión preliminar el 16 de julio de 2025. El anuncio describía Gateway como una forma de convertir API y funciones Lambda en herramientas compatibles con MCP (AWS What's New, 16-07-2025). En la disponibilidad general, el 13 de octubre de 2025, AWS añadió la frase que importa aquí: Gateway ya podía conectarse a servidores MCP existentes (AWS What's New, 13-10-2025). Desde entonces, un MCP remoto alojado por un tercero puede ir detrás de Gateway sin código intermedio.

La documentación actual define Gateway como una pasarela de IA gestionada: un único punto de entrada seguro para el tráfico de los agentes hacia herramientas, otros agentes y modelos (descripción de Gateway). Hay tres clases de destino. Los destinos MCP funcionan en modo agregado: Gateway los une en un solo servidor MCP virtual. Los destinos HTTP pasan el tráfico tal cual. Los destinos de inferencia enrutan llamadas a modelos según el nombre del modelo (destinos admitidos).

Un destino MCP puede salir de siete fuentes: Lambda, una etapa REST de API Gateway, OpenAPI, Smithy, un servidor MCP, una plantilla de socio o un conector integrado (destinos MCP). Aquí usamos solo el servidor MCP. La tabla resume los cambios que afectan a un agente de reputación.

En un año, Gateway pasó de convertidor de API a pasarela con identidad, límites, filtros y enrutado de modelos. Quien pone herramientas de datos de terceros detrás de Gateway busca control centralizado, no conversión de protocolos.

¿Conexión directa o detrás de Gateway?

La pregunta ya salió en la comunidad. En r/aws alguien preguntó cómo usar desde AgentCore un MCP remoto alojado por un proveedor SaaS sin montar un contenedor. La respuesta más votada dice que el código del agente puede llamar directamente al MCP remoto y que Gateway sobra en ese caso. Otra respuesta añade que, cuando muchos agentes llegan a varios MCP remotos, Gateway junta en un sitio la identidad de entrada y salida y la observabilidad (hilo de r/aws). Las dos tienen razón: depende de cuántos agentes, cuántos equipos y quién custodia la clave.

Nuestra regla tiene tres casos. Con una persona, un agente y una clave, la conexión directa es lo más simple: la clave va a Secrets Manager, el agente la lee al arrancar y la manda en la cabecera. Con una agencia que atiende a varias marcas, cada una con su presupuesto, o con un equipo de seguridad que exige un único lugar para claves de terceros y un registro por llamada, Gateway compensa. La clave queda en AgentCore Identity, el código del agente solo conoce la URL de Gateway y los topes por cliente viven en el interceptor.

El tercer caso es la Responses API de Bedrock. El anuncio del 24 de febrero de 2026 explica que se indica el ARN del Gateway en la solicitud como conector de herramientas; Bedrock descubre las herramientas, las ejecuta e inyecta los resultados en la conversación (anuncio de ejecución en el servidor). Para ese flujo, las herramientas tienen que estar detrás de Gateway.

Tenemos dos guías parecidas. La de Gemini Enterprise para sentimiento de marca trata Google Cloud, donde los almacenes MCP personalizados solo aceptan OAuth o ninguna autenticación. La de Copilot Studio para fichas de cuentas trata un caso de ventas en Microsoft. AWS se diferencia en que el propio destino de servidor MCP acepta una API key.

El destino de servidor MCP: versiones, sincronización y nombres

AWS fija tres requisitos para un destino de servidor MCP. El servidor debe ofrecer herramientas; prompts y recursos son opcionales y se sincronizan si el servidor los anuncia. La versión del protocolo debe ser 2026-07-28, 2025-11-25, 2025-06-18 o 2025-03-26. La URL debe ir codificada y Gateway la usa tal cual (destinos de servidor MCP).

Hay dos modos de listado. En DEFAULT, al crear o actualizar el destino, Gateway llama a tools/list, prompts/list, resources/list y resources/templates/list y guarda el resultado en un catálogo único. Si después el servidor cambia sus herramientas, hay que llamar a SynchronizeGatewayTargets. En DYNAMIC, Gateway pregunta al servidor en cada solicitud del cliente, pero no funcionan la búsqueda semántica ni OAuth de tres patas.

El 10-11-2026, entre las 00:17 y las 00:18 (hora de Singapur), enviamos a https://api.everyinfra.com/mcp las mismas solicitudes que haría Gateway al sincronizar. Todas fueron gratuitas. initialize respondió en 0,16 segundos. tools/list tardó 0,12 segundos y devolvió 12 herramientas en 16 250 bytes. prompts/list devolvió 7 prompts, uno de ellos llamado brand_monitoring; resources/list, 6 recursos; resources/templates/list, ninguno.

La negociación de versión fue lo más útil. Al pedir 2026-07-28, EveryInfra respondió 2025-11-25; al pedir 2025-06-18 o 2025-03-26, devolvió la misma versión. Es lo que dice la especificación de MCP: si el servidor admite la versión pedida, la repite; si no, responde con otra que admita, normalmente la más reciente (ciclo de vida, MCP 2025-11-25). Las cuatro versiones están en la lista de Gateway, así que el saludo inicial funciona.

La especificación 2026-07-28 trata Tasks como una extensión que ambas partes acuerdan al inicio (especificación MCP 2026-07-28). Gateway solo admite MCP Tasks con esa versión (MCP Tasks en Gateway), así que hoy no sirven con EveryInfra. La alternativa es el modo asíncrono propio: se añade "mode":"async" a everyinfra_call_api, se recibe un job_id al instante y se consulta con everyinfra_get_job, que no cobra ni cuenta para el límite por minuto. El tiempo máximo de una invocación en Gateway es de 15 minutos (cuotas de AgentCore); nuestra llamada síncrona más lenta tardó 29,5 segundos.

Gateway cambia los nombres de las herramientas. El nombre público es destino___herramienta, con tres guiones bajos (nombres de herramientas). Si el destino se llama everyinfra, el agente ve everyinfra___everyinfra_call_api. El nombre más largo de los 12 es everyinfra___everyinfra_list_captcha_types, con 42 caracteres. En el prompt del sistema, en las reglas de Policy y en los límites hay que usar el nombre con prefijo, o bien cortar en ___ antes de comparar, como hace nuestro interceptor.

Que la lista de herramientas esté en caché también oculta fallos. En un issue público de GitHub, un destino MCP con credenciales de cliente OAuth aparecía como READY y listaba herramientas, pero cada tools/call devolvía un error interno y el servidor nunca recibía la llamada (issue 809 de agentcore-samples). En r/aws, otro usuario intentó conectar el MCP remoto de GitHub a través de Gateway y no consiguió que funcionara OAuth de tres patas (r/aws: AgentCore y el MCP de GitHub). Con EveryInfra el riesgo es más fácil de pasar por alto: initialize, tools/list y prompts/list funcionan sin clave. Si se guarda una clave equivocada en AgentCore Identity, el destino sincroniza igual y sigue en READY.

Por eso conviene una prueba rápida al crear el destino: llamar a everyinfra_get_account a través de Gateway. A las 00:24 devolvió saldo y límites en 0,24 segundos, sin cargo. A las 00:18 llamamos a everyinfra_call_api sin clave y recibimos HTTP 200, isError y unauthorized, también sin cargo. No probamos everyinfra_get_account con una clave errónea. Si la prueba no muestra un saldo, lo primero es revisar la credencial.

Autenticación de salida: cómo entrega Gateway la clave de EveryInfra

La página de autenticación de salida de AWS tiene una matriz por tipo de destino. Para servidores MCP admite seis opciones: ninguna, el rol de servicio de Gateway (SigV4), credenciales de cliente OAuth, código de autorización OAuth, intercambio de tokens OAuth y API key. No admite credenciales IAM de quien llama ni el paso directo de tokens (autenticación de salida). SigV4 solo sirve si delante del servidor MCP hay un servicio de AWS que valide firmas IAM, como AgentCore Runtime, API Gateway o una URL de función Lambda. EveryInfra no valida firmas IAM y hoy no tiene servidor OAuth, así que queda la API key.

Son dos pasos. Primero se crea un proveedor de credenciales de API key en AgentCore Identity. En la consola, en Outbound Auth, se elige Add API key; se puede pegar la clave o apuntar a un secreto de Secrets Manager, y el nombre admite hasta 50 caracteres (añadir una API key). Por API, la operación es CreateApiKeyCredentialProvider (referencia de la API). Después se asocia el proveedor al destino con credentialProviderType: API_KEY y cuatro valores en apiKeyCredentialProvider: el ARN del proveedor, la ubicación (HEADER o QUERY_PARAMETER), el nombre del parámetro y el prefijo (autorización del destino).

Los valores dependen de lo que acepte EveryInfra, y lo comprobamos a las 00:18. Con Authorization: Bearer <clave>, tools/call se ejecutó y cobró. Con la cabecera X-API-Key, EveryInfra respondió unauthorized con el mensaje «no API key provided (header Authorization: Bearer or ?key= query param)» y aclaró que no había cargo. Sin clave, el resultado fue el mismo. La configuración es, por tanto, HEADER, Authorization y Bearer. El mensaje menciona también el parámetro ?key=, pero no lo recomendamos: las URL acaban en registros de acceso, y Gateway puede enviar sus registros de invocación a CloudWatch, S3 o Firehose (anuncio de PrivateLink y registros, septiembre de 2025).

Aquí va la configuración como plantilla de CloudFormation. Los tipos y propiedades coinciden con la referencia de CloudFormation que consultamos el 10-11-2026 (AWS::BedrockAgentCore::GatewayTarget, AWS::BedrockAgentCore::Gateway), pero la plantilla no se ha desplegado.

# Ejemplo de configuración (CloudFormation). No se ha desplegado en AWS.
# La clave de EveryInfra se lee de Secrets Manager; nunca se escribe en la plantilla.
Resources:
  BrandMonGateway:
    Type: AWS::BedrockAgentCore::Gateway
    Properties:
      Name: reputacion-gw
      RoleArn: arn:aws:iam::123456789012:role/reputacion-gateway-role
      ProtocolType: MCP
      AuthorizerType: CUSTOM_JWT
      AuthorizerConfiguration:
        CustomJWTAuthorizer:
          DiscoveryUrl: https://login.example.com/.well-known/openid-configuration
          AllowedAudience: [reputacion-gateway]
      InterceptorConfigurations:
        - Interceptor: { Lambda: { Arn: arn:aws:lambda:eu-west-1:123456789012:function:reputacion-interceptor } }
          InterceptionPoints: [REQUEST, RESPONSE]
          InputConfiguration: { PassRequestHeaders: true }
  EveryInfraTarget:
    Type: AWS::BedrockAgentCore::GatewayTarget
    Properties:
      GatewayIdentifier: !Ref BrandMonGateway
      Name: everyinfra
      TargetConfiguration:
        Mcp: { McpServer: { Endpoint: https://api.everyinfra.com/mcp } }
      CredentialProviderConfigurations:
        - CredentialProviderType: API_KEY
          CredentialProvider:
            ApiKeyCredentialProvider:
              ProviderArn: "<ARN del proveedor creado con CreateApiKeyCredentialProvider>"
              CredentialLocation: HEADER
              CredentialParameterName: Authorization
              CredentialPrefix: Bearer

Hay dos cosas que revisar. La primera es la herramienta de despliegue. Un issue del starter toolkit de AgentCore indica que, en agentcore.json, los destinos de servidor MCP solo respetaban la autenticación de salida NONE y OAUTH; API_KEY solo funcionaba en destinos de API Gateway, aunque CloudFormation sí lo admitía (issue 499 del starter toolkit, 10-04-2026). Las notas de octubre de 2026 anuncian AgentCore CLI 1.0, pero no dicen si el problema está resuelto. La segunda es el rol: un rol de servicio propio necesita GetWorkloadAccessToken, GetResourceApiKey y secretsmanager:GetSecretValue sobre el secreto (autenticación de salida, sección API key).

En cuanto al coste, AgentCore Identity cobra 0,010 USD por cada 1000 solicitudes de token o API key cuando se usa sola, pero la página de precios aclara que es gratuita a través de AgentCore Gateway o Runtime (precios de AgentCore). Guardar la clave de EveryInfra en Gateway no añade ninguna línea a la factura.

Autenticación de entrada: cada persona con su identidad corporativa

La entrada decide quién puede usar el agente. La documentación ofrece JWT, IAM y dos modos de delegación: solo autenticar, o no autenticar (autenticación de entrada). En una agencia, el personal suele entrar con Okta, Microsoft Entra ID o Cognito, así que lo normal es JWT: se crea el Gateway con CUSTOM_JWT, se indica la URL de descubrimiento OIDC y se limitan los tokens con allowedAudience, allowedClients o scopes. Si un token no vale, Gateway responde con un error RFC 6750 y una cabecera WWW-Authenticate que indica los scopes necesarios. La documentación avisa además de que algunos claims del JWT, entre ellos el subject, quedan en CloudTrail; mejor no poner ahí un correo ni otros datos personales.

Nuestro presupuesto usa un claim propio llamado cliente. En este ejemplo, quien trabaja la cuenta de una marca de automoción recibe auto-mx y quien lleva una cadena de cafeterías recibe cafe-es. Tras validar la firma, el interceptor lee el claim del token en las cabeceras. Los interceptores no reciben cabeceras por defecto: hay que activar passRequestHeaders (configurar interceptores). La misma página recuerda que las cabeceras llevan tokens y que no deben ir a los registros.

Sobre el modo sin autenticación, la documentación es tajante: no usarlo para pruebas, no conectarlo a destinos con datos sensibles y reservarlo para pasarelas públicas con límites propios. Con EveryInfra el riesgo es directo. Gateway añade la clave de pago a cada llamada de salida, así que una entrada abierta deja gastar el saldo a cualquiera que conozca la URL. Nuestra guía de configuración del MCP remoto lo resume igual: la clave es la cartera.

Un interceptor Lambda con presupuesto diario por cliente

Los interceptores llegaron el 26 de noviembre de 2025. El artículo de lanzamiento de AWS los presenta para control de acceso fino, filtrado de herramientas por identidad y cambios en solicitudes y respuestas (artículo de lanzamiento). En re:Invent, en diciembre de 2025, el equipo de Gateway contó que los clientes pedían un lugar común para ejecutar lógica entre los agentes y las herramientas (minuto 25:37 de la charla AIM3313 de re:Invent 2025).

Las reglas son pocas. Cada Gateway tiene como mucho un interceptor REQUEST y uno RESPONSE, ambos en Lambda. REQUEST se ejecuta antes de llamar al destino; RESPONSE, después de la respuesta del destino y antes de contestar a quien llama. Gateway puede reintentar un interceptor tras un fallo o un tiempo de espera, así que la función debe ser idempotente (interceptores).

La carga es el mensaje JSON-RPC tal cual. En REQUEST llega gatewayRequest.body, con el method (por ejemplo tools/call) y los params. En RESPONSE se añade gatewayResponse, con código de estado y cuerpo. Si un interceptor REQUEST devuelve transformedGatewayResponse, Gateway se la manda al cliente y no llama al destino; aun así, el interceptor RESPONSE se ejecuta una vez (tipos y cargas de interceptores). AWS publica un ejemplo de código abierto con dos interceptores Lambda que imputan el coste de inferencia por usuario y aplican topes diarios y mensuales; al superarlos devuelve 403 con BUDGET_EXCEEDED (interceptor de uso en aws-samples). Ese ejemplo mide tokens de modelo; nosotros aplicamos la misma idea al gasto en datos de las herramientas MCP.

El interceptor tiene que resolver tres preguntas: cuánto costará la llamada, cuánto costó de verdad y qué pasa si falla. Para la primera, el catálogo gratuito de EveryInfra (GET /api/v1/social/catalog) indica un price_usd por capacidad; se guarda una vez al día y se reserva ese precio antes de llamar. Para la segunda miramos respuestas MCP reales de las 00:18 y las 00:25. Una llamada correcta trae content pero no structuredContent, y el cargo está en billing.charged_usd dentro de la cadena JSON de content[0].text. Una llamada fallida trae structuredContent.error con un código. Para la tercera, EveryInfra no cobra fallos ni resultados vacíos, así que charged_usd vale 0.

La trampa está en el código de estado. A las 00:18 y 00:19 enviamos llamadas REST demasiado seguidas y chocamos con el límite de la clave de prueba, 10 llamadas por minuto: REST respondió HTTP 429. A las 00:24 chocamos con el mismo límite por MCP y la respuesta fue HTTP 200 con isError: true, el código rate_limited y retry_after: 14. A las 00:24 también enviamos a propósito sort: "hot": MCP devolvió HTTP 200 con invalid_value y did_you_mean: ["popular", "top"].

La especificación de MCP pone los errores de herramienta dentro del resultado para que el modelo los lea y corrija la siguiente llamada; es el diseño correcto. Pero significa que, en el interceptor RESPONSE y en los registros de Gateway, una llamada fallida también aparece con estado 200. Cualquier tasa de éxito o presupuesto basado en el código de estado sale mal.

Envolvimos las respuestas reales en el formato de carga de la documentación de AWS y las pasamos por el manejador completo. El destino de la prueba se llama everyinfra, igual que en el ejemplo de configuración, así que cada herramienta lleva el prefijo everyinfra___. Usamos un tope diario de 0,002 USD y ejecutamos los casos en el orden de la tabla. Es un resultado local, no de Gateway: demuestra que la lógica entiende las respuestas reales de EveryInfra, no que Gateway envíe la carga exactamente como dice la documentación.

El filtro de herramientas merece un comentario. El MCP de EveryInfra tiene 12 herramientas y el agente de reputación necesita 4: everyinfra_call_api, everyinfra_get_job, everyinfra_get_account y everyinfra_list_capabilities. Las demás ocupan contexto del modelo y dan al agente acciones que no le tocan. Con el filtro, el array tools baja de 16 883 a 4357 bytes, un 74 % menos; como las descripciones entran en el contexto en cada turno, se ahorran unos 3000 tokens por turno. En el minuto 19:17 de la misma charla de re:Invent, AWS habló de agentes con unas 300 herramientas que gastaban cientos de miles de tokens solo en cargar descripciones, y propuso la búsqueda semántica. Con un solo servidor MCP y pocas herramientas, filtrar en el interceptor es más simple y evita los 0,025 USD por 1000 de Search API. Otra opción es escribir una lista fija en el destino con mcpToolSchema; la referencia de la API dice que la admiten todos los tipos de credencial, pero entonces Gateway deja de sincronizar y hay que actualizarla a mano (McpServerTargetConfiguration). Ojo también con las anotaciones: everyinfra_call_api declara destructiveHint: true porque gasta saldo, así que una regla que solo permita herramientas de lectura la bloqueará. Las reglas deben ir por nombre de herramienta.

Interceptores, límites, Policy y WAF: qué controla cada uno

El 6 de agosto de 2026 AWS publicó a la vez los límites de frecuencia propios y las reglas temporales de Policy (anuncio, artículo sobre límites). Un límite cuenta solicitudes por dimensión: nombre del destino, nombre de herramienta en forma destino___herramienta, cualquier claim del JWT o el principal IAM. También sirven cabeceras y campos del cuerpo, pero solo junto a una dimensión de identidad (dimensiones de los límites). Cada Gateway admite hasta 50 límites, los cambios se aplican en 30 segundos y no tienen coste adicional.

El control que más se malinterpreta es el límite de frecuencia. La documentación dice, en negrita, que falla en abierto: si el servicio de límites cae o no puede resolver una dimensión, la solicitud pasa. No debe ser la única barrera (límites de frecuencia). Sirve para que un cliente no agote la cuota por minuto de EveryInfra, no para un tope en dólares, que exige un contador propio en el interceptor. Policy aplica reglas Cedar antes de cada llamada a herramienta (Policy): decide quién llama a qué y con qué argumentos, pero no sabe cuánto cuesta. WAF va más afuera: una web ACL por Gateway, y cada solicitud de entrada pasa por sus reglas antes de llegar a cualquier destino (proteger la pasarela con WAF). Lo razonable es usar los cuatro: WAF para escáneres, límites para ráfagas, Policy para permisos y el interceptor para el dinero.

Una ida y vuelta real

Gateway funciona en modo agregado, así que la llamada casi no cambia respecto a la directa: solo cambia el nombre de la herramienta. A través de Gateway, el agente llama a everyinfra___everyinfra_call_api; Gateway quita el prefijo, saca la clave de AgentCore Identity, la pone en Authorization y reenvía la llamada. La captura muestra nuestra llamada directa de las 00:18:20 (hora de Singapur), con el nombre original para poder repetirla sin pasarela.

Cada publicación de Reddit trae id, url, title, text, author_username, community, like_count, comment_count y posted_at, los mismos response_fields que el catálogo indica para reddit/search (ver la página de la API de búsqueda de Reddit). El agente necesita título, inicio del texto, enlace, fecha, contadores y comunidad. El nombre de autor no ayuda a medir la reputación y es un dato personal que un informe de marca no debería mostrar.

La página de precios cuenta ListTools, InvokeTool y Ping como invocaciones de Gateway, a 0,005 USD por cada 1000 (precios de AgentCore). Una ronda del agente suele listar herramientas una vez y luego llamar a varias. Si el cliente MCP ejecuta initialize y tools/list antes de cada llamada, las invocaciones crecen más rápido que las llamadas. Nuestro cálculo cuenta una lista por ronda más las llamadas, sin initialize, porque la página no dice si cuenta. Las sesiones MCP de Gateway ayudan: guardan el identificador de sesión del destino y lo reutilizan, sin reiniciar en cada solicitud (funciones de Gateway, sesiones MCP).

Las herramientas de datos tardaron entre 4,7 y 29,5 segundos, y la búsqueda en X fue la más lenta. Sin una pasarela desplegada no pudimos medir lo que añade Gateway, pero con estos tiempos no será el cuello de botella. El tiempo de espera del cliente debe fijarse según la herramienta más lenta: con 10 segundos, el cliente corta la búsqueda en X y el agente se queda sin nada, mientras la solicitud en EveryInfra puede seguir en curso. No probamos si una desconexión del cliente se cobra, así que no conviene contar con un reintento gratis. Lo más seguro es "mode":"async" y después everyinfra_get_job.

Qué datos recibe el agente de reputación

Gateway solo vigila la puerta; que el agente sirva depende de lo que devuelve cada herramienta. Usamos como marca de prueba el fabricante de coches eléctricos Rivian, porque a principios de noviembre de 2026 estaba entregando su nuevo R2 y había conversación fresca en Reddit, X, YouTube y Threads.

Una página de Reddit cubre algo más de una hora. reddit/search ordenado por newest devolvió 10 publicaciones entre las 15:01 y las 16:13 UTC del 09-11-2026: 1,21 horas. Un agente que mire cada seis horas se perderá casi todo salvo que lea más páginas. Cada página cuesta 0,000556 USD, así que una página por hora y seis páginas cada seis horas cuestan casi lo mismo; la primera opción detecta antes una queja. Nuestro plan hace 24 búsquedas en Reddit al día. Repetimos la búsqueda 23,8 minutos después, a las 00:42 (hora de Singapur): las 10 publicaciones eran las mismas y la más reciente seguía siendo la de las 16:13 UTC, aunque la llamada se hizo a las 16:42 UTC. No sabemos si no hubo publicaciones nuevas o si la búsqueda iba con retraso; en cualquier caso, mirar cada 20 minutos no habría encontrado más que mirar cada hora.

La búsqueda por palabras es literal. Con la palabra clave Rivian R2 problem llegaron 5 publicaciones: una preguntaba por la reventa de un portátil Alienware m18 R2 y otra hablaba de una videoconsola. La búsqueda empareja palabras, no significados, así que el agente necesita su propio filtro de relevancia antes de escribir el informe.

**En X, latest abarca un día y no va en orden estricto.** twitter/search con Rivian since:2026-11-08 y sort en latest devolvió 25 publicaciones entre las 15:14 UTC del 08-11-2026 y las 16:26 UTC del 09-11-2026, es decir, 25,19 horas, sin orden estricto de la más nueva a la más antigua. El agente no puede usar la primera fecha como cursor; tiene que quitar duplicados por id. El orden por defecto es peor para vigilar reputación: de 25 publicaciones, 5 tenían más de 30 días y otras 5 eran de la propia cuenta de la marca, con 247 707 seguidores. La página de la API de búsqueda de X explica los parámetros.

YouTube mezcla canales y vídeos antiguos. youtube/search ordenado por fecha devolvió 10 resultados y solo 6 eran vídeos de los últimos 7 días. Los otros 4 eran una entrada de canal, sin url ni view_count, y vídeos de hace más de un mes, uno de ellos de 2024. Nuestro primer script leía view_count directamente y falló con la entrada de canal.

Las fechas de los comentarios de YouTube son relativas. youtube/comments sobre el vídeo KP8I6yoWXsY («Rivian Replaced My R2 After Just 2 Months», publicado el 07-11-2026) devolvió 20 comentarios con posted_at del tipo «30 minutes ago» o «1 day ago». Hay que convertirlos con la hora de la llamada, no después; un día más tarde la conversión ya estaría desfasada. Este es el código que ejecutamos sobre la respuesta real; la consulta empezó a las 00:28:05 hora de Singapur, es decir, a las 16:28:05 UTC del 09-11-2026.

# Convierte "30 minutes ago" en una fecha absoluta, usando la hora en que se hizo la llamada.
# Ejecutado en local sobre los 20 comentarios reales de youtube/comments del 10-11-2026.
import re
from datetime import datetime, timedelta, timezone

UNITS = {"second": 1, "minute": 60, "hour": 3600, "day": 86400, "week": 604800, "month": 2592000, "year": 31536000}

def absolute(posted_at: str, fetched_at: datetime) -> tuple[str, str]:
    """Devuelve (fecha ISO en UTC, precisión). La precisión es la unidad del texto original."""
    m = re.match(r"(\d+)\s+(second|minute|hour|day|week|month|year)s?\s+ago", posted_at)
    if not m:
        return posted_at, "absoluta"          # ya viene como fecha ISO
    n, unit = int(m.group(1)), m.group(2)
    return (fetched_at - timedelta(seconds=n * UNITS[unit])).isoformat(timespec="minutes"), unit

fetched = datetime(2026, 11, 9, 16, 28, 5, tzinfo=timezone.utc)
print(absolute("30 minutes ago", fetched))      # ('2026-11-09T15:58+00:00', 'minute')
print(absolute("14 hours ago (edited)", fetched))  # ('2026-11-09T02:28+00:00', 'hour')
print(absolute("1 day ago", fetched))           # ('2026-11-08T16:28+00:00', 'day')

De los 20 comentarios, 1 quedó con precisión de minutos, 12 con precisión de horas y 7 con precisión de días. Guardar la precisión junto a la fecha evita conclusiones falsas: «1 day ago» puede ser cualquier momento entre 24 y 47 horas antes, y una gráfica por horas no debería tratarlo como un dato exacto. Consulte también la página de la API de comentarios de YouTube.

Un tercio de los comentarios del vídeo hablan del creador. Etiquetamos a mano los 20 comentarios de YouTube y los 7 de un hilo de Reddit sobre recompras, con una regla escrita y una sola persona. En YouTube, 8 se quejaban del producto, el servicio o la entrega; 6 hablaban sobre todo del creador; 4 eran preguntas y 2, otra cosa. En Reddit, 3 eran quejas y 4 trataban piezas y detalles legales. Contar palabras negativas exageraría las quejas de marca en YouTube; los comentarios de Reddit, en cambio, explican mejor el problema que el título del hilo.

Threads llega en varios idiomas. threads/search sobre Rivian devolvió 17 publicaciones en 12,1 segundos, a lo largo de 17 horas. Las 17 mencionan la marca y algunas están en francés y en ucraniano. Para una agencia con clientes en varios mercados, agrupar por idioma antes de resumir es obligatorio. Más detalles en la API de datos de Threads.

La búsqueda de noticias no se completó dos veces. google_news/search devolvió HTTP 503 por REST a las 00:21:45 y, por MCP a las 00:42:42, HTTP 200 con isError y el código unavailable; las dos respuestas indicaron que no había cargo. Eso significa «no se pudo consultar», nunca «no hay noticias»; un interceptor que solo cuente éxitos escribiría «hoy no hubo noticias» en el informe.

Recortar campos en el interceptor RESPONSE

La factura de Lambda es mínima; la del modelo, no. El agente hace 37 llamadas a herramientas al día y, con los tamaños medidos, las respuestas suman unos 468 047 bytes diarios. A unos 4 bytes por token son unos 117 000 tokens al día y 3,5 millones al mes, sin contar noticias, de las que no hay muestra. El interceptor RESPONSE ya analiza cada resultado para leer el cargo, así que quitar ahí los campos que no se usan sale casi gratis.

Conservamos ocho campos: url, title, text (primeros 280 caracteres), posted_at, like_count, comment_count, view_count y community. Fuera quedan autores, avatares, miniaturas, dominios de enlaces y objetos anidados. Los bytes salen de las respuestas reales.

X y YouTube son los que más ahorran, porque cada publicación o vídeo arrastra el perfil completo del autor y enlaces multimedia. Al cambiar una respuesta hay que tener en cuenta dos cosas. La primera es que transformedGatewayResponse sustituye a la respuesta original (tipos y cargas de interceptores); los datos son una cadena JSON dentro de content[0].text, así que hay que analizarla, recortarla y volver a serializarla, sin tocar billing. La segunda es que quitar autores no es solo cuestión de tokens: los términos de la API de datos de Reddit y la política para desarrolladores de X limitan el uso de datos de identidad, y un informe de marca no debería nombrar a particulares.

Hay un hueco que el filtro no cierra. Según AWS, Policy solo evalúa herramientas MCP; sea cual sea el modo, Gateway siempre permite prompts/list, prompts/get, resources/list, resources/read y resources/templates/list (Gateway con Policy). Una publicación en r/AI_Agents avisa de que cada destino MCP nuevo puede traer recursos que Policy no ve (hilo de r/AI_Agents). Revisamos lo que expone EveryInfra: 7 prompts y 6 recursos, todos guías públicas como everyinfra://guide/getting-started o everyinfra://pricing. Leerlos es gratis y no toca datos de clientes, así que aquí no hay riesgo; si la misma pasarela atiende un servidor MCP interno, sus recursos se revisan aparte.

Precios de Bedrock AgentCore Gateway: cuánto cuesta el agente al mes

Estos son los precios de AWS que leímos en la página de precios de AgentCore a las 00:15 (hora de Singapur) del 10-11-2026. Los de Lambda vienen de la página de precios de Lambda.

La propia página trae un ejemplo: un agente con 600 000 llamadas InvokeTool al mes paga 3 USD de Gateway, a 5 USD por millón, y 1400 USD de búsqueda web, a 7 USD por cada 1000 consultas. Gateway es barato; el dinero se va en las herramientas que hay detrás, y en nuestro caso pasa lo mismo.

En EveryInfra, reddit/search, twitter/search, youtube/search, youtube/comments, reddit/comments y threads/search cuestan 0,000556 USD por llamada, es decir, 0,556 USD por 1000; google_news/search cuesta 0,792 USD por 1000. Los fallos, los límites de frecuencia, los parámetros inválidos y los resultados vacíos no se cobran. En nuestras llamadas hubo 12 casos así: 7 límites de frecuencia, 2 llamadas sin autorización, 1 parámetro inválido y 2 consultas de noticias que no se completaron, todos con cargo 0 USD. Las 9 llamadas correctas costaron 0,005004 USD en total. Los precios vigentes están en la página de precios.

El plan mensual sale de las mediciones. Reddit se busca cada hora, 24 veces al día, y los comentarios de los hilos con quejas, 5 veces. X se busca dos veces al día, porque una página cubre unas 25 horas. YouTube se busca una vez y sus comentarios se leen 3 veces. Las noticias, dos veces. En total son 37 llamadas a herramientas al día repartidas en 25 rondas (24 horarias y un informe diario), y cada ronda lista herramientas una vez.

El resultado es claro. Gateway y la Lambda de los interceptores cuestan unos 0,0108 USD al mes, el 1,71 % del gasto en datos de EveryInfra. Con Policy en cada llamada, la proporción sube al 6,11 %, porque Policy cuesta 0,025 USD por 1000, cinco veces la invocación de Gateway. Por cada 1000 llamadas, Gateway supone el 0,89 % de reddit/search; por cada 1000 publicaciones de Reddit, los datos cuestan 0,0556 USD. Quedan fuera dos costes: las lecturas y escrituras de DynamoDB para el presupuesto, y el modelo, que lee unos 3,5 millones de tokens de respuestas al mes. Ese último depende del modelo elegido y casi seguro supera todo lo anterior junto; por eso importa recortar campos.

Para una agencia con varias marcas, la proporción se mantiene: diez marcas con el mismo plan suman unos 6,31 USD al mes en datos y unos 0,108 USD en Gateway y Lambda, porque ambos lados cobran por llamada. Solo cambia si se activa la búsqueda semántica, necesaria con cientos de herramientas; entonces cada búsqueda cuesta 0,025 USD por 1000 más la indexación. Con EveryInfra como único destino no hace falta.

En qué se diferencia de Gemini Enterprise y Copilot Studio

Hemos publicado otras dos guías de plataformas de agentes para empresas con el MCP de EveryInfra. Cada una tiene otro foco; la tabla ayuda a elegir.

Si los datos deben acabar en un almacén y no en un informe, la guía de Snowflake Cortex Agents es la referencia; su conector MCP solo acepta OAuth, así que el montaje es muy distinto. Si aún no hay plataforma elegida, conviene empezar por el plano de monitorización de reputación multiplataforma, que trata listas de objetivos, duplicados, cursores y revisión humana. Para los reembolsos de llamadas fallidas está la guía de conciliación de reembolsos.

Límites y preguntas abiertas

Esto es lo que no probamos o lo que hoy no funciona.

La parte de AWS no se ha ejecutado. Los comandos, la plantilla, el JSON de destinos y credenciales y el comportamiento del interceptor desplegado siguen solo la documentación. La lógica del interceptor sí se ejecutó en local con respuestas reales en el formato documentado, pero Gateway podría enviar campos que no vimos. Antes de producción hay que hacer un tools/list y un tools/call en una pasarela de pruebas.

La API key de salida puede no aplicarse en algunas herramientas de despliegue. Un issue del starter toolkit indica que API_KEY como salida de un destino MCP en agentcore.json no tenía efecto tras desplegar (issue 499 del starter toolkit, 10-04-2026). No sabemos si está resuelto; lo prudente es usar la API CreateGatewayTarget, la consola o CloudFormation y comprobarlo con un tools/call.

Las reglas de cada plataforma siguen vigentes. Los datos son publicaciones y comentarios públicos, pero su uso se rige por los términos de la API de datos de Reddit, la política para desarrolladores de X y las políticas para desarrolladores de los servicios de API de YouTube. Los informes citan texto y enlaces, sin recopilar ni mostrar perfiles de particulares.

La clave de prueba tenía un límite bajo. Permitía 10 llamadas por minuto, de ahí los 7 límites de frecuencia. Una clave de producción muestra su propio límite en everyinfra_get_account; los límites de Gateway deben ajustarse a él para frenar las ráfagas antes de que lo haga EveryInfra.

Cambios de los últimos 60 días

La cronología del principio ya recoge los cambios del propio Gateway: MCP Tasks, respaldo de InvokeModel y Web Answer. Esta tabla añade cuatro publicaciones de AWS del 20 de octubre al 6 de noviembre de 2026 que no están en la cronología y que importan cuando una herramienta de terceros va detrás de Gateway.

Preguntas frecuentes

¿Qué diferencia hay entre AgentCore Gateway y AgentCore Runtime? (Sugerencia de búsqueda: «agentcore gateway vs runtime».) Runtime ejecuta el código del agente; Gateway gestiona las herramientas, los modelos y los otros agentes a los que llama. El agente de reputación puede correr en Runtime o en un contenedor propio, siempre que llegue a la URL de Gateway por MCP (descripción de Gateway).

¿AgentCore Gateway es lo mismo que Amazon API Gateway? (Sugerencia: «agentcore gateway vs api gateway».) No. API Gateway sirve API HTTP generales; AgentCore Gateway habla MCP y une varias fuentes de herramientas en un solo servidor MCP. Se complementan: una etapa REST de API Gateway puede ser un tipo de destino de AgentCore Gateway (destinos MCP).

¿Un destino de servidor MCP puede usar una API key? ¿Dónde se guarda? (Sugerencia: «agentcore gateway api key».) Sí. Se guarda en AgentCore Identity con CreateApiKeyCredentialProvider y en el destino se configura la cabecera Authorization con el prefijo Bearer. La clave nunca aparece en el código ni en los prompts (añadir una API key). Una herramienta de despliegue no aplicaba este ajuste en destinos MCP (issue 499 del starter toolkit).

¿Hace falta un interceptor REQUEST, uno RESPONSE o los dos? (Sugerencia: «agentcore gateway interceptor request response».) Cada Gateway admite uno de cada tipo. Un presupuesto necesita los dos: REQUEST revisa el tope y bloquea, y RESPONSE lee el cargo real, lo anota y recorta campos (configurar interceptores).

¿Cómo funciona bedrock agentcore gateway pricing y puede costar más que los datos? (Sugerencia: «amazon bedrock agentcore gateway pricing».) No: con nuestro plan, Gateway cuesta unos 0,0093 USD al mes y los datos unos 0,6313 USD; el cálculo está en la sección de precios.

¿Para qué usar Gateway en vez de conectar el agente al MCP remoto? (hilo de r/aws.) Para una persona y un agente basta la conexión directa; la sección «¿Conexión directa o detrás de Gateway?» explica cuándo compensa.

¿Policy bloquea todas las solicitudes MCP? (hilo de r/AI_Agents.) No: las solicitudes de prompts y recursos pasan siempre; el final de la sección sobre recortar campos explica por qué aquí no hay riesgo.

Primeros pasos: primero directo, después Gateway

1. Crear una API key en la consola de EveryInfra y seguir la guía rápida para enviar un tools/list y un tools/call con curl. La guía del MCP remoto y la página del servidor MCP explican la configuración de clientes.
2. Guardar la misma clave en AgentCore Identity con CreateApiKeyCredentialProvider.
3. Crear el Gateway con entrada CUSTOM_JWT, la URL de descubrimiento del proveedor de identidad y los clientes permitidos.
4. Añadir un destino de servidor MCP para https://api.everyinfra.com/mcp, con el proveedor de API key, cabecera Authorization y prefijo Bearer.
5. Cuando el destino sincronice, enviar un tools/call a través de Gateway, por ejemplo reddit/search, y buscar billing en el resultado. Una lista de herramientas sola no prueba que la clave funcione.
6. Desplegar el interceptor REQUEST y RESPONSE con el presupuesto de cada cliente en una variable de entorno, primero en una pasarela de pruebas.
7. Configurar los límites de Gateway a partir del límite que muestra everyinfra_get_account, uno por cada valor del claim cliente.

Los parámetros y campos de cada plataforma están en las páginas de la API de datos de Reddit, la API de datos de X y la API de datos de YouTube. Para comparar otras herramientas de datos, búsqueda y automatización está el mercado de infraestructura.

Referencias

Leímos todas las páginas de AWS el 10-11-2026 (hora de Singapur). Las fechas entre paréntesis son las de publicación que muestra cada página; las páginas de documentación sin fecha no la llevan. Los datos de EveryInfra salen de las respuestas en bruto de nuestras llamadas reales del mismo día.

1. AWS What's New: Amazon Bedrock AgentCore preview (16-07-2025) <https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-bedrock-agentcore-preview/>
2. AWS What's New: Amazon Bedrock AgentCore is now generally available (13-10-2025) <https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available/>
3. Documentación de AWS: Amazon Bedrock AgentCore Gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html>
4. Documentación de AWS: Supported targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-supported-targets.html>
5. Documentación de AWS: MCP targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-targets-mcp.html>
6. AWS Machine Learning Blog: Apply fine-grained access control with Bedrock AgentCore Gateway interceptors (26-11-2025) <https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/>
7. AWS What's New: Server-side tool execution with AgentCore Gateway (24-02-2026) <https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-bedrock-server-side-tool-execution-agentcore-gateway/>
8. AWS What's New: AWS WAF for Amazon Bedrock AgentCore (29-06-2026) <https://aws.amazon.com/about-aws/whats-new/2026/06/aws-waf-amazon-bedrock-agentcore/>
9. AWS What's New: Temporal policies and rate limits in AgentCore (06-08-2026) <https://aws.amazon.com/about-aws/whats-new/2026/08/temporal-policies-agentcore/>
10. AWS What's New: AgentCore Identity hosted consent portal (01-09-2026) <https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-agentcore/>
11. Documentación de AWS: AgentCore release notes (November and October 2026) <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html>
12. AWS What's New: AgentCore Gateway InvokeModel support and model fallback (22-10-2026) <https://aws.amazon.com/about-aws/whats-new/2026/10/agentcore-gateway-invokemodel-fallback/>
13. AWS Machine Learning Blog: Getting started with Web Answer on Amazon Bedrock AgentCore (05-11-2026) <https://aws.amazon.com/blogs/machine-learning/getting-started-with-web-answer-on-amazon-bedrock-agentcore/>
14. Reddit r/aws: How to integrate AWS AgentCore with a remote MCP server <https://www.reddit.com/r/aws/comments/1pwtc53/how_to_integrate_aws_agentcore_with_a_remote_mcp/>
15. Documentación de AWS: MCP servers targets <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html>
16. Model Context Protocol: Specification 2025-11-25: Lifecycle <https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle>
17. Model Context Protocol: Specification 2026-07-28 <https://modelcontextprotocol.io/specification/2026-07-28>
18. Documentación de AWS: MCP tasks in AgentCore Gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-mcp-tasks.html>
19. Documentación de AWS: Quotas for Amazon Bedrock AgentCore <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html>
20. Documentación de AWS: Tool naming <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-tool-naming.html>
21. GitHub awslabs/agentcore-samples: Issue 809: tools/call internal error on an OAuth MCP target <https://github.com/awslabs/agentcore-samples/issues/809>
22. Documentación de AWS: Outbound authorization <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-outbound-auth.html>
23. Documentación de AWS: Add an API key credential provider <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-add-api-key.html>
24. AWS API Reference: CreateApiKeyCredentialProvider <https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateApiKeyCredentialProvider.html>
25. Documentación de AWS: Target authorization configuration <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-building-adding-targets-authorization.html>
26. AWS What's New: AgentCore Gateway PrivateLink and invocation logging (2025-09) <https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-bedrock-agentcore-gateway-privatelink-invocation-logging/>
27. Documentación de AWS: CloudFormation: AWS::BedrockAgentCore::GatewayTarget <https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrockagentcore-gatewaytarget.html>
28. Documentación de AWS: CloudFormation: AWS::BedrockAgentCore::Gateway <https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-bedrockagentcore-gateway.html>
29. GitHub aws/bedrock-agentcore-starter-toolkit: Issue 499: API_KEY outbound auth on an MCP target (10-04-2026) <https://github.com/aws/bedrock-agentcore-starter-toolkit/issues/499>
30. AWS: Amazon Bedrock AgentCore pricing <https://aws.amazon.com/bedrock/agentcore/pricing/>
31. Documentación de AWS: Inbound authorization <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-inbound-auth.html>
32. Documentación de AWS: Configure interceptors <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-configuration.html>
33. YouTube: AWS re:Invent 2025 AIM3313: AgentCore Gateway (2025-12) <https://www.youtube.com/watch?v=DlIHB8i6uyE>
34. Documentación de AWS: Gateway interceptors <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html>
35. Documentación de AWS: Interceptor types and payloads <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-types.html>
36. GitHub aws-samples: sample-agentcore-gateway-usage-interceptor <https://github.com/aws-samples/sample-agentcore-gateway-usage-interceptor>
37. AWS API Reference: McpServerTargetConfiguration <https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_McpServerTargetConfiguration.html>
38. AWS Machine Learning Blog: Configure rate limits for AI traffic on AgentCore Gateway (06-08-2026) <https://aws.amazon.com/blogs/machine-learning/configure-rate-limits-for-ai-traffic-on-agentcore-gateway/>
39. Documentación de AWS: Rate limit dimensions <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits-dimensions.html>
40. Documentación de AWS: Rate limits <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-rate-limits.html>
41. Documentación de AWS: Policy in AgentCore <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html>
42. Documentación de AWS: Protecting your gateway with AWS WAF <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-waf.html>
43. Documentación de AWS: Gateway features <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-features.html>
44. Documentación de AWS: Use MCP sessions with your AgentCore gateway <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-sessions.html>
45. Reddit: Data API Terms <https://redditinc.com/policies/data-api-terms>
46. X Developer Platform: Developer Policy <https://docs.x.com/developer-terms/policy>
47. Documentación de AWS: Use an AgentCore Gateway with Policy <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/use-gateway-with-policy.html>
48. Reddit r/AI_Agents: AgentCore Gateway Policy covers MCP tools only <https://www.reddit.com/r/AI_Agents/comments/1xat5hx/agentcore_gateway_policy_covers_mcp_tools_only/>
49. AWS: AWS Lambda pricing <https://aws.amazon.com/lambda/pricing/>
50. Reddit r/aws: AgentCore connection to GitHub MCP? <https://www.reddit.com/r/aws/comments/1t7fp90/agentcore_connection_to_github_mcp/>
51. Google for Developers: YouTube API Services Developer Policies <https://developers.google.com/youtube/terms/developer-policies>
52. AWS Machine Learning Blog: Govern AI agent access with Okta Cross App Access and AgentCore, part 2 (06-11-2026) <https://aws.amazon.com/blogs/machine-learning/govern-ai-agent-access-with-okta-cross-app-access-and-amazon-bedrock-agentcore-part-2/>
53. Documentación de AWS: Web Answer connector <https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-connector-web-answer-tool.html>
54. AWS Machine Learning Blog: ServiceNow on-behalf-of token exchange with AgentCore Gateway (03-11-2026) <https://aws.amazon.com/blogs/machine-learning/servicenow-on-behalf-of-token-exchange-with-bedrock-agentcore-gateway/>
55. AWS Machine Learning Blog: How MoEngage turned over 400 APIs into agent tools with AgentCore Gateway (29-10-2026) <https://aws.amazon.com/blogs/machine-learning/how-moengage-turned-over-400-apis-into-agent-tools-with-agentcore-gateway/>
56. AWS Machine Learning Blog: Building an agentic AI platform on Amazon Bedrock AgentCore (28-10-2026) <https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore/>
57. AWS Machine Learning Blog: How Eon built multi-cloud investigation with an MCP gateway on AgentCore (20-10-2026) <https://aws.amazon.com/blogs/machine-learning/how-eon-built-multi-cloud-investigation-with-an-mcp-gateway-on-amazon-bedrock-agentcore/>