Sometime in the past two years, the Model Context Protocol stopped being Anthropic’s clever idea and became the plumbing of the agent economy. The proof is not a keynote demo or a benchmark. It is a roadmap post. When a protocol project publishes a roadmap whose headline items are transport unification and SDK ergonomics, it has crossed the line from revolutionary to load-bearing. Revolutionary protocols announce capabilities. Load-bearing protocols announce deprecation policies.

Read as engineering, the document is excellent, and this piece will treat it that way. Read as the substrate that shopping agents are being built on, the five priority areas it contains verify everything except the thing a shopping agent actually needs before it recommends or buys anything: whether the product data flowing through the pipe is true.

The Rewrite That Made MCP Boring

The previous roadmap landed in March with four priorities: transport evolution and scalability, agent communication, governance maturation, and enterprise readiness. The bulk of it shipped in the 2026-07-28 specification release, and the changelog reads less like a feature list and more like a demolition notice.

Protocol-level sessions and the initialization handshake are gone (SEP-2575, SEP-2567), which means a server can now scale horizontally without holding any state. Clients can call server/discover to learn a server’s supported versions and capabilities before doing anything else. List results became cacheable (SEP-2549). Tasks moved into an official extension (SEP-2663), and a new Multi Round-Trip Requests pattern (SEP-2322) replaced server-initiated requests so that elicitation flows work on stateless servers.

The summary sentence in the maintainers’ own words: “a remote MCP server is now no different from any other HTTP workload.” Before that change, operating a remote MCP server meant shared session stores or gateway packet inspection, both of which add latency and cost. Now every request carries its own context, servers run on ordinary load-balanced HTTP infrastructure, and a counting exercise by the consultancy AFFiNCO notes the practical consequences: serverless deployment on edge workers, authorization aligned with production OAuth 2.0 and OpenID Connect, and standard headers that let gateways route and meter agent traffic without opening the request body.

Governance matured in step. A formal Contributor Ladder, Working Groups that triage their own specification proposals, and a published feature lifecycle and deprecation policy with a minimum twelve-month window before anything disappears. That last item sounds like the most boring sentence in this article. It is also the most important one for anyone selling software on multi-year contracts, because a protocol with a deprecation policy is a protocol a procurement department can sign.

Security work concentrated where enterprises actually feel pain: issuer validation, issuer-bound client credentials, Client ID Metadata Documents as the preferred client registration path, and the Enterprise-Managed Authorization extension promoted to stable, which lets organizations govern MCP server access through the identity provider they already run.

This is what winning looks like for a protocol. Nobody writes love letters about it. Everybody installs it.

The Numbers Behind the Confidence

Ask three sources how many MCP servers exist and you get three answers, and none of them are lying, because they count different things. The AFFiNCO tally records 9,652 servers in the official registry, 15,926 GitHub repositories tagged mcp-server, and 86,148 stars with 10,799 forks on the reference-servers repository, where fork counts matter more than stars because forks signal teams shipping private variants. An enterprise-adoption analysis circulating this month puts the public server count more conservatively above 5,800 while counting roughly 28 percent of Fortune 500 companies as deployers.

The download curves have the same spread. Monthly SDK tallies run from roughly 97 million to more than 400 million depending on the counting window, and the same analysis that models 750 to 900 million monthly downloads by the close of 2026 also observes that growth is decelerating in percentage terms while accelerating in absolute volume, which is the signature curve of late-stage standard adoption, not early hype.

Two more figures complete the picture. Forty-five percent of surveyed software companies run MCP in some form of production, though broad rollout alone sits at 19 percent, meaning most deployments are still narrow. And Gartner projects that 75 percent of API gateway vendors will ship MCP features by the end of this year, while CData estimates 30 percent of enterprise application vendors will launch their own MCP server in the same window. When the gateway vendors and the application vendors both fold a protocol into their release plans, it stops being an integration choice and becomes a checkbox on enterprise deals, the way REST APIs and SSO already are.

The checkbox status is underwritten by neutral governance. Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded with Block and OpenAI, with backing from Google, Microsoft, AWS, Cloudflare and Bloomberg. Figma, Intuit, Netlify, Zoom, Xero and PostHog built against the new specification revision before it shipped, and Cloudflare, AWS Bedrock and Vercel documented deployment paths of their own. Procurement’s oldest objection, vendor capture, is dead.

Agents with Passports

Of the five new priority areas, the one that will matter most to anyone building commerce agents is agent identity, and it deserves a close read because it is genuinely the right bet.

MCP authorization, as the roadmap states plainly, “is built around a person approving access in a browser.” That model fit interactive clients. It does not fit the callers arriving now, which the maintainers describe as “agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present, or delegating narrower authority to sub-agents.” The stated goal is “a standardized way to recognize and trust those agent identities, built on existing standards rather than pasted API keys and long-lived tokens.”

The engineering plan is serious: finalizing Demonstrating Proof of Possession (DPoP, RFC 9449), defining an opinionated path for agent identity and delegation through Workload Identity Federation and the ID-JAG grant behind Enterprise-Managed Authorization, and working directly with the IETF’s OAuth and WIMSE working groups so the underlying standards grow the building blocks agent identity needs.

When this lands, an MCP server will finally know who is knocking. A shopping agent calling a payments tool will present a workload-bound credential that proves what it is, whom it acts for, and what it is allowed to do, and the server can decide accordingly. That closes a real and current gap, one that AFFiNCO’s survey work sizes starkly: roughly four in ten internet-facing MCP servers today ship with zero authentication at all.

