Use MCP sessions with your AgentCore gateway
MCP sessions enable stateful interactions between clients and your AgentCore gateway. When sessions are enabled, the gateway generates a unique session identifier during initialization and maintains state across multiple requests, enabling advanced MCP features such as elicitation and sampling.
Benefits of using sessions
- Stateful MCP server target interactions
-
The gateway stores the MCP server target’s session ID and reuses it on subsequent tool calls. This avoids re-initialization on every request and enables targets to maintain context across calls.
- Faster responses with AgentCore Runtime targets
-
When the target’s session is reused, AgentCore Runtime doesn’t need to cold-start a new MCP server connection on each request, resulting in faster response times.
- Enables advanced MCP features
-
Sessions are a prerequisite for elicitation and sampling, which require tracking state across multiple requests.
- User-scoped security (authenticated gateways)
-
For gateways with inbound authentication, sessions are bound to the verified user identity, preventing session hijacking.
Enable sessions on your gateway
To enable sessions, specify a sessionConfiguration in the protocolConfiguration.mcp field when creating or updating your gateway.
{ "protocolConfiguration": { "mcp": { "sessionConfiguration": { "sessionTimeoutInSeconds": 3600 } } } }
The sessionTimeoutInSeconds parameter is optional. If omitted, the default timeout is 3600 seconds (1 hour). Valid range is 900 (15 minutes) to 28800 (8 hours). The timeout is absolute, calculated from the first initialize request.
To also enable features that depend on sessions such as elicitation and sampling, you must additionally enable response streaming:
{ "protocolConfiguration": { "mcp": { "sessionConfiguration": { "sessionTimeoutInSeconds": 3600 }, "streamingConfiguration": { "enableResponseStreaming": true } } } }
Note
When sessions are enabled on a gateway, you cannot include Mcp-Session-Id in the metadataConfiguration of a gateway target’s header propagation settings. The gateway manages session IDs internally. Attempting to do so returns an HTTP 400 Bad Request error.
Session lifecycle
The session lifecycle follows the MCP protocol’s initialization flow:
-
The client sends an
initializerequest to the gateway. -
The gateway creates a session, stores session metadata, and returns a unique
Mcp-Session-Idin the response header. -
The client includes the
Mcp-Session-Idheader in all subsequent requests. -
The gateway validates the session existence, expiry, and user identity (for authenticated gateways) on each request.
-
When the session times out or the client disconnects, the session expires.
On the first tool call to an MCP server target within a session, the gateway initializes a connection with the target and stores the target’s session ID. Subsequent tool calls to the same target reuse this stored session ID, avoiding repeated initialization.
User identity and session scoping
Sessions are scoped to the authenticated user identity to prevent session hijacking. The gateway derives the user identity differently depending on the inbound authentication method configured on your gateway:
| Authentication method | User identifier | Behavior |
|---|---|---|
|
OAuth / OIDC |
|
Fully scoped. Only the user who created the session can use it. The |
|
AWS IAM (SigV4) |
Principal ARN |
Fully scoped. Only the IAM principal who created the session can use it. The Principal ARN is globally unique across AWS, immutable for the IAM entity’s lifetime. Example: |
|
No authentication |
None |
No user scoping. Sessions are available but not bound to any identity. Anyone with the session ID can interact with the session. |
Important
For gateways with no inbound authentication, sessions carry a session hijacking risk as described in the MCP specification security considerations
For authenticated gateways, if a different user attempts to use an existing session ID, the gateway returns HTTP 404 Not Found — the session is invisible to other users.
Session timeout and expiry
The session timeout is calculated from the first initialize request. After the timeout period, the session expires and cannot be used.
-
Default timeout: 3600 seconds (1 hour)
-
Configurable range: 900 seconds (15 minutes) to 28800 seconds (8 hours)
If an MCP server target’s session expires before the gateway session timeout, the gateway transparently re-initializes with the target and updates the stored target session ID. The gateway session remains active.
Error handling
| Scenario | HTTP status | Description |
|---|---|---|
|
Missing |
400 Bad Request |
All requests after |
|
Invalid or expired session ID |
404 Not Found |
The session does not exist or has timed out. |
|
Different user attempts to use another user’s session (authenticated gateways) |
404 Not Found |
The session is invisible to other users. |
|
|
400 Bad Request |
Returned at control plane when creating or updating a target. |