MCP on Shopify, BigCommerce and Adobe Commerce: what AI agents can do on each platform

MCP (Model Context Protocol) is an open standard that lets an AI agent call tools in other software, including your ecommerce platform. On Shopify, BigCommerce and Adobe Commerce alike, an agent connected through MCP can read your catalogue, stock, orders and customers, and prepare changes for your team to approve. What differs is what each platform provides and where the hard work sits:

• Shopify: content, search visibility and automations alongside Shopify Flow. Shopify provides Storefront MCP and Catalog MCP for eligible stores.
• BigCommerce: keeping stock, prices and promotions right across storefronts and customer groups. Every live store can switch on BigCommerce's own Storefront MCP server.
• Adobe Commerce and Magento: large catalogues, B2B rules and custom code, where many changes should reach your developers as a pull request.

This guide is for ecommerce leads and the developers or agencies who look after their stores.

What is the same on every platform

MCP does not add features to your platform. It gives an agent a common way to find and call tools, such as "search products" or "update a product description", and each tool still calls the platform's own API underneath.

There are two kinds of MCP connection, and they are easy to confuse:

• Shopper-facing: the platform runs an MCP server that AI shopping assistants use to search your catalogue and build a cart. The assistant belongs to the shopper.
• Store operations: your team, developer or agency connects an agent to your store data, with permissions you choose, so it can find problems and prepare fixes. Most of this guide is about this kind.

An agent is only as good as the data it reads. A variant with the wrong price gets quoted by a shopping assistant and planned around by an operations agent, so the first useful work is usually making prices, variants, stock and visibility match the product page.

The safe way to run agents is also the same everywhere. Start with access that only reads. The agent proposes each change with its evidence, a named person approves it, it is applied with an undo point (or as a pull request, for code), and then it is checked. That is how Vortex IQ works, and it applies equally to agents your developers build with frameworks such as LangChain.

Shopify: content, Flow automations and personalisation

Shopify looks after hosting and checkout, and many Shopify stores are run by small teams. So agent work lands on the jobs a small team never gets to: product content, automations, and showing the right products to the right customers.

What Shopify offers today

Shopify provides Storefront MCP and Catalog MCP for eligible stores. What they mean for your store is covered in our Shopify Storefront and Catalog MCP guide. The rest of this section covers agents your team connects to your own store data.

What an agent can see on a Shopify store

With access to your Shopify admin data, an agent can read what a store manager usually checks one screen at a time:

• Stock by location against recent sales, to flag products likely to sell out before the next delivery and draft a reorder for you to check.
• Orders and customer history, to draft a reply to "where is my order?" for your support person to send.
• Product titles, descriptions, images and collections, to find thin or duplicated descriptions, images with no alt text and products in no collection.

A product that is low on stock, featured on your home page and booked into next week's email needs one decision, and an agent that sees all three can bring it to you.

Shopify Flow with an agent in the loop

Shopify Flow runs fixed rules: a trigger, optional conditions and an action. "When stock falls below ten, tag the product and email the buyer." Rules like that are dependable because they never improvise, and for the same reason Flow will tag the product without noticing it leads tomorrow's campaign.

Keep Flow for the rules that should always fire, and add an agent where judgement is needed:

1. Flow fires on its trigger: low stock, a high-value order, or a new product with an empty description.
2. The agent reads the wider context: sales rate, campaigns that feature the product, similar products in stock.
3. It proposes what to do and why: feature a different product, hold an email, or draft the description in your brand voice.
4. Someone on your team approves, edits or rejects it.
5. The approved change is applied and checked.

Apps can add their own Flow triggers and actions, so the hand-off can be automatic while the approval stays with a person.

Content in your brand voice for Google and AI answers

On many Shopify stores the biggest gap is content: descriptions written once at launch, collection pages with one line of text, a blog that stopped months ago. Shoppers now find stores through Google and through AI answers such as ChatGPT, and AI answers favour stores whose product information is accurate and current.

An agent can work through this a page at a time: find the thinnest descriptions or, with Google Search Console connected, the pages that show in search but are rarely clicked, then draft new copy from your brand guidelines, including the title and description shown in search results. You change anything that does not sound like you, and approve it before it goes live.

An example: personalisation on a Shopify store

An example: picture a skincare brand on Shopify whose product recommendations were set up at launch and never revisited. Customers often buy a cleanser first and come back for a moisturiser, but the store recommends whatever is newest, sometimes out of stock. An agent connected through MCP would:

