Amazon Bedrock AgentCore Gateway の MCP サポート拡張

While deploying Model Context Protocol (MCP) servers in production, enterprises need fine-grained access control across servers, observability into which teams use which tools, security guarantees against data exfiltration, and centralized credential management, all at scale. Amazon Bedrock AgentCore Gateway sits between MCP servers and the clients that consume them, centralizing credential management, observability, and secure connectivity into a single trusted entry point.

Today, we’re extending AgentCore Gateway with new capabilities that further strengthen support for enterprise MCP deployments. This post covers extended MCP tool schema support, MCP prompts and MCP resources as first-class primitives, dynamic listing for runtime discovery of MCP servers, streaming and session management for stateful real-time interactions, elicitation for mid-execution input requests, and OAuth 2.0 on-behalf-of token exchange for delegated authentication. For hands-on examples, visit the GitHub samples repository.

Unite MCP servers for enterprise through AgentCore Gateway

Without a centralized gateway, every MCP server that your organization builds must independently handle credentials, policy enforcement, private connectivity, and logging. This means that your legal team’s contract review MCP server, your finance team’s data retrieval MCP server, and your operations team’s incident response MCP server each carry the same infrastructure burden. Security teams review each server individually, developers wait for approvals, and nobody has a unified view of how MCP infrastructure is being used across the organization.

AgentCore Gateway helps avoid this duplication by establishing a single-entry point that MCP traffic flows through. The following diagram shows the main features for AgentCore Gateway that allow central governance and control.

Each team builds only the business logic for their MCP server. AgentCore Gateway handles everything else. It aggregates capabilities across different target types, including MCP servers, REST APIs, AWS Lambda functions, and more. Resource-based policies (RBP) control who can invoke AgentCore Gateway, for example, restricting invocation to an Amazon Virtual Private Cloud (Amazon VPC). Service control policies (SCPs) govern how AgentCore Gateway is maintained within your AWS organization.

For network isolation, AgentCore Gateway supports AWS PrivateLink for both control plane and data plane operations so that traffic stays within your Amazon VPC boundaries. You can also connect to private API endpoints or MCP servers through managed VPC resource mode. Centralized application and identity logs help you manage audit and compliance requirements.

With interceptor capability, AWS Lambda functions can customize requests and responses, enabling fine-grained access control, sanitization, custom authorization logic, and more. Integration with AgentCore Policy (Preview) provides agentic guardrails defined around your tools for deterministic policy enforcement at a centralized plane. AgentCore Gateway also helps facilitate the OAuth 2.0 authorization code flow, where the agent authenticates on behalf of a user before invoking tools.

Now, you will walk through the new capabilities that we’re adding to AgentCore Gateway to further strengthen enterprise MCP support.

Surface your MCP server primitives through a single gateway

AgentCore Gateway becomes a single MCP endpoint that aggregates capabilities from every MCP server in your organization. Clients see one unified tool catalog, one prompt library, and one resource namespace, not 20 separate connections to manage. Under the hood, AgentCore Gateway supports all three MCP primitives: tools, prompts, and resources. Tool definitions in MCP include an optional outputSchema for defining expected output structure and annotations describing behavioral properties such as whether a tool is read-only or destructive, alongside the standard name, icons, description, and inputSchema. The gateway also supports prompts, resources, and resource templates through their full set of MCP methods: tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read, and resources/templates/list. The following architecture diagram shows how AgentCore Gateway facilitates list and invoke calls.

In the default listing mode, AgentCore Gateway discovers and caches tools, prompts, and resources from connected MCP server targets. This cache is implicitly refreshed whenever you call CreateGatewayTarget or UpdateGatewayTarget, and can be explicitly refreshed using the SynchronizeGatewayTargets API. When clients make list calls such as tools/list, prompts/list, or resources/list, AgentCore Gateway returns the response directly from this cache without invoking the MCP server target. The actual interaction with the MCP server target only happens during invoke operations: tools/call, prompts/get, and resources/read. At that point AgentCore Gateway routes the request to the correct target.

Tools and prompts returned by AgentCore Gateway are prefixed with the target name using the format targetName___. Unlike tools and prompts, resource URIs are returned without a target name prefix; the original URI from the downstream MCP server is passed through. When creating an MCP server target that exposes resources, you can optionally specify a resourcePriority value (1–1000) to control how AgentCore Gateway resolves conflicts when multiple targets expose the same resource URI. If no priority is defined, a default value of 1000 is applied. When a conflict occurs, AgentCore Gateway returns the resource from the target with the lowest resourcePriority value. If two conflicting resources share the same priority, the resource from the target that was synchronized first is returned.

Because resource URIs are provided by the downstream MCP server target and aren’t validated or sanitized by AgentCore Gateway, take care with untrusted targets. A malicious or compromised MCP server could return URIs pointing to internal endpoints or local file system paths. Validate and sanitize resource URIs before following them, and don’t automatically fetch or render URIs from untrusted MCP server targets.

Dynamic listing for runtime flexibility

Some MCP servers personalize their capabilities per user. A permissions-aware server might expose approve_expense only to managers, or a multi-tenant server might surface HIPAA-compliant tools only for healthcare customers. Dynamic listing lets you preserve that server-side access control while still routing through AgentCore Gateway.

