What Is MCP, and Why Your Shopify Apps Are About to Talk to Your AI Assistant

Here is how most merchants use an AI assistant for store work today. You export a CSV, or copy forty product titles into a chat window, or screenshot a report. The assistant writes something useful. You copy it back out and paste it into the admin one field at a time.

That workflow has a name in software: manual data transfer. It is the thing integrations were invented to eliminate, and it is what most of us have quietly reverted to over the past two years, because the assistant could not see anything.

MCP removes the copy-paste step.

What it actually is

The Model Context Protocol is an open standard for connecting AI assistants to outside tools and data. The specification is public at modelcontextprotocol.io, and it is supported across a range of assistants and developer tools, including ChatGPT.

The structure has three parts. The host is the AI application you are using. A server is a program that exposes capabilities to it. A client is the connection between them, one per server.

Servers can offer three kinds of thing. Tools are executable functions the assistant can invoke: run an audit, write a field, query a database. Resources are data sources that provide context, like a file or a record set. Prompts are reusable templates for structuring a task.

For merchants, tools are the whole story. The rest is plumbing.

Why this is not just another integration

Every SaaS product you use has spent a decade building one-off connectors: a Zapier app, a Slack bot, a Google Sheets add-on. Each one is bespoke, each one breaks separately, and none of them help the assistant you actually talk to.

MCP inverts that. An app implements the protocol once and becomes callable by any assistant that speaks it. You are not waiting for your SEO tool to build an integration with your specific assistant. The tool exposes what it can do, and whatever you use picks it up.

Two transport modes exist. Local servers run on your own machine and talk over standard input and output, which is mostly a developer concern. Remote servers run over HTTP and serve many users at once. Those are the ones merchants will encounter, and the only kind discussed here.

Shopify already shipped one, and you did not have to do anything

If this still feels theoretical, it is not. Every Shopify store has a Storefront MCP endpoint at https://{shop}.myshopify.com/api/mcp. The tools on it include get_cart, update_cart, and search_shop_policies_and_faqs, plus catalog search tools on a companion endpoint.

That is your store, exposed as a set of functions an assistant can call on behalf of a shopper. Shopify built it. You did not opt in and you do not administer it. Whatever you think about the direction of travel, the platform has already decided the storefront should be machine-callable, and shipped it as infrastructure rather than a feature you enable.

The admin side is where merchants get a say, and that is where apps come in.

What connecting an app actually looks like

Here is the concrete version, using our own implementation because it is the one we can describe honestly.

In Seokai's settings there is a section called "Connect AI assistant." You start the connection there, and the OAuth consent screen appears inside your Shopify admin. You see what the assistant will be allowed to do before you approve it. Approve, and the assistant now has a set of tools available in whatever interface you normally use.

Three properties of that flow matter, and none of them come free with the protocol.

The connection is bound to one store. If you run three shops, you connect three times, deliberately. The spec does require access tokens to be issued for one specific server and rejected everywhere else, which closes a real class of attack, but scoping a connection down to a single merchant's data is a product decision the app has to make.

Every connection is listed and revocable. You can see which assistants are connected and cut any of them off from the same screen.

Nothing gets access implicitly. An assistant that has never been through consent cannot call anything, regardless of what it already knows about your store from public pages.

Read tools and write tools are not the same category

This is the distinction to hold onto when you evaluate any MCP-enabled app.

Read tools return information. In Seokai's case: run an SEO audit, check agent readiness, report your current usage and rate-limit status. The worst outcome from a read tool is a wasted question.

Write tools change your store. Generate meta titles, descriptions and keywords for up to ten items per call, write image alt text, fill in missing product types. These run through exactly the same generators and the same plan and credit gates as the buttons in the app, which is the point. An assistant calling a write tool is not a side door around your plan limits; it is a different way of pressing the same button.

The default we chose, and would argue for generally, is that write tools do not overwrite existing values unless you explicitly ask. An assistant filling 400 blank meta descriptions is useful. An assistant replacing 400 meta descriptions you spent a month writing is a support ticket and possibly a ranking incident.

Shopify draws the same line in its own extension model. Sidekick's data extensions are for retrieval, with action extensions as a separate category for anything that modifies. We went into why that split constrains Sidekick's usefulness for audits here.

Why this beats pasting things into a chat window

Three reasons, and only the third one is interesting.

The data is real and current. No export, no stale snapshot, no products you forgot to include in the paste.

The actions actually land. The assistant writes to your store instead of handing you text to transcribe.

And the gates are real. When you paste a spreadsheet into a chatbot, nothing is enforcing anything. There is no rate limit, no consent record, no cap on how much it does, no log of what changed. When the same work happens through a connected app, all of those exist because the app already had them for its own UI. The protocol did not invent the guardrails. It just made it possible to use an assistant without stepping outside them.

That is the actual argument for MCP over copy-paste, and it is a governance argument rather than a convenience one.

Where it is still rough

Assistant support varies, and the interface for managing connections differs everywhere. Tool descriptions are written by the app developer, so a badly described tool gets called at the wrong moment. And an assistant left to run unsupervised will happily call a write tool more times than you intended, which is why any app exposing writes needs a ceiling on how much it can spend on your behalf.

Those are real limitations, not reasons to wait. The direction is settled: the assistant you already use is becoming the interface to the apps you already pay for, and the apps that expose good tools with sane defaults will get used far more than the ones that make you log in.

If you want to see what connecting looks like on a store you control, the settings and scopes guide walks through it.