What Is MCP (Model Context Protocol)? The 2026 Spec Removed the Session

MCP is an open standard for connecting AI applications to external systems: a server publishes what a system can do, and any compatible client can discover and call it. That definition is stable and it is the answer to the question. What is not stable is the mechanism underneath it, and that is where most current explanations of MCP have quietly gone out of date.

On 28 July 2026 the protocol removed the handshake. There is no initialize exchange, no protocol-level session, and no Mcp-Session-Id header. Every request now carries its own protocol version and client capabilities as metadata, and the server accepts or rejects each request independently. Diagrams showing a client opening a session with a server are drawing the previous era of the protocol.

This guide gives the definition, specifies what the July 2026 revision changed, and then does the part no general explainer does: it sets the three commerce MCP surfaces you can actually deploy today — WooCommerce, Shopify, and NetSuite — side by side on the axis that decides whether they are safe, which is authentication, and names the protocol-revision mismatch already sitting between them.

Contents

• What MCP is, in one paragraph
• What the 28 July 2026 revision changed
• Which era do your client and server speak?
• What an MCP server actually exposes
• What WooCommerce, Shopify and NetSuite actually ship
• Why the three auth models are not interchangeable
• What MCP does not let an agent do to your store
• MCP calls spend the same NetSuite concurrency budget as your integrations
• The security rules the specification makes mandatory
• Before you expose a store or ERP over MCP

What MCP is, in one paragraph

The Model Context Protocol is an open standard that defines how an AI application discovers and calls capabilities in an external system. The protocol’s own documentation offers the comparison “a USB-C port for AI applications” — a standard connector, so a system implements it once rather than once per client. The practical effect is the elimination of per-client integration work: a server that exposes your order data is callable from any compatible client without a second build.

Three roles appear in every MCP deployment. The host is the AI application the user interacts with. The client lives inside the host and speaks the protocol. The server is the process that fronts your system — your store’s REST API, your ERP, your database — and translates protocol calls into real operations against it. Messages are JSON-RPC.

Governance is the durable fact worth citing. Anthropic open-sourced MCP on 25 November 2024, then donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation, announced 9 December 2025, alongside Block’s goose and OpenAI’s AGENTS.md as the other founding contributions. AWS, Bloomberg, Cloudflare and Google joined as members. Vendor-neutral governance is why Oracle, WooCommerce and Shopify have each been willing to ship MCP endpoints into their own products rather than wait out a format war.

What the 28 July 2026 revision changed

The 2026-07-28 revision made MCP stateless, and the maintainers describe it as the largest revision since launch. The initialize / notifications/initialized handshake is gone. Protocol-level sessions and the Mcp-Session-Id header are gone from the Streamable HTTP transport. Every request now carries io.modelcontextprotocol/protocolVersion and io.modelcontextprotocol/clientCapabilities in its _meta field, and the server judges each request on its own.

The stated reason is deployability. With no session to pin a client to a process, requests route through ordinary load balancers and no shared session store is required. Servers that genuinely need state across calls are told to mint explicit handles and pass them as ordinary tool arguments, which makes that state visible in the tool contract instead of hidden in the transport.

Several other pieces moved in the same revision. Servers must now implement server/discover, an RPC that returns supported protocol versions, capabilities and identity in one call. The methods ping, logging/setLevel and notifications/roots/list_changed were removed. Stream resumability went with the sessions: the Last-Event-ID header and SSE event IDs are gone, so a broken response stream loses the in-flight request and the client must re-issue it as a new request with a new request ID. Results now carry a required resultType field, and list responses carry ttlMs and cacheScope caching hints.

Three features were deprecated rather than removed: Roots, Sampling and Logging. They keep working through a minimum twelve-month deprecation window under the specification’s new feature-lifecycle policy, but new implementations are told not to adopt them. The suggested replacements are ordinary tool parameters or resource URIs instead of Roots, direct integration with a model provider’s API instead of Sampling, and stderr or OpenTelemetry instead of Logging. The HTTP+SSE transport, deprecated since March 2025, was reclassified as formally Deprecated in the same pass.

