MCP 2026-07-28 Explained: Why Stateless Tool Connections Matter for Claude Agents

The biggest Claude-related update this month may not be a model release.

It is the Model Context Protocol update.

The 2026-07-28 MCP specification changes the lower-level connection model between AI agents and external tools. The official MCP blog calls it the largest revision since launch. That description is reasonable: the release moves MCP toward a stateless protocol core, removes the old initialize / initialized handshake and protocol-level session ID, formalizes Extensions, brings Tasks into the extension model, and makes MCP Apps a production-ready direction for interactive tool interfaces.

In plain English:

MCP is changing from a session-based tool connection protocol into a more cloud-native tool protocol for agents.

MCP is changing from a session-based tool connection protocol into a more cloud-native tool protocol for agents.

That matters because AI agents are becoming more than chat interfaces. Claude Code, IDE agents, Dify, n8n, enterprise copilots, internal workflow agents, and custom automation systems all need a reliable way to discover tools, call tools, handle permissions, return results, and keep audit trails.

If models are the engine, MCP is becoming one of the socket standards between agents and the outside world.

What problem does MCP solve?

The hard part of building an AI agent is usually not generating text.

The hard part is connecting the model to real tools safely and consistently.

For example, an agent may need to:

• read a GitHub repository
• search Notion or Confluence documents
• query order data
• inspect local files
• call a browser automation tool
• create a ticket
• access a CRM
• generate a report
• ask a human for approval

Without a standard protocol, every integration becomes custom work.

GitHub has one API shape. Notion has another. Databases have another. Browsers, internal APIs, file systems, CI systems, and ticketing tools all have their own authentication, request format, response format, error handling, and permission model.

The result is predictable:

The model layer can be replaced, but the tool layer becomes harder and harder to maintain.

The model layer can be replaced, but the tool layer becomes harder and harder to maintain.

MCP tries to solve that by defining a standard connection model between agents and tools. Tool providers expose capabilities through MCP servers. Agent hosts discover those capabilities and call them through the protocol.

You can think of MCP in three roles:

The value is not that one tool becomes easier to use.

The value is that tool access becomes reusable infrastructure.

The main change: MCP is going stateless

The keyword in this update is stateless.

Earlier MCP implementations were often understood as session-based:

1. the client connects to an MCP server
2. the client sends an initialize request
3. the server returns capabilities and a session identifier
4. later requests carry that session identity
5. both sides continue interacting inside that connection context

That model is intuitive in local desktop usage. Claude Desktop connecting to a local file-system server can keep state in a local process without much infrastructure cost.

But session state becomes expensive when MCP moves into cloud, enterprise, multi-user, gateway, and platform environments.

Imagine a company with 500 employees using agents. Each employee may connect to GitHub, databases, documents, ticketing systems, and internal services. The backend should be able to:

• load-balance requests
• scale horizontally
• retry failures
• route requests to different instances
• add authentication
• enforce rate limits
• record logs
• apply audit policies
• separate teams, projects, and users

If every request depends on a hidden session stored inside one server instance, that architecture becomes harder.

Stateless MCP is closer to ordinary HTTP service design:

Each request carries enough information to be handled independently.

Each request carries enough information to be handled independently.

If an application needs state, it can still keep state explicitly. For example, a tool can return a basket_id, browser_id, task_id, or other handle, and the model can pass that handle back in later calls.

The important change is that state is no longer hidden in the transport session.

Why removing initialize and sessions matters

At first, removing initialize and protocol-level sessions may look like a small protocol detail.

It is not.

It changes MCP from a local-first tool protocol into something easier to operate as production infrastructure.

According to the official 2026-07-28 specification notes, the old initialize / initialized handshake is retired. The Mcp-Session-Id header and the protocol-level session are also removed. Protocol version, client identity, and capabilities now travel with requests through _meta, and clients can use server/discover if they want server capabilities up front.

That has practical consequences.

1. Scaling becomes simpler

Without protocol-level sessions, a request can land on any server instance behind a normal load balancer. You do not need to pin one user to one backend instance just because that instance created the session.

2. Gateways become easier

The new spec includes Mcp-Method and Mcp-Name HTTP headers for Streamable HTTP transport. That makes it easier for gateways, proxies, load balancers, and rate limiters to route, authorize, and observe traffic without deep inspection of the full body.

3. Recovery becomes clearer

If one request fails, recovery is about that request and its explicit state, not a hidden session chain.

For long-running work, the Tasks extension becomes the better abstraction than relying on an always-open session.

4. Multi-tenant security becomes more explicit

Enterprise systems need to know:

• who called the tool
• which team or project they belong to
• what permissions apply
• whether the tool can read, write, delete, deploy, or send messages
• where the call should be logged

