Exploring the Future of "Sessions" (Thread IDs / Conversation IDs)

[kurtisvg]

Background & Current State

Recently, the MCP core maintainers made the decision to remove "Sessions" from the protocol.

Historically, sessions were included in the protocol but suffered from significant ambiguity and implementation complexities. After reviewing the trade-offs between stateful and sessionless architectures, the decision was made to move to a sessionless baseline.

You can read the full context of this decision here:

• Transports WG Decision Doc: sessions-vs-sessionless-decision.md
• Core Maintainers Vote & Discussion: #2536

Pushback

Since the decision, we've received pushback from the community highlighting scenarios where maintaining state across a series of interactions feels necessary. There is an active debate, including alternative proposals to retain or rework this functionality (see PR #2822).

We are opening this issue to formally collect concrete use cases for "sessions", and to discuss what a path forward might look like.

Experimental Extension

Before bringing sessions back into the core protocol, we are considering introducing it as an experimental extension. However, to do this successfully, we need to resolve the core challenges that caused us to remove sessions in the first place.

If we reintroduce this concept, we also need to move away from the term "Sessions." The word is heavily overloaded across different networking and application layers. Moving forward, we are proposing terms like Conversation IDs or Thread IDs to more accurately reflect their purpose: grouping a logical sequence of MCP requests.

Challenges

For any Thread ID / Conversation ID proposal to succeed, we need to clearly define its scope. Previous implementations struggled because the boundaries were too blurry. We need to answer:

1. Lifecycle Management:
   • When exactly does a Thread ID start and stop?
   • Is the lifecycle explicitly managed by the client (e.g., an initialization call), or implicitly created on the first tool call?
   • How do we handle cleanup and timeouts for abandoned threads?
2. Scope of Impact:
   • What protocol capabilities should a Thread ID be allowed to mutate?
   • Does a Thread ID only provide context to tools/call execution?
   • Or should a Thread ID be allowed to dynamically alter the results of tools/list, resources/list, and prompts/list based on the conversation's state? (Allowing this previously caused massive caching and synchronization headaches).

Call for Use Cases

To design this right, we need to know exactly how you were using (or planning to use) sessions.

Please reply below with your use cases. When doing so, try to answer:

• What is the exact workflow you are trying to achieve?
• Why can't this be solved by passing state/context directly into the tool call parameters?
• Do you need the Thread ID to change the available tools/resources, or just the execution context of a specific tool?

Looking forward to the community's input.

[kurtisvg]

Here's a quick summary of use cases mentioned in modelcontextprotocol/modelcontextprotocol#2822:

Observability

@javapro108 commented:

Observability. No standard field to correlate requests for a workflow in logs or audit trails. Every deployment solves this ad hoc today.

Routing Affinity and Sticky Sessions

@Agent-Hellboy commented:

Currently, I am putting an adapter above the client that forwards this header, and my custom gateway understands it.

I uses Mcp-Client-Session-Id to grant sessions to my agents.

if the spec formalize this, gateway might support this and in future i can use an available gateway.

@LucaButBoring commented:

We have a use case for this in Bedrock AgentCore [...] on the current spec, we do VM isolation [...] according to the session ID which doubles as a form of sticky sessions, and that session ID that can be either client- or server-generated [...]

If no session ID is ever provided, we create a new VM on every request, which adds a fair bit of latency to each call.

@bittola commented:

Server-side form workflows require sticky routing to a specific backend instance because the form state is process-local.

[...] parallel first calls from a host pipeline land on different instances, each mints its own workflow_id, and the conversation ends up with split state across instances.

What we actually need is exactly what this PR proposes: a stable, client-generated, per-workflow identifier present on every request including the first.

Tool, Resource, and Prompt Scoping

@javapro108 commented:

Tool/resource/prompt scoping. Without a stable identifier, servers return the full catalog on every request regardless of what the current unit of work needs.

@javapro108 commented:

A third scope — "context" — would naturally complete this model: same user, same authorization, but different logical unit of work.

Interoperability with A2A

@javapro108 commented:

MCP and A2A are increasingly deployed together in agentic pipelines. Having no equivalent primitive in MCP creates an interoperability gap and forces every deployment to reinvent what A2A has already standardized.

[n0mad-ai]

Use case: local-first persistent-memory server (durable state behind the tool boundary)

Coming over from discussion #2894 — thanks to @javapro108 for the pointer.

