Do you need an MCP server? Check this first.

Someone on your team has read that AI shopping agents are coming and that MCP — the Model Context Protocol — is how they'll read your catalog. There's a line item in a plan somewhere that says "build MCP server".

Before you scope that, check whether you already have one. There's a decent chance you do.

Shopify ships it by default

From Shopify's developer documentation: every Shopify store exposes an MCP endpoint at /api/mcp, by default, with no custom setup required. Through it an agent can search your catalog, pull product details, manage a cart, answer questions from your policies, and begin a checkout. The UCP catalog tools — search_catalog, lookup_catalog, get_product — sit on a companion endpoint.

You didn't install anything. It's on.

We found this out the hard way: we were three-quarters of the way through planning an open-source MCP kit with a Shopify adapter first, because that's where the stores are. It would have been redundant the day it shipped. Checking the docs took four minutes and saved a quarter of work.

Worth knowing what it isn't: Storefront MCP is read-only for catalog data. Agents can shop through it. They cannot manage your store with it.

So what's the real question?

If your platform already exposes an endpoint, "should we build an MCP server" is the wrong question. The right one is harsher:

Is the data behind that endpoint good enough to sell from?

An agent that reaches your catalog and finds a stale price will quote the stale price. One that finds stock counts that lag your warehouse by an hour will confidently sell something you don't have — and unlike a human shopper, it won't pause at a slightly-off product photo and think twice. It reads your feed as fact.

So the work that actually matters isn't the protocol. It's the boring part underneath it:

• Are prices in the feed the prices at checkout — including sales, tiers, and currency?
• Does inventory reflect reality, or last night's batch job?
• Do variants carry the attributes an agent needs to answer "does this come in a 10"?
• When something goes out of stock, how long until the endpoint knows?

None of that is glamorous and all of it decides whether agent traffic converts or embarrasses you.

When you do need to build one

Headless and composable stores are the other case. There's no vendor shipping this for you — that's the trade you made when you decoupled. Your catalog, pricing and inventory sit behind your own APIs, in shapes you designed, and an agent has no idea how to read any of them.

If that's you, the work is real but it isn't enormous. The data is already behind APIs. MCP is a standard shape to expose it in, plus the auth and rate limiting you want on anything an autonomous client can hit as fast as it likes.

The order still holds, though. Fix the feed first. A well-built MCP server in front of bad data just makes the bad data easier to reach.

The five-minute version

1. Find out what your platform already does. Check the docs, not a blog post from spring — this space moves monthly and we nearly built on our own stale assumption.
2. If you have an endpoint, audit the data behind it before you touch the protocol.
3. If you're headless, nobody's coming to do this for you. Scope it — after the feed audit.

If you want to know how your store looks to an agent right now, our agentready scanner is free and needs no email for a score — 29 checks across structured data, agent access, feeds, and ACP/UCP/MCP discovery. It'll tell you what you already have before you pay anyone to build it.