3 ways to expose legacy APIs to AI agents before the 28 July 2026 MCP switch

Summary. The Model Context Protocol specification 2026-07-28 is locked as a release candidate since 21 May 2026 and ships final on 28 July 2026. Its maintainers call it the largest revision of the protocol since launch, and it contains breaking changes. Six Specification Enhancement Proposals remove the session layer: the initialize handshake is gone under SEP-2575, and the Mcp-Session-Id header is gone under SEP-2567. Roots, Sampling and Logging are deprecated under SEP-2577, with at least 12 months before any removal. The error code for a missing resource moves from the MCP-custom -32002 to the JSON-RPC standard -32602. For teams with a legacy integration layer, this is the moment the question stops being theoretical. If an AI agent is going to read your order system, something has to expose it, and the interface contract just changed. Three approaches are viable, they cost very different amounts, and on Amazon API Gateway the gap between a REST API at $3.50 per million calls and an HTTP API at $1.00 per million is the difference between a pilot you can afford and one you cannot.

What actually changed in MCP 2026-07-28

The release candidate was published on 21 May 2026 by lead maintainers David Soria Parra and Den Delimarsky. Their framing is direct: "The headline change is that MCP is now stateless at the protocol layer."

That sentence has more operational weight than it first appears.

Under the previous 2025-11-25 specification, calling a tool over Streamable HTTP meant establishing a session first. The client sent an initialize request, the server responded with an Mcp-Session-Id, and every subsequent request carried that header, pinning the client to whichever server instance issued it. Horizontal scaling therefore needed sticky routing and a shared session store.

In 2026-07-28, the same call is one self-contained request:

            POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}
          

The protocol version, client info and client capabilities that were exchanged once at connection time now travel in _meta on every request. A new server/discover method lets clients fetch server capabilities when they need them upfront. The maintainers describe the deployment consequence plainly: a remote MCP server that previously needed sticky sessions, a shared session store and deep packet inspection at the gateway can now run behind a plain round-robin load balancer.

Three further changes matter for anyone operating this in production.

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers so load balancers, gateways and rate limiters can route on the operation without reading the body, and servers reject requests where the headers and body disagree. List and resource read results carry ttlMs and cacheScope, modelled on HTTP Cache-Control, so a client knows how long a tools/list response stays fresh and whether it is safe to share across users. W3C Trace Context propagation in _meta is documented with the traceparent, tracestate and baggage key names locked down, so a trace that starts in a host application follows the tool call through the client SDK, the MCP server and whatever the server calls downstream, arriving as one span tree in an OpenTelemetry-compatible backend.

If you match on the literal -32002 error code anywhere in your client, that code changes to -32602 under SEP-2164. It is a one-line fix that will otherwise surface as a mystery in production.

Why this lands on the integration team, not the AI team

The common failure in enterprise AI programmes is not the model. It is that the model has nothing trustworthy to call.

An agent that can answer questions about your business needs an interface to your business. In most organisations that interface does not exist in a form anything can safely consume. What exists is a 2016 SOAP service, a REST API that returns HTTP 200 with an error object in the body, a database that three teams write to directly, and a batch job that reconciles the difference at 02:00. None of that is a tool definition.

So the AI roadmap stalls at the integration layer, and it stalls quietly, because the pilot demo worked against a mock.

MCP is one answer to this: a standard way to describe what a system can do and let a model call it. Which is why the 2026-07-28 changes are worth reading before you commit an architecture. Building a stateful MCP server in August 2026 against a spec that removed sessions in July is an expensive way to learn the release calendar.

Three ways to expose a legacy system

There are three shapes that work. They are not equivalent, and the choice is usually driven by how much you trust the underlying system rather than by engineering taste.

1. Direct MCP server over the existing API

Write an MCP server that calls your existing REST or SOAP endpoints and presents them as tools. The legacy system does not change. The MCP server does the translation, the auth exchange, and the shaping of responses into something a model can use.

This is the fastest path and the right default when the underlying API is broadly sane. The work is in the tool definitions, not the plumbing. With full JSON Schema 2020-12 now available for tool inputSchema and outputSchema under SEP-2106, including composition with oneOf, anyOf and allOf, you can describe a legacy contract accurately rather than flattening it. Note the constraint the spec adds: implementations must not auto-dereference external $ref URIs, and should bound schema depth and validation time.

