MCP Specification 2026-07-28: The AI-to-Enterprise Standard Goes Stateless

What MCP is, without the jargon

Before the new specification makes sense, it helps to name the problem MCP was created to solve. Picture an organisation running an accounting system, a warehouse system, an HR system and a procurement system, that now wants an AI assistant able to answer a question like "how much does this customer still owe us". In the world before MCP, the development team had to write a separate connector for every pairing — this AI with that system, another AI with the same system — and switching AI provider meant rebuilding the lot.

MCP acts as a standard plug. A business system exposes what is called an MCP server, which advertises the tools it offers — search invoices, check a balance, look up a stock level. On the other side, the AI acts as an MCP client that knows how to read that list of tools and call them the same way every time. Write the connector once, use it with several AI vendors. That is why the protocol spread so quickly among organisations building agentic AI systems, and why it now matters to IT departments that never intended to be early adopters. For protocol basics and a worked configuration example, see our article on using MCP with Claude.

The biggest change: sessions are gone

In earlier specification revisions, a conversation between client and server had to start with an initialize handshake: a greeting that agreed which protocol version both sides would speak, after which the server issued an identifier for that connection. Every subsequent request had to carry that identifier in an Mcp-Session-Id header so the server knew it was still talking to the same party.

That works nicely while the MCP server runs on a single machine. It stops working the moment an organisation wants a real deployment serving hundreds of users, because the server has to remember the state of every open connection. Put several instances behind a load balancer, and a follow-up request routed to an instance that has never seen that identifier simply fails. The usual workarounds — pinning each user to the same instance, or adding a shared state store — both add moving parts that can break.

The 2026-07-28 specification cuts that knot by removing the initialize handshake and Mcp-Session-Id altogether. Every request becomes self-contained: it carries everything the server needs in one go. An MCP server is then just another HTTP service. Round-robin load balancing works out of the box, instances can be added or removed freely, and a single instance can be restarted without disconnecting anyone.

Roughly what a tool call looks like (illustrative shape, not the full specification):

POST /mcp
Content-Type: application/json
Authorization: Bearer <access_token>
# Older revisions also required the Mcp-Session-Id returned by initialize.
# In 2026-07-28 that line is gone — the request stands on its own.

{
  "jsonrpc": "2.0",
  "id": 42,
  "method": "tools/call",
  "params": {
    "name": "search_invoices",
    "arguments": { "customer": "ACME", "status": "open" }
  }
}

Enterprise-Managed Authorization: central IT finally gets a say

The other half of the story is authorization. The complaint organisations have voiced consistently is that an employee can install an AI tool on their own machine and wire an external MCP server into it, with IT having no visibility that the connection exists at all. It is the same pattern as the shadow IT wave that arrived with cloud services a decade ago — except that this time the far end of the connection is a system holding real business records.

Enterprise-Managed Authorization, which reached stable status on 6 July 2026, closes that gap. The idea is to move approval away from "the user clicks accept" and towards "the organisation decides in advance, at its central identity provider". An organisation can then state which groups of employees may connect to which MCP servers, and revoking access centrally when someone leaves cuts every connection at once. Anthropic, Microsoft and Okta implemented it from the start, which matters because a control plane only works if both the identity vendors and the AI vendors honour it.

The same release folds in six authorization-related proposals, all of which align MCP with standards the industry already runs on — OAuth 2.0 and OpenID Connect — instead of inventing MCP-specific machinery. One concrete example is the requirement to validate the iss value that identifies which authorization server issued a token, following RFC 9207, which closes off mix-up attacks where a client is tricked into presenting a token to the wrong party. The direction is the same one we described in our article on enterprise information security: stop improvising, and stand on standards that have already been reviewed for years.

The authorization flow in outline (illustrative):

1) client calls the MCP server without a token
   -> server responds 401 and points at the expected token issuer

2) client sends the user to the organisation's identity provider
   (OAuth 2.0 / OIDC) -> the ORGANISATION decides whether this user
   may connect to this server at all

3) client receives an access token and must confirm that iss matches
   the issuer it expected (per RFC 9207) before using it

4) every later request simply carries
   Authorization: Bearer <access_token>  — no session id anywhere

Three additions, and three features on the way out

Beyond those two headline changes, the release adds structure that lets MCP grow without amending the core every time, and retires features that turned out to see little real use.

What to prepare before letting an AI touch real data

Specification news tends to be read as a developer topic, but the more important decisions sit with IT leadership: what are we willing to let an AI read, and can we prove after the fact what it actually read? Those questions can be answered before any tool is chosen.

• Inventory what is already connected — many organisations already have employees running AI tools wired into external services, with no central list. Build that list first.
• Settle central identity — EMA only pays off if there is a central identity provider to enforce it. If every system still has its own separate password, the benefit never arrives.
• Scope permissions at the destination, not at the AI — the account an AI connects with should carry only the rights it genuinely needs, not borrowed administrator credentials because that was quicker to set up.
• Insist on an audit trail — if you cannot say who asked for what, when, and through which channel, you are not ready. This ties directly into the principles in AI governance for organisations.
• Start read-only — let the AI search and summarise before letting it create or amend records, until the review process has been proven.

What it takes to connect an AI to an ERP — and where Saeree ERP stands

To be straightforward about it: Saeree ERP does not currently ship an MCP server, and our own AI assistant is still in development. This article is not a claim that we are ready to plug into the new standard on day one. It is an explanation of the conditions that have to exist first.

There are two of them. The first is that the target system must expose an API that can be called at all. The second, and the more important one, is that the system must be able to express permissions finely enough — because as described above, the protocol governs only who may connect, never what they may do once connected. The business system is the last line of control.

On that second condition, what Saeree ERP provides today is concrete. An organisation's own administrator can grant permissions by role and by menu, set a user to inactive when someone leaves or changes duties, and define the period during which an account is valid (valid from–to) for temporary staff or external auditors. Every change carries a record of who amended which entry and when. None of that requires a request to the vendor. The system also supports two-factor authentication to reduce the risk of account takeover, which matters more, not less, once an account may be driven by automated tooling rather than by a person at a keyboard.

The question of where the data physically sits follows close behind. Organisations that have to explain their data location to an auditor usually keep core systems in their own data centre and then decide, deliberately, which parts an external service may reach. That is the same trade-off we set out in on-premise versus cloud, and the same instinct behind treating data-protection obligations as a design input rather than an afterthought — a point we cover in PDPA and your ERP system.

Conclusion

MCP has travelled from an open-source project launched in late 2024 to a specification designed for real enterprise deployment. Removing sessions turns an MCP server into an ordinary HTTP service that an operations team can run with the skills it already has. Enterprise-Managed Authorization turns each connection into something the organisation grants and can withdraw centrally, rather than something each employee accepts on their own.

What a standard cannot do is decide on your behalf which data an AI should see, and what it should be permitted to do with it. Record-level permissions, disabling accounts that are no longer in use, and a usable audit trail all remain the responsibility of the business system at the far end. Organisations that have those two things in order will be the ones that benefit from the new standard soonest — and carry the least risk while doing so.

"A connection standard tells you how to plug the cable in. It never tells you what the other end should be allowed to see — that answer still lives in the permissions of your own business system."

- The Saeree ERP team

References

• Model Context Protocol Blog — The 2026-07-28 MCP Specification Release Candidate (21 May 2026)
• InfoQ — AI Model Context Protocol Adds Centralised Auth for Enterprise (6 July 2026)
• Model Context Protocol — official specification documentation
• RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification

Information verified as of 20 July 2026.