MCP servers stop remembering sessions: Mastra adopts the new spec, so any instance can answer
Synopsis
Mastra's @mastra/mcp 2.0 now supports the MCP 2026-07-28 specification, which removes server sessions so every request is self-contained. Under the previous spec a client opened each connection with an initialize request, the server returned a session ID, and later requests had to carry it; a load balancer routing to another instance produced 400 session not found errors, worked around with sticky sessions or a shared store such as Redis. Now any instance can answer any request, a round-robin balancer suffices, and if an instance crashes the next request goes elsewhere while the client continues.
Interpretation
MCP servers built with Mastra can now scale like ordinary HTTP services, across load-balanced instances or on serverless platforms that scale to zero. The previous MCP spec had a client open every connection with an initialize request; the server created a session, returned a session ID, and every following request had to include it. The session ID pinned the client to the instance that issued it, and a request routed to an instance that did not recognize the ID returned 400 session not found; the workarounds were sticky sessions or a shared session store like Redis, which worked but added complexity, latency and potentially cost.
There is no protocol-level state between requests; each request is independent and behaves like a regular HTTP request. The 2026-07-28 spec makes two changes: SEP-2575 removes the initialize handshake and SEP-2567 removes the Mcp-Session-Id header and protocol-level sessions. Under a traditional round-robin load balancer any instance can respond to any request without sticky sessions or a session store; if an instance crashes, the balancer routes the next request to another instance and the client continues as normal.
Every HTTP request now carries an Mcp-Method header, plus an Mcp-Name header for tool calls, prompts and resources, so gateways, rate limiters and firewalls can decide about a request without parsing its body. List results such as tools/list and resources/list now include two hints borrowed from HTTP caching: ttlMs, how long the result stays fresh, and cacheScope, whether it can be shared across users (public) or only reused for the caller (private). The server/discover method reports an MCP server's capabilities, viewed in Mastra through getServerInfo(), and a response includes the supported MCP spec versions, capabilities, and a name and description.
Perspective
The report covers Mastra's support for the MCP 2026-07-28 spec: @mastra/mcp 2.0 has already removed the SSE transport, roots, sampling and Dynamic Client Registration, and it only accepts clients on the 2026-07-28 spec. It suits engineers building or operating MCP servers who need to judge whether to migrate. The spec also deprecates the HTTP+SSE transport, roots, sampling, logging and OAuth Dynamic Client Registration, and the deprecated features registry lists the migration path and earliest removal date for each.
Tasks, previously an experimental feature, are now an official extension: a long-running tool call can respond straight away with a task handle and keep working in the background while the client checks with tasks/get until the result is ready. Mastra says it is investigating options for supporting tasks in @mastra/mcp, and in the meantime a long-running tool can report progress with context.mcp.progress(). requestState lets a server ask the user a question mid-call without holding the connection open; in Mastra, suspend() from a tool's execute function asks the question and resumeData reads the answer, and deserialized the requestState records the tool, a fingerprint of its arguments, the question and who asked.