1. Read the order history and find which products are bought together, or one after the other.
2. Check stock, so it does not pair anything about to run out.
3. Propose complementary products for each product page, a "complete your routine" collection, and a segment of customers who bought a cleanser but never a moisturiser.
4. Draft a short email for that segment in the brand's voice.
5. Wait while the team approves the pairings, rewrites the email's opening and leaves the collection for later.
6. Once the changes are live, check that each product page shows the approved pairings and nothing out of stock.

Whether sales rise is a separate question, answered over the following weeks by comparing like with like. The agent's first job is to make the change correctly.

BigCommerce: stock, prices and promotions across storefronts

Many of the BigCommerce stores we work with run more than one storefront, sell through other channels, or use B2B Edition. The useful agent work there is keeping stock, prices and promotions consistent everywhere a product appears, and testing changes before shoppers see them.

What BigCommerce offers today

Since 11 May 2026, BigCommerce has offered its own Storefront MCP server to every live store. The store owner switches it on under Settings > API and MCP > MCP. It gives AI shopping agents seven shopping tools to search your catalogue and build a cart, and hands the shopper a checkout link. Our guide shows how to switch it on and test it.

That server reads your catalogue exactly as it is, so a wrong price or a product you meant to hide reaches the shopper's assistant too. Fixing that is the operations side.

Keeping stock, prices and orders in sync on BigCommerce

Many BigCommerce problems are quiet ones: stock that differs from the warehouse, a price list that no longer matches the storefront, a free delivery threshold on product pages that differs from the one at checkout, products hidden that nobody meant to hide.

An agent with read access to BigCommerce and the systems around it (your ERP, warehouse or supplier feeds, through a connector) can check continuously for:

• Stock that differs from your system of record, by SKU and location.
• Prices that differ between a price list, a customer group and what each storefront shows.
• Products visible with no stock, or hidden with plenty.
• Orders sitting in a status nobody is watching.

For each finding it proposes a fix. Price and visibility changes are the ones that can hurt, so test them on a copy of production that is in sync with live, then push live with your say-so and a way to reverse them. Our founders built StagingPro on BigCommerce for exactly that step.

Personalised shopping that respects stock

On BigCommerce, personalisation usually runs through customer groups, price lists and promotions, plus your theme or recommendation app. The failures shoppers notice are a recommended product that is out of stock, a promotion applied to the wrong group, or a trade buyer seeing retail prices. So make personalisation dependable first, then sharper:

• Check every promotion and recommendation rule against current stock, and propose replacements for products that cannot be bought.
• Compare what each customer group should see with what it does see, storefront by storefront.
• Group customers by what they buy and how often, and propose a promotion or landing page for each group, with the copy drafted.
• Propose category copy matched to what each storefront's customers search for.

Each proposal names the storefront and customer group it affects.

An example: a BigCommerce retailer heading into a promotion

An example: picture a BigCommerce retailer with stock data in two places, BigCommerce and a warehouse system, and a big promotion coming up. In past peaks, best sellers sold out early while slow lines tied up cash in the warehouse. The agent would:

1. Read stock by SKU and location from both systems, and list every SKU where they disagree.
2. Read the promotion plan: which categories, which storefronts, from which date.
3. Estimate demand for the promoted SKUs from recent sales and the same period last year, and list those likely to sell out before the next delivery.
4. Propose reorder quantities for the buyer, substitutes to feature if a best seller runs low, and a markdown on overstocked slow lines.
5. Apply the approved changes to a copy of the live store, so the team sees the promotion pages as shoppers will.
6. Push live once the team approves, then check each day of the promotion that stock, prices and featured products still match the plan.

The reorder itself stays with the buyer, in their own purchasing system.

Adobe Commerce and Magento: deep catalogues, B2B rules and code

Adobe Commerce and Magento Open Source give you more control than the other two platforms, and more to look after: store views for each market, stock in several sources, B2B company accounts and custom modules. So agent work reaches the store two ways. Data changes, such as a description or a price rule, go through the admin or API with an undo point. Code changes go in a pull request that your developers or agency review, test on staging and deploy as usual.

Connecting agents to Adobe Commerce and Magento

Magento has REST and GraphQL APIs, and the admin lets you create an integration limited to the resources you choose, such as catalogue and inventory but not customers or sales. A sensible setup:

• The narrowest access that does the job, starting with tools that only read.
• A staging environment as well as production, so proposals are tested where a mistake costs nothing.
• A log of every call, so your developers can see what the agent read and changed.

Once it reads reliably, it can join up areas owned by different people: a stock change in one source alters what a category page shows, and so what Google sees, and the agent can raise that as one ticket.