The Question None of the Five Priorities Ask

Here is the problem, and it is structural rather than cosmetic. Identity authenticates the caller. It says nothing about the payload.

Walk the five priority areas and ask of each one what it verifies. Agentic messaging primitives, webhooks and channels so clients are not left polling, govern the timing of delivery. HTTP-native transport unification governs the pipe. Agent identity governs who is calling. Improved primitives standardize the form of tool results, because “a tools/call response can carry the same output in more than one form,” and introduce progressive discovery, because “connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question, and tool selection tends to get worse as the list grows.” The SDK area governs developer comfort. Timing, pipe, caller, form, menu length, comfort.

Not one of the five contains result integrity, provenance, or content verification. Progressive discovery shrinks the menu. It does not vet the kitchen.

The security literature already knows what this omission costs, because the first systematic audit of an agent payments protocol measured it. The Ben-Gurion University and Intuit analysis of Google’s AP2 protocol cataloged 48 threats and found that the shared-MCP deployment architecture amplifies the largest number of semantic manipulation threats of any architecture studied. It flagged MCP metadata poisoning specifically, because tool descriptions persist across sessions and carry high instruction weight, and it rated pre-signing context poisoning, the attack that corrupts catalog data and tool results upstream of a perfectly valid signature, at CVSS 8.3, solidly in the High band. The paper’s framing is the sentence this whole argument rests on: “AP2 mainly secures the signed mandates and receipts; the pre-signing context that shapes them, including catalog data, tool results and A2A messages, remains outside the signed mandates.”

The market, meanwhile, is moving toward the answer before the spec does. AFFiNCO’s 2027 outlook has signed tool manifests “becoming buying criteria rather than an optional security nicety,” and registry curation and namespace trust mattering more than raw server availability. Buyers are ahead of the roadmap on integrity. The roadmap’s answer to trust is who may call. The buyers’ question is what came back.

Where the Hole Floods First: Shopping

In payments, the credential is the crown jewel, and everything else is context. Agent commerce via MCP inverts that geometry. The credential layer is being hardened by three standards bodies at once, while the content layer, the star ratings, review counts, bestseller badges and sponsored placements that decide which products an agent even considers, is the cheapest input in the entire stack to corrupt.

Follow a corruption end to end. Purchased five-star reviews inflate a listing. The listing’s aggregates flow into product APIs and scraper endpoints. Those endpoints back MCP servers that shopping agents query. The results enter model context. The context shapes the recommendation. The recommendation becomes a cart, and an agent whose identity is cryptographically impeccable signs a mandate for a product that earned nothing. Every hop after the lie enters is standardized, versioned, governed by a Linux Foundation fund, and protected by an OAuth profile. The lie itself encounters no checkpoint at any hop, because none exists.

A live demonstration from the commerce side shows how legibility compounds the problem. At a recent webinar reported by International Business Times, Nisum ran a chain of autonomous agents shopping for running shoes end to end, and when retailers blocked data access or returned unusable product specs, the agents simply dropped them. “For the agents, this is really a reason to simply skip you and go to the next retailer,” Nisum’s Guillermo Delgado said. Correct, and note the inverse: a retailer whose data is legible and poisoned gets read faithfully. Legibility is not trustworthiness. To a model, a fabricated review corpus and a genuine one are the same bytes.

What a Filtered Endpoint Looks Like

The fix is not to slow down the protocol work; every item on the roadmap deserves to ship. The fix is to give agents at least one endpoint in the loop whose value proposition is the integrity of what it returns rather than the reach of what it indexes. That is the layer GoBuy exists to provide:

  • Filter before scoring. Smart Score runs 0 to 100 on review quality and authenticity, computed only after manipulated and low-information reviews are removed, so purchased rating volume, the cheapest input to corrupt, stops being an input at all.
  • Curation instead of a firehose. Top seven verified products per category, which removes both the hundred-tool menu problem and the placement auction from the discovery path an agent walks.
  • Persistence as the test. The GoBuy Verified badge requires holding a filtered score of 80 or above for 90 days, which separates a stable property of a product from a purchased window engineered around a shopping event.
  • Machine-native delivery. Agents query the filtered trust layer over MCP at gobuy.ai/api/mcp before recommending or assembling any cart, and humans get the same signal injected onto Amazon product pages through the Chrome extension.

The protocol’s own trajectory argues for exactly this shape. Agent identity will tell the server who is calling. A filtered trust endpoint tells the caller what to believe. A stack with the first and not the second produces authenticated delivery of misinformation.

What to Watch

Four signals over the next two quarters. First, whether a specification enhancement proposal lands for signed tool manifests or result provenance; AFFiNCO’s buyer-criteria forecast gives it a constituency, and the natural home already exists in the Server Card Working Group, whose .well-known metadata conventions let a client reason about a server before connecting. Second, whether Server Cards stay capability-only or grow quality and provenance fields, which is the cheapest place in the entire ecosystem to make trust legible. Third, WIMSE and DPoP reaching production MCP deployments, the first shopping agents carrying workload-bound credentials end to end. Fourth, the first documented case of tool-result poisoning steering an agent-mediated purchase; when it arrives, the mandate will validate, the identity will validate, and the only broken link will be the one nobody certified.

The pipes are becoming boring, which is a compliment and the whole point of infrastructure. The water is the product. Point your browser at gobuy.ai, or wire the filtered trust layer into any agent at gobuy.ai/agent-docs before it signs its next cart.