Workflow. I maintain a local-first, persistent-memory MCP server (working OSS implementation, in daily use). The agent accumulates durable state — facts, decisions, preferences, project topology — over months, across disconnected sessions, client restarts, and redeploys. Tools are essentially recall(query), save(content), load(id). The defining moment is session start: a fresh client with an empty context whose first call is recall for state written weeks ago, possibly by a different process. The store is the system of record; the connection is disposable.

Why this is orthogonal to the stateless core. I read "stateless" as a property of the transport/protocol layer — no server-side session affinity required, any node can serve any request. That's compatible with a server whose data is durable, because the durability lives behind the tool boundary, not in transport state. The server stays protocol-stateless even though what it exposes outlives every connection. A stable identifier only needs to select which durable namespace a call touches — it does not need to carry or reconstruct state.

What's missing today — durable-vs-ephemeral capability advertising. Beyond the identifier itself: there's no way for a server to signal that its backing store is durable vs. ephemeral. Clients/agents can't currently reason about whether a recall-style result is authoritative-and-cacheable or transient. A capability flag here would let hosts make sane caching / re-fetch decisions instead of treating every server as stateless-in-the-data-sense.

Identifier shape that fits this class. Client-owned and long-lived — not transport-created, not connection-scoped. What travels is a selector for the durable namespace, whose lifecycle the client owns. A connection-scoped id is the wrong fit here; the whole point is that it survives the client.

Happy to turn this into concrete conformance scenarios — the running implementation I'm referring to is bastra-recall, an open-source local-first memory server I maintain.

[javapro108]

Use Case: Dynamic Tool Activation in a Multi-Domain ERP System

We're building a small ERP solution covering sales, purchasing, production, finance, HR. It has 100+ tools with complex schema. Loading them all at once bloats the LLM context and degrades user experience. So we built a dynamic tool activation pattern with meta tool:

• The server starts every conversation with a single meta-tool: manageTools(always available) — it has a catalogue of all available tools with brief description of each. Also tool description changes to indicate currently active tools and available tools.
• As the user's intent becomes clear, the model calls manageTools to load relevant tools (capped at 10 active at a time).
• As the conversation evolves, tools are swapped in and out.

For example: user can start with "sort out the supplier situation for some issue" but doesn't know yet whether they'll touch purchasing, finance, or inventory — and neither does the model. The right tool set emerges turn by turn as intent is revealed.

Why Thread/Conversation IDs are essential here

It allows to determine what capability model can have for the given state of the conversation. We can't solve this by passing state into tool parameters or by dumping all schemas upfront and hoping the model self-filters; the schemas still consume LLM context whether the model uses them or not.

Each Thread/Conversation ID needs its own isolated, mutable tool list. Two users on the same server — one in purchasing, one in finance — must get completely different tools/list responses simultaneously.

Results we've seen with meta tool approach in our tests are far promising

• Token usage is under control
• Task completion on multi-step workflows is significantly better
• Focused experience without cross-domain noise

[n0mad-ai]

@javapro108 this is the most concrete answer in the thread to the issue's scope-of-impact question — which capability a Thread ID should be allowed to mutate. Your answer (it mutates tools/list, per unit of work) plus the "two simultaneous users on one server — one in purchasing, one in finance — must see different tools/list" scenario is exactly the kind of conformance case worth pinning down. And the protocol-level point holds: tools/list can't carry a conversation parameter itself, so scoping it per unit-of-work needs an identifier that rides on the method, not on tool arguments.

Where I'd draw a line — because it bears directly on lifecycle and cleanup, the other open question — is that your case and the durable-memory one I described want different identifiers under the same name:

• Yours is connection-scoped and ephemeral. The active-tool set is a live, mutable view that exists for one conversation and is meant to disappear afterward.
• Mine is client-owned and long-lived. The selector points at a durable namespace that outlives every connection; nothing about it is meant to be cleaned up on disconnect.

That difference isn't cosmetic — it changes where the state lives, which is the part I'd flag. In your pattern the active-tool set is server-side, per-thread, mutable state. On a sessionless baseline where any node can serve any request, that's the exact statefulness the decision removed: the next tools/list has to land on a node that knows which tools this thread activated, which pulls sticky routing or a shared store back in. My case only sidesteps that because the state lives behind the tool boundary (in the store), so the identifier stays a pure selector and the transport stays genuinely stateless.

