MCP for Magento 2: what a Model Context Protocol server actually does
A shopper asks an assistant whether a product is in stock. Without an MCP server, the answer comes from whatever your store looked like the last time something crawled it — hours ago, or weeks. With one, the assistant asks your store and reads back what is actually there. Then, if you let it, places the order.
Everything below is based on a real Magento store, not a mocked demo.
A real order, start to finish
This is not a simulation. Order 000000005 exists in a live Magento store, and Claude placed it.
Catalogue search, cart, a real shipping quote, a placed order — no browser automation, no scripted demo path, nothing staged for the recording.
Recorded on demo.angeo.dev. Playback loads YouTube only after you press play — nothing third-party is requested before that.
The same session as a transcript. Every monospace line is a tool call the assistant made to Magento; the shopper never sees these.
I want to buy a Fusion Backpack.
Found it — Fusion Backpack, SKU 24-MB02, $59, in stock.
Added. Subtotal $59.
Ship it to me — here are my details.
One method available: Flat Rate, fixed $10.00. Subtotal $59 plus $10 shipping — $69.00 USD. Shall I place the order?
Yes.
Order 000000005, status pending, $69.00 USD. Here is your payment link.
Transcript of the session in the video above. Price, stock and shipping all resolved through Magento’s own rules — the assistant invented none of them.
Three details worth noticing, because each one answers a question people ask next:
The shipping quote is real. Flat Rate at $10.00 came from the store’s own configuration, not from a guess about typical delivery costs.
place_order ran only after an explicit yes. The assistant presented the full total and stopped — that behaviour is enforced server-side, not asked for in a prompt.
The order came back pending, with a payment link. The assistant never touches card details; payment completes through the store’s own gateway, outside the conversation entirely. That is a deliberate design decision, and the reason this stays clear of PCI scope. The full write-up of this session covers the payment question in depth.
What MCP is
An MCP server is a live API that AI assistants already know how to talk to.
The protocol behind that API — the Model Context Protocol — is an open standard for connecting assistants to external systems. Rather than each vendor inventing its own plugin format, a system exposes one endpoint and any conforming client can use it.
Major assistants, including Claude, ChatGPT, Perplexity, Grok and Mistral Le Chat, support remote MCP servers in varying forms, with availability differing by plan. You implement the protocol once instead of building for each vendor separately.
Why the answer is current
Everything else in AEO produces artefacts that AI systems fetch on their own schedule. MCP produces a surface they query on yours. The difference shows up as two different paths for the same question:
Without MCP
Shopper asks about a product
↓Assistant recalls what it crawled or was fed
↓Snapshot from the last crawl or feed refresh
↓Answer that may already be wrong
With MCP
Shopper asks about a product
↓Assistant calls a tool on your endpoint
↓Magento service layer — live price, live stock
↓Answer from the store itself
The right-hand path also skips page rendering entirely — no HTML to parse, no JavaScript to wait for.
| Mechanism | Direction | Freshness | Answers | Best for |
|---|---|---|---|---|
| llms.txt | Crawler fetches a file | As fresh as the last cron run | What the store is and sells | Being found and understood |
| ACP feed | Merchant pushes a file | As fresh as the refresh interval | The full catalogue | Appearing in shopping results |
| Product JSON-LD | Crawler reads a page | As fresh as the last crawl | One product, per page | Being extracted correctly |
| MCP server | Agent queries live | Current, per request | Whatever the agent asks | Staying accurate mid-conversation |
None of these replaces another. A feed is how you get into a shopping result; a live connection is how the conversation stays accurate once it starts.
What an agent can do — and what it cannot
The base server exposes four read-only tools: store information, the category tree, product search with filters, and a full product card with description, attributes, price and stock.
Nothing in the base install changes state. It cannot create anything, cannot modify anything, and cannot spend money.
Installing it is safe and reversible. The server only exposes the same catalogue information your storefront already makes public.
Checkout is a separate, deliberate step. Adding the checkout module brings six more tools — the ones visible in the transcript above — for ten in total.
The split matters more than the tool count. Read access and write access are different decisions carrying different risk, so they are different installs rather than a configuration flag you have to remember to leave off. What stops an agent doing damage covers the write side in detail.
The honest part: this is not a discovery channel
An MCP server will not make ChatGPT recommend your store. Nobody finds you through your MCP endpoint. It does nothing until a person has already connected to it — which means they already knew you existed.
This is worth stating plainly because the surrounding marketing rarely does. Discovery is the job of the other signals: crawler access in robots.txt, an llms.txt content map, complete Product JSON-LD, and a registered product feed. Those put you in an answer. MCP is what happens after.
One qualifier. Assistant vendors run connector directories — catalogues of MCP servers a user can browse and add. A listing there is a genuine discovery surface, but it is a directory listing rather than a property of the protocol, and it requires being accepted. Treat it as a separate channel to apply for, not something an endpoint earns by existing.
Who it is for right now
Repeat and B2B purchasing
A buyer who reorders the same consumables every month does not need to be discovered — they need the reorder to take thirty seconds. Procurement is repetitive and specification-driven, which is exactly the work that gets delegated to an assistant first. This is the strongest near-term case, and B2B stores are best positioned for it.
Your own team
The most immediately useful deployment is often internal. Install the read-only server, connect your own assistant, and merchandisers can interrogate the catalogue in plain language — without writing SQL or waiting on a developer.
“Which products in Outdoor are in stock but have no images?”
“How many SKUs are missing a GTIN?”
“What is the price of SKU 24-MB02 across all four store views?”
Answered in the chat, against live data, by someone who has never opened a database client. No customer needs to be involved for this to pay off in the first week.
An audience that already follows you
If you have customers who would plausibly add your store to their assistant, the connection is worth offering. If you do not, an MCP endpoint is infrastructure with nobody on the other end.
What stops an agent doing damage
Letting a language model touch a live store is a reasonable thing to be nervous about. The defences that matter are enforced in Magento, not requested in a prompt — a model that misreads an instruction still cannot exceed what the server permits.
- Read-only by default. The base install exposes nothing that changes state.
- Server-side rate limiting. An agent stuck in a loop cannot turn your catalogue into an outage.
- Guest checkout only. No customer accounts, no order history, no stored payment methods. The exposure of a compromised session is one cart.
- No card data. As in the transcript above, the order lands pending and payment completes through your own gateway or a payment link — outside the conversation.
- Order guardrails. Configurable caps on order value and item count, plus per-IP limits on placement.
- Confirmation before purchase. Order placement is annotated as destructive, so assistants stop and ask. It is never called autonomously.
If checkout tools are enabled but the endpoint does not require authentication, the checkout tools hide themselves and a critical notice appears in the admin. An open checkout endpoint would let anyone on the internet place orders anonymously — so rather than trusting the merchant to notice, the module refuses to expose them. The read-only catalogue tools keep working.
MCP, ACP and UCP are not competing
They are frequently confused because all three involve AI agents and commerce. They solve different steps:
| Protocol | Job | Who talks to it |
|---|---|---|
| MCP | Give any assistant live, structured access to a system | Any MCP client |
| ACP | Get a catalogue into ChatGPT’s shopping surface | OpenAI |
| UCP | Let an agent verify a merchant and transact on Google surfaces | Google surfaces and conforming agents |
MCP is vendor-neutral and general-purpose; the other two are commerce-specific and tied to particular ecosystems. For the sequencing argument between the commerce protocols, see ACP vs UCP for Magento 2.
The part that trips people up
Your store’s own /mcp path authenticates with a bearer token and has no OAuth flow, which means it cannot be pasted directly into an assistant’s connector settings. Assistants expect an OAuth-capable endpoint. Adding a custom connector with your raw store path will fail, and the failure is not obvious from the error.
Plan for that before promising anyone a one-click button. The full connection flow per assistant — including the OAuth requirement and the landing-page pattern for shoppers without an account — is in the MCP Checkout documentation.
Getting started
Install the read-only server first and leave it there for a while. It is safe, reversible, and enough to find out whether anyone actually connects.
composer require angeo/module-mcp-server
bin/magento setup:upgrade
# confirm the endpoint answers an MCP handshake
curl -s -X POST https://your-store.com/mcp -d '{"method":"initialize"}'Both modules are MIT licensed with no licence key, account or telemetry. Version requirements live in the compatibility matrix, read from each package’s composer.json rather than restated here.
Add checkout only once you have a reason to. It does what the video shows — which is the point, and also the reason to exercise it on staging first.
What to expect
A read-only server is a low-risk afternoon: your own team gets a useful tool immediately, and the store is positioned for a channel that is still forming. Checkout is a real capability with real consequences — order 000000005 is not a mock-up — but agent-initiated purchasing is not mainstream traffic yet.
The honest position: install it because the internal use pays for itself and the positioning is cheap, not because it will bring orders this quarter.
Questions
Can an AI agent really place an order in Magento?
Yes. The video and transcript above show Claude completing a guest checkout on a live Magento store — order 000000005, $69.00 USD. The agent calls the Magento service layer over JSON-RPC, so prices, stock, tax and shipping resolve through Magento’s own rules and an agent order obeys the same logic as a human one. Placement happens only after the shopper confirms.
Is it safe to expose my catalogue to AI agents?
Everything the read-only server exposes is already public on your storefront; the difference is that it arrives structured instead of scraped. The read-only default and server-side rate limiting are what make it defensible. Write access arrives only when you install the checkout module deliberately.
How is payment handled if the agent cannot take card details?
The order is placed with payment deferred — it lands pending, and the shopper completes payment through the store’s own gateway or a payment link, entirely outside the conversation. This is why the flow stays clear of PCI scope: no card data ever reaches the assistant.
Does an MCP server make my store visible in ChatGPT?
No. Visibility comes from crawler access, structured data, a content map and a product feed. An MCP server only does anything once someone has already connected to it. The two jobs are separate, and doing one does not achieve the other.
How is MCP different from llms.txt?
llms.txt is a static file a crawler fetches on its own schedule. MCP is a live connection an agent queries in the moment, returning current prices and stock. Different mechanisms serving different needs — a store doing this properly has both.
Which assistants can connect?
Any MCP client. Major assistants including Claude, ChatGPT, Perplexity, Grok and Mistral Le Chat support remote MCP servers in varying forms, with availability differing by plan. Implementing the protocol once covers all of them rather than building per vendor.
Do I need MCP if I already have an ACP product feed?
They serve different steps. The feed is how your catalogue reaches ChatGPT’s shopping surface — that is discovery. MCP is how an assistant queries your store accurately during a conversation, and how it can transact without a browser. Neither substitutes for the other.
Next: the module · connecting an assistant · scan your store first
Discovery comes before any of this. If you have not checked whether AI systems can read your store at all, start there.