Amazon Bedrock introduces new capabilities for agent interaction

Amazon Bedrock has introduced new stateful MCP client capabilities on the AgentCore Runtime platform, enabling interactive multi-turn agent workflows that were previously impossible with stateless implementations. Developers building AI agents often face challenges when their workflows need to pause mid-execution to ask users for clarification, request large language model (LLM)-generated content, or provide real-time progress updates during long-running operations. Stateless MCP servers cannot handle these scenarios.

The introduction of three new capabilities from the MCP specification addresses these limitations. These capabilities include Elicitation (requesting user input mid-execution), Sampling (requesting LLM-generated content from the client), and Progress Notification (streaming real-time updates). These features transform one-way tool execution into bidirectional conversations between your MCP server and clients.

The Model Context Protocol (MCP) is an open standard defining how LLM applications connect with external tools and data sources. The specification outlines server capabilities (tools, prompts, and resources exposed by servers) and client capabilities (features clients offer back to servers). While the previous release focused on hosting stateless MCP servers on AgentCore Runtime, this new capability completes the implementation of the bidirectional protocol.

Clients connecting to AgentCore-hosted MCP servers can now respond to server-initiated requests. In this post, you will learn how to build stateful MCP servers that request user input during execution, invoke LLM sampling for dynamic content generation, and stream progress updates for long-running tasks. You will see code examples for each capability and deploy a working stateful MCP server to Amazon Bedrock AgentCore Runtime.

The original MCP server support on AgentCore used stateless mode, where each incoming HTTP request was independent, with no shared context between calls. This model is straightforward to deploy and reason about, and it works well for tool servers that receive inputs and return outputs. However, it has a fundamental constraint: the server cannot maintain a conversation thread across requests, ask the user for clarification in the middle of a tool call, or report progress back to the client as work happens.