The trap is one-to-one mapping. A tool per endpoint produces forty tools, and a model choosing among forty near-identical tools chooses badly. Model the tools on the tasks a user wants done, not on the endpoints that happen to exist.

2. an anti-corruption layer, then MCP on top

When the legacy contract is genuinely bad, wrapping it directly propagates the badness into your tool definitions and then into the model's behaviour. The fix is an intermediate service that owns a clean domain model and translates outward.

This costs more and it is the right call when the legacy system is being replaced anyway, when several consumers need the same clean contract, or when the underlying semantics are unsafe to expose. It also gives you the natural place to enforce idempotency, which matters more with agents than with humans because an agent will retry. We covered the mechanics in idempotency keys and safe retries for REST APIs; the short version is that any agent-callable write needs a key, because a model that gets a timeout will try again.

The architectural pattern here is the same one that governs a monolith decomposition, and the same caution applies: define the boundary from observed usage, not from the org chart. We wrote that up in application modernization from monolith to microservices.

3. Read-only projection

For a large class of questions the agent does not need to call the system at all. It needs to read a projection of the system's data, kept current, with no write path.

This is the cheapest and safest option and it is consistently underused. If the ask is "which orders are stuck", a read replica or a materialised view with an MCP server in front answers it with no risk to the transactional system, no auth exchange into a 2016 service, and no possibility of an agent mutating anything. Start here when the use case is analytical. Move to option 1 or 2 when the agent genuinely needs to act.

The last two rows are in the table because they get proposed, not because we recommend them.

What the gateway costs

Integration architecture arguments are usually settled by cost, so here are the published numbers as of the Amazon API Gateway pricing page updated 13 May 2026.

HTTP APIs are $1.00 per million requests for the first 300 million per month, then $0.90 per million. REST APIs are $3.50 per million for the first 333 million, $2.80 per million for the next 667 million, and $2.38 per million beyond that. Data transfer out is $0.09 per GB. Optional REST API caching is charged hourly by cache size: a 1.6 GB cache is $0.038 per hour, which is $0.912 per day.

AWS's own worked example puts a serverless web application at 432 million HTTP API requests per month, billed as 300 million at $1.00 per million plus 132 million at $0.90 per million, for $418.80, or $0.97 per million blended. The equivalent traffic on REST APIs starts at $3.50 per million.

The relevance to MCP is that ttlMs and cacheScope are now in the protocol. A tools/list response that clients cache for the server's declared TTL is a call you never pay for. On a REST API at $3.50 per million, a chatty client listing tools on every interaction is a line item; under the new caching semantics it does not have to be.

The WebSocket row deserves a note. Because the stateless rework removes the need to hold an SSE stream open to deliver server-initiated prompts, replaced by an InputRequiredResult that the client answers and re-issues with the echoed requestState under SEP-2322, a whole class of long-lived-connection billing and load-balancer tuning stops being necessary.

Authorization is where the migration bites

Six SEPs harden the authorization specification to sit closer to how OAuth 2.0 and OpenID Connect are actually deployed. Two of them will show up in your migration.

Clients must validate the iss parameter on authorization responses per RFC 9207 under SEP-2468. The spec flags this as a low-cost mitigation for a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern, and warns that a future version will expect clients to reject responses that omit iss. If you run an authorization server, start supplying it now.

Clients also declare their OpenID Connect application_type during Dynamic Client Registration under SEP-837, which fixes the common failure where an authorization server defaults a desktop or CLI client to "web" and then rejects its localhost redirect URI. If your team has ever lost a day to that, it now has a name and a fix.

Agent-facing endpoints change the threat model in ways that are worth thinking about separately from the protocol mechanics; we covered that ground in prompt injection and AI agent security guardrails.

The deprecations, and why they are not urgent

Roots, Sampling and Logging are deprecated under SEP-2577, with the replacements the spec names: tool parameters, resource URIs or server configuration for Roots; direct integration with LLM provider APIs for Sampling; stderr on stdio transports and OpenTelemetry for Logging.

These are annotation-only deprecations. The methods, types and capability flags keep working in this release and in every specification version published within a year of it, and removing any of them requires a separate SEP under the new feature lifecycle policy, which guarantees at least twelve months between deprecation and the earliest possible removal.

So: plan the migration, do not panic the sprint. The breaking change that needs action before 28 July 2026 is the stateless transport rework, not the deprecations.

