A retail MCP server must support a shopping cart that the model builds up across several tool calls: create the cart, add items, then check out. The server runs as several stateless instances behind a load balancer. Which design follows the 2026-07-28 guidance?
Select an answer to reveal the explanation.
Short Explanation
Think of a coat-check ticket: you hand back the number, and any attendant can find your coat. A cart handle passed as a tool argument works the same way across instances. The trap is reaching for sessions, which this revision removed.
Full Explanation
MCP in revision 2026-07-28 has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next. The tools specification's stateful-tools guidance says servers that need state across calls, such as a shopping cart, should return an explicit handle from a creation tool and accept that handle as an argument on subsequent calls. The model carries the handle forward, and the server stores the cart under that key in shared storage, so any instance can serve any call. Mcp-Session-Id was removed; a modern server should ignore the header and must not mint or echo session IDs. Per-connection memory breaks behind a load balancer and contradicts the rule that behavior must not depend on connection state, since requests can arrive on any connection or instance. requestState is scoped to a single multi round-trip retry: the client echoes it only on the retry of the original request and must not use it for any other request, so it cannot carry a cart across separate tool calls. Exam caveat: for an unauthenticated server the handle acts as a bearer token, so it should be high-entropy and short-lived. Operational check: create a cart, route the add_item call to a different instance, and confirm the item lands in the same cart.