Automations that suit the way Magento is built

Magento gives an agent things to watch that the other platforms do not have in the same form:

• Stock across sources. With Multi-Source Inventory, one product can hold stock in several warehouses. An agent can compare salable quantity with physical stock, flag reservations that never cleared, and propose source priorities so orders ship from the warehouse that has the goods.
• Indexers and cron. A price change that never reaches the storefront is often a stalled indexer or cron job, which an agent can catch before customers do. In Vortex IQ, this is a job for Store Health (Pulse).
• Price rules. Catalogue and cart price rules overlap easily across websites and customer groups. An agent can list every active rule, find the ones that stack or contradict each other, and propose which to end.

SEO and merchandising across store views

On Magento, SEO and merchandising problems multiply by store view. A product can have a good description in one store view and an empty one in another. Layered navigation can generate large numbers of filter URLs that search engines crawl instead of your categories. An agent can work through this one store view at a time:

1. Find products and categories with missing, duplicated or untranslated content, ranked by traffic if you connect analytics.
2. Draft the missing content in the right language and your brand voice, for a person to review.
3. Check which filter URLs search engines crawl, and propose which to keep out of search.
4. Flag products pinned to the top of a category that are out of stock, and strong sellers buried further down, then propose new positions.
5. Review promotions against stock, margin and, with a price feed connected, competitor prices, and propose rule changes with reasons.

Content and category positions can be applied through the API once approved. Filter URL handling usually means configuration or code, so it goes to your developers as a pull request or clear steps.

An example: a B2B merchant on Adobe Commerce

An example: picture a B2B merchant on Adobe Commerce selling to trade customers. Each company has several buyers with different roles, its own shared catalogue and contract prices, and approval rules above a spending limit. Stock sits in three warehouses. Contract prices are agreed in the ERP and take days to reach the store, and buyers searching by part number often find nothing. Step by step, the agent would:

1. Connect through an integration limited to catalogue, inventory and B2B company data, with tools that only read.
2. Compare ERP contract prices with each company's shared catalogue, and list every mismatch.
3. Check stock across the three warehouses against open orders, and flag orders waiting on one warehouse while another holds the stock.
4. Find part numbers that return no results, usually because the attribute is not searchable, and propose the change.
5. Hand the lasting fix to the developers: a scheduled sync so contract prices reach the store the day they change. Store Development (CodeCraft) prepares it as a pull request, and the agency's engineers review, test and deploy it.
6. Apply the approved data fixes with an undo point, then rerun the comparisons to confirm the mismatches have gone.

Every step that changes something goes through the team.

What Adobe Commerce and Magento offer today

How to connect MCP to an Adobe Commerce or Magento store, and which options exist today, is covered in our Adobe Commerce and Magento MCP guide. Whichever route you take, the points above apply: narrow access, read first, test on staging, code through review.

Where to start on any platform

1. Work through the agent-ready store audit, which sets out what an AI assistant can read, reach and buy on your store.
2. Pick one job you know is a problem and connect one agent to it, with access that only reads.
3. Agree who approves which kinds of change before the agent can write anything.

To start from findings on your own store, ask for a free store audit.

Frequently asked questions

Is MCP the same as Shopify Flow or a platform API?

No. Shopify Flow runs fixed rules inside Shopify, and a platform API is how software reads and writes store data. MCP is a standard way for an AI agent to find and call tools, and most store MCP tools call the platform's API underneath. Many stores use all three.

Can an AI agent change my live store without asking?

Only if someone gives it write access and no approval step. You decide the permissions. We recommend read-only access to start, a named person approving each change, an undo point for data changes and a pull request for code.

Do I need a developer or an agency to use MCP?

The store owner can switch on BigCommerce's Storefront MCP from the control panel. Connecting an agent to your admin data, setting its permissions and reviewing its code is work for whoever looks after your store technically, in-house or at your agency. On Adobe Commerce and Magento, involve them from the start.

Can one agent work across Shopify, BigCommerce and Adobe Commerce stores?

Yes, if it has a connection to each store, which suits agencies with clients on several platforms. The tools differ by platform, so check what each connection can read and write, and keep approvals separate for each store.

Will MCP personalise my storefront by itself?

No. MCP connects an agent to your store; personalisation still runs through your platform's own features and apps. The agent proposes segments, pairings and promotions, and checks that what goes live matches what was approved.

Whichever platform you run, the work has the same shape: an agent reads your store and the systems around it, finds what is wrong and prepares the change. It proposes. Your team approves. Nothing goes live without your say-so.