MCP for Shopify apps:
hype versus what
actually works.

There's a version of the MCP story that's mostly noise, and a version that's mostly signal, and almost every post you'll read about Model Context Protocol for Shopify blends the two until you can't tell which is which. So let me draw the line up front. The part that genuinely changes how apps get built is real and already paying off. The part that promises MCP is your next product, your next moat, your next billion-dollar surface, is mostly a pitch deck dressed as a trend.

Here's the single number that should anchor your thinking. By the first quarter of 2026, every Shopify store had a Storefront MCP endpoint live by default, which means roughly 5.6 million stores became addressable by AI shopping agents without any merchant lifting a finger. That's the genuinely big thing. It's also the thing most app founders are misreading, because "the surface exists" and "you should build a business on top of it" are two completely different claims, and the gap between them is where a lot of money is about to get wasted.

I've sat in three seats in this ecosystem. I helped build the Partner Program in Shopify's early days, so I've watched a hundred app categories rise and get commoditized. I founded and sold a software company, so I know what a durable product feels like versus a feature waiting to be absorbed. And I co-founded a nine-figure DTC operator, so I've been the merchant deciding which apps stay installed and which get cut the moment something native does the same job. MCP looks different from each seat, and the honest read only emerges when you hold all three at once.

This is the long, skeptical version. What MCP actually is in plain terms. The three official servers and what each one really does. The open-sourced AI Toolkit Shopify shipped in April 2026. A clean split between what works today and what's overhyped. The concrete use cases that earn their keep, where MCP creates real leverage for app builders, where it's a trap, and the risks nobody markets to you. Then a decision framework you can actually run against your own roadmap.

If you build apps in this ecosystem, or you're deciding whether to bet engineering quarters on MCP, this is the read that tries to tell you the truth rather than sell you a course.

What MCP actually is,
without the
buzzwords.

MCP is a standard way for an AI model to talk to a tool or a data source. That's it. Before MCP, every time you wanted a model to read a product catalog or update inventory, somebody hand-built a custom bridge between that specific model and that specific system. MCP replaces those one-off bridges with a shared interface, so any compliant agent can talk to any compliant tool the same way. Think of it as a common plug rather than a new kind of electricity.

The analogy people reach for is USB, and it's actually a decent one. Before USB, every device needed its own port and its own driver. After USB, you had one shape of connector and a shared expectation of how data would flow. MCP is trying to be that for AI agents and the systems they need to touch. The model doesn't have to guess the shape of your data or invent the right call. The server tells it, in a structured way, what's available and how to ask for it.

Why does that matter for Shopify specifically? Because the whole platform runs on APIs, and the new primary user of a lot of those APIs is no longer a developer typing code or a shopper clicking buttons. It's an agent with a job to do. When a customer asks ChatGPT to find them a pair of trail runners under $140 and the agent goes off to search real catalogs, something has to translate "find trail runners under $140" into a structured query a store can answer. MCP is that translation layer, standardized so the agent doesn't have to learn each store from scratch.

Here's the part that trips people up. MCP isn't a Shopify invention, and it isn't magic. It's a protocol, a set of conventions, and protocols are only as useful as the things that implement them and the value those things carry. A protocol doesn't sell anything, doesn't retain anyone, doesn't make a product good. It just lets two systems agree on how to talk. So when you read that MCP is "transforming commerce," translate that in your head to "there's now a standard way for agents to reach stores," and then ask the only question that matters: standard access to what, and worth paying for by whom?

I labor this because the confusion between "the protocol exists" and "the protocol is valuable to build on" is the root of nearly every bad MCP bet I expect to watch get made this year. The protocol is real and it's settling fast. Whether your specific idea on top of it is a business is a separate question entirely, and the rest of this post is mostly about answering that one honestly.

The three MCP servers,
and which one you
should care about.

Shopify ships three official MCP servers, and conflating them is the fastest way to talk nonsense about this topic. There's Dev MCP for people building software, Storefront MCP for AI shopping agents reaching catalogs and checkout, and Customer Account MCP for what happens after a purchase. They serve completely different users and carry completely different stakes. If you only remember one distinction from this post, make it this one.

Dev MCP is a developer tool. It connects a coding agent like Claude Code, Cursor, or VS Code to Shopify's documentation and to the live GraphQL schemas for the Admin and Storefront APIs. It's about accuracy while you build. It doesn't touch a customer, doesn't sell anything, and doesn't sit in a live storefront. It's the least glamorous of the three and, as I'll argue, the most reliably useful right now.