So I think both use cases argue for the same identifier primitive — a client-or-conversation-scoped selector present on every request, including tools/list — but they sit at opposite ends of two axes the WG has to decide explicitly: lifecycle (ephemeral-on-disconnect vs. durable-across-restarts) and where the scoped state lives (server-side mutable vs. behind the tool boundary vs. client-driven). Worth separating those, or the extension ends up specifying one lifecycle for two genuinely different needs.

One smaller point: the progressive-disclosure mechanism itself — manageTools swapping the active set — is separable from Thread IDs. A single always-on meta-tool plus notifications/tools/list_changed already does the swapping per connection today; the protocol-level identifier is only load-bearing for the cross-user / cross-connection scoping you describe, not for the disclosure itself. Naming that split might help the WG see exactly which part actually needs new protocol surface.

[LucaButBoring]

Expanding on my comment from the previous issue, I put together a sequence diagram demonstrating the session management flow we rely on and why:

Sequence diagram

sequenceDiagram
    participant C as Client (MCP host)
    participant RT as AgentCore Runtime
    participant VM as microVM<br/>(customer MCP server)

    note over C,VM: For MCP, AgentCore routes requests to a microVM using the Mcp-Session-Id header.<br/>(The X-Amzn-Bedrock-AgentCore-Runtime-Session-Id header, 33-256 chars, is the<br/>session header for the HTTP, A2A, and AG-UI protocols - it is optional for MCP.)

    note over C,VM: Initialization (pre-2026-07-28)
    C->>RT: InitializeRequest (no Mcp-Session-Id)
    note over RT: No session affinity yet, so<br />AgentCore provisions a new microVM.
    RT->>VM: start container
    activate VM
    VM->>RT: ready

    alt Server does not assign an Mcp-Session-Id (recommended default)
        RT->>VM: InitializeRequest (Mcp-Session-Id supplied by AgentCore)
        note over VM: The server accepts the supplied<br />ID and does not reject it.
        VM->>RT: InitializeResult
    else Server assigns its own Mcp-Session-Id
        RT->>VM: InitializeRequest
        VM->>RT: InitializeResult (Mcp-Session-Id assigned by the server)
    end

    note over RT: AgentCore maps the<br />Mcp-Session-Id to this microVM.
    RT->>C: InitializeResult (with Mcp-Session-Id)
    note over C: The client stores the Mcp-Session-Id and sends<br />it on every later request. AgentCore returns an<br />Mcp-Session-Id either way.

    note over C,RT: Reusing the Mcp-Session-Id routes the request to<br />the same microVM. Omitting it gives no affinity,<br />so the request lands on a new microVM (cold start).

    C->>RT: CallToolRequest (with Mcp-Session-Id)
    RT->>RT: look up microVM by Mcp-Session-Id
    RT->>VM: CallToolRequest
    VM->>RT: CallToolResult
    RT->>C: CallToolResult

    C->>RT: CallToolRequest (with Mcp-Session-Id)
    RT->>RT: look up microVM by Mcp-Session-Id
    RT->>VM: CallToolRequest
    VM->>RT: CallToolResult
    RT->>C: CallToolResult

    note over RT,VM: AgentCore tears the microVM down on idle (default 15 minutes), at<br />the maximum lifetime (up to 8 hours), on StopRuntimeSession, or<br />on a failed health check. The microVM is terminated<br />and its memory is sanitized.
    RT--)VM: teardown
    deactivate VM

    note over C,VM: As a consequence of 2026-07-28 removing the Mcp-Session-Id header and AgentCore using that header<br/>as its main affinity key, if the client/server implement no additional custom handling, there is<br/>no key to route on. That means each request lands on a new microVM, with a new container per request.<br/><br/>Keeping affinity would require routing on some alternative key.

Loading

A few key points on this:

• For MCP servers that don't leverage Mcp-Session-Id (which is to say, most of them), we hit branch 1 of the alt section in the diagram, where AgentCore Runtime fills in its own Mcp-Session-Id for instance affinity and can rely on the MCP client to generally pass it on the next request, which then reuses the same container.
• As noted in our documentation, for HTTP, A2A, and AG-UI we require a custom header (X-Amzn-Bedrock-AgentCore-Runtime-Session-Id). This actually works (but is optional) for MCP as well, but there is a meaningful distinction in the integration patterns between protocols. In the case of HTTP/A2A/AG-UI, the customer typically owns both ends of the communication, so it's not an issue for them to pass a custom header. For MCP, this is generally not the case - customers don't usually own both ends of the wire, and can't force off-the-shelf host applications to handle X-Amzn-Bedrock-AgentCore-Runtime-Session-Id for them.
  • Many hosts do support passing custom headers to the transport, but AgentCore Runtime session IDs are dynamically-assigned and aren't expected to be hardcoded in a config file like a bearer token might be.
