AWS AgentCore Runtime Hosts MCP Servers for Amazon Quick Agents

September 1, 2026news
Amazon BedrockMCPAI Agents

AWS published a step-by-step integration guide on 31 August 2026 showing how to host Model Context Protocol servers on Amazon Bedrock AgentCore Runtime and wire them into Amazon Quick chat agents and Flows. The pattern eliminates per-use-case custom connectors: once an MCP server is deployed and authenticated through AgentCore Gateway, any Quick agent or workflow can invoke its tools directly, promoting organisational reuse of AI capabilities across teams.

For developers already thinking about pipeline architecture as the primary driver of AI gains, this walkthrough is a concrete example of that thesis — the infrastructure plumbing around the model, not the model itself, determines what the agent can actually do.

Three hosting paths, one production choice

AWS surfaces three deployment options depending on existing infrastructure and reliability requirements:

Hosting path Entry point Key capabilities Integration mechanism
Existing REST API or API Gateway endpoint Your own REST API Direct API connectivity AgentCore Gateway
AWS Lambda function Serverless function Bare-minimum execution, no session state AgentCore Gateway
AgentCore Runtime Containerised MCP server Session isolation, extended execution time, persistent file systems, built-in authentication, observability, enhanced payload, bidirectional streaming, evaluations AgentCore Gateway

The Runtime path delivers the full production feature set. Prerequisites: Python 3.10 or later, the Amazon Bedrock AgentCore SDK, the MCP library at version 1.10.0 or higher, a running Docker daemon, and an Amazon Quick subscription at the Author tier or above.

MCP server implementation and container deployment

The server is minimal. Using FastMCP with stateless_http=True — required for AgentCore Runtime compatibility — the server must be reachable at 0.0.0.0:8000/mcp, the default path the Runtime expects of all MCP containers. Individual Python functions become callable MCP tools via the @mcp.tool() decorator; the server starts with transport="streamable-http".

Deployment uses the bedrock-agentcore-starter-toolkit at version 0.1.21 or higher. Running agentcore configure --entrypoint mcp_server.py --name simple_mcp_server triggers an interactive setup that auto-generates a Dockerfile, a .dockerignore, and a .bedrock_agentcore.yaml configuration file. A subsequent agentcore launch builds the container image, pushes it, and registers the Runtime endpoint. AWS resource naming is derived from the --name parameter, keeping deployment reproducible without manual container registry operations.

Authentication architecture: inbound and outbound OAuth 2.0

The auth model splits into two orthogonal flows. Inbound Auth governs whether Amazon Quick is allowed to reach AgentCore Gateway; Outbound Auth governs whether the Gateway is allowed to call the MCP server on AgentCore Runtime. Both flows use OAuth 2.0 — the only authentication protocol the MCP specification currently supports for this integration pattern.

AWS implements both through separate Amazon Cognito user pools, though any OIDC-compatible identity provider can substitute. The Inbound Auth pool issues tokens that the Gateway validates via JWT, using a discovery URL at https://cognito-idp.{REGION}.amazonaws.com/{user_pool_id}/.well-known/openid-configuration. The Outbound Auth pool authenticates machine-to-machine calls using an OAuth credential provider registered in AgentCore Identity. A single IAM role attached to the Gateway requires three permissions: bedrock-agentcore:InvokeAgentRuntime, bedrock-agentcore:InvokeRegistryMcp, and secretsmanager:GetSecretValue, scoped to the specific runtime ARN.

One non-obvious implementation detail: when constructing the Token URL for Amazon Quick's connector configuration, the underscore in the Cognito user pool ID must be removed — for example, us-west-2_qNBcTlLbR becomes us-west-2qNBcTlLbR. The Authorization URL uses the same base but replaces token with authorize. The MCP endpoint URL registered under the Gateway's Target section URL-encodes the full AgentCore Runtime ARN and appends ?qualifier=DEFAULT.

The Gateway is named ac-gateway-mcp-server in the walkthrough. The Target must use OAuth Client as its authorisation type — the Gateway rejects other methods for MCP targets. Both the Gateway and its Target must reach a Ready state before Amazon Quick connector registration can proceed.

Amazon Quick connector registration and tool surfacing

Inside Amazon Quick, the path goes through Connectors → Create for your team → Model Context Protocol (MCP). The connector accepts the Gateway's Resource URL as the MCP Server Endpoint and supports optional private VPC connectivity to restrict network exposure. Quick offers two authentication modes: User authentication for interactive, per-person identity flows, and Service authentication for programmatic integrations. The guide demonstrates User authentication via Cognito.

Once created, Quick performs an automatic listTools sync against the MCP server. Tools become available — surfaced as Actions — only after the sync reaches an Available or Ready state. Those Actions can then be linked to any Quick chat agent or Flow, giving agents direct invocation rights over the MCP tools without additional connector development. Cleanup must run in reverse creation order across seven resource categories to avoid dependency conflicts.

As agent control architectures grow more complex, standardised transport and auth contracts like MCP become load-bearing infrastructure rather than convenience features — and managed hosting that handles session isolation, streaming, and observability out of the box lowers the cost of that standardisation considerably.

Related Reading