{"slug": "mcp-went-stateless-your-agent-workflow-did-not", "title": "MCP went stateless. Your agent workflow did not.", "summary": "The Model Context Protocol (MCP) has released a stable revision that removes the session-based transport, making the protocol stateless and more compatible with standard HTTP infrastructure. The change eliminates the initialization handshake and protocol-level sessions, allowing any server instance to handle requests, which simplifies scaling and integration with load balancers and caches. However, the revision does not make the work performed through MCP stateless, and the protocol still relies on host applications to manage durable task state and authorization.", "body_md": "MCP `2026-07-28`\n\nis now the stable Model Context Protocol revision. Its biggest architectural change is a stateless, sessionless core designed to run more naturally on ordinary HTTP infrastructure.\n\nThat is a major improvement for protocol implementers. It does not make the work performed through MCP stateless.\n\n*Disclosure: AI tools assisted with editing this article. The Manor AI team reviewed the technical claims against the stable MCP specification, changelog, and referenced SEPs before publication.*\n\nBefore MCP, each AI host tended to invent its own adapters for files, databases, developer tools, and business systems. Every connection brought a new schema, discovery model, authentication flow, error model, and lifecycle.\n\nMCP gives hosts and servers a common way to expose:\n\nThe protocol standardizes how capabilities are described and invoked. It does not decide why a capability should be used, who should approve it, or where the result should live tomorrow.\n\nEarlier Streamable HTTP deployments could establish a session and carry an `Mcp-Session-Id`\n\nacross requests. Horizontally scaled servers then needed session affinity or shared session infrastructure.\n\nThe new revision removes the initialization handshake and protocol-level session. Each request carries the information needed to understand it, while `server/discover`\n\nlets clients inspect server capabilities.\n\nAny healthy server instance can now handle a request. This fits ordinary load balancers, gateways, caches, and tracing systems much better.\n\nWhen a workflow needs state across calls, the server can return an explicit handle and accept that handle as a normal argument later. A `basket_id`\n\n, `browser_id`\n\n, or `job_id`\n\nbecomes application data instead of invisible transport state.\n\nA server may still need more information while processing a request. The Multi Round-Trip Requests pattern makes that requirement explicit.\n\nInstead of depending on an open bidirectional session, an operation can return `input_required`\n\n. The client collects the requested input and retries the operation with `inputResponses`\n\n.\n\nThe correlation state is visible and routable rather than hidden inside a connection.\n\nMCP now has a first-class extension model. Optional capabilities are advertised explicitly and can evolve without forcing every implementation to adopt them at the same time.\n\nTwo extensions are especially relevant to agent applications:\n\nThese extensions make MCP useful beyond short synchronous tool calls. They still do not replace the product-level operating model around a team.\n\nThe revision strengthens authorization and aligns it more closely with OAuth and OpenID Connect deployments.\n\nAuthentication can establish whether a client may connect to a server. It cannot fully answer whether this specific agent should send an email, publish a post, modify a record, or delete a file in the current situation.\n\nThe specification keeps that boundary explicit: host applications still need consent interfaces, access controls, and safe execution behavior.\n\nA tool call can be self-contained while the work around it remains durable.\n\nConsider a customer-onboarding workflow. It may include research, document generation, CRM updates, email drafts, approvals, and a final handoff. Several MCP calls may participate, but the team still needs to know:\n\nNone of that belongs in a transport session. It belongs in the host application's data model.\n\nChat is useful for expressing intent. It is a poor database for operational state.\n\nA real task needs an owner, priority, acceptance criteria, plan, status, evidence, comments, and a result that can be verified. If execution stops halfway through, another person should be able to see what happened and continue the work.\n\nThe conversation can start the task. The task should become the record of the work.\n\nThis also explains why an MCP Task and a product-level task are different concepts. The MCP extension represents the lifecycle of a protocol operation. A host application decides how that operation relates to a business goal, an owner, policy, review, and a result that remains useful later.\n\nGiving every agent access to every document and every tool is convenient in a demo and dangerous in production.\n\nContext should belong to a boundary such as a project, workspace, customer account, team, or environment. That boundary groups the people, agents, knowledge, tools, integrations, and rules that belong to the same work.\n\nIt answers two basic questions:\n\nWithout a boundary, retrieval and tool calling become global capabilities with unclear ownership.\n\nApproval should not be a popup added after an automation is designed.\n\nA task should be able to pause, show the proposed action and supporting evidence, record a decision, and continue from the same state. That creates a useful division of responsibility:\n\nThis matters most for customer communication, publishing, permission changes, payments, and destructive actions.\n\nWhen automation produces a bad result, the first question is usually: why?\n\nThe answer should not require reconstructing an entire chat transcript. A production host should preserve the plan, steps, tool results, artifacts, approvals, errors, and final status associated with the work.\n\nEvidence helps operators review a proposed action, developers debug a failed run, and teams improve a workflow after repeated use.\n\nThe protocol is intentionally not a business-process engine. A production host still needs:\n\nThat is not a weakness in MCP. It is the correct separation of concerns.\n\nMCP standardizes the integration surface. The host remains responsible for turning tool calls into work a team can operate.\n\nGive an agent a small task with a verifiable result. Let it use one document and one scoped tool. Trigger an action that should require approval.\n\nThen verify that the system:\n\nThat path reveals whether the system is only an agent demo or something a team can operate.\n\n*Originally published by the Manor AI team on Medium. This DEV edition is a technical cross-post with the original URL set as canonical.*\n\n``", "url": "https://wpnews.pro/news/mcp-went-stateless-your-agent-workflow-did-not", "canonical_source": "https://dev.to/calvin_lin_816fc5a7ce26a1/mcp-went-stateless-your-agent-workflow-did-not-53p", "published_at": "2026-08-03 16:51:49+00:00", "updated_at": "2026-08-03 17:12:03.400463+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure", "ai-agents"], "entities": ["Model Context Protocol", "Manor AI"], "alternates": {"html": "https://wpnews.pro/news/mcp-went-stateless-your-agent-workflow-did-not", "markdown": "https://wpnews.pro/news/mcp-went-stateless-your-agent-workflow-did-not.md", "text": "https://wpnews.pro/news/mcp-went-stateless-your-agent-workflow-did-not.txt", "jsonld": "https://wpnews.pro/news/mcp-went-stateless-your-agent-workflow-did-not.jsonld"}}