Summary: Amazon Bedrock AgentCore can host MCP Apps so AI hosts render interactive HTML widgets from a model tool response. A tool call runs through AgentCore Gateway and runtime to business logic, then the host retrieves widget HTML and injects structured content in a sandboxed iframe. The article recommends widgets only for interactive flows while leaving simple tools text-only.
MCP Apps takes the Model Context Protocol further by adding interactive HTML widgets that AI hosts such as ChatGPT and Claude render in place. For product builders this solves a genuine problem: more and more users reach services through an AI host, yet a text-only response caps what you can offer them. Amazon Bedrock AgentCore supplies the runtime and the gateway needed to host these apps, with no infrastructure to run yourself and no coupling to one host.
Two phases behind every request
Ask an AI host to “show all unicorns” and the host turns that phrasing into an MCP tools/call message. AgentCore Gateway forwards it to the AgentCore runtime, where your MCP server lives. That server hands the business logic to a Lambda function and returns whatever comes back. When the tool has a widget resource URI attached, the host follows up with a separate resources/read request to pull down the self-contained HTML. It then paints that HTML inside a sandboxed iframe and injects the structured data carried by the tool response.
Widgets are not for every tool. In the sample Unicorn Rentals app, view_bookings and return_unicorn answer with plain text, because a rich interface would add nothing there. The list_unicorns tool, by contrast, maps to a unicorn-list resource that draws interactive cards showing images, names, hourly rates, and availability.
Inside the MCP server
The sample is a TypeScript application sitting on the official MCP SDK plus the @modelcontextprotocol/ext-apps extension. It runs as an Express.js HTTP server, managed internally by the AgentCore runtime. Tools get registered through registerAppTool, and a tool’s config may carry a _meta.ui.resourceUri field naming the widget the host should render. The data payload that ends up inside the widget travels in the structuredContent field of the tool response.
Widgets are registered as MCP resources with registerAppResource. Every resource carries a name, a URI, and a handler that hands back the HTML. Hosts find them through resources/list and retrieve them through resources/read.
Where AgentCore takes work off your hands
AgentCore runtime gives you a host that is secure, serverless, isolated per session, and natively MCP-aware. AgentCore Gateway puts it behind a single endpoint that any MCP Apps-compatible host can reach. Incoming requests pass through AWS WAF before they reach the gateway, and the gateway calls the runtime through its IAM execution role. This mirrors the pattern we described for OpenRouter’s hosted sandboxed shell: the platform absorbs the undifferentiated infrastructure, leaving you business logic and widget design.
Persistence in the sample comes from DynamoDB, while widget images are served by CloudFront backed by S3. The MCP server itself stays thin — business operations go to a Lambda function, and responses come back wrapped in MCP format.
What this means for your roadmap
MCP Apps is a standard that does not favor any one host. The same server runs in ChatGPT, in Claude, or in any other host that implements the Apps extension, so a widget built once delivers the same rich experience everywhere. The cost of that is a second response path to think through: text-only tools for simple queries, widget-backed tools for interactive flows. How caching behaves from host to host is not spelled out in the supplied source material, so measure it yourself if performance matters.
Teams already building MCP servers can treat widgets as a natural next step. Teams that are not get enough infrastructure lifted away by AgentCore that the real work becomes designing the widget HTML and choosing which tools deserve a rich interface.