Which era do your client and server speak?

Check both ends before you assume a connection will work, because two of the seven possible combinations fail outright. The specification names the two eras: modern revisions carry version, identity and capabilities as per-request metadata (2026-07-28 and later), and legacy revisions establish a session with an initialize handshake (2025-11-25 and earlier). An implementation supporting both is dual-era.

The table is the specification’s own compatibility matrix, condensed.

Verdict: dual-era is the only safe posture for anything you ship this year, and it is a property of the server, not of a request — clients are told to cache the era they detected for the lifetime of that server process or origin. If you are commissioning an MCP server for your store or ERP, “which protocol revisions does it serve?” belongs in the acceptance criteria, not in the post-launch bug report.

This matters right now because the ecosystem is mid-migration. Oracle’s documentation for the NetSuite AI Connector Service requires the connecting AI client to follow “Protocol version 2025-06-18” — by the specification’s own definition, a legacy, handshake-based revision, three revisions behind current. It works today because the major AI clients are dual-era. It works because of a compatibility path, not because the mental model in the average explainer is current.

What an MCP server actually exposes

An MCP server exposes three things, and the distinction between them decides your risk. Tools are actions the model can invoke — create a record, update an order status. Resources are data the model can read — an order list, an inventory level. Prompts are reusable prompt templates the server offers for common tasks.

Tools are the only one of the three that changes anything, which makes the tool list the security review artifact for an MCP deployment — not the model, not the prompt, and not the vendor’s marketing page. Read the tool list and you have read the complete set of state changes an agent can make through that server.

Read it as the caller, though, not as an administrator. Under the current revision the tool set returned by tools/list must not vary per-connection, but it may vary by the authorization presented on the request — the specification’s example is returning only the tools the caller’s granted scopes permit, since credentials are now per-request input rather than connection state. A review performed with an admin credential can therefore show a different, larger surface than the one a given integration actually receives. Enumerate the list using the exact credential the integration will run with.

Note what is no longer in the recommended set. Sampling, the mechanism by which a server could ask the client’s model to generate text, is deprecated. So are Roots and Logging. A server design that leans on any of the three is building on a feature with a published removal path, and the specification maintains a registry of deprecated features precisely so that this is checkable rather than a matter of opinion.

What WooCommerce, Shopify and NetSuite actually ship

All three platforms in the commerce stack we work in have shipped MCP surfaces, and they are not equivalent. The differences that matter are the authentication model and how much of the write surface is exposed. The table below is drawn from each vendor’s own documentation, checked 11 August 2026.

Verdict: treat these as three different exposure classes, not three flavours of the same feature. Shopify’s is a public storefront surface by design, WooCommerce’s is a credentialed admin surface still in preview, and NetSuite’s is an authenticated employee surface that inherits an existing permission model. The only one you can safely point a third-party agent at without further work is the one that was built to be public.

WooCommerce’s canonical set arrived with version 10.9, in an advisory dated 12 May 2026: four product abilities (woocommerce/products-query, product-create, product-update, product-delete) and three order abilities (woocommerce/orders-query, order-update-status, order-add-note). WooCommerce describes them as a transport-neutral capability contract rather than REST wrappers, usable from MCP, CLI and admin tooling alike. Its documentation also carries an explicit warning that order and customer operations may expose personally identifiable information and that compliance remains the store operator’s responsibility. For where this sits relative to agent-driven checkout, see our breakdown of what agentic commerce ships today versus what has only been announced.

Shopify’s Storefront MCP exposes get_cart, update_cart and search_shop_policies_and_faqs at /api/mcp on the shop domain, with catalog tools search_catalog, lookup_catalog and get_product on a separate /api/ucp/mcp endpoint. Shopify’s documentation states plainly that Storefront MCP servers do not require authentication.