Stateless does not mean less security. It means each call needs clearer identity, authorization, and traceability.

Extensions: MCP now has a cleaner way to grow

Another important part of the update is the Extensions framework.

Every protocol faces the same problem:

The core standard must stay stable, but ecosystems keep asking for new capabilities.

The core standard must stay stable, but ecosystems keep asking for new capabilities.

Today, developers want better permission declarations.

Tomorrow, they want richer user interfaces.

After that, they want task progress, approval flows, generated files, server-rendered dashboards, or enterprise-managed authorization.

If all of this is forced into the core protocol, MCP becomes bloated and difficult to implement consistently.

Extensions solve that by creating a clearer place for capabilities that should be declared, negotiated, and adopted gradually.

For MCP server authors, this means future servers may need to describe more than tool names and JSON schemas. They may need to declare:

• which extensions are supported
• whether long-running Tasks are supported
• whether interactive UI components are available
• what resource types can be returned
• whether extra authorization is required
• whether the host can safely render or embed something

This moves MCP servers from “a wrapper around tool functions” toward “reusable agent capability modules.”

MCP Apps: applications designed for agents

MCP Apps may be the most underestimated part of this direction.

When people say “AI app,” they usually mean:

• a website
• a chatbot
• a plugin
• a browser extension
• a desktop client
• a workflow product

MCP Apps point to a different form: applications that are callable, composable, renderable, and reusable by agents.

For example, a finance analysis app does not have to start as a full SaaS dashboard. It could expose a set of MCP capabilities:

• read spreadsheets
• detect abnormal numbers
• generate analysis assumptions
• produce summaries
• create reports
• request human confirmation
• write back to an approved system

A content operations app could expose:

• collect topic ideas
• extract reference material
• generate outlines
• produce a website version
• produce a newsletter version
• generate image prompts
• archive assets
• record keywords

If these capabilities are exposed through MCP, an agent can combine them with other tools instead of only opening one isolated app.

Human-facing apps are designed for people to click.

MCP Apps are closer to applications that agents can call, compose, and present inside an AI workflow.

The official MCP release notes describe MCP Apps as server-rendered user interfaces that can render in sandboxed iframes, with UI-initiated actions going through the same audit and consent path as direct tool calls. That is an important design direction for enterprise use.

What developers should check now

If you are only using Claude Desktop, Claude Code, or a managed tool, you may not need to take immediate action. Tool providers and SDKs will handle much of the transition.

But if you maintain MCP servers, build an internal agent platform, operate an MCP gateway, or connect agents to enterprise systems, this update deserves a compatibility review.

1. Check whether your MCP server depends on sessions

Look for assumptions such as:

• user identity stored only in connection state
• task progress stored only in session memory
• permissions cached at initialization time
• tool availability decided only during the old handshake
• server instance affinity required for correctness

If your server depends on those patterns, move state upward into explicit mechanisms:

• authorization layer
• task system
• database or cache
• request metadata
• explicit handles such as task_id or browser_id
• gateway-level observability

Do not assume that “the connection is still open” means “the state is safe.”

2. Rework authorization around every call

In a stateless model, each request should be evaluated with clear identity and permissions.

For enterprise MCP adoption, answer these questions:

• Who is calling this tool?
• Which team, project, or tenant does the call belong to?
• Which data can this user read?
• Can this tool write?
• Can it delete?
• Can it call external services?
• Can it trigger high-risk actions?
• Is the call logged with enough context?

Agent tool calling should never rely only on model self-discipline.

As the protocol becomes more standardized, teams need stronger permission design, logs, rate limits, and audit trails.

3. Separate model access from tool access

Models will keep changing.

Today you may use Claude. Tomorrow you may use GPT, Gemini, Kimi, or another model.

The tool layer should not need to be rewritten every time the model changes.

MCP’s long-term value is that it separates:

Which model should reason about the task?
Which tools can the agent use?

Which model should reason about the task?
Which tools can the agent use?

If GitHub, databases, documents, browsers, and internal APIs are exposed through stable MCP servers, the model layer becomes easier to swap.

That is the real infrastructure value.

A cleaner enterprise AI architecture

Many teams still start AI adoption with model questions:

• Which model should we use?
• Claude or GPT?
• Opus or Sonnet?
• How do we access it from our region?
• How much will it cost?

Those questions matter, but they are not enough.

For production agent systems, separate the architecture into three layers.

1. Model access layer

This layer handles:

• model routing
• API keys
• Base URL configuration
• compatibility APIs
• logs
• balance and billing
• concurrency
• failover
• usage controls

apito.ai fits here as a unified model access layer for Claude and related workflows.

2. Tool connection layer

This is where MCP fits.

It handles:

