Amazon Bedrock AgentCore と Mistral AI Studio を活用した、本番環境対応の EC モデルコンテキストプロトコルサーバーの構築と接続

When ecommerce teams need faster time-to-market for AI-powered customer experiences, they face weeks of custom integration work that delays launches and increases security risks. Building and connecting a production-ready AI assistant typically requires custom API code for each client, container infrastructure management, and complex authentication. Amazon Bedrock AgentCore and Mistral AI Studio streamline this process. A production-ready ecommerce Model Context Protocol (MCP) server on Amazon Bedrock AgentCore, connected to Mistral AI Studio, streamlines development. The MCP provides standardized integration protocols, AgentCore Runtime manages containers and validates tokens, and Amazon Cognito handles identity.

In this post, you build and connect that server end to end. You will implement MCP tools, set up two-layer JSON Web Token (JWT) authentication, deploy with AWS Cloud Development Kit (AWS CDK), and connect the result to Mistral AI’s Vibe. The post also covers prerequisites, solution architecture, best practices for MCP servers and Vibe connectors, and resource cleanup. The ecommerce server that you build supports product search, order placement, review submission, and returns processing using Amazon DynamoDB for data and Amazon Cognito for identity management.

Amazon Bedrock AgentCore is a platform to build, connect, and optimize AI agents at scale. Within it, AgentCore Runtime is the fully managed serverless component for hosting agent and MCP workloads, with session isolation, long-running request support, built-in JWT validation, and observability, so you don’t manage containers, load balancers, or auth middleware. In this post, you build the MCP server with Python and FastMCP, then deploy it to Runtime for managed hosting. Amazon Cognito manages user identity through OAuth 2.1, keeping each customer’s data isolated. With MCP, you write one server that multiple AI clients connect to, rather than building a separate integration for each client. Mistral AI’s Vibe gives users a conversational interface to the server on web, iOS, and Android.

By the end, you will have a working ecommerce MCP server that authenticates users through Amazon Cognito, scopes data access per customer, and responds to natural language queries from Vibe. Because the server uses the MCP standard, other MCP-compatible clients can also connect to it.

To see the solution in action, watch the following demo. Then, explore the full post for a detailed guide on implementing your own production-ready MCP server and querying it from Vibe.

Prerequisites

You need an AWS account with permissions to create Amazon DynamoDB tables (NoSQL database), Amazon Cognito user pools (user identity, OAuth 2.1), AWS Identity and Access Management (IAM) roles, and Amazon Elastic Container Registry (Amazon ECR) repositories, and to access Amazon Bedrock AgentCore (platform for building and running AI agents). For local development tools, install Python 3.10 or later, Node.js 18 or later, AWS CDK (npm install -g aws-cdk), the AWS Command Line Interface (AWS CLI) configured with credentials, and the Amazon Bedrock AgentCore CLI (pip install bedrock-agentcore). You also need a Mistral AI account with access to Vibe. Docker isn’t required because AgentCore Runtime builds container images in the cloud using AWS CodeBuild.

Solution overview

We show you how to build an ecommerce MCP server that performs real shopping operations: searching products, placing orders, submitting reviews, and processing returns. You work with three layers:

• Application layer: The MCP server is a Python application built with FastMCP, a framework for building MCP servers. It exposes six ecommerce tools through an /mcp endpoint and a /health endpoint for monitoring. AgentCore Runtime runs the server as a container.

• Data layer: Five Amazon DynamoDB tables store ecommerce data: Products, Customers, Orders, Reviews, and Returns. You provision the tables with on-demand capacity for automatic scaling. Global Secondary Indexes support efficient query patterns.

• Security layer: Two-tier authentication that keeps each customer’s data private. Amazon Cognito serves as the identity provider, AgentCore Runtime validates JWT tokens at the infrastructure level, and the application extracts user-specific attributes to scope data access to the authenticated customer.

You deploy the solution using AWS CDK with four infrastructure stacks. The DynamoDBStack creates the five data tables with indexes and configures them for straightforward teardown in development environments. The CognitoStack provisions the user pool with custom attributes for customer identification and creates OAuth 2.1 app clients configured for Mistral AI Vibe integration. The DataLoaderStack uses an AWS Lambda custom resource to seed the database with realistic test data (50 products, 10 customers, 50 orders, reviews, and returns), so you can test the server immediately after deployment. The AgentCoreRuntimeStack creates an IAM role with the required permissions, provisions an ECR repository for the container image, and stores configuration parameters that the deployment command references.

Figure 1. Request flow architecture for the ecommerce MCP server