Oracle’s NetSuite AI Connector Service is the most tightly bound of the three. Connections go to https://<accountid>.suitetalk.api.netsuite.com/services/mcp/v1/suiteapp/com.netsuite.mcpstandardtools, authenticate with OAuth 2.0 authorization code grant with PKCE, and install an integration record you can manage under Setup > Integration > Manage Integrations. Oracle is explicit about the boundary: “All data access and actions are determined by your NetSuite role and permissions. The tools don’t provide any additional access beyond what your NetSuite role allows.” Oracle also states the service has not been assessed for HIPAA compliance and must not be used for protected health information. Execution logs are retained 21 days in production and 7 days in sandbox.

Why the three auth models are not interchangeable

The auth model determines who can call the tools, and the three platforms answer that question in three incompatible ways — so a pattern that is correct on one is a breach on another. Copying a Shopify storefront integration pattern onto a WooCommerce admin endpoint is the specific mistake this section exists to prevent.

Shopify’s Storefront MCP is unauthenticated because its tools are scoped to what a shopper could already see and do: browse the catalog, manipulate their own cart, read policies. Publishing that to any agent is the intended design, not an oversight. Nothing in that tool set reads another customer’s data.

The stateless revision does add a consequence worth tracing on that surface. With no protocol session, a server that must carry state across calls returns an explicit handle and accepts it as an ordinary tool argument — the specification’s own worked example is a shopping cart. It then draws the distinction that matters here: on an authenticated server a handle is a name, and the server revalidates the caller’s authorization against it on every call; on an unauthenticated server the handle is necessarily a bearer token. A cart handle on a public storefront endpoint is therefore the credential, and the specification’s guidance follows directly — generate it with sufficient entropy, keep it opaque, and give it a bounded lifetime. A guessable cart identifier is another shopper’s cart.

WooCommerce’s deprecated MCP endpoint authenticates with an X-MCP-API-Key header carrying a REST API consumer key and secret, at one of three permission levels — read, write, or read_write. That credential is store-wide. It does not represent a shopper, and it does not narrow by record. Issuing a read_write key to reach one reporting use case grants the full product-delete and order-mutation surface along with it.

NetSuite inverts the model: the agent acts as a specific NetSuite user, and every tool call is filtered through that user’s role permissions. The security question stops being “what does this integration’s credential allow” and becomes “which role am I connecting as” — a question your NetSuite administrator can already answer, and the reason a dedicated, minimally-permissioned role is the right first move before anyone connects a client. The same least-privilege discipline that governs calling AI APIs from SuiteScript applies here in reverse: the traffic is inbound, but the governance is the same account budget.

What MCP does not let an agent do to your store

No shipped commerce MCP surface currently exposes a payment or checkout write, and that is the most useful thing to know before the conversation turns to risk. WooCommerce’s canonical ability set covers products and orders only — there is no cart, checkout, payment, customer or coupon ability in it. Shopify’s Storefront MCP can build a cart, not charge one. NetSuite’s tools reach what the connecting role can already reach through REST, which means the ceiling is your existing permission design rather than anything MCP added.

This is a deliberate boundary rather than an accident of scheduling, and it holds the line at the point where errors stop being recoverable. An agent that mislabels a product or adds a wrong order note has made a reversible mistake. An agent that captures a payment has not.

The practical consequence is that the risk in a store-side MCP deployment is concentrated in reads and in low-grade writes, which is exactly where it is easiest to under-estimate. An unscoped read tool over order data is a bulk PII egress path, and WooCommerce’s own documentation flags precisely that. Treat a broad orders-query ability as a data-export surface, because that is what it is. The same framing applies to any model reading production records — the reasoning we set out in how language models are actually being used inside NetSuite workflows.

MCP calls spend the same NetSuite concurrency budget as your integrations