Storefront MCP is the one the agentic-commerce hype is really about. It connects to a store's catalog, cart, and policies so an AI shopping assistant can search products, build a cart, apply a discount, and reach checkout on a shopper's behalf. This is the surface ChatGPT, Perplexity, Google's AI Mode, and Copilot actually hit when someone shops through them. When you read that 5.6 million stores became discoverable inside AI assistants in 2026, this is the server doing the work, and it switched on by default for eligible US merchants in late March of that year.

Customer Account MCP is the one almost nobody talks about, and that's a mistake. It handles the post-purchase relationship: tracking an order, managing a return, accessing the account, all through an AI client. The reason it matters more than its press coverage suggests is that it's the difference between a one-time agent-placed order and an actual customer relationship. The genuinely hard, valuable problem in agentic commerce isn't getting an agent to place an order. It's what happens to that order, and that customer, afterward. That's where I'd point a thoughtful builder's attention, and we'll come back to it.

One more distinction people blur constantly: placement. Dev MCP runs locally, next to the coding agent, and never sees a shopper or sits in production traffic. Storefront MCP and Customer Account MCP are live, hosted surfaces that real customers reach through real AI clients. The further right you go on that list, the more your product's reliability depends on decisions made by companies you don't control, which is the thread that runs through the risk section later.

So which should you care about? If you write code for Shopify, Dev MCP is worth installing this week, full stop. If you're thinking about how agents discover and buy your merchants' products, Storefront MCP is the surface to make your value legible to, not the thing to reinvent. And if you want the underrated angle with the least competition, Customer Account MCP and the post-purchase relationship is where I'd look hardest. Three servers, three jobs, three completely different strategic implications. Anyone who tells you "MCP" as a single undifferentiated thing hasn't actually used it.

The AI Toolkit, and why
Shopify open-sourced
the whole thing.

On April 9, 2026, Shopify open-sourced the Shopify AI Toolkit under the MIT license, bundling its official MCP server stack, a set of agent skills, and a Claude Code plugin into one namespace. Three weeks later, the Winter 2026 edition extended it so that Storefront MCP shipped inside Hydrogen, turning every Hydrogen storefront on Oxygen into an AI agent endpoint by default. That's the consumer-facing wrapper around the same plumbing, and it's a deliberate, revealing move.

Why give it away? Because Shopify doesn't make money from the protocol. It makes money from merchants succeeding and from payments flowing through its rails. The faster every store becomes legible to every AI agent, the more commerce routes through Shopify rather than around it. Open-sourcing the toolkit is the cheapest possible way to make the entire ecosystem agent-ready at once, and it signals that Shopify intends to own the default path rather than charge a toll on the protocol. That strategic read tells you a lot about where the value is and isn't.

The toolkit itself is genuinely useful for developers. It's a free, open MCP server that connects coding agents to Shopify's developer docs, the GraphQL API schemas, and live store operations through the Shopify CLI. Developers use it to search docs, validate GraphQL queries, and run store operations in natural language. The DEV Community writeups describe production setups with nineteen distinct skills and safe execution patterns, which tells you it's past the toy stage and into real workflows. This is the part of the MCP story where the hype and the reality actually agree.

Here's the strategic point hiding in plain sight. When a platform open-sources the connective tissue, it's telling you the tissue itself isn't where it expects anyone to capture value, including you. The toolkit is infrastructure, and infrastructure that's free and official commoditizes fast. If your plan was to be the company that connects AI agents to Shopify stores, Shopify just shipped that for free, under a permissive license, with its own brand behind it. That doesn't kill every idea in the space. It kills the thin ones, which is the recurring theme of this whole analysis.

The pattern here echoes what I wrote about in how AI is reshaping Shopify apps: the platform absorbs the generic layer and leaves the defensible, specific work to builders who go deeper than a wrapper. Open-sourcing the toolkit is that absorption happening in real time. The question it forces on every app founder is uncomfortable and clarifying at once. If Shopify gives away the connection, what exactly are you charging for?

What genuinely works
today, and it's not what
you'd expect.

The most real, least hyped win is in development workflow, not in commerce. Ask a coding agent to write a Shopify Admin API mutation without schema access, and roughly half the time you'll get a confident-looking GraphQL block referencing fields Shopify retired two years ago. Dev MCP validates against the live schema before you fire a request, which kills that loop. The reported 40 to 60 percent time savings on routine admin workflows is plausible precisely because so much developer time was being lost to that exact failure.