One caveat that does need attention: anyone who shipped against the 2025-11-25 experimental Tasks API has to migrate. Tasks has graduated from an experimental core feature to an extension, the lifecycle is reshaped around the stateless model with tasks/get, tasks/update and tasks/cancel, and tasks/list is removed because it cannot be scoped safely without sessions.

A migration sequence that works

The order below front-loads the cheap reversible work and defers the expensive irreversible work until the spec is final on 28 July 2026.

Start by inventorying what an agent would actually need to call, expressed as tasks rather than endpoints. Most teams discover the list is shorter than feared, and that half of it is read-only, which routes to the projection option.

Next, pick the shape per use case. Read-only questions go to a projection. Sane APIs get a direct MCP server. Bad contracts get an anti-corruption layer, and that decision gets made once rather than per endpoint.

Then check the four things the new spec changes in your code: the -32002 to -32602 error code, any client that depends on the initialize handshake, anything storing an Mcp-Session-Id, and any gateway rule that inspects the request body rather than routing on Mcp-Method.

Finally, validate against the release candidate rather than waiting. The maintainers set the ten-week window from 21 May to 28 July 2026 specifically so SDK maintainers and client implementers could validate against real workloads, and under the SDK tier system Tier 1 SDKs are expected to ship support inside it. A Standards Track SEP can no longer reach Final status until a matching scenario lands in the conformance suite, so the conformance suite is the thing to test against.

The real cost of an integration programme is rarely the connectors. It is the contracts you accept without reading them.

India-specific considerations

For teams building this out of India for global systems, two things change the calculus.

The first is that the integration layer is where data residency decisions get made, and they get made implicitly. An MCP server that proxies a query to a system in one region and returns personal data into a model hosted in another has just made a cross-border transfer decision, usually without anyone writing it down. Decide it deliberately, at the boundary, in the anti-corruption layer if you have one.

The second is the Digital Personal Data Protection Act, 2023, which places obligations on the data fiduciary that determines the purpose and means of processing personal data. As Anirudh Burman's analysis for the Carnegie Endowment sets out, those duties include erasure on consent withdrawal or on expiry of the specified purpose, breach notification to the Data Protection Board of India, and appointing a data protection officer. An agent-callable tool that returns customer records is processing personal data, and the tool definition is a good place to be explicit about which fields it is allowed to return. We design integrations aligned with DPDP requirements; the compliance determination itself sits with the operator and their counsel.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, CMMI Level 5 appraised and MSME certified, with senior-led engineering teams and partnerships including AWS, Microsoft and Google. We work on the layer between legacy systems and AI agents: inventorying what an agent actually needs to call, choosing per use case between a direct MCP server, an anti-corruption layer and a read-only projection, and building the result against the 2026-07-28 specification rather than the one it replaces. If your AI roadmap is stalled at the integration layer rather than the model, talk to our team about scoping the first slice. Related reading: enterprise AI agent development and managed Kubernetes and AI platform services.

References

1. Model Context Protocol Blog, The 2026-07-28 MCP Specification Release Candidate

1. Model Context Protocol Blog, The 2026 MCP Roadmap

1. Model Context Protocol Blog, The Future of MCP Transports

1. Model Context Protocol, Draft specification

1. Model Context Protocol, Draft changelog

1. Model Context Protocol, SEP-2575: remove the initialize handshake

1. Model Context Protocol, SEP-2567: remove Mcp-Session-Id

1. Model Context Protocol, SEP-2243: Mcp-Method and Mcp-Name headers

1. Model Context Protocol, SEP-2549: ttlMs and cacheScope

1. Model Context Protocol, SEP-414: W3C Trace Context propagation

1. Model Context Protocol, SEP-2106: full JSON Schema 2020-12 for tools

1. Model Context Protocol, SEP-2164: -32602 for missing resources

1. Model Context Protocol, SEP-2322: Multi Round-Trip Requests

1. Model Context Protocol, SEP-2577: feature deprecations

1. IETF, RFC 9207: OAuth 2.0 Authorization Server Issuer Identification

1. JSON Schema, Draft 2020-12

1. Amazon Web Services, Amazon API Gateway pricing

1. Anirudh Burman, Carnegie Endowment for International Peace, Understanding India's New Data Protection Law

Last updated: 16 July 2026.