The diagram illustrates the request flow when a user interacts with the ecommerce MCP server through Mistral Vibe. Before the first request, the user authenticates through an OAuth 2.1 login flow: Vibe opens a Cognito-hosted login page, the user enters their credentials, and Cognito issues a JWT token that Vibe stores for the session. When a user asks, “Show me my recent orders,” the AI model determines it needs to call the get_order_history MCP tool and sends an MCP request over HTTPS to the AgentCore endpoint. The request includes the Bearer JWT token from the OAuth 2.1 login flow. Before reaching the application code, AgentCore’s JWT Validator verifies the token with Cognito User Pool. It checks the signature, expiration, and client authorization, then rejects invalid tokens. Once validated, the request reaches the MCP Server container, which calls Cognito to retrieve the customer ID attribute that links the authenticated user to their ecommerce profile. With the customer identity confirmed, the server queries the relevant DynamoDB tables. The operation is scoped to only that customer’s data to enforce privacy and isolation. The server then sends the structured response back through AgentCore to Vibe, which generates a natural language answer like “You have 2 recent orders: Order #1234 for Wireless Headphones (delivered) and Order #1236 for Laptop Stand (processing).”

This architecture uses layered security. AgentCore Runtime authenticates requests at the infrastructure layer by validating the JWT signature and expiration. The application then uses the authenticated identity to scope data access to that specific customer’s orders, reviews, and returns, so one user can’t access another user’s data. The serverless design scales based on demand, and stateless containers distribute across availability zones.

Technical walkthrough

In this section, we walk through the key components of the ecommerce MCP server, from project structure and tool definitions to authentication and deployment on Amazon Bedrock AgentCore.

Project organization

You can find the complete source code and detailed implementation at this GitHub repo. Three main components work together to form the MCP server:

• The MCP server application lives in the mcp_server/ directory and contains the core business logic. server.py defines the six ecommerce tools using FastMCP decorators and configures the HTTP transport. utils/auth.py handles customer identity extraction from JWT tokens. utils/dynamodb_client.py provides a clean interface to the five DynamoDB tables, handling common operations like product search, order creation, and review queries.

• The infrastructure code in ecommerce-mcp-cdk/ defines the AWS resources using CDK stacks. The DynamoDB stack creates five tables with appropriate indexes for efficient queries. The Cognito stack provisions the user pool with custom attributes and two OAuth clients, one for general API access and one specifically configured for Mistral AI Studio. The DataLoader stack seeds the database with realistic test data on first deployment. The AgentCoreRuntime stack creates the IAM execution role with appropriate permissions for DynamoDB, Cognito, and Amazon CloudWatch, provisions the ECR repository for container images, and stores configuration values in SSM Parameter Store for reference during deployment.

• The deployment configuration is captured in .bedrock_agentcore.yaml, which is generated by the agentcore configure command. This file tells AgentCore where to find the Cognito user pool for JWT validation, which client IDs are authorized to connect, and which request headers should be forwarded to the application.

Defining MCP tools

You define MCP tools as Python functions decorated with @mcp.tool(). The function’s parameters, type hints, and docstring become the tool schema. The AI model reads this schema to decide when and how to call each tool.

Here’s an example showing how the order history tool is defined with authentication:

@mcp.tool()
def get_order_history(limit: int = 10) -> dict:
    """
    Get order history for the authenticated user.

    REQUIRES AUTHENTICATION - Pass Authorization header.

    Args:
        limit: Maximum number of orders to return

    Returns:
        List of past orders with status, product details, and pricing
    """
    customer_id = get_current_customer_id()
    if customer_id == 'anonymous':
        return {"success": False, "error": "Authentication required"}

    try:
        orders = db.get_customer_orders(customer_id, limit=limit)
        # Enrich orders with product names
        enriched_orders = []
        for order in orders:
            product_id = order.get('product_id')
            if product_id:
                product = db.get_product(product_id)
                if product:
                    order['product_name'] = product.get('name', 'Unknown Product')
                    order['product_category'] = product.get('category', 'Unknown')
            enriched_orders.append(order)
        return {"success": True, "order_count": len(enriched_orders), "orders": enriched_orders}
    except Exception as e:
        return {"success": False, "error": str(e)}

This tool demonstrates several important patterns. The docstring clearly states “REQUIRES AUTHENTICATION” so the AI model understands this tool needs a logged-in user. The first lines check the customer identity and immediately return an error if the user is anonymous. This is defense in depth even though AgentCore Runtime has already validated the JWT at the infrastructure layer. The response enriches order data by joining with product information, returning both machine-readable IDs and human-friendly labels so the AI model can generate natural language responses without making additional calls.

You configure the server for stateless operation, which AgentCore requires for load balancing:

mcp = FastMCP("ecommerce-mcp-server")
mcp_app = mcp.http_app(path="/mcp", stateless_http=True)

Two-layer authentication

You split authentication across two layers, each with a specific responsibility. AgentCore Runtime owns cryptographic validation. The application code only needs to resolve the validated token into a customer identity.

At the infrastructure layer, AgentCore Runtime validates every JWT before it reaches the application. It verifies the cryptographic signature against Cognito’s public keys and checks the issuer, expiry, and client ID against the allowed list. Invalid tokens are rejected immediately. The application code doesn’t run for unauthenticated requests.