Let me make the failure concrete, because it's the heart of why Dev MCP works. Without it, an agent will happily hand you a Liquid filter like a money formatter that has never existed, but looks plausible enough to ship. You don't catch it until runtime, and you lose an hour chasing a bug that the model invented out of pattern-matching. With the schema in context, the agent checks the real fields and the real filters before it writes the line. That's not a flashy feature. It's the removal of a tax you were paying every single week, and removal of friction is the most underrated kind of progress.

The second thing that genuinely works is Storefront MCP as a discovery surface. This isn't speculative. Stores are discoverable inside ChatGPT, Copilot, Google AI Mode, and Gemini right now, and shoppers are using those assistants to find products. The agent queries the catalog with a natural-language search, gets ranked products back, and surfaces them. Whether your products show up well is a real, addressable problem today, which is exactly why I've written separately about whether your products are winning or invisible inside ChatGPT. The surface works. Your visibility on it is up to you.

The third thing that works is the schema-validation accuracy loop as a general principle, not just for Shopify code. Any time you put a structured, authoritative source in front of an agent before it acts, you trade a hallucination for a checked fact. That's the whole quiet thesis of MCP, and it's the part that's durable regardless of which checkout feature survives and which gets pulled. The plumbing that makes agents accurate is real progress. The product fantasies bolted on top of it are where the hype lives.

Let me ground the data-quality point with operator experience. At WIN, when we cleaned up product titles and structured our descriptions, we did it for human conversion and on-site search, not for agents. The agentic surface just raised the stakes on work we already knew paid off. A title that reads "Merino Crew, Charcoal, Heavyweight" beats "Our Bestselling Top" every time a machine is the one choosing, and the machine is now choosing more often. The merchants who win the AI-discovery surface in 2026 are the ones who treated catalog data as a first-class asset before anyone mentioned MCP. The tool that does that cleanup at scale is selling a measurable outcome, a far better thing to be than a connector.

Notice the pattern in all three wins. None of them is "build the next big MCP app." They're "remove a developer tax," "show up well on a surface that already exists," and "make data legible to machines." Unsexy, specific, and earned. That's almost always what genuinely works looks like in this ecosystem, and it's almost never what the loudest pitch is selling.

What's overhyped, and
the checkout reversal that
proves it.

The single clearest piece of evidence that the agentic-checkout hype got ahead of reality is what happened to OpenAI's Instant Checkout. It launched, ran for roughly five months, and got quietly pulled in March 2026. Only about 30 merchants were ever live on it, and roughly 8 percent of US adult ChatGPT users tried it in the first month, with usage staying low the whole trial. OpenAI repositioned around discovery and merchant storefronts instead of in-chat purchasing. If in-chat checkout were the inevitable future, that's not how its highest-profile implementation would have ended.

Read that reversal carefully, because it's instructive. The agent placing an order turned out to be the easy, demoable part. The hard parts were the unglamorous ones: onboarding merchants, showing accurate product data, handling multi-item carts, connecting loyalty and memberships, and dealing with everything that happens after the order. Those are operational, not protocol problems, and no amount of slick MCP plumbing solves them on its own. The demo was always going to look magic. The business underneath it was always going to be a grind.

So here's the first overhyped claim: that in-chat agentic checkout is about to replace your storefront. It isn't, at least not on the timeline the pitches imply. Discovery inside AI assistants is real and growing. Full transactional handoff to an agent, with the relationship and the edge cases that come with it, is much earlier and much harder than the slides suggest. Building your company around the assumption that customers will soon buy everything through an agent in a chat window is building on a surface that just got walked back by the company that hyped it most.

The second overhyped claim is that MCP is a product category you should rush to own. It's a protocol. Protocols don't get owned by app builders; they get implemented by platforms and adopted by everyone. The people who got rich from USB weren't the ones who "built on the USB protocol" as a business. They were the ones who built valuable devices that happened to use it. Treating "MCP integration" as your differentiator is like a hardware company in 2005 whose pitch was "we support USB." Of course you do. So does everyone. What else have you got?

The third piece of hype worth puncturing is the idea that Catalog MCP and the full B2B agentic story are ready to build a company on today. The Catalog API only opened to all developers in March 2026, which means building on it now is building on a surface that's still moving under your feet. Early access can be an advantage if you have the appetite to rebuild as it shifts. It's a liability if you mistake "available" for "stable." A lot of the most ambitious MCP pitches are quietly betting on surfaces that haven't finished forming, and that's a different risk profile than the confident tone implies.

The concrete use cases
that actually earn
their keep.