• We explicitly do not need this to imply any binding to conversation state. It is best-effort and can map to any scope controlled by the client application on the other end (including having a new session on every request, though this is the worst case for latency).

[watnab]

Use case (brief): Multi-step tool workflows where a resource server keeps state keyed by an opaque handle returned from an earlier call — i.e., the Explicit Handle pattern recommended as the sessionless replacement.

Why passing state via tool parameters isn't sufficient (Q2):
The Explicit Handle pattern makes state correlation depend on the model reliably relaying an opaque value from a tool result into subsequent tool arguments. That relay path is exactly what prompt-injection mitigations increasingly constrain: tool-output quarantining, data-flow restrictions between untrusted output and later tool calls, context compaction, confirmation prompts on suspicious values — any of these can drop, rewrite, or block an opaque token. (To be clear, injection-driven leakage of handles is a real topic, but not one I intend to dig into here.)

The concern is operational, not adversarial: attacks will keep evolving, so client-side defenses will keep evolving — meaning servers built on handle relay inherit continuous behavioral churn from host applications they don't control. Handle passing that works today can silently degrade after a host hardens its injection defenses. @LucaButBoring already characterized client relay as best-effort; the defense arms race makes it a degrading best-effort channel.

This is an independent reason to want an identifier that, as @n0mad-ai put it, "rides on the method, not on tool arguments" — deterministic, and outside the model-mediated path.

Q3: Execution context only. No need for the identifier to mutate tools/list.

[n0mad-ai]

@watnab's churn argument has a second half that makes it worse: the relay channel's loss rate is unobservable from the server side. When a host's defenses drop or rewrite a handle, the server just sees an unknown or missing handle — indistinguishable from a legitimate new workflow. There is no error, no signal, nothing to alert on; the degradation @watnab describes would not even show up in anyone's metrics. We learned this the expensive way on an adjacent problem: a correlation field on an application-mediated path silently stopped arriving, and the loss (over 99% of events) was invisible until we counted the same traffic through an independent second channel. Correlation that rides inside content degrades silently by nature; correlation that rides on the method is both deterministic and auditable — either side can count it.

And for the client-owned, long-lived selector from my earlier comment, model relay is the wrong layer even before defenses enter the picture: a namespace selector that has to stay stable across months of sessions cannot be something that must survive every context compaction in between. Ephemeral execution context may tolerate a best-effort relay; a durable namespace selector cannot, which is one more reason the two identifiers should not be collapsed into one mechanism.

[watnab]

A follow-up from a different angle on my earlier comment.

My previous comment was from the position of a developer who got hit by prompt-injection defenses: when I built my MCP server I first adopted exactly the recommended explicit-handle pattern, but it wouldn't run reliably — the hand-off itself kept getting flagged as a possible injection, so I went looking for an alternative and landed on Mcp-Session-Id.

This time I want to raise a question from the opposite seat — the position of someone implementing PI defenses — because thinking about what this decision recommends made me uneasy, and I'd rather put the question to the group than assume I'm right.

The analogy I keep coming back to: SQL injection got a structural fix in bind variables — data is kept out of the command channel, so a value can't be mistaken for a command. Prompt injection has no equivalent yet; defenses are still best-effort. The recommended replacement asks the model to relay an opaque handle from a tool result into the next tool call — i.e. it puts a correlation identifier inside the untrusted-data channel, which feels like the opposite direction from the bind-variable lesson.

So my question, genuinely open: does officially recommending a model-relayed handle make prompt-injection defense harder? A PI defense that restricts "tool output flowing into the next call" now has to avoid breaking the officially recommended pattern.

The hard part, as I see it: a legitimate relay and a malicious one travel the same path, so the requirement becomes "allow the legitimate handoff, reject the malicious handoff" — and I genuinely don't know whether that line can be drawn reliably.

I can't claim with authority that this actively undermines PI defense — I'm not that specialist, which is exactly why I'm raising it rather than asserting it. But it looks enough like moving against the one place we have a clean answer (SQLi/bind variables) that I think it's worth the group working through before this settles into a recommendation.