MCP went stateless. Your agent workflow did not.

Calvin Lin — Mon, 03 Aug 2026 16:51:49 +0000

MCP 2026-07-28 is 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.

That is a major improvement for protocol implementers. It does not make the work performed through MCP stateless.

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.

What problem MCP solves

Before 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.

MCP gives hosts and servers a common way to expose:

Tools a model can invoke;
Resources that provide data and context;
Prompts that package reusable interaction patterns.

The 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.

What changed in MCP 2026-07-28

1. The core protocol is stateless

Earlier Streamable HTTP deployments could establish a session and carry an Mcp-Session-Id across requests. Horizontally scaled servers then needed session affinity or shared session infrastructure.

The new revision removes the initialization handshake and protocol-level session. Each request carries the information needed to understand it, while server/discover lets clients inspect server capabilities.

Any healthy server instance can now handle a request. This fits ordinary load balancers, gateways, caches, and tracing systems much better.

When 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, browser_id, or job_id becomes application data instead of invisible transport state.

2. Server-to-client interaction becomes an explicit round trip

A server may still need more information while processing a request. The Multi Round-Trip Requests pattern makes that requirement explicit.

Instead of depending on an open bidirectional session, an operation can return input_required. The client collects the requested input and retries the operation with inputResponses.

The correlation state is visible and routable rather than hidden inside a connection.

3. Extensions can evolve outside the core

MCP 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.

Two extensions are especially relevant to agent applications:

MCP Apps can render interactive interfaces such as forms and charts inside a conversation.
MCP Tasks adds asynchronous operations with durable handles, polling, and mid-flight input.

These extensions make MCP useful beyond short synchronous tool calls. They still do not replace the product-level operating model around a team.

4. Authorization improves, but host policy remains necessary

The revision strengthens authorization and aligns it more closely with OAuth and OpenID Connect deployments.

Authentication 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.

The specification keeps that boundary explicit: host applications still need consent interfaces, access controls, and safe execution behavior.

Stateless protocol is not stateless work

A tool call can be self-contained while the work around it remains durable.

Consider 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:

the goal and current status;
who owns the work;
which documents and instructions were used;
which tools were available;
what completed and what failed;
where human input was required;
which evidence supports the result.

None of that belongs in a transport session. It belongs in the host application's data model.

A prompt is not a durable task

Chat is useful for expressing intent. It is a poor database for operational state.

A 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.

The conversation can start the task. The task should become the record of the work.

This 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.

Context needs an operating boundary

Giving every agent access to every document and every tool is convenient in a demo and dangerous in production.

Context 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.

It answers two basic questions:

What information may this agent use?
What actions may this agent take here?

Without a boundary, retrieval and tool calling become global capabilities with unclear ownership.

Human approval belongs inside execution

Approval should not be a popup added after an automation is designed.

A 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:

the agent prepares and explains the action;
the runtime enforces the checkpoint;
a person makes the decision;
the task records what happened.

This matters most for customer communication, publishing, permission changes, payments, and destructive actions.

Evidence makes agent work debuggable

When automation produces a bad result, the first question is usually: why?

The 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.

Evidence helps operators review a proposed action, developers debug a failed run, and teams improve a workflow after repeated use.

What production hosts still need to provide

The protocol is intentionally not a business-process engine. A production host still needs:

an operating boundary for people, agents, knowledge, and rules;
persistent context beyond one conversation;
work objects with ownership, status, acceptance criteria, and results;
narrowly scoped tools and credentials;
approval checkpoints for consequential actions;
evidence that makes execution reviewable;
workflows that can be repeated and improved.

That is not a weakness in MCP. It is the correct separation of concerns.

MCP standardizes the integration surface. The host remains responsible for turning tool calls into work a team can operate.

A practical test

Give 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.

Then verify that the system:

pauses before the consequential action;
shows useful evidence;
records the decision;
resumes from the same state;
leaves a result another person can inspect.

That path reveals whether the system is only an agent demo or something a team can operate.

References

Originally published by the Manor AI team on Medium. This DEV edition is a technical cross-post with the original URL set as canonical.
``

DEV Community: Calvin Lin