Strip away the abstraction and there are four MCP use cases that pull real weight in 2026. Agents helping operate a store. Agents connecting a shopper's AI client to a store for discovery. Accelerated developer workflow. And the underrated post-purchase relationship. Each is at a different maturity, and knowing which is which keeps you from building for a future that hasn't arrived while ignoring the value sitting in front of you.

The first is agents operating a store. With the AI Toolkit, a merchant or developer can run real store operations in natural language through Claude Code or Cursor: updating products, adjusting inventory, building sections, scaffolding apps. A complete Shopify review app was reportedly built end to end with a coding agent, with the agent handling security patterns like HMAC verification without being told to, and it ended up serving real merchants in production. That's not a demo. That's a working build, and it's the most concrete proof that the developer-side use case is real.

The second is connecting a shopper's AI to a store. This is the ChatGPT-finds-your-product flow, and it works for discovery today. A shopper asks an assistant for a recommendation, the agent queries Storefront MCP, and ranked products come back. The catch, and it's a big one, is that the checkout completion piece is exactly what just got walked back. So this use case is genuinely live for discovery and much shakier for transaction. Treat the discovery half as a present-tense opportunity and the transaction half as a watch-this-space, because conflating them is how you over-invest.

The third is developer workflow acceleration, which I've already made the case for and which sits on the firmest ground of all four. It's not speculative, not dependent on consumer behavior shifting, and not exposed to a checkout feature getting pulled. It just makes building faster and more accurate, today, for anyone who writes Shopify code. If you're a founder weighing where to spend your own engineering time, this is the use case with the best risk-adjusted return, because the payoff is immediate and the downside is basically zero. It connects directly to the practical reality of how building a Shopify app actually works in 2026.

The fourth is the post-purchase relationship through Customer Account MCP, and it's the one I'd watch most closely precisely because it's the least crowded. Every founder is chasing the discovery and checkout surface because that's where the demos are. Almost nobody is building for what turns a single agent-placed order into a returning customer: the order tracking, the return, the re-order, the account relationship. That's the part that compounds, and it's the part the market is currently ignoring. The least crowded valuable problem is usually the best place to build, and right now that describes the post-purchase layer.

Where MCP creates real
leverage, and where
it's a distraction.

Real leverage from MCP shows up when it lets you do something the merchant genuinely values that you couldn't do as cleanly before. It's a distraction when it's a feature you add to look current, or a wrapper that the platform is about to ship for free. The dividing line is the same one that decides every app's fate: if your app vanished tomorrow, would the merchant feel it? MCP doesn't change that question. It just makes the wrong answers more obvious, faster.

Here's where the leverage is real. If you hold proprietary data, a relationship, or a workflow that an agent needs a reliable place to route work through, MCP makes you more valuable, not less, because agents need trustworthy endpoints and you're one. A tool that makes catalogs machine-legible, a service that owns the merchant's trust on a hard problem, an integration that's genuinely deep rather than a thin pass-through: these get stronger in an agentic world because the agent has to send the work somewhere, and it sends it to whatever is dependable. The agent is a router. Be a destination worth routing to.

Here's where it's a distraction. Adding "MCP support" to a thin app to look modern doesn't change the underlying fact that the app is thin. Building a connector that Shopify already open-sourced is volunteering to compete with free and official. Betting your roadmap on in-chat checkout becoming dominant is wagering on the exact surface that just got pulled back. And reinventing the protocol plumbing instead of using the standard one is spending engineering on undifferentiated work. None of those create leverage. They consume it, while feeling like progress, which is the most expensive kind of mistake.

I'll put it even more bluntly, because founders need bluntness here. MCP is leverage for builders who already have something worth connecting to, and a distraction for builders hoping the connection itself will be the something. If you've got real product depth, the agentic shift is a tailwind, because it routes intent to whoever is dependable and specific. If you've got a thin layer, the same shift is a headwind, because the thin layer is exactly what gets absorbed. The protocol is neutral. What it does to you depends entirely on what you'd built before it arrived. This is the same dynamic at the heart of where AI is real versus theater for app founders.

The real risks, including
the one merchants already
lived through.

The biggest risk in building on MCP is platform dependency in its sharpest form yet, and it's not theoretical. When your product is a layer on top of someone else's protocol servers, a single policy change, a tightened trust tier, or a shifted endpoint can reset your economics overnight. That's not a hypothetical: it's precisely what merchants on Instant Checkout experienced when OpenAI pulled the feature with about 30 of them live. They didn't do anything wrong. The surface beneath them moved.

