The July 2026 specification moves MCP towards stateless scale, explicit multi-round trips, background tasks and enterprise-managed identity.
The Model Context Protocol specification published on 28 July is less visually dramatic than a new frontier model, but potentially more important for enterprise architecture. The release makes the protocol more explicit about stateless operation, multi-round-trip requests, long-running tasks, headers, caching and managed identity.
In practical terms, MCP is moving from a convenient way to connect a model to a tool towards a production integration layer.
Why statelessness matters
Earlier agent integrations often kept transport sessions open and stored implicit state inside them. That can work for a local prototype. At scale it creates operational friction: sticky routing, difficult recovery, hidden context and infrastructure that must preserve a connection longer than the business task requires.
The July specification removes protocol-level session dependency. If an application needs state, a tool can issue an explicit handle that the model passes back in later calls.
That is a healthier boundary. State becomes visible to the application rather than hidden in the transport. It can be versioned, expired, authorised and audited.
Stateless transport does not mean stateless business processes. It means the protocol no longer confuses the two.
Multi-round trips make tools conversational without becoming opaque
Real tools sometimes need more information in the middle of a call. A payment workflow may require confirmation. A travel request may lack a cost centre. A procurement action may need a missing supplier identifier.
The new multi-round-trip request pattern lets a server return an input_required result and ask for specific information before the original operation resumes. This allows a tool to remain explicit about what is missing and why.
For enterprise systems, that is preferable to silently guessing parameters or forcing every exception into a separate chat prompt. The missing input can be surfaced to a user, another agent or an approval workflow with a traceable contract.
Tasks separate long-running work from the request
The specification moves Tasks into an extension and defines poll-based status retrieval plus updates. This reflects a basic truth: an agent call may start work that cannot finish inside one HTTP response.
Examples include:
- generating a large regulatory report;
- running a batch reconciliation;
- waiting for an external approval;
- processing a document archive;
- coordinating work across several agents.
A task object needs ownership, status, progress, cancellation, expiry and output references. Enterprises should add those requirements even when the protocol treats some of them as implementation choices.
Protocol support is not governance
MCP standardises how clients and servers describe capabilities and exchange calls. It does not decide whether a specific user should be allowed to invoke a tool, whether the action is legally appropriate, or how a company should segregate duties.
A production MCP layer still needs:
- authentication and authorisation;
- per-tool and per-action scopes;
- parameter validation;
- secrets management;
- rate and cost limits;
- data-loss prevention;
- prompt-injection defences;
- policy enforcement;
- full telemetry;
- version and deprecation management.
An MCP server that exposes a powerful internal API without these controls is not an enterprise integration. It is a new attack surface.
Tool contracts become strategic assets
A well-designed MCP tool is more than an API wrapper. It packages a business capability in language an agent can understand and software can enforce.
For example, create_refund is too broad. A safer capability might expose propose_refund, return the applicable policy and evidence, and require a separate approval token before execute_approved_refund becomes available.
The naming, schemas, descriptions and error states shape model behaviour. Tool design is therefore part API engineering, part policy design and part user experience.
What to standardise now
Organisations adopting MCP should define a house standard covering:
- ownership and lifecycle of every server;
- approved authentication patterns;
- naming and schema conventions;
- read, propose and execute separation;
- idempotency and retry behaviour;
- task and cancellation semantics;
- allowed network destinations;
- mandatory audit fields;
- compatibility testing across clients;
- deprecation and incident procedures.
The goal is not to force every integration through one team. It is to prevent hundreds of incompatible tool surfaces from becoming the next integration debt.
The Lexdatum view
MCP is becoming the vertical connective tissue between agents and enterprise capabilities.
Its value will not come from the number of tools a company exposes. It will come from the quality of the contracts: small, governed, observable capabilities that agents can use without inheriting unlimited authority.
The protocol is maturing. Enterprise operating standards now need to mature with it.
Sources
Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.