I Tried Enabling MCP 2026-07-28 on Amazon Bedrock AgentCore Gateway

Introduction

On July 28, 2026, the new MCP specification 2026-07-28 was released. The initialize handshake and Mcp-Session-Id have been removed, and the design is now stateless: each request indicates the protocol version and client information by itself via _meta.

https://blog.modelcontextprotocol.io/posts/2026-07-28/

On the same day, the AWS blog also announced that AgentCore Gateway supports this 2026-07-28.

https://aws.amazon.com/jp/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/

I checked the responses under the new specification using a newly created Gateway for testing.

What I Tested

Test Environment

• Gateway: Newly created with a minimal configuration, with AWS_IAM as the authentication method
• MCP target: An MCP server implemented for testing (AWS Lambda Function URL)

Before and After Updating supportedVersions

When I checked with get-gateway, there were the following two versions before the update.

{ "mcp": { "supportedVersions": ["2025-03-26", "2025-11-25"] } }

After adding 2026-07-28, three versions were listed.

{ "mcp": { "supportedVersions": ["2025-03-26", "2025-11-25", "2026-07-28"] } }

Adding 2026-07-28 with UpdateGateway

UpdateGateway replaces supportedVersions with the value you specify. Therefore, I listed the two existing versions as well and added 2026-07-28.

aws bedrock-agentcore-control update-gateway \
  --gateway-identifier "<GATEWAY_ID>" \
  --name "<GATEWAY_NAME>" \
  --role-arn "<GATEWAY_ROLE_ARN>" \
  --protocol-type MCP \
  --protocol-configuration '{
    "mcp": {
      "supportedVersions": ["2025-03-26", "2025-11-25", "2026-07-28"]
    }
  }' \
  --authorizer-type AWS_IAM

Running tools/list with 2026-07-28 Without a Session

To verify a stateless call, I sent tools/list as the first request. I did not run initialize, and I did not attach Mcp-Session-Id.

For <GATEWAY_URL>, I specified the Gateway URL returned by get-gateway (ending in /mcp).

The Mcp-Method header is used to identify the method without parsing the JSON-RPC body. It is required in 2026-07-28. For tools/call, Mcp-Name, which indicates the tool name, is also required, but it is not needed for tools/list.

Client information and capabilities are passed in _meta of each request.

POST <GATEWAY_URL>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/list

{
  "jsonrpc": "2.0",
  "id": "new-tools-list",
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "<CLIENT_NAME>",
        "version": "<CLIENT_VERSION>"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The HTTP status was 200, and I was able to retrieve the list of tools. Here is an excerpt from the response.

{
  "result": {
    "tools": [{ "name": "<TARGET_NAME>___<TOOL_NAME>", "inputSchema": { "type": "object" } }],
    "resultType": "complete",
    "ttlMs": 0,
    "cacheScope": "private"
  }
}

resultType indicates whether the response is complete, and becomes input_required when the server requests additional input. ttlMs and cacheScope are fields that indicate the validity period and scope of application when a client caches the list result.

2025-11-25 After the Update and the Response When the Header Is Omitted

After adding the new version, I ran tools/call with 2025-11-25; the HTTP status was 200 and isError was false.

Even when I sent tools/list without MCP-Protocol-Version, the tool list was returned with 200. The response did not include resultType, ttlMs, or cacheScope, and from this response alone I could not tell which version had been selected. The AWS blog explains that requests with the header omitted are treated as the default 2025-03-26.

Response for an Unsupported Version

When I specified the unsupported 2099-01-01, the HTTP status was 400 and error.code was -32022. The response is as follows.

{
  "jsonrpc": "2.0",
  "id": "unsupported-version",
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version: 2099-01-01",
    "data": {
      "requested": "2099-01-01",
      "supported": ["2025-03-26", "2025-11-25", "2026-07-28"]
    }
  }
}

Summary

With AgentCore Gateway, old and new versions can coexist, so you can migrate clients on older versions to the new version gradually. In fact, even after adding the new version, tools/call with 2025-11-25 succeeded.

The official MCP blog explains that going stateless allows MCP servers to scale on ordinary HTTP infrastructure. For workloads where fluctuating load has been a challenge, migrating to 2026-07-28 is an option. Enabling it takes just one UpdateGateway call, so please give it a try.

References

• Amazon Bedrock AgentCore Developer Guide "List available tools in an AgentCore gateway"
  • https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-using-mcp-list.html
• Amazon Bedrock AgentCore Control Plane API Reference "MCPGatewayConfiguration"
  • https://docs.aws.amazon.com/bedrock-agentcore-control/latest/APIReference/API_MCPGatewayConfiguration.html