There's a well-known cautionary pattern in this ecosystem: a Shopify app that went from daily installs to zero overnight when the platform shifted underneath it. MCP makes that pattern available at a deeper level, because now you can be dependent not just on Shopify's app policies but on the behavior of multiple AI platforms whose protocols you don't control. The more layers of someone else's plumbing your business runs through, the more single points of failure you've signed up for, and the agentic stack adds several at once.

The second risk is the commoditization of thin apps, which MCP accelerates rather than causes. A thin app that mostly wraps an API call or rephrases data is exactly what an agent with schema access and a Storefront MCP endpoint can now do in-line, without your app in the middle. That was always coming, as I argued in the broader piece on AI reshaping the app landscape. MCP just shortens the timeline. If your moat was "we connect this to that," the connection is now standard and often free, and the moat is gone.

The third risk is the maintenance tax, which is real and rarely budgeted. Community-built MCP servers depend on individual maintainers tracking Shopify's API changes, and when the API moves and the maintainer is on vacation, things break in production. Even on official servers, you should plan to spend something like 20 to 30 percent of your initial build time annually just staying current with API, protocol, and trust-tier changes. That's not a one-time integration cost. It's an ongoing tax on every quarter, and pretending otherwise is how MCP projects quietly become more expensive than the pitch claimed.

This risk is deeper than the ordinary "you build on Shopify, so Shopify can change the rules" version everyone already accepts. The classic version has one landlord, and you can usually see the big shifts coming a quarter or two out by reading the roadmap. The agentic version has several landlords at once, and they don't coordinate. Your product can run through Shopify's Storefront MCP, get surfaced by OpenAI's agent, and depend on Anthropic's or Google's client behaving a certain way, all in one customer journey. Any one of them can change something on their own timeline, with no obligation to warn you. The Instant Checkout reversal is the clean example: that was OpenAI's decision, not Shopify's, and the merchants exposed had no seat at that table. Layered dependency means layered exposure, and most pitches quietly assume the layers are stable when the whole point of how new they are is that they aren't.

The fourth risk is subtler and more strategic: you can win the agentic surface and still lose the customer. If a shopper buys your merchant's product through an agent and the entire relationship lives inside that agent's interface, who owns the customer? Not necessarily the brand, and not necessarily your app. The agent can become the relationship, and the brand becomes an interchangeable supplier behind it. That's the deeper threat agentic commerce poses, and it's the same disintermediation logic I unpack in the broader work on what agentic commerce means for Shopify brands. MCP is the on-ramp to that world, which means it's also the on-ramp to that risk.

What MCP does to app
pricing, and how the
money changes.

Almost nobody talks about the pricing consequences of all this, which is strange, because pricing is where the agentic shift shows up in your bank account. The old Shopify app pricing model was simple: a flat monthly fee, maybe tiered by store size, while the merchant clicked around in your interface. That model assumes a human is in the loop, in your dashboard, deciding your tool is worth $49 a month. MCP quietly breaks several of those assumptions, and the apps that don't notice will watch their unit economics drift.

The most obvious shift: when an agent calls your app, nobody is looking at your interface. The merchant doesn't see your dashboard, onboarding, or upsell prompts, because the agent goes straight to the function it needs. That's fine if your value is the function. It's a problem if a chunk of your perceived value was the experience around it, the thing that justified the price each month. Strip the human out and a flat subscription starts to feel abstract.

That pushes pricing toward usage and outcomes rather than seats. If an agent calls your service ten thousand times this month to enrich product data, a flat $49 doesn't capture that, and per-seat is meaningless because there are no seats, there's a machine. The natural fit is metered pricing (per call, per resolved task, per unit of work the agent routes to you) or outcome pricing (a slice of the recovered revenue or conversion lift you can attribute). That's harder to build and sell than a flat fee, but it's the model that survives when the buyer is partly a machine and the value is delivered invisibly. The apps clinging to flat seat pricing are the ones whose margins compress as agents drive volume they don't get paid for.

The blunt version for founders: the agentic shift is a pricing event, not just a product event. If your value is real and measurable, MCP lets you charge for that outcome in ways flat seat pricing never allowed. If your value was the interface and the habit of logging in, the same shift erodes what your price was anchored to. Re-examine your pricing on the assumption that a real share of your usage will soon come from agents.

Security, permissions, and
what you're really handing
an agent.

