Cuando los equipos de comercio electrónico necesitan un tiempo de comercialización más rápido para las experiencias de los clientes impulsadas por la IA, se enfrentan a semanas de trabajo de integración personalizado que retrasa los lanzamientos y aumenta los riesgos de seguridad. Crear y conectar un asistente de IA listo para producción generalmente requiere un código API personalizado para cada cliente, administración de infraestructura de contenedores y autenticación compleja. Amazon Bedrock AgentCore y Mistral AI Studio agilizan este proceso. Un servidor Model Context Protocol (MCP) de comercio electrónico listo para producción en Amazon Bedrock AgentCore, conectado a Mistral AI Studio, agiliza el desarrollo. MCP proporciona protocolos de integración estandarizados, AgentCore Runtime administra contenedores y valida tokens y Amazon Cognito maneja la identidad.
En esta publicación, usted construye y conecta ese servidor de un extremo a otro. Implementará herramientas MCP, configurará la autenticación JSON Web Token (JWT) de dos capas, implementará con el AWS Cloud Development Kit (AWS CDK) y conectará el resultado a Vibe de Mistral AI. La publicación también cubre los requisitos previos, la arquitectura de la solución, las mejores prácticas para servidores MCP y conectores Vibe, y la limpieza de recursos. El servidor de comercio electrónico que cree admite la búsqueda de productos, la realización de pedidos, el envío de reseñas y el procesamiento de devoluciones mediante Amazon DynamoDB para datos y Amazon Cognito para administración de identidades.
Amazon Bedrock AgentCore es una plataforma para crear, conectar y optimizar agentes de IA a escala. Dentro de él, AgentCore Runtime es el componente sin servidor totalmente administrado para alojar cargas de trabajo de agentes y MCP, con aislamiento de sesión, soporte de solicitudes de larga duración, validación JWT integrada y observabilidad, para que no administre contenedores, balanceadores de carga ni middleware de autenticación. En esta publicación, creará el servidor MCP con Python y FastMCP y luego lo implementará en Runtime para alojamiento administrado. Amazon Cognito administra la identidad del usuario a través de OAuth 2.1, manteniendo aislados los datos de cada cliente. Con MCP, escribe un servidor al que se conectan varios clientes de IA, en lugar de crear una integración separada para cada cliente. Vibe de Mistral AI ofrece a los usuarios una interfaz conversacional con el servidor en la web, iOS y Android.
Al final, tendrá un servidor MCP de comercio electrónico en funcionamiento que autentica a los usuarios a través de Amazon Cognito, limita el acceso a los datos por cliente y responde a consultas en lenguaje natural de Vibe. Debido a que el servidor utiliza el estándar MCP, otros clientes compatibles con MCP también pueden conectarse a él.
Para ver la solución en acción, mire la siguiente demostración. Luego, explore la publicación completa para obtener una guía detallada sobre cómo implementar su propio servidor MCP listo para producción y consultarlo desde Vibe.
Requisitos previos
Necesita una cuenta de AWS con permisos para crear tablas de Amazon DynamoDB (base de datos NoSQL), grupos de usuarios de Amazon Cognito (identidad de usuario, OAuth 2.1), roles de AWS Identity and Access Management (IAM) y repositorios de Amazon Elastic Container Registry (Amazon ECR), y para acceder a Amazon Bedrock AgentCore (plataforma para crear y ejecutar agentes de IA). Para herramientas de desarrollo local, instale Python 3.10 o posterior, Node.js 18 o posterior, AWS CDK (npm install -g aws-cdk), la interfaz de línea de comandos de AWS (AWS CLI) configurada con credenciales y la CLI de Amazon Bedrock AgentCore (pip install bedrock-agentcore). También necesitas una cuenta Mistral AI con acceso a Vibe. Docker no es necesario porque AgentCore Runtime crea imágenes de contenedores en la nube mediante AWS CodeBuild.
Descripción general de la solución
Le mostramos cómo crear un servidor MCP de comercio electrónico que realice operaciones de compra reales: buscar productos, realizar pedidos, enviar reseñas y procesar devoluciones. Se trabaja con tres capas:
Capa de aplicación: el servidor MCP es una aplicación Python creada con FastMCP, un marco para crear servidores MCP. Expone seis herramientas de comercio electrónico a través de un punto final /mcp y un punto final /health para monitoreo. AgentCore Runtime ejecuta el servidor como un contenedor. Capa de datos: cinco tablas de Amazon DynamoDB almacenan datos de comercio electrónico: productos, clientes, pedidos, reseñas y devoluciones. Usted aprovisiona las tablas con capacidad bajo demanda para el escalado automático. Los índices secundarios globales admiten patrones de consulta eficientes. Capa de seguridad: Autenticación de dos niveles que mantiene la privacidad de los datos de cada cliente. Amazon Cognito actúa como proveedor de identidad, AgentCore Runtime valida los tokens JWT a nivel de infraestructura y la aplicación extrae atributos específicos del usuario para limitar el acceso a los datos del cliente autenticado.
La solución se implementa mediante AWS CDK con cuatro pilas de infraestructura. DynamoDBStack crea las cinco tablas de datos con índices y las configura para un desmontaje sencillo en entornos de desarrollo. CognitoStack proporciona al grupo de usuarios atributos personalizados para la identificación del cliente y crea clientes de aplicaciones OAuth 2.1 configurados para la integración de Mistral AI Vibe. DataLoaderStack utiliza un recurso personalizado de AWS Lambda para inicializar la base de datos con datos de prueba realistas (50 productos, 10 clientes, 50 pedidos, reseñas y devoluciones), de modo que pueda probar el servidor inmediatamente después de la implementación. AgentCoreRuntimeStack crea una función de IAM con los permisos necesarios, aprovisiona un repositorio ECR para la imagen del contenedor y almacena los parámetros de configuración a los que hace referencia el comando de implementación.
Figura 1. Arquitectura de flujo de solicitudes para el servidor MCP de comercio electrónico
El diagrama ilustra el flujo de solicitudes cuando un usuario interactúa con el servidor MCP de comercio electrónico a través de Mistral Vibe. Antes de la primera solicitud, el usuario se autentica a través de un flujo de inicio de sesión de OAuth 2.1: Vibe abre una página de inicio de sesión alojada en Cognito, el usuario ingresa sus credenciales y Cognito emite un token JWT que Vibe almacena para la sesión. Cuando un usuario pregunta: "Muéstrame mis pedidos recientes", el modelo de IA determina que necesita llamar a la herramienta MCP get_order_history y envía una solicitud de MCP a través de HTTPS al punto final de AgentCore. La solicitud incluye el token Bearer JWT del flujo de inicio de sesión de OAuth 2.1. Antes de llegar al código de la aplicación, el validador JWT de AgentCore verifica el token con Cognito User Pool. Comprueba la firma, la caducidad y la autorización del cliente y luego rechaza los tokens no válidos. Una vez validada, la solicitud llega al contenedor del servidor MCP, que llama a Cognito para recuperar el atributo de ID del cliente que vincula al usuario autenticado con su perfil de comercio electrónico. Una vez confirmada la identidad del cliente, el servidor consulta las tablas de DynamoDB relevantes. La operación se centra únicamente en los datos de ese cliente para imponer la privacidad y el aislamiento. Luego, el servidor envía la respuesta estructurada a través de AgentCore a Vibe, lo que genera una respuesta en lenguaje natural como "Tiene 2 pedidos recientes: pedido n.° 1234 para auriculares inalámbricos (entregado) y pedido n.° 1236 para soporte para computadora portátil (en procesamiento)".
Esta arquitectura utiliza seguridad en capas. AgentCore Runtime autentica las solicitudes en la capa de infraestructura validando la firma y el vencimiento de JWT. Luego, la aplicación utiliza la identidad autenticada para limitar el acceso a los datos de los pedidos, reseñas y devoluciones de ese cliente específico, de modo que un usuario no pueda acceder a los datos de otro usuario. El diseño sin servidor se escala según la demanda y los contenedores sin estado se distribuyen entre zonas de disponibilidad.
Tutorial técnico
En esta sección, analizamos los componentes clave del servidor MCP de comercio electrónico, desde la estructura del proyecto y las definiciones de herramientas hasta la autenticación y la implementación en Amazon Bedrock AgentCore.
organización del proyecto
Puede encontrar el código fuente completo y la implementación detallada en este repositorio de GitHub. Tres componentes principales trabajan juntos para formar el servidor MCP:
La aplicación del servidor MCP se encuentra en el directorio mcp_server/ y contiene la lógica empresarial principal. server.py define las seis herramientas de comercio electrónico que utilizan decoradores FastMCP y configura el transporte HTTP. utils/auth.py maneja la extracción de identidad del cliente a partir de tokens JWT. utils/dynamodb_client.py proporciona una interfaz limpia para las cinco tablas de DynamoDB y maneja operaciones comunes como búsqueda de productos, creación de pedidos y consultas de revisión. El código de infraestructura en ecommerce-mcp-cdk/ define los recursos de AWS mediante pilas de CDK. La pila de DynamoDB crea cinco tablas con índices apropiados para consultas eficientes. La pila de Cognito proporciona al grupo de usuarios atributos personalizados y dos clientes OAuth, uno para acceso API general y otro configurado específicamente para Mistral AI Studio. La pila DataLoader siembra la base de datos con datos de prueba realistas en la primera implementación. La pila AgentCoreRuntime crea la función de ejecución de IAM con los permisos adecuados para DynamoDB, Cognito y Amazon CloudWatch, aprovisiona el repositorio de ECR para imágenes de contenedores y almacena valores de configuración en SSM Parameter Store como referencia durante la implementación. La configuración de implementación se captura en .bedrock_agentcore.yaml, que se genera mediante el comando de configuración de agentcore. Este archivo le indica a AgentCore dónde encontrar el grupo de usuarios de Cognito para la validación JWT, qué ID de cliente están autorizados para conectarse y qué encabezados de solicitud deben reenviarse a la aplicación.
Definición de herramientas MCP
Las herramientas MCP se definen como funciones de Python decoradas con @mcp.tool(). Los parámetros de la función, las sugerencias de tipo y la cadena de documentación se convierten en el esquema de la herramienta. El modelo de IA lee este esquema para decidir cuándo y cómo llamar a cada herramienta.
A continuación se muestra un ejemplo que muestra cómo se define la herramienta de historial de pedidos con autenticación:
Esta herramienta demuestra varios patrones importantes. La cadena de documentación indica claramente "REQUIERE AUTENTICACIÓN" para que el modelo de IA comprenda que esta herramienta necesita un usuario que haya iniciado sesión. Las primeras líneas verifican la identidad del cliente e inmediatamente devuelven un error si el usuario es anónimo. Esta es una defensa en profundidad a pesar de que AgentCore Runtime ya ha validado el JWT en la capa de infraestructura. La respuesta enriquece los datos del pedido al unirse con la información del producto, devolviendo identificaciones legibles por máquina y etiquetas amigables para los humanos para que el modelo de IA pueda generar respuestas en lenguaje natural sin realizar llamadas adicionales.
Usted configura el servidor para operación sin estado, lo que AgentCore requiere para el equilibrio de carga:
Autenticación de dos capas
La autenticación se divide en dos capas, cada una con una responsabilidad específica. AgentCore Runtime posee validación criptográfica. El código de la aplicación solo necesita convertir el token validado en una identidad de cliente.
En la capa de infraestructura, AgentCore Runtime valida cada JWT antes de que llegue a la aplicación. Verifica la firma criptográfica con las claves públicas de Cognito y verifica el emisor, el vencimiento y la ID del cliente con la lista permitida. Los tokens no válidos se rechazan inmediatamente. El código de la aplicación no se ejecuta para solicitudes no autenticadas.
En la capa de aplicación, el servidor resuelve el JWT validado en una identidad de cliente. Dado que los tokens de OAuth 2.1 no incluyen atributos personalizados en su carga útil, el servidor llama a Cognito para recuperar el custom:customer_id que vincula al usuario con sus datos de comercio electrónico. Utiliza un enfoque de método dual para manejar diferentes tipos de tokens:
El método principal decodifica la carga útil de JWT para extraer el nombre de usuario y el ID del grupo de usuarios, luego llama a admin_get_user() usando permisos de IAM. Este enfoque maneja tokens OAuth 2.1 de Mistral Le Chat. El método alternativo llama a get_user() directamente cuando los tokens incluyen el alcance del administrador. Una vez recuperado, el ID del cliente se almacena en el contexto de la solicitud y lo utilizan herramientas autenticadas para limitar las operaciones de la base de datos a los datos de ese usuario.
Nota: AgentCore Identity admite reclamos personalizados en tokens JWT, que pueden reenviar atributos como customer_id directamente a su aplicación sin una llamada API adicional. Para obtener más información, consulte Configuración de OAuth para AgentCore Runtime y Inbound JWT Authorizer. En su lugar, esta publicación utiliza el enfoque explícito admin_get_user(), porque funciona con proveedores de identidad compatibles con OpenID Connect (OIDC) y muestra el flujo de autenticación completo paso a paso.
Flujo de trabajo de implementación
La implementación del servidor MCP implica cuatro pasos: aprovisionamiento de infraestructura, creación de usuarios, configuración de AgentCore e implementación de contenedores.
El aprovisionamiento de infraestructura utiliza AWS CDK para crear los recursos necesarios. Al ejecutar cdk implementar –all desde el directorio ecommerce-mcp-cdk se implementan cuatro pilas en secuencia. La implementación tarda unos 5 minutos y genera los valores necesarios para los siguientes pasos. Estos incluyen el ARN del rol de IAM, el URI del repositorio de ECR, la URL de descubrimiento de Cognito y los ID de cliente. Estos valores también se almacenan en SSM Parameter Store para una recuperación rápida.
La creación de usuarios genera cuentas de demostración en el grupo de usuarios de Cognito. El script create_cognito_users.py crea diez usuarios de prueba (demo1@example.com a demo10@example.com) y asigna a cada uno un ID de cliente único que los vincula a sus pedidos y reseñas en DynamoDB.
La configuración de AgentCore le indica al tiempo de ejecución cómo validar tokens y reenviar solicitudes. El comando de configuración de agentcore crea el archivo .bedrock_agentcore.yaml con la configuración necesaria:
Los elementos de configuración clave en el archivo YAML generado son:
DiscoveryUrl apunta al punto final de configuración OIDC de Cognito, donde AgentCore recupera las claves públicas para la verificación JWT. La lista de clientes permitidos restringe el acceso a clientes OAuth autorizados. requestHeaderAllowlist le dice a AgentCore que reenvíe el encabezado de Autorización a la aplicación. Sin esta configuración, las solicitudes parecerían anónimas.
La implementación de contenedores utiliza el comando de implementación agentcore, que organiza una compilación e implementación basadas en la nube. AgentCore crea un proyecto de CodeBuild en su cuenta de AWS, carga su código fuente en Amazon Simple Storage Service (Amazon S3) y crea una imagen de Docker ARM64 en CodeBuild. No necesita que Docker esté instalado localmente. Luego, AgentCore envía la imagen a ECR y llama a la API de Bedrock AgentCore para crear e iniciar el tiempo de ejecución. La primera invocación tiene un inicio en frío de 10 a 20 segundos mientras se inicializa el contenedor. Las solicitudes posteriores dentro de la sesión responden en milisegundos.
El diagrama de flujo completo
El diagrama demuestra cómo funciona la solución en cuatro fases distintas.
Figura 2. Arquitectura de cuatro fases que muestra la configuración única, el flujo de conexión OAuth 2.1 y la autenticación por solicitud
Durante la fase de configuración, un desarrollador ejecuta cdk implementar para crear los recursos de AWS. Estos incluyen el grupo de usuarios de Cognito, clientes de aplicaciones OAuth, cinco tablas de DynamoDB, roles de IAM y parámetros de SSM. Luego, el desarrollador configura AgentCore Runtime con el grupo de usuarios de Cognito y los ID de clientes autorizados, y ejecuta la implementación de agentcore para construir e implementar el contenedor del servidor MCP.
La fase de conexión ocurre una vez por sesión de usuario. El usuario abre Vibe, agrega un conector MCP personalizado con OAuth 2.1 e ingresa la URL del servidor AgentCore y las credenciales de OAuth. Cuando hacen clic en Conectar, Mistral descubre el proveedor de identidad de Cognito y abre una ventana emergente en el navegador para iniciar sesión. Después de que el usuario se autentica, Cognito emite un token JWT Bearer que Mistral almacena y actualiza automáticamente durante la sesión.
La fase de descubrimiento también ocurre una vez por sesión, inmediatamente después de la autenticación. Mistral envía una solicitud list_tools() a AgentCore con el token de portador. AgentCore valida el JWT y reenvía la solicitud al servidor MCP, que devuelve las seis herramientas disponibles y sus esquemas de parámetros. Mistral ahora sabe qué operaciones admite el servidor y qué argumentos acepta cada herramienta.
La fase de Solicitud ocurre con cada interacción. Cuando un usuario pregunta "¿Qué productos electrónicos hay en stock por menos de $500?", Mistral envía una solicitud MCP a AgentCore con el token JWT. AgentCore valida el token con Cognito verificando la firma, el vencimiento y la autorización del cliente. Una vez validada, la solicitud llega al servidor MCP. El servidor extrae la identidad del cliente de Cognito, consulta a DynamoDB los datos solicitados destinados a ese cliente y devuelve resultados formateados. Luego, Mistral genera una respuesta en lenguaje natural para el usuario.
Esta arquitectura separa la implementación de la autenticación en tiempo de ejecución, valida los tokens en la capa de infraestructura, descubre las herramientas disponibles antes de la primera solicitud y limita el acceso a los datos al cliente autenticado.
Mejores prácticas para la implementación de MCP
Las siguientes pautas cubren la construcción y protección de su servidor MCP en Amazon Bedrock AgentCore y su conexión segura a Mistral Vibe.
Construyendo servidores MCP con AgentCore
Al crear servidores MCP para su implementación en Amazon Bedrock AgentCore, concéntrese en un diseño claro de herramientas, seguridad en capas y operaciones listas para producción.
Escriba descripciones de herramientas que ayuden a los modelos de IA a llamar a la función correcta
Los modelos de IA dependen en gran medida de las descripciones de las herramientas a la hora de decidir qué función llamar. La documentación clara y explícita en la cadena de documentación de su herramienta afecta directamente la precisión con la que el modelo selecciona e invoca las herramientas.
Limite el número de herramientas por servidor: mantenga cada servidor enfocado con entre 5 y 8 herramientas bien definidas en lugar de docenas de funciones superpuestas. Cada herramienta adicional aumenta la complejidad de la decisión del modelo. Si necesita más operaciones, divídalas en varios servidores MCP agrupados por dominio (por ejemplo, un servidor para la gestión de pedidos y otro para el catálogo de productos). Los clientes de IA como Vibe pueden conectarse a varios servidores en una sola sesión. Guía explícita de parámetros: incluya ejemplos en cadenas de documentación ("por ejemplo, 'computadora portátil', 'auriculares inalámbricos'") y mencione errores comunes ("NO pase 'en stock' como texto de consulta, use el parámetro in_stock_only"). Devuelva respuestas estructuradas: incluya identificadores legibles por máquina (order_id, product_id) y etiquetas legibles por humanos (product_name, status) para que el modelo pueda generar respuestas naturales sin llamadas de seguimiento.
Implementar seguridad en capas
AgentCore Runtime valida los JWT en la capa de infraestructura, pero las comprobaciones a nivel de aplicación son igualmente importantes para una defensa en profundidad.
Validar a nivel de herramienta: verifique la identidad del usuario al inicio de cada función protegida, aunque AgentCore Runtime bloquee las solicitudes no autenticadas en el borde. Devuelve mensajes de error claros para usuarios anónimos. Verifique la propiedad de los datos: antes de las mutaciones, confirme que el recurso pertenece al usuario autenticado (por ejemplo, verifique que order.customer_id coincida con el customer_id del token) para evitar el acceso no autorizado. Aplicar IAM con privilegios mínimos: alcance la función de ejecución de AgentCore Runtime para acciones específicas en recursos específicos. Otorgue solo GetItem, PutItem y Query en ARN de tablas con nombre, sin permisos comodín. Haga cumplir los límites de las llamadas a herramientas con la política AgentCore: utilice la política AgentCore para interceptar las llamadas a las herramientas antes de que se ejecuten. Defina reglas que validen qué herramientas se pueden llamar, verifique que los parámetros se encuentren dentro de rangos aceptables (por ejemplo, limite la cantidad de 1 a 100 al realizar el pedido) y rechace las llamadas que queden fuera de los límites definidos. Utilice AgentCore Gateway para la administración de API: coloque AgentCore Gateway frente a su tiempo de ejecución para administrar la limitación de velocidad, el enrutamiento de solicitudes y controles de acceso adicionales en la capa API. Descope tokens antes de pasarlos a las herramientas: al reenviar un JWT a una herramienta, elimínelo solo para las reclamaciones que la herramienta necesita. No pase el token completo con todos los ámbitos y atributos. Esto sigue el principio de privilegio mínimo para la propagación de tokens y limita la exposición si una herramienta se ve comprometida.
Construido para operaciones de producción.
AgentCore Runtime administra la orquestación de contenedores, pero el código de su servidor debe admitir una implementación y resolución de problemas confiables.
Configure el modo sin estado: establezca stateless_http=True en mcp.http_app() para que AgentCore pueda distribuir solicitudes entre instancias de contenedor sin afinidad de sesión. Implemente infraestructura como código: use CDK o Terraform para hacer que toda su pila sea reproducible. Incluya la configuración de RemovalPolicy adecuada para entornos de desarrollo y producción. Semilla con datos de prueba realistas: incluya un cargador de datos que rellene tablas con registros representativos para que pueda validar el comportamiento de la herramienta inmediatamente después de la implementación.
Conexión de servidores MCP a Mistral Vibe
Al conectar servidores MCP a Mistral Vibe, verifique que cada servidor sea confiable, esté autenticado correctamente y tenga alcance solo los permisos que necesita.
Agregue solo servidores MCP confiables
Recomendamos encarecidamente conectarse solo a sus propios servidores MCP o a servidores confiables y bien documentados, especialmente para herramientas que pueden ejecutar código o acceder a sistemas confidenciales.
Como ocurre con cualquier servicio web, la seguridad del servidor MCP comienza con los conceptos básicos de seguridad. Un buen servidor debería:
Requerir autenticación sólida (OAuth, tokens que caducan). Haga cumplir reglas de autorización claras. Utilice conexiones seguras y manejo de sesiones para evitar el secuestro.
Antes de otorgarle a un conector acceso a sus datos confidenciales, asegúrese de que el servidor MCP pase esta verificación básica.
Hay varias formas en que un servidor MCP malicioso puede engañarlo para que cause problemas:
Inyección rápida: los comandos ocultos o las instrucciones integradas en las descripciones de las herramientas o los metadatos pueden engañar al modelo para que realice acciones no deseadas. Observación de herramientas y ocupación de errores tipográficos: las herramientas maliciosas o similares con nombres similares pueden anular silenciosamente las legítimas, lo que genera llamadas inesperadas a herramientas y comportamientos no deseados. Sobreexposición: otorgar más acceso o funcionalidad de la necesaria aumenta la superficie de amenazas sin ningún beneficio. Escalada de privilegios a través del reenvío de tokens: pasar el JWT completo del usuario a una herramienta le otorga a esa herramienta los privilegios completos del usuario. Una herramienta comprometida podría acceder a recursos más allá de su alcance. Pase sólo las afirmaciones mínimas que cada herramienta necesita.
Incluso una herramienta aparentemente inofensiva puede convertirse en un riesgo para la seguridad si es engañosa y se le ha dado suficiente acceso a sus flujos de trabajo. Por supuesto, esta preocupación no se aplica en el caso del servidor MCP de comercio electrónico que estamos construyendo nosotros mismos.
Tenga en cuenta que si forma parte de un plan empresarial de Vibe, solo permitimos que los administradores del plan agreguen conectores personalizados para evitar los tipos de problemas de seguridad documentados en la sección anterior.
Controlar la cantidad de conectores MCP habilitados
Agregar conectores en Vibe amplía lo que pueden hacer sus modelos Mistral, pero también introduce compensaciones. Cada nuevo Conector añade complejidad que el modelo debe gestionar. Algunos conectores exponen decenas de funciones. Con sólo 10 conectores activos, es posible que el modelo tenga que elegir entre más de 150 funciones posibles antes de decidir a cuál llamar.
Más conectores pueden generar una mayor probabilidad de error, ya que cada integración adicional aumenta la probabilidad de parámetros mal configurados, llamadas a herramientas o funciones incorrectas o comportamientos inesperados. Siempre que sea posible, recomendamos limitar a 5 o 6 conectores activos a la vez.
Crea indicaciones de limpieza
Incluso con los conectores adecuados, la calidad de la salida depende en gran medida de la calidad de la entrada.
Las indicaciones ambiguas conducen a un rendimiento deficiente. Si su solicitud es vaga, el modelo de lenguaje grande (LLM) podría malinterpretar la tarea o proporcionar resultados irrelevantes.
Para escribir mejores indicaciones en Vibe:
Nombra la herramienta y la acción explícitamente: "Buscar el informe del segundo trimestre" -> "Usar Notion para buscar el informe de ingresos del segundo trimestre" Especifica los parámetros: "Muéstrame los correos electrónicos de John" ???? "Enumerar los correos electrónicos de Gmail de John Smith en los últimos 7 días" Definir alcance/formato: "Verificar lo que está planeado para el lunes" ???? "Consulte el calendario y muestre solo los títulos de los eventos del lunes en una lista con viñetas"
Limpiar recursos
Para evitar cargos continuos, elimine los recursos creados en este tutorial. Primero, detenga AgentCore Runtime ejecutando agentcore delete –name ecommerce_mcp_server. Luego elimine las pilas de CDK ejecutando cdk destroy –all desde el directorio ecommerce-mcp-cdk. Esto elimina las tablas de Amazon DynamoDB, el grupo de usuarios de Amazon Cognito, los roles de IAM, el repositorio de Amazon ECR y los recursos relacionados. Las tablas de DynamoDB usan RemovalPolicy.DESTROY, por lo que se eliminan automáticamente. Verifique que los recursos se hayan eliminado consultando la consola de AWS CloudFormation.
Conclusión
Esta publicación de blog explicó la creación de un servidor MCP de comercio electrónico listo para producción utilizando Amazon Bedrock AgentCore, Amazon DynamoDB y Amazon Cognito, y luego conectándolo a Vibe de Mistral AI. Cubrimos cómo definir herramientas MCP con documentación clara compatible con IA, implementar autenticación de dos capas donde AgentCore valida tokens JWT a nivel de infraestructura mientras la aplicación aplica reglas de propiedad de datos, implementar la solución utilizando infraestructura CDK como código y establecer mejores prácticas tanto para el desarrollo del servidor como para la integración del cliente. El código fuente completo, los scripts de implementación y la guía paso a paso están disponibles en este repositorio de Github.
Los patrones de esta solución se aplican a otros dominios. Si es nuevo en MCP, clone el repositorio e implemente el servidor de comercio electrónico tal como está. Experimente con las herramientas de Vibe para ver cómo funcionan los ciclos de solicitud y respuesta de MCP. Luego modifique una sola herramienta para devolver datos de su propio sistema. Si ya ejecuta cargas de trabajo en AgentCore Runtime, reemplace las herramientas de comercio electrónico con operaciones específicas de su dominio, como una herramienta de atención al cliente que consulta una base de datos de tickets o una herramienta de servicios financieros que recupera registros de transacciones. Si se está preparando para la producción, agregue paneles de Amazon CloudWatch para conocer la latencia de las solicitudes y las tasas de error, integre AWS WAF para un filtrado de solicitudes adicional y utilice Amazon EventBridge para activar notificaciones sobre eventos de pedidos.
Para explorar soluciones relacionadas, consulte AWS para agentes autónomos para conocer patrones de arquitectura de agentes más amplios, la documentación de Amazon Bedrock AgentCore para funciones avanzadas como persistencia de memoria y aplicación de políticas, y las guías de integración de Mistral AI para conectar herramientas empresariales adicionales a Vibe. Para conocer los servicios de AWS utilizados en esta publicación, consulte la Guía para desarrolladores de Amazon DynamoDB, la Guía para desarrolladores de Amazon Cognito, la Guía para desarrolladores de AWS CDK, la documentación de FastMCP y la especificación del Protocolo de contexto del modelo. Nos encantaría saber cómo utiliza MCP y AgentCore Runtime en sus aplicaciones. Comparta sus experiencias en los comentarios o comuníquese con el equipo de servicios de IA de AWS.
Sobre los autores
Ying Hou, doctorado
Ying es arquitecto senior de soluciones especializado en Amazon Web Services, centrado en infraestructuras y marcos de IA generativa. Con sede en Londres, trabaja con clientes para entrenar previamente, post-entrenar y alojar grandes modelos de lenguaje para inferencia utilizando la infraestructura de AWS, con una profunda experiencia en Amazon SageMaker HyperPod. Ying ayuda a las organizaciones a diseñar y optimizar sus cargas de trabajo de inferencia y capacitación de aprendizaje automático a escala, lo que les permite aprovechar al máximo los clústeres de GPU, la capacitación distribuida y el servicio eficiente de modelos en AWS.
Samuel Barry
Samuel es científico aplicado en Mistral AI, donde lidera iniciativas posteriores a la capacitación para modelos de lenguaje de frontera con un enfoque en la generación de datos sintéticos, evaluación, escalamiento de modelos, ajuste fino supervisado y aprendizaje por refuerzo. Su trabajo abarca tanto el desarrollo de modelos internos como la participación estratégica de los clientes, contribuyendo a los avances en la IA multimodal, la alineación y la seguridad, al tiempo que ayuda a implementar sistemas de IA de vanguardia en aplicaciones del mundo real.
Siddhant Waghjale
Siddhant es científico aplicado en Mistral AI y trabaja en la capacitación previa y posterior para modelos de lenguaje con un enfoque en casos de uso de código y ciberseguridad. Su trabajo abarca SFT, RL y canales de generación de entornos de construcción para producir datos de entrenamiento en una variedad de tareas.