At the application layer, the server resolves the validated JWT into a customer identity. Since OAuth 2.1 tokens don’t include custom attributes in their payload, the server calls Cognito to retrieve the custom:customer_id that links the user to their ecommerce data. It uses a dual-method approach to handle different token types:

def extract_customer_id_from_token(access_token: str) -> Optional[str]:
    """
    Extract custom:customer_id from a Cognito access token.

    Handles OAuth 2.1 tokens using AdminGetUser via IAM.
    """
    cognito = boto3.client('cognito-idp', region_name=AWS_REGION)

    # Primary method: AdminGetUser for OAuth 2.1 Authorization Code tokens
    try:
        payload = _decode_jwt_payload(access_token)
        username = payload.get('username') or payload.get('sub')
        user_pool_id = payload.get('iss', '').rstrip('/').split('/')[-1]

        if username and user_pool_id:
            user_info = cognito.admin_get_user(
                UserPoolId=user_pool_id,
                Username=username
            )
            for attr in user_info['UserAttributes']:
                if attr['Name'] == 'custom:customer_id':
                    return attr['Value']
    except (ClientError, Exception):
        pass

    # Fallback method: get_user() for token types with admin scope
    try:
        user_info = cognito.get_user(AccessToken=access_token)
        for attr in user_info['UserAttributes']:
            if attr['Name'] == 'custom:customer_id':
                return attr['Value']
    except ClientError:
        pass

    return None

The primary method decodes the JWT payload to extract the username and user pool ID, then calls admin_get_user() using IAM permissions. This approach handles OAuth 2.1 tokens from Mistral Le Chat. The fallback method calls get_user() directly when tokens include admin scope. After it’s retrieved, the customer ID is stored in request context and used by authenticated tools to scope database operations to that user’s data.

Note: AgentCore Identity supports custom claims in JWT tokens, which can forward attributes like customer_id directly to your application without an additional API call. For more information, see Configuring OAuth for AgentCore Runtime and Inbound JWT Authorizer. This post uses the explicit admin_get_user() approach instead, because it works with OpenID Connect (OIDC)-compatible identity providers and shows the full authentication flow step by step.

Deployment workflow

Deploying the MCP server involves four steps: infrastructure provisioning, user creation, AgentCore configuration, and container deployment.

Infrastructure provisioning uses AWS CDK to create the required resources. Running cdk deploy --all from the ecommerce-mcp-cdk directory deploys four stacks in sequence. The deployment takes about 5 minutes and outputs the values needed for the next steps. These include the IAM role ARN, ECR repository URI, Cognito discovery URL, and client IDs. These values are also stored in SSM Parameter Store for quick retrieval.

User creation seeds the Cognito user pool with demo accounts. The create_cognito_users.py script creates ten test users (demo1@example.com through demo10@example.com) and assigns each a unique customer ID that links them to their orders and reviews in DynamoDB.

AgentCore configuration tells the runtime how to validate tokens and forward requests. The agentcore configure command creates the .bedrock_agentcore.yaml file with the necessary settings:

agentcore configure \
  -e server.py \
  -p MCP \
  -n ecommerce_mcp_server \
  -er $ROLE_ARN \
  -ecr $ECR_URI \
  -ac '{"customJWTAuthorizer":{"discoveryUrl":"$DISC_URL","allowedClients":["$CLIENT_ID","$MISTRAL_CLIENT_ID"]}}' \
  -rha "Authorization" \
  -r us-west-2 \
  --non-interactive

The key configuration elements in the generated YAML file are:

authorizer_configuration:
  customJWTAuthorizer:
    discoveryUrl: https://cognito-idp.us-west-2.amazonaws.com/us-west-2_xxxxx/.well-known/openid-configuration
    allowedClients:
      - xxxxxxxxxxxxxxxxxxxxxxxxxx  # mcp-client
      - yyyyyyyyyyyyyyyyyyyyyyyyyy  # mistral-oauth-client
request_header_configuration:
  requestHeaderAllowlist:
    - Authorization

The discoveryUrl points to Cognito’s OIDC configuration endpoint, where AgentCore fetches the public keys for JWT verification. The allowedClients list restricts access to authorized OAuth clients. The requestHeaderAllowlist tells AgentCore to forward the Authorization header to the application. Without this setting, requests would appear anonymous.

Container deployment uses the agentcore deploy command, which orchestrates a cloud-based build and deployment. AgentCore creates a CodeBuild project in your AWS account, uploads your source code to Amazon Simple Storage Service (Amazon S3), and builds an ARM64 Docker image in CodeBuild. You don’t need Docker installed locally. AgentCore then pushes the image to ECR and calls the Bedrock AgentCore API to create and start the runtime. The first invocation has a cold start of 10 to 20 seconds while the container initializes. Subsequen