Here's the part glossed over in almost every excited MCP write-up, and the part that will produce the first wave of bad headlines. When you expose a store to an agent through MCP, you're handing a non-deterministic system the ability to read and sometimes act on real commerce data: catalogs, orders, customer accounts, inventory, discounts. An agent isn't a script that does exactly what you wrote, it's a model that interprets and decides, and "decides" is the word that matters. The governance questions that follow are the cost of admission, and most teams are skipping the bill.

Start with permissions. The instinct when wiring up an agent is to grant broad access so it can do whatever the user asks, but that's the wrong default. An agent with write access to inventory and discounts can, through a confused instruction or a manipulated input, do real damage fast: zero out stock, publish a 90 percent discount, expose customer records. The discipline is least privilege. Give the agent the narrowest scope that does the job, read-only wherever you can tolerate it, write access only where it's needed and gated behind a confirmation. Customer Account MCP touches personal data, so it deserves the tightest scoping of all. "Let the agent do everything" is a liability dressed as convenience.

Then there's a newer threat class traditional app security never had to think about: prompt injection. Because an agent reads and acts on text, a malicious input hidden in a product review, a customer message, or a data field can try to hijack what the agent does next. Imagine a customer-service agent reading a return request with hidden instructions telling it to issue a full refund and a store-credit bonus. A human reads that and laughs. An agent without guardrails might comply. The moment your agent reads untrusted text and can take an action, you've opened that door. The defenses (input sanitization, action confirmation for anything consequential, separating the data an agent reads from the instructions it follows) are the unglamorous work that has to make it into production.

There's also a data-governance layer above the per-action security. Every time an agent reaches into a store, customer data may flow to whatever AI client made the call, which can sit outside your jurisdiction. For a merchant under GDPR or in a regulated category, "the agent looked up the customer's order" is a data-processing event with real obligations, and "who is the processor when an OpenAI agent reads a Shopify customer record through your app" has no settled answer yet. Treat it as a live risk.

None of this is a tangent, it connects straight back to the strategy. Security and governance aren't just risk-avoidance, they're a moat. In an ecosystem where the connection is free and the protocol is standard, "I can be trusted to act safely on your store" is a real differentiator, especially for enterprise and mid-market merchants whose compliance teams will ask these exact questions. The serious destination can answer them. The thin connector can't.

Should you build on MCP?
A framework for app
founders.

Here's the decision framework I'd actually run if I were advising you, and it's deliberately conservative because the downside of an over-eager MCP bet is high and the cost of waiting a quarter is low. It runs in three gates, and you only advance to the next one if you clear the current one honestly. Most founders should clear gate one, pause at gate two, and think hard at gate three.

The thread running through all three gates is the destination-versus-router test from earlier. Gate one is pure tooling, so everyone passes. Gate two is about being found, which almost everyone should pursue with discipline. Gate three is the one where most of the bad bets get made, because it's where founders mistake a protocol for a product. If your honest answer at gate three is "the connection is the value," that's your signal to redirect the engineering somewhere defensible. The same instinct that tells you when an app is too thin to survive should be screaming here.

One more practical note that the framework assumes but is worth stating. Whatever you build on or around MCP, keep a leg you actually control. A direct merchant relationship, owned data, an email list, a workflow that doesn't evaporate if a trust tier changes. The merchants who got burned by Instant Checkout had no such leg on that surface, so when it disappeared they had nothing. Building on a platform is fine. Building only on a platform, with no fallback you own, is how you end up at the mercy of someone else's product decision. That principle predates MCP and will outlast it.

So strip it all back to the honest summary. MCP is a real, settling protocol that makes agents accurate and makes stores reachable, and the parts that work are the unglamorous ones: faster, more correct development, and better visibility on a discovery surface that already exists. The parts that are overhyped are the ones promising the protocol itself is your product, or that in-chat checkout is about to replace the storefront, a claim the Instant Checkout reversal just undercut in public. The leverage is real for builders who are destinations and a trap for builders who are trying to be routers. And the risk, platform dependency at a new depth, is exactly the risk merchants already lived through once this year.

If you're an app founder reading the agentic shift and trying to decide where to spend your next two quarters, the answer usually isn't "build the big MCP play." It's "use the tooling now, make yourself legible now, and reserve a real product bet for the place you'd be a destination, not a connector." I've built in this ecosystem, sold software inside it, and operated a brand that cut apps the moment something native did the same job. If you want a candid read on whether your MCP idea is leverage or distraction, that's exactly the work the consumer SaaS practice exists to do, and the broader piece on Sidekick versus your app stack is a good companion to this one.

Questions from founders
reading the agentic
shift.