An MCP connection is not a separate lane. Oracle states that unless an administrator assigns the integration record a specific concurrency governance limit, the AI Connector Service uses the same resources as every other integration and is limited by the account’s concurrent-request limit — and it can only use the portion left unallocated after other integrations have taken their share.

Oracle’s own worked example: with a total integration concurrency limit of five concurrent requests and two allocated to a REST web services integration, the AI Connector Service can use only the remaining three. Exceed it and the caller receives a Too Many Requests error, at which point the user has to ask the AI client to retry.

There is a multiplier here that is easy to miss when sizing this. Oracle notes that a single prompt calling a single MCP tool produces one main request that is “typically preceded by additional requests specified by the MCP protocol,” and tells you to count those too. One user question is therefore worth more than one slot against the account budget. Oracle also notes AI clients typically support up to about 5,000 rows per call, and that large queries risk token limits and timeouts. Plan MCP capacity against the same account-level ceiling that governs your sync jobs, not as new headroom — the arithmetic is the one covered in our AI for commerce teams guide hub.

The security rules the specification makes mandatory

MCP’s authorization chapter is normative, and three of its requirements exist specifically to stop token misuse — so they are the ones to check in any server you did not write yourself. A protected MCP server acts as an OAuth 2.1 resource server. It must implement OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover its authorization server.

The audience rules are the load-bearing ones. An MCP server must validate that an access token was issued specifically for it as the intended audience, per RFC 8707. It must only accept tokens valid for its own resources, and it must not accept or transit any other token. Clients must not send a server any token that was not issued by that server’s authorization server, and must send the resource parameter identifying the target server in both authorization and token requests — regardless of whether the authorization server supports it.

Read together, those requirements ban token passthrough: an MCP server that forwards the token it received to a downstream API is violating the specification, not merely cutting a corner. The revision also tightened client-side validation with RFC 9207 issuer checking, and deprecated Dynamic Client Registration in favour of Client ID Metadata Documents. For the risk vocabulary around what an agent does once it holds a tool, use the OWASP GenAI Security Project’s named categories — excessive agency, tool misuse, goal hijacking — rather than improvised terms.

Before you expose a store or ERP over MCP

Work down this list in order. It is the sequence that catches the expensive problems before they reach production data.

• Confirm which protocol revisions your server serves, and require dual-era support in writing before accepting delivery.
• Confirm the revision your intended AI client speaks, and check it against the server’s list — the compatibility matrix has two failing cells.
• Read the server’s full tool list and treat it as the complete set of possible state changes.
• Create a dedicated, minimally-permissioned NetSuite role for the connection rather than reusing an administrator role.
• Classify every read tool that touches orders or customers as a PII egress path and record where that data goes.
• Verify the server validates token audience and does not forward received tokens to downstream APIs.
• Check the integration record’s concurrency allocation before go-live, and size for more than one request per user prompt.
• Confirm no write tool reaches payment, refund or fulfilment capture without a human approval step.
• Record log retention limits against your own audit requirements — 21 days production and 7 days sandbox for the NetSuite service.
• Re-check any deprecated feature the server depends on: Roots, Sampling, Logging and HTTP+SSE all have published removal paths.

MCP removes per-client integration work; it does not remove integration design. Deciding which records an agent may reach, under which identity, with which writes gated, is the same scoping exercise that governs any other connection into a store or an ERP — and it is the part that does not come out of a specification. If you are working out where an agent surface fits against an existing NetSuite and WooCommerce sync, that scoping is the work we do.

Frequently asked questions

Related guides

• AI Invoice Reconciliation in NetSuite: A SuiteScript Pattern That Scales Past 10,000 Invoices a Month
• How AI Is Reshaping E-Commerce Integrations: Why a Model in the Data Path Breaks Retry
• LLMs Inside ERP: How AI Language Models Are Being Used in NetSuite Workflows in 2026