{"slug": "extending-mcp-support-for-amazon-bedrock-agentcore-gateway", "title": "Extending MCP support for Amazon Bedrock AgentCore Gateway", "summary": "Amazon Web Services has extended support for the Model Context Protocol (MCP) in its Amazon Bedrock AgentCore Gateway, adding new capabilities for enterprise deployments including enhanced tool schema support, MCP prompts and resources as first-class primitives, dynamic server discovery, and OAuth 2.0 token exchange. The gateway serves as a centralized entry point between MCP servers and clients, handling credential management, observability, and secure connectivity to eliminate the need for each server to independently manage security and policy enforcement. This update aims to help enterprises deploy MCP servers at scale with fine-grained access control, centralized governance, and unified visibility across teams.", "body_md": "[Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/)\n\n# Extending MCP support for Amazon Bedrock AgentCore Gateway\n\nWhile deploying [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification/2025-11-25) 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) sits between MCP servers and the clients that consume them, centralizing credential management, observability, and secure connectivity into a single trusted entry point.\n\nToday, we’re extending AgentCore Gateway with new capabilities that further strengthen support for enterprise MCP deployments. This post covers extended [MCP tool schema](https://modelcontextprotocol.io/specification/2025-11-25/server/tools#data-types) support, [MCP prompts](https://modelcontextprotocol.io/specification/2025-11-25/server/prompts) and [MCP resources](https://modelcontextprotocol.io/specification/2025-11-25/server/resources) as first-class primitives, [dynamic listing](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html#gateway-target-MCPservers-considerations) for runtime discovery of MCP servers, streaming and session management for stateful real-time interactions, [elicitation](https://modelcontextprotocol.io/specification/2025-11-25/client/elicitation) for mid-execution input requests, and [OAuth 2.0 on-behalf-of token exchange](https://oauth.net/2/token-exchange/) for delegated authentication. For hands-on examples, visit the [GitHub samples repository](https://github.com/awslabs/agentcore-samples/tree/main/01-tutorials).\n\n## Unite MCP servers for enterprise through AgentCore Gateway\n\nWithout 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.\n\n[AgentCore Gateway](https://aws.amazon.com/blogs/machine-learning/transform-your-mcp-architecture-unite-mcp-servers-through-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.\n\nEach 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html), [REST APIs](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-schema-openapi.html), [AWS Lambda](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-add-target-lambda.html) functions, and [more](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-supported-targets.html). [Resource-based policies (RBP)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/resource-based-policies.html) control who can invoke AgentCore Gateway, for example, restricting invocation to an [Amazon Virtual Private Cloud (Amazon VPC)](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). [Service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) govern how AgentCore Gateway is maintained within your AWS organization.\n\nFor network isolation, [AgentCore Gateway](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/vpc-interface-endpoints.html) supports [AWS PrivateLink](https://aws.amazon.com/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](https://aws.amazon.com/blogs/machine-learning/configuring-amazon-bedrock-agentcore-gateway-for-secure-access-to-private-resources/). Centralized [application](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-gateway-metrics.html) and [identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-identity-metrics.html) logs help you manage audit and compliance requirements.\n\nWith [interceptor](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors.html) capability, AWS Lambda functions can customize requests and responses, enabling fine-grained access control, sanitization, custom authorization logic, and [more](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-examples.html). Integration with [AgentCore Policy (Preview)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html) 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](https://aws.amazon.com/blogs/machine-learning/connecting-mcp-servers-to-amazon-bedrock-agentcore-gateway-using-authorization-code-flow/), where the agent authenticates on behalf of a user before invoking tools.\n\nNow, you will walk through the new capabilities that we’re adding to AgentCore Gateway to further strengthen enterprise MCP support.\n\n## Surface your MCP server primitives through a single gateway\n\nAgentCore 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`\n\nfor defining expected output structure and `annotations`\n\ndescribing behavioral properties such as whether a tool is read-only or destructive, alongside the standard `name`\n\n, `icons`\n\n, `description`\n\n, and `inputSchema`\n\n. The gateway also supports prompts, resources, and resource templates through their full set of MCP methods: `tools/list`\n\n, `tools/call`\n\n, `prompts/list`\n\n, `prompts/get`\n\n, `resources/list`\n\n, `resources/read`\n\n, and `resources/templates/list`\n\n. The following architecture diagram shows how AgentCore Gateway facilitates list and invoke calls.\n\nIn 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](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_CreateGatewayTarget.html) or [UpdateGatewayTarget](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_UpdateGatewayTarget.html), and can be explicitly refreshed using the [SynchronizeGatewayTargets](https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_SynchronizeGatewayTargets.html) API. When clients make list calls such as `tools/list`\n\n, `prompts/list`\n\n, or `resources/list`\n\n, 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`\n\n, `prompts/get`\n\n, and `resources/read`\n\n. At that point AgentCore Gateway routes the request to the correct target.\n\nTools and prompts returned by AgentCore Gateway are prefixed with the target name using the format `targetName___`\n\n. 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`\n\nvalue (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`\n\nvalue. If two conflicting resources share the same priority, the resource from the target that was synchronized first is returned.\n\nBecause 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.\n\n## Dynamic listing for runtime flexibility\n\nSome MCP servers personalize their capabilities per user. A permissions-aware server might expose `approve_expense`\n\nonly 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.\n\nWhen creating a target, you choose between two listing modes: *default* and *dynamic*. In default listing mode, AgentCore Gateway invokes the MCP server during `CreateGatewayTarget`\n\nor `UpdateGatewayTarget`\n\noperations to discover and cache tools, prompts, and resources. This cache can be explicitly refreshed using the `SynchronizeGatewayTargets`\n\nAPI. 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`\n\nor `UpdateGatewayTarget`\n\noperations. 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`\n\n, `prompts/get`\n\n, and `resources/read`\n\nroute directly to the MCP server target. The following architecture diagram illustrates how both modes work together.\n\nMCP 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](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-mcp-semantic-search.html) capability can’t be used.\n\nThis 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.\n\n## Streaming, session management, and elicitation\n\nMany 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.\n\n### Streamable HTTP\n\nWithout 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`\n\nrequest with `Accept: application/json, text/event-stream`\n\n, 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`\n\ncontinue to receive a single JSON response, preserving full backward compatibility.\n\nWhen response streaming is enabled on AgentCore Gateway, the response interceptor behavior changes and must check the `isStreamingResponse`\n\nfield in `gatewayResponse`\n\nto distinguish between streaming and non-streaming responses. The response interceptor is invoked for events that contain a JSON-RPC `id`\n\nfield. The response interceptor isn’t invoked for `notifications/progress`\n\n, `notifications/message`\n\n, and `pings`\n\n. To enable streaming, set the `enableResponseStreaming`\n\nblock during the `CreateGateway`\n\nor `UpdateGateway`\n\nAPI call.\n\nWhen 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.\n\n### Session management\n\nSession management introduces stateful multi-turn workflows to AgentCore Gateway. When you enable sessions, AgentCore Gateway generates a `Mcp-Session-Id`\n\non 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.\n\nTo enable sessions, add a `sessionConfiguration`\n\nblock during the `CreateGateway`\n\nor `UpdateGateway`\n\nAPI call. You can configure the session timeout from a minimum of 15 minutes to a maximum of 8 hours. The default is 1 hour.\n\nSessions 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`\n\nheader, and HTTP 404 for expired or non-existent sessions.\n\nBehind 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.\n\nWhen 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`\n\nto 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 before the gateway session timeout, the gateway re-initializes the target transparently and continues serving the client.\n\n### Elicitation\n\nElicitation enables MCP servers behind AgentCore Gateway to pause execution and request input from the end user. This is particularly valuable for high-risk operations where the server needs explicit user confirmation, structured data collection, or out-of-band authentication before proceeding.\n\nAgentCore Gateway supports the following elicitation modes. In *form mode*, the MCP server sends a flat JSON Schema describing the fields that it needs, and the client renders a form for the user to complete. In *URL mode*, the server sends a URL that the client opens for the user, typically an OAuth consent screen or an external approval workflow. In *URL exception mode*, the server returns `URLElicitationRequiredError`\n\ncontaining a URL, prompting the client to redirect the user and retry the tool call after the user completes the external flow.\n\nHere’s how form mode elicitation works through AgentCore Gateway. Steps 1–6 cover session initialization and tool discovery. After that, the client sends a `tools/call`\n\nrequest with the `Mcp-Session-Id`\n\nheader. AgentCore Gateway forwards the tool call to the MCP server target. The target opens an SSE stream and sends an `elicitation/create`\n\nrequest. AgentCore Gateway forwards the `elicitation/create`\n\nrequest to the client on the SSE stream. The client presents the form to the user and collects the response. The client then sends the elicitation response (action: accept or decline) using the same `Mcp-Session-Id`\n\n. AgentCore Gateway forwards the response to the MCP server target, which acknowledges HTTP 202 Accepted. The target continues to process the request with the new information.\n\nElicitation requires both streaming and sessions to be enabled on your gateway. AgentCore Gateway respects capability negotiation; it only declares elicitation support to a downstream MCP server when the connecting client has declared support for it during initialization. This means if a client doesn’t support elicitation, the MCP server won’t attempt to send elicitation requests, avoiding unexpected behavior. AgentCore Gateway also supports multiple active elicitations per session, so a client can have concurrent tool calls each with their own pending elicitation.\n\nWhen thinking about elicitation for your AgentCore Gateway, keep the following in mind. Elicitation timeout is governed by the AgentCore Gateway connection timeout. If a user takes longer than the connection timeout to respond to a form or complete a URL flow, the request times out. Plan your connection timeout accordingly for workflows that involve human interaction. If the connection between the client and AgentCore Gateway breaks during an elicitation, AgentCore Gateway does not support resuming that specific tool call. The client should retry the original `tools/call`\n\nrequest. The gateway supports elicitation pass-through for MCP server targets only. For non-MCP target types such as REST APIs or AWS Lambda functions, elicitation is not applicable since those targets do not initiate elicitation requests.\n\n## OAuth 2.0 on-behalf-of token exchange\n\nWhen your agents need to access downstream resources on behalf of authenticated users, AgentCore Gateway supports OAuth 2.0 on-behalf-of (OBO) token exchange through AgentCore Identity. This enables a zero-trust authentication model where the original user’s identity is preserved and propagated through every hop in the request chain, while each layer receives a token scoped precisely to its intended audience.\n\nThe MCP client authenticates to AgentCore Gateway with JWT A, scoped to the gateway audience (`aud: gw`\n\n), over the `/mcp`\n\nstreamable HTTP connection. When AgentCore Gateway needs to call a downstream MCP server target, it calls AgentCore Identity to exchange JWT A for JWT B, now scoped to the MCP server audience (`aud: mcp`\n\n). If the MCP server in turn needs to call a further downstream API, it can use `GetResourceOAuth2Token`\n\nto obtain JWT C scoped to the downstream API audience (`aud: api`\n\n). At every hop, the original user identity (`sub: X`\n\n) is carried forward, so downstream services can enforce fine-grained, per-user authorization without triggering additional consent flows. The claims used in this flow are strictly for example purposes, and should only be used to understand this diagram.\n\nAgentCore Identity acts as the central token broker for this entire flow. It provides a secure token vault for storing OAuth credentials and client secrets so that neither AgentCore Gateway nor MCP servers need to manage credentials directly, and workload identity for service-to-service authentication using AWS workload identity rather than long-lived secrets. It supports standard token exchange ([RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html)) or JWT authorization grant ([RFC 7523](https://www.rfc-editor.org/rfc/rfc7523.html)), depending on the identity provider.\n\n## Conclusion\n\nWith this release, you can build stateful multi-turn agent workflows with real-time progress streaming, human approval gates that pause and resume execution, and zero-trust identity propagation, through a single managed endpoint. No custom session stores, no hand-rolled streaming infrastructure, no shared service account credentials. Your MCP servers stay focused on business logic. AgentCore Gateway handles the rest: discovery, streaming, state, identity, and policy, centrally governed and incrementally adoptable.\n\nTo get started, review the [Amazon Bedrock AgentCore Gateway documentation](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html) for configuration details on each feature covered in this post. For hands-on examples, visit the [GitHub samples repository](https://github.com/awslabs/agentcore-samples/tree/main/01-tutorials). If you’re already running MCP servers behind AgentCore Gateway, you can adopt these capabilities incrementally without changes to your existing AgentCore Gateway or target configurations.", "url": "https://wpnews.pro/news/extending-mcp-support-for-amazon-bedrock-agentcore-gateway", "canonical_source": "https://aws.amazon.com/blogs/machine-learning/extending-mcp-support-for-amazon-bedrock-agentcore-gateway-2/", "published_at": "2026-06-01 18:35:03+00:00", "updated_at": "2026-06-02 20:26:46.220275+00:00", "lang": "en", "topics": ["artificial-intelligence", "machine-learning", "ai-agents", "ai-infrastructure", "ai-tools"], "entities": ["Amazon Bedrock AgentCore Gateway", "Amazon Web Services", "Model Context Protocol"], "alternates": {"html": "https://wpnews.pro/news/extending-mcp-support-for-amazon-bedrock-agentcore-gateway", "markdown": "https://wpnews.pro/news/extending-mcp-support-for-amazon-bedrock-agentcore-gateway.md", "text": "https://wpnews.pro/news/extending-mcp-support-for-amazon-bedrock-agentcore-gateway.txt", "jsonld": "https://wpnews.pro/news/extending-mcp-support-for-amazon-bedrock-agentcore-gateway.jsonld"}}