When creating a target, you choose between two listing modes: *default* and *dynamic*. In default listing mode, AgentCore Gateway invokes the MCP server during CreateGatewayTarget or UpdateGatewayTarget operations to discover and cache tools, prompts, and resources. This cache can be explicitly refreshed using the SynchronizeGatewayTargets API. When clients make list calls, AgentCore Gateway serves the response directly from this cache without contacting the backend server. In dynamic listing mode, AgentCore Gateway doesn’t invoke the MCP server during CreateGatewayTarget or UpdateGatewayTarget operations. Instead, list calls are forwarded live to the MCP server at request time, using the identity of the calling user. In both modes, invoke operations such as tools/call, prompts/get, and resources/read route directly to the MCP server target. The following architecture diagram illustrates how both modes work together.

MCP Server 1 is configured with dynamic listing mode, while MCP Server 2 and 3 use default listing mode. The AgentCore Gateway cache contains only the capabilities from the default mode servers. During list calls, the response is paginated; the cached and MCP Server 1 primitives are returned on different pages. Because the primitives aren’t indexed at AgentCore Gateway for dynamic listing targets, the semantic tool search capability can’t be used.

This dual-mode architecture also gives you flexibility for multi-tenancy and fine-grained access control (FGAC). For both listing modes, you can enforce policies centrally using AgentCore Policy or AWS Lambda response interceptors to filter capabilities based on tenant identity. For example, you can restrict a tenant to only see read-only tools. For dynamic listing mode, you can manage access control directly at the MCP server itself, since list operations execute under the end user’s identity, and the MCP server target returns only the capabilities that user is authorized to access.

Streaming, session management, and elicitation

Many enterprise MCP workflows go beyond straightforward request-response tool calls. An MCP server might need to stream progress updates while generating a report, pause mid-execution to ask a user for approval before performing a sensitive action, or maintain context across a multi-step conversation that spans several tool invocations. AgentCore Gateway supports Streamable HTTP transport, MCP session management, and elicitation, which enable stateful, real-time, human-in-the-loop interactions.

Streamable HTTP

Without streaming, a tool call that takes 45 seconds returns nothing until completion, and the user stares at a spinner. With streaming, they see progress events in real time. When a client sends a tools/call request with Accept: application/json, text/event-stream, AgentCore Gateway opens an SSE stream and forwards events from the MCP server target in real time, including progress notifications, logging messages, and the final tool result. Clients that send only Accept: application/json continue to receive a single JSON response, preserving full backward compatibility.

When response streaming is enabled on AgentCore Gateway, the response interceptor behavior changes and must check the isStreamingResponse field in gatewayResponse to distinguish between streaming and non-streaming responses. The response interceptor is invoked for events that contain a JSON-RPC id field. The response interceptor isn’t invoked for notifications/progress, notifications/message, and pings. To enable streaming, set the enableResponseStreaming block during the CreateGateway or UpdateGateway API call.

"protocolConfiguration": {
  "mcp": {
    "streamingConfiguration": {
      "enableResponseStreaming": true
    }
  }
}

When thinking about streaming use cases with AgentCore Gateway, keep the following in mind. AgentCore Gateway determines the HTTP status code from the first event in the stream. If an error occurs mid-stream, it’s delivered as a JSON-RPC error object within an SSE frame rather than as an HTTP status code, since the status has already been sent. Pre-stream errors such as authentication failures, throttling, or validation errors are returned as standard JSON-RPC error responses with no SSE framing.

Session management

Session management introduces stateful multi-turn workflows to AgentCore Gateway. When you enable sessions, AgentCore Gateway generates a Mcp-Session-Id on the first initialize request and returns it as a response header. The client includes this header on subsequent requests, allowing AgentCore Gateway to track client interactions, maintain mappings to downstream MCP server sessions, and correlate elicitation requests across tool calls.

To enable sessions, add a sessionConfiguration block during the CreateGateway or UpdateGateway API call. You can configure the session timeout from a minimum of 15 minutes to a maximum of 8 hours. The default is 1 hour.

"protocolConfiguration": {
  "mcp": {
    "sessionConfiguration": {
      "sessionTimeoutInSeconds": 3600
    }
  }
}

Sessions are scoped to the authenticated user. AgentCore Gateway derives the user identity from the authorization context, the JWT bearer token for OAuth ingress or the IAM credentials for AWS_IAM ingress, and validates that every request within a session originates from the same user. This helps prevent session hijacking, where one client attempts to use another client’s session identifier. AgentCore Gateway returns HTTP 400 if a session-enabled gateway receives a request without an Mcp-Session-Id header, and HTTP 404 for expired or non-existent sessions.

Behind the scenes, AgentCore Gateway persists the session ID in a fully managed durable store to manage sessions across requests. When AgentCore Gateway receives the first tool call for a given MCP server target within a session, it initializes a connection to that target, negotiates capabilities on behalf of the client, and stores the target session identifier. Subsequent tool calls to the same target within the session reuse this mapping, avoiding repeated initialization overhead. Because of this behavior, AgentCore Runtime doesn’t need to cold-start a new micro-VM on each request, resulting in faster response times.

When thinking about sessions for your AgentCore Gateway, keep the following in mind. Enabling sessions is a prerequisite for elicitation. If you’re using header propagation to forward Mcp-Session-Id to targets today, you can’t simultaneously enable session management because the gateway needs to own the session lifecycle. If a downstream MCP server session expires be