AgentCore Gateway and MCP 2026-07-28: A UK Upgrade Checklist

The biggest MCP revision since launch — without a big-bang cutover

The Model Context Protocol 2026-07-28 specification is the largest change since MCP shipped: the protocol becomes stateless, scales on ordinary HTTP infrastructure, hardens OAuth/OIDC alignment, and adds a governed extensions system so future growth does not require another breaking core bump.

For teams on Amazon Bedrock AgentCore Gateway, AWS's message is deliberately calm: adding 2026-07-28 is a configuration change. You do not recreate the gateway or rewire every Lambda/OpenAPI target. Clients pick a version per request. That is the right shape for UK estates that cannot freeze production agents for a weekend migration.

What actually changed (enterprise view)

AgentCore Gateway continues to aggregate Lambda, APIs and MCP server targets behind one MCP endpoint. On the new path, the first tool call is one request, not handshake-then-call.

Why UK teams should care this quarter

1. Horizontal scale — Sticky sessions and shared session stores were the tax of early MCP. Stateless MCP fits ALB/API Gateway patterns UK platforms already operate.
2. Observability — W3C Trace Context in _meta plus honest HTTP status codes means CloudWatch/OpenTelemetry dashboards stop guessing.
3. Regulated change control — Dual-version advertising lets you show CAB a reversible, staged plan instead of a hard cutover.
4. Client diversity — Claude Code, Cursor, custom Strands/LangGraph agents and partner tools will upgrade on different clocks. Gateway can speak both until they catch up.

Pre-flight audit (do this before UpdateGateway)

Ask three questions AWS itself recommends, made concrete for UK ops:

1. Are clients ready? Confirm MCP client SDKs in each agent framework ship 2026-07-28 support. Tier-1 SDKs were expected during the RC window — verify your pinned versions in CI, do not assume.
2. What breaks if sessions disappear? Search your code and runbooks for: protocol sessions used as app state, logging/setLevel, literal -32002 matching, Roots / Sampling / Logging dependencies, and tools that need elicitation or sampling (clients must advertise matching capabilities or get -32021).
3. Do you control both sides? You do not need to. Dual-version gateways serve old and new clients simultaneously.

Also note: if a gateway fronts an MCP target that upgrades before clients do, Gateway can translate ordinary tool calls — but elicitation/sampling across that version gap is not supported. Plan those tools carefully.

Safe UK rollout sequence

Stage A — Inventory (3–5 days)

• Catalogue every Gateway ID, supportedVersions, inbound auth (IAM SigV4 vs OAuth/JWT), and downstream targets.
• List agents and SDK versions that call each gateway.
• Flag tools that use elicitation, sampling, progress tokens or custom header-bound fields.

Stage B — Dual advertise (1 change window)

Read current config, then send the complete supportedVersions list (UpdateGateway replaces, it does not append):

aws bedrock-agentcore-control get-gateway \
  --gateway-identifier <gateway-id>

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

Supported versions on Gateway today include 2025-03-26, 2025-06-18, 2025-11-25 and 2026-07-28. Keep whatever you already advertise plus the new one.

Stage C — Prove the new path

Call the gateway with MCP-Protocol-Version: 2026-07-28 and Mcp-Method: tools/list. Success means the version is live. -32022 means it is not in supportedVersions yet (body lists what is).

Migrate pilot agents first (non-prod → one production workflow). Watch HTTP 4xx rates separately from application JSON-RPC errors.

Stage D — Trim only when clean

When inventory shows no clients still requesting the old version, UpdateGateway again without that version. Have a rollback list ready (re-add the old version) before you trim.

Operational gotchas worth a runbook line

• Requests that omit MCP-Protocol-Version default to 2025-03-26. If that default is not in supportedVersions, the call is rejected — so do not drop 2025-03-26 until every client sends an explicit header.
• Header/body contradictions on header-bound fields return HTTP 400 / -32020.
• Deprecations (Roots, Sampling, Logging) remain functional for a grace window, but new UK builds should not take fresh dependencies on them — prefer tool parameters, provider APIs and OpenTelemetry.

Bottom line

MCP 2026-07-28 is designed to be the last core break. AgentCore Gateway lets UK estates adopt it the way they should adopt any protocol change: advertise dual, migrate clients, verify telemetry, then retire. The teams that rush to a single-version production gateway will invent an outage. The teams that treat supportedVersions as a controlled rollout list will barely notice the cutover.