MCP Is Growing From a Tool Protocol Into an Operating Layer

The web scaled when the request became portable

The web did not scale because websites stopped having state. Shopping carts, accounts, payments, and databases all kept state. It scaled because the request became portable enough for browsers, servers, proxies, and infrastructure to coordinate without sharing one fragile conversation.

AI-connected software is reaching the same transition.

The first phase of MCP proved that a model could discover and call a tool. That was the essential opening. It gave assistants a common way to reach software, data, and workflows outside the model.

But access is only the beginning. Real software has different client versions, optional capabilities, human decisions, long-running work, and partial failures. A tool call proves access. An operating contract makes the experience dependable.

The 2026-07-28 revision carries more of that operating contract into the protocol itself.

A tool call is not yet a dependable product

Imagine a compliance platform whose customer asks an AI agent to prepare a quarterly evidence package.

The agent must collect thousands of records, check them against policy, flag exceptions, request missing information, and present the final package for approval. The work takes twenty minutes. A human decision is needed halfway through. The final result is easier to review in a structured interface than in a wall of text.

A basic tool call can start this work. It cannot, by itself, define what happens next.

The request has to survive a closed chat tab. The user has to find the same run again. A scheduled agent has to start the job at quarter end without pretending a person is present. The server has to know whether the client can render a review widget or handle a request for more information.

The gap between a demo and dependable software is the machinery around the call. When every developer invents that machinery independently, clients behave inconsistently and every protocol change becomes an application migration. The new specification standardizes more of this layer.

The new MCP contract makes clients and servers explicit

Earlier MCP clients begin with an initialize handshake and negotiate a protocol version for the session. That model remains important because many deployed clients use it today.

The 2026-07-28 revision retires the handshake for modern clients. Each request travels on its own. It carries the protocol version in the MCP-Protocol-Version header, the operation in the required Mcp-Method and Mcp-Nameheaders, and the client's identity and capabilities in _meta. A minimal modern request looks like this:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: prepare_evidence_package

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"prepare_evidence_package","arguments":{"quarter":"Q2"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"acme-agent","version":"1.0"}}}}

Clients can call the new server/discover RPC up front to learn which versions, capabilities, instructions, and extensions a server supports. No request depends on it. If a client asks for an unsupported version, the server returns the versions it does serve so the client can retry deliberately instead of guessing.

The official versioning contract also defines dual-era servers. One endpoint can serve the established initialize-based era and the modern per-request era at the same time. Clients and servers can move at different speeds without turning every upgrade into a coordinated cutover.

Modern MCP is stateless at the protocol layer. The Mcp-Session-Id header is gone. Applications still store user data and workflow progress, but servers no longer need a hidden protocol session to route each request. Any request can land on any instance behind a plain round-robin load balancer. If your server needs state across calls, mint an explicit handle from a tool and have the model pass it back as an argument. The model can see the handle and thread it between tools, which works better than state hidden in the transport.

The practical result is simpler infrastructure and explicit compatibility.

Agent experiences can now ask, show, and continue

Software used through an agent should not be limited to one request followed by one block of text.

MCP Apps, now an extension under the formal framework, gives a tool a standard way to attach a sandboxed interactive interface. A travel tool can compare options. A compliance tool can show exceptions, evidence, and an approval control. The conversation remains the entry point. The interface appears only when it improves the task.

Multi Round-Trip Requests handle the other half: input mid-call. When a tool needs a missing parameter or an exact-action confirmation, the server returns resultType: "input_required" along with the requests it needs answered. The client collects the answers and retries the original call with them attached in inputResponses. A final result is explicitly marked complete.

MRTR replaces the server-initiated elicitation/create, sampling/createMessage, and roots/list requests that previously required a held-open bidirectional stream. That is what makes guided interaction possible over a stateless protocol.

This matters for trust. An agent can prepare a consequential action while the server still requires the user to confirm the exact operation before execution.

At Noodle Seed, guided input and exact-action confirmation are already implemented for modern requests using sealed, bounded state and single-use confirmation protection. The established legacy interaction behavior is preserved for older clients. We currently describe modern negotiation and multi-round support as preview while host adoption continues to be validated.

Our widgets have been exercised successfully in both ChatGPT and Claude. The runtime adapts the host-specific presentation metadata each client expects, so developers do not need separate business logic for every host. Visual details can still vary by host.

A headless product can still have a face. It simply presents the right face for the task and the host.

The boring protocol details are what make software operable

The most valuable infrastructure improvements are often the least dramatic in a feature list. This release is full of them.

Routing moved into headers. Mcp-Method and Mcp-Name are now required on Streamable HTTP requests, so a gateway, rate limiter, or WAF can route and meter on headers instead of parsing JSON bodies. Servers reject requests where the headers and body disagree, which closes a class of routing mismatches.

List results became cacheable. Responses from tools/list, prompts/list, resources/list, and resources/read carry ttlMs and cacheScope, modeled on HTTP cache semantics. Combined with deterministic ordering, clients can cache tool catalogs safely and keep upstream prompt caches stable across reconnects.

Tracing is standardized. W3C Trace Context propagates through fixed key names in _meta, so a distributed trace can follow a call from the client SDK through the MCP server into downstream systems in any OpenTelemetry-compatible backend.

Schemas got real. Tool inputSchema and outputSchema are lifted to full JSON Schema 2020-12. Input schemas keep the type: "object" root constraint but now allow composition, conditionals, and references. Error behavior tightened too. The code for a missing resource changed from the MCP-custom -32002 to the JSON-RPC standard -32602, so grep your client for the old literal.

