Every AI tool that touches your Amazon business — the agency dashboard with an assistant bolted on, the Claude connector someone on your team wired to Seller Central, the repricer that grew a chat interface this year — talks to your accounts through a plumbing layer most operators have never heard of. On July 28, that plumbing got its largest rewrite since it existed. I gave it four sentences in Sunday's weekly synthesis. It deserves more than four sentences, because two of the changes are about what happens when a write to your catalog fails halfway through, and whose identity the tool acts under when it writes. Those are not developer concerns. Those are catalog-integrity concerns with a migration window that lands exactly on top of your Q4 prep.
What happened
The Model Context Protocol — the open standard, originally created by Anthropic, that the current generation of AI agents and assistants uses to connect to outside systems — published specification revision 2026-07-28, its largest since launch (changelog on modelcontextprotocol.io). The headline changes: the protocol is now stateless (sessions and the initialization handshake are gone), stream resumability was removed so a broken connection loses the in-flight request and the client must re-issue it as a new one, authorization was tightened around OAuth 2.0/OIDC with credentials now bound to the issuer that granted them, and three long-standing features (Roots, Sampling, Logging) entered a twelve-month deprecation window.
Why most operators will read this wrong
The dumb take is the obvious one: "this is developer plumbing, I sell products." And I understand the instinct — you did not get into ecommerce to have opinions about JSON-RPC error code allocation, and I promise you I will not be sharing mine.
But here's the pattern I keep writing about, most recently when Claude's default model swapped silently under every subscription: the layer you don't look at is the layer where changes reach your P&L unannounced. Your brand probably has somewhere between three and ten pieces of software that can write to your catalog, your prices, or your ad account. Over the past eighteen months, a growing share of them grew AI features, and the connective tissue under those features is, increasingly, MCP. When the spec that defines connection behavior, retry behavior, and identity gets rewritten, every one of those vendors is now on a migration path — and their migration schedule is not on your calendar, even though the risk lands on your catalog.
The real signal isn't "everything is about to break." Nothing breaks on day one; there's a formal twelve-month deprecation policy, which is more grace than Amazon ever gives you. The real signal is that the failure model and the identity model of third-party write access to your business both just changed, and you now have a short, specific list of questions your vendors should be able to answer.
What actually changes for a brand doing $200K/month
Three of the spec changes translate directly into operator language.
1. The retry problem is now explicit — and it's a write-integrity question. The old protocol had a mechanism for resuming a broken stream and redelivering missed messages. The new revision removes it: if the connection drops mid-request, the in-flight request is simply lost, and the client is required to re-issue it as a brand-new request. For reads — "summarize my search term report" — nobody cares. For writes, this is the whole ballgame. A price update that dies mid-flight and gets blindly re-issued can apply twice. One that dies and doesn't get re-issued silently never happened, and you find out when the January fee change hits a price you thought you'd already moved. Whether your vendor's tooling handles this correctly — idempotent writes, confirmation before retry — was always an implementation detail. Now it's a question the spec forces every implementer to answer, which means it's a question you're allowed to ask them.
2. Identity got real. The revision aligns authorization with production-grade OAuth 2.0/OIDC: credentials are bound to the authorization server that issued them, clients must validate the issuer before completing an authorization, and the old dynamic self-registration mechanism is deprecated in favor of a scheme that plays properly with enterprise identity providers. Translated: the industry is moving from "the tool has a token someone pasted in eighteen months ago" toward "the tool acts under a nameable, manageable, revocable identity." I said it Sunday and it's the durable point: you should be able to name the human on every write path into your catalog and ad account. Most brands can't. The protocol is now built to make that answerable — but only if you actually ask, because nothing about this change forces your vendor to clean up who's holding what.
3. The migration wave lands in your Q4 runway. The spec is dated July 28. SDKs update first, then every vendor who built on MCP rewrites their connector layer — realistically through this fall. That's August-to-October engineering work across the entire seller-tool ecosystem, finishing (or not finishing) right as you enter the weeks where a broken integration costs the most. A connector that fails quietly in March is an annoyance. One that fails quietly in the second week of November — your repricer stops receiving updates, your inventory sync drops a warehouse — is a five-figure event that will get misdiagnosed as a demand problem first. The statelessness change cuts the other way, to be fair: stateless protocols are genuinely easier to run reliably at scale, which is why the change was made, and a year from now these connectors should fail less, not more. The risk isn't the destination. It's vendors doing rushed rewrites during the exact quarter you can least afford their bugs.
What I'd do this week
- Build the write-path inventory. One page: every tool that can write to catalog, pricing, inventory, or advertising; what it can write; and which named human authorized it. This is thirty minutes and it's the prerequisite for everything else. If you did this when I suggested it Sunday, you're done with step one.
- Send three questions to every vendor on that list. Does your integration layer use MCP, and are you on a migration path to the 2026-07-28 revision? When do you expect to complete it? How do you handle a write request that fails mid-flight — is it retried, and is it safe to retry? A vendor with real engineering answers these in one reply. A vendor who responds with marketing language just told you something more important.
- Ask when, not whether. You want vendor migrations done before mid-October or deferred until January. If a vendor tells you they're shipping a connector rewrite in November, that's them scheduling their riskiest deploy of the year inside your highest-revenue window, and you should say so.
- Declare your own integration freeze. Whatever the vendors do, decide now that you aren't adding new AI tools with write access between mid-October and mid-January. Peak season is for tools that have already earned trust, not trials.
- If you built your own automations: your SDK update is a Tuesday decision, same rule as always — update on your schedule, re-run your golden set of real SKUs, grade the guardrails, then deploy. The deprecation window means you have months. Use them; don't spend a August weekend panic-migrating something with twelve months of runway.
What I'd ignore
The protocol-drama threads. There is a genuinely entertaining argument happening among developers about the deprecation of a feature called Sampling, and none of it will ever touch your ACOS. Ignore anyone framing this as "MCP is dead" or "MCP won" — a spec revision with a formal deprecation policy is what maturing infrastructure looks like, not a funeral or a coronation. Ignore any agency or consultant who repackages this into an "MCP migration readiness audit" retainer; everything above is an inventory, three emails, and a calendar decision, and you just read the whole methodology for free. And ignore the reflex to check whether this makes any model better or worse. It doesn't. This is the week to remember that the tools wrapped around the models — and the plumbing wrapped around the tools — change your risk profile more often than the models do.
The models had a quiet week. The pipes didn't. Watch the pipes.