Amazon Bedrock AgentCore Hosts MCP Apps With Interactive HTML Widgets

Amazon has published a reference architecture and working sample demonstrating how to build and deploy interactive Model Context Protocol (MCP) applications on Amazon Bedrock AgentCore — a platform that handles scaling, session isolation, and health monitoring so developers can focus on protocol adapter code and widget design. As AI hosts like ChatGPT and Claude become primary interfaces for end users, services that return only plain text are structurally disadvantaged against those that render rich, interactive HTML inline. This pattern closes that gap without coupling deployment to any single host.

The timing matters for teams already navigating production AI failures rooted in architecture rather than model capability. The MCP Apps extension addresses a concrete structural gap — no standardised mechanism previously existed for MCP servers to negotiate widget rendering across heterogeneous hosts — and AgentCore provides the managed infrastructure layer that makes it viable at scale.

Architecture: thin protocol adapter over existing services

The reference application, Unicorn Rentals, exposes four MCP tools — list_unicorns, book_unicorn, view_bookings, and return_unicorn — and two widget resources: unicorn-list and booking-confirmation. The MCP server is a TypeScript application built on @modelcontextprotocol/sdk with the @modelcontextprotocol/ext-apps extension, running as an Express.js HTTP server that AgentCore runtime manages internally.

Business logic is isolated in a dedicated AWS Lambda function that performs DynamoDB reads and writes. The MCP server acts as a protocol adapter only. In production, this Lambda can be replaced with existing services running on Amazon ECS or Amazon EKS — any backend reachable via HTTP or an SDK client. Widget HTML is served as self-contained MCP resources with ui://widget/ URIs. Tools that return text-only responses — view_bookings and return_unicorn — omit the _meta.ui.resourceUri field in their tool config, skipping Phase 2 widget rendering entirely. Static assets are distributed through Amazon CloudFront backed by Amazon S3.

Execution has two distinct phases. In Phase 1, an AI host translates a natural language request into an MCP tools/call message routed to the AgentCore Gateway endpoint. AWS WAF screens the request using an IP allowlist, managed threat-detection rules, and rate limiting before the Gateway invokes the AgentCore runtime via its own IAM execution role over SigV4. In Phase 2, if the tool response carries a resourceUri, the host sends an MCP resources/read request for that URI, retrieves the self-contained HTML, and renders it inside a sandboxed iframe — injecting the structured data payload from the tool response through the MCP Apps lifecycle.

Security and access control model

AgentCore runtime enforces resource-based policies that restrict invocation to the AgentCore Gateway execution role, denying all other principals. The Gateway accepts inbound requests with No Auth, handles the SigV4 credential exchange internally, and exposes a single managed endpoint to external hosts — callers never handle AWS credentials directly.

Production guidance adds two further control layers: strict JSON schema validation on tool arguments inside the MCP server, and re-validation of those arguments inside the Lambda function so business logic never trusts unvalidated input crossing the protocol boundary. For unstructured text, Amazon Bedrock Guardrails can filter harmful content, enforce topic restrictions, and redact PII before responses reach the client. This aligns with the broader recognition that infrastructure governance, not model-level guardrails, is what makes agent deployments safe.

Deployment stack

The full deployment uses AWS CDK via a single deploy.sh script. Prerequisites are Node.js 22 or higher and AWS CLI V2.0 or higher. Runtime configuration specifies the NODE_22 environment, the entry point, and MCP protocol mode — the last item activating protocol-specific runtime optimisations. Teardown is a single npx cdk destroy invocation.

AI Mastery analysis

The architectural pattern is disciplined, but its real value is in what it defers. AgentCore runtime uses consumption-based pricing on container runtime and invocations — the source material does not publish specific rates — meaning teams trading operational simplicity for cost predictability may encounter surprises at scale. Right-sizing container memory and CPU allocation and reviewing Lambda concurrency are flagged as levers, but no configuration targets or traffic volume guidance is supplied.

The more consequential observation concerns the MCP Apps extension itself. The standard governs how HTML widgets are declared, transmitted, and injected via structuredContent, but rendering fidelity depends entirely on how each AI host implements sandboxed iframe injection. ChatGPT and Claude are cited as supporting hosts, but the spec cannot guarantee visual parity when iframe sandboxing policies diverge between hosts. Developers who treat the "build once, render everywhere" claim literally will encounter host-specific rendering edge cases that MCP conformance alone cannot resolve.

The Lambda-as-thin-adapter pattern suits greenfield deployments, but teams with existing gRPC or event-driven backends face a non-trivial translation step the source material glosses over. "Standard invocation patterns like HTTP calls or SDK clients" implicitly favours REST-shaped services — the same class of architectural specificity problem that surfaces after the prototype phase ends.

The WAF IP allowlist model also grows brittle as the number of registering AI hosts increases, particularly when hosts operate from dynamic egress ranges. A token-based or OAuth model would be more maintainable at scale; the source acknowledges OAuth as a supported AgentCore runtime auth option that this solution deliberately does not activate for inbound requests.

The broader signal is that MCP is maturing from a tool-calling convention into a UI delivery substrate. AWS instrumenting AgentCore to host that substrate natively — handling session isolation, scaling, and protocol negotiation as managed infrastructure — reflects the same systems-engineering logic that makes pipeline architecture outperform raw model capability. Whether the MCP Apps extension achieves the cross-host rendering ubiquity that justifies the "build once" investment depends less on AWS than on how consistently competing AI hosts implement the sandboxed widget lifecycle.

Primary source

Build interactive MCP Apps using Amazon Bedrock AgentCore — AWS Machine Learning Blog