Authorization hardened in specific ways. Authorization servers should return the iss parameter per RFC 9207 and clients must validate it before redeeming a code, which closes an authorization-server mix-up hole. Client credentials are bound to the issuer that minted them. Dynamic Client Registration is formally deprecated in favor of Client ID Metadata Documents, with a compatibility window.

And the protocol finally has a lifecycle. Roots, Sampling, and Logging are deprecated. They keep working for at least twelve months under the new deprecation policy, but new implementations should use the replacement patterns. Every future removal gets the same minimum window.

None of these items sells a product on its own. Together they replace assumptions with declarations and give implementers fewer opportunities to disagree in production. Less defensive glue for developers. Better failure evidence for businesses. More consistent behavior for end users.

Compatibility is part of the product

A new specification does not cause every MCP client to upgrade on the same morning.

Some clients will adopt the modern era quickly. Others will continue using the established initialize flow. Some will support MCP Apps but not Tasks. Some will add extension support gradually. This is normal for an open protocol used across many products.

The wrong response is to make every developer choose between new capabilities and existing users.

Noodle Seed handles the choice inside the protocol runtime. One deployed app and one endpoint answer both eras. Legacy clients retain the wire behavior they already depend on. Modern clients declare their version and capabilities per request, discover what the server supports, and receive modern results.

The upgrade belongs in the runtime, not in every customer's application.

That boundary protects what developers have already shipped. Apps do not need a new manifest. Deploy records, tools, resources, prompts, connectors, widgets, URLs, and runtime execution stay in place. Customers do not need to redeploy merely to gain the new serving behavior.

The application describes the capability. The runtime presents it safely to the client making the request. That is protocol progress without customer churn.

What Noodle Seed developers can rely on today

Noodle Seed now serves the modern 2026-07-28 contract alongside all legacy revisions the platform already accepted. The supported version set is owned by the platform and remains consistent for apps served from the same origin.

Modern clients can discover the server, negotiate explicitly, receive the modern result and error shapes, and complete guided input or confirmation rounds. Legacy clients continue through their existing initialize, list, and call flows.

MCP Apps remain useful in either era. If a client can render a widget, Noodle Seed serves the UI resource and the metadata required to connect it to the tool. If it cannot, the tool still returns meaningful content. The capability stays useful without making the interface a hard dependency.

The authorization layer has adopted the relevant 2026-07-28 requirements, including issuer validation, while preserving existing OAuth connections. Inbound credentials remain bound to the intended resource and are never forwarded to a business backend.

Developers did not add version switches, create separate host deployments, or rewrite their tool workflows. That is the point of a governed runtime. The protocol seam changes while the business capability remains stable.

What comes next: machine identity and durable work

Two opt-in MCP extensions expand the model beyond work performed inside one foreground conversation. Noodle Seed plans to implement both. Neither is part of our shipped developer surface today.

The first is OAuth Client Credentials. It gives a confidential client its own identity through the OAuth client credentials grant, using a client secret or a signed JWT assertion. A scheduled service, CI job, daemon, or background agent can request a narrowly scoped token without impersonating a human user.

This does not mean unlimited autonomy. The client must be registered, authenticated, and granted explicit scopes. A reporting agent might read evidence and start a report while lacking permission to approve it.

The second is Tasks, now a formal extension with a poll-based lifecycle. A long-running operation can return a durable task handle instead of keeping the original request open. A client can poll status with tasks/get, receive updates, cancel cooperatively, respond when input is required, and retrieve the completed result later.

A task handle does not by itself guarantee that a job runs only once or stops immediately when cancelled. The implementation still needs durable storage, idempotency, recovery, authorization, and expiry. The extension provides the shared lifecycle on which those guarantees can be built.

Together, these extensions connect two previously separate worlds: interactive assistants and operational automation.

The complete value chain

Return to the quarterly compliance package.

A Noodle Seed developer defines the tools, scopes, review widget, required input, and approval step once, focusing on product rules instead of inventing a protocol state machine. Their business customer authorizes a background reporting client with limited scopes. At quarter end, it starts a durable Task, receives a handle, and continues other work while the evidence package is processed.

If records are missing, the Task pauses for input. The end user reviews exceptions in a widget and confirms the exact action. The Task resumes, and its result remains available after the original conversation ends.

For developers, the value is less protocol, identity, and state-machine infrastructure to build and maintain. They spend more time on the differentiating workflow while the runtime absorbs protocol changes. For their business customers, the value is background automation that can be governed, observed, and sold as a product capability. The business decides which machine identities exist, what each can do, and where approval remains mandatory. And the end user gets work that starts where they already are, asks for attention only when judgment matters, and survives interruptions without losing progress.

The best protocol upgrade is one users never notice

MCP will continue to evolve. Clients will continue adopting capabilities at different speeds. New extensions will appear as agent-connected software takes on more consequential work.

Developers should not have to rebuild their product around every protocol generation.

Noodle Seed's thesis is that developers define the useful software body and experience. The governed runtime absorbs compatibility, identity, and host adaptation, and eventually durable work.

The best protocol upgrade is one your existing users never have to notice.

Users should keep the app that already works. New clients should gain richer capabilities while older clients receive the behavior they understand. Developers should not choose between progress and continuity.

If your customers are asking to use your software from ChatGPT, Claude, or their own agents, build the governed headless version with Noodle Seed. Start with the workflow they already care about, prove it locally, and deploy when it is ready.

Sources

• MCP 2026-07-28 changelog
• MCP 2026-07-28 release announcement
• MCP protocol versioning
• OAuth Client Credentials extension
• Tasks extension