• GitHub access
• databases
• file systems
• browsers
• internal APIs
• knowledge bases
• ticket systems
• tool schemas
• permission-aware tool calls

3. Business workflow layer

This is the actual work:

• coding
• research
• report generation
• customer support
• content production
• data analysis
• automated testing
• internal operations

These three layers should not be mixed.

If they are mixed, model changes force tool rewrites. Tool growth creates permission chaos. Complex workflows create opaque cost and debugging problems.

The 2026-07-28 MCP update is a reminder that agent engineering is not just prompt engineering. It is connection design, permission design, state design, and workflow design.

Should you migrate immediately?

Do not panic.

If you use managed tools, follow their upgrade path.

If you build MCP infrastructure, run a review now.

This checklist matters more than changing code immediately.

MCP is moving from a local tool protocol toward the connection layer for agent ecosystems. The earlier your team standardizes the tool layer, the less you will be dragged around by model and tool updates later.

Where apito.ai fits

apito.ai is not an MCP server, and it does not need to be described as the MCP protocol itself.

Its cleaner role is the model access layer.

If your team uses Claude Code, Cursor, Dify, n8n, Open WebUI, or a custom agent workflow, apito.ai can help centralize:

• API keys
• Claude-compatible model access
• request logs
• usage and cost visibility
• team or tool-level configuration
• migration between access domains

MCP fits in the tool connection layer:

• connect GitHub
• connect databases
• connect files
• connect browsers
• connect internal systems
• connect knowledge bases

A healthier agent architecture is:

Model access through a unified gateway.
Tool access through a standard protocol.
Business work through controlled workflows.

Model access through a unified gateway.
Tool access through a standard protocol.
Business work through controlled workflows.

That way, models can change, tools can expand, and cost and permissions remain visible.

If you previously configured ClaudeAPI-related tools, migration to apito.ai usually means changing the request domain from claudeapi.com to the corresponding apito.ai endpoint. Whether keys, model names, or request parameters need adjustment should always follow the live console and current integration notes.

What this MCP update really changes

This update is not simply “Claude got another tool feature.”

It changes the default assumption of the agent ecosystem.

Previously, tool access was often treated as platform-specific:

• Claude has Claude tools.
• Cursor has Cursor integrations.
• Dify has Dify nodes.
• n8n has n8n workflows.
• Enterprises write internal connectors one by one.

MCP pushes toward a different model:

Tool capabilities should become standard resources that different agents can discover, call, combine, and govern.

Tool capabilities should become standard resources that different agents can discover, call, combine, and govern.

That has long-term consequences.

Model quality still matters. But agent-era competition will also happen in protocols, connectors, permissions, observability, and workflow infrastructure.

That is why this MCP update deserves attention.

It moves Claude and the broader MCP ecosystem further toward agent infrastructure, not just model interaction.

FAQ

Is MCP only for Anthropic?

No. Anthropic initiated MCP, but MCP has developed as an open protocol ecosystem with SDKs, specifications, servers, hosts, and community implementations. Treat it as an agent tool-connection standard rather than a private plugin format.

Will older MCP servers stop working?

Not automatically. It depends on how the server is built and which host or SDK it uses. Servers that depend heavily on protocol sessions, handshake-time configuration, or connection-local state should be reviewed. Simpler tool servers may mainly need SDK and compatibility updates.

What changed in the 2026-07-28 MCP specification?

The major changes include a stateless protocol core, removal of the old initialize / initialized handshake and Mcp-Session-Id, request metadata through _meta, optional server/discover, header-based routing with Mcp-Method and Mcp-Name, cacheable list responses, Extensions, Tasks, MCP Apps, authorization hardening, and updated SDKs.

How is MCP different from an API gateway?

MCP is mainly a tool connection protocol. It helps agents discover and call external capabilities. An API gateway usually handles model access, authentication, rate limits, routing, logging, billing, and failover. In enterprise systems, they work better together than as replacements.

Is apito.ai a replacement for MCP?

No. apito.ai is better understood as a unified model access and usage-management layer. MCP is better understood as the tool connection layer. One calls models; the other exposes tools to agents.

What should enterprises do first?

Do not start by adding as many MCP servers as possible. Start with a tool permission table: which tools are read-only, which can write, which require human confirmation, which are test-only, and which need complete logs.

Sources

• Model Context Protocol Blog: The 2026-07-28 Specification
• Model Context Protocol Blog: The 2026-07-28 MCP Specification Release Candidate
• Model Context Protocol Docs: What is MCP?
• Model Context Protocol Specification: 2026-07-28 specification
• Anthropic Docs: Model Context Protocol
• GitHub: github-mcp-server

Disclosure

apito.ai / ClaudeAPI is an independent third-party technical service and is not affiliated with Anthropic or the Model Context Protocol project.