The Model Context Protocol crossed from prototype to production sometime in 2025. By the time Anthropic donated it to the Linux Foundation's Agentic AI Foundation in December 2025, the question for Magento teams was no longer whether MCP was real. It became what to expose, what to lock down, and how any of this works behind a load balancer. None of those answers are obvious yet, and the official roadmap is candid that several are still open. This is a look at what you can build today, what to leave for later, and where the sharp edges are.
MCP defines three things a server can expose: Tools, Resources, and Prompts. The mapping to Magento is cleaner than you'd expect.
Resources are read-only context. The catalog, order history, inventory levels, customer groups, active cart price rules. Anything the model needs to know about before suggesting or acting. They are surfaced into the model's context only when the host or user opts in, and they don't execute anything.
Tools are functions the model can invoke. Creating an order, applying a coupon, adjusting stock, triggering a cache flush. The MCP specification is explicit that tool descriptions must be treated as untrusted unless they come from a trusted server, and that the host must get user consent before invoking one.
Prompts are reusable templates. Canned workflows like "summarize last week's sales for category X" or "draft a follow-up for the top five abandoned-cart products." These are user-controlled, not model-controlled, and they're underrated. A merchant team that defines five good prompts gets more daily value than one handed unrestricted access to the database.
If your team already knows Magento's own service layer, the mapping writes itself. Anything that reads store data is a Resource candidate. Anything that changes store data is a Tool candidate. The admin workflows your staff repeat every week are Prompt candidates.
Every production-grade Magento MCP we have looked at in 2026 enforces read-only at two layers. The protocol exposes only read operations, and the store itself refuses writes regardless of what the client asks for. Freento's open-source Magento 2 module is a clean reference for this pattern, and the commercial implementations do the same. That double enforcement isn't paranoia. It's the right architecture given three facts about where MCP sits in 2026.
First, models get the details wrong. They invent field names, pick the wrong option out of a list, send a number where text belongs. Validation catches most of it, but the model will try things nobody anticipated. On a read request, the cost of a bad call is an error message. On a write request, the cost can be a corrupted order.
Second, the specification treats tool descriptions as untrusted. If your server is shared across several stores and someone registers a tool with a misleading description, a downstream agent might call it. Consent flows are only as strong as the interface asking for consent, and those vary wildly across AI clients.
Third, write access multiplies the audit surface. You need to log who called what and when, what changed, and reconcile it against the change history Magento already keeps. Most teams don't have that ready on day one.
Read-only, scoped narrowly, with permissions that separate catalog from customer data from orders, covers maybe 80% of what merchants actually want: analytics, inventory checks, configuration audits, support diagnostics. All without the operational risk.
That doesn't mean writes are off-limits forever. It means treat them as a separate phase. Three things make writes ready to ship.
A strict allow-list of actions, each with its own permissions and rate limit. Not "the model can call anything the store can do." Specific, named actions with bounded behavior. Adjusting stock by ten units or fewer is a different action from adjusting stock without a ceiling, and the two carry different risk.
Human approval for anything a customer will feel. If the agent wants to issue a refund, apply a discount above some threshold, or change a published price, the request goes to a person in Slack or in the admin before it lands. MCP supports exactly this: a server can ask the host to surface a confirmation step.
Protection against repeats. The model will retry when something times out. If order creation cannot recognise that it has already seen a request, you get duplicate orders the first time the network blips.
That is three weeks of careful work for an experienced Magento team, on top of however long the read-only server took. Plan accordingly.
For a server reachable over the internet, the specification wants modern OAuth, and as of its June 2025 revision it is specific about how clients must identify which server they are talking to. That is clean for a single store: one store, one set of credentials, one set of permissions.
Running one server across several stores is messier, because the credentials for each store must stay genuinely separate. The 2026 roadmap from the lead maintainer is honest about this. Enterprise needs like single sign-on, audit trails, gateway behaviour, and portable configuration are listed as a priority area, but the working group meant to handle them does not yet exist. That is not a knock on the project. It is a fast-moving open standard. It does mean that if you need single sign-on today, you are building it yourself, and you will likely redo it when the standard catches up.
In practice, for internal tools where the AI client runs on someone's laptop, the simpler authentication options work fine. For a remote, customer-facing server, the realistic answer is either wait a quarter or two, or build defensively and expect to rebuild the authentication layer.
Three real options.
Install an existing module. Freento's open-source server covers sales, catalog, customers, marketing, and system information as read-only tools on recent Magento 2 releases. If your need is "let our merchandiser ask Claude what's low on stock," install it Friday and stop reading this. The commercial options cover more of the store and add an admin interface, but trade away some of the open-source flexibility.
Build your own. Worth it if you have store-specific things the off-the-shelf servers don't expose: custom modules, B2B quote workflows, fields synced from an ERP, multi-warehouse stock logic. Start with read-only access to three or four kinds of data, test it against a real AI client, and iterate. This is the path where custom Magento-to-LLM integration work earns its keep.
Wait. Defensible if you have nothing AI-touching in production and your team is at capacity. The protocol will be more stable in twelve months. The cost of waiting is staying behind on internal tooling. Your support team is still pasting spreadsheet exports into ChatGPT.
A read-only server exposing five things: products with attribute filters, orders filtered by date and status, inventory levels, abandoned carts, and active cart price rules. Simple token authentication. Permissions that split catalog access from customer data access. A log of every call, kept separately, retained ninety days.
Two weeks for an experienced team. It gives merchants, support, and analysts a faster path to store data than clicking through the admin, and it's small enough that the inevitable drift in the standard over the next year doesn't break much.
The roadmap names four priority areas: handling more traffic, agents talking to each other, governance, and enterprise readiness. A standard way for a server to publish what it can do is coming, which will let registries and crawlers discover what your server offers without connecting to it first. That changes the discoverability story. Your server becomes a surface other agents can find.
Expect more agent-to-agent traffic over the next eighteen months. Your server may end up being called by another company's procurement agent, not just by a human's Claude window. That shifts the threat model from internal tool to public API, and Magento has already learned what that costs at the payment layer, where card-skimming code sits quietly inside a store that keeps working perfectly. New surfaces attract the same kind of attention. Build with that in mind even if you don't ship for it now.
Building the bridge between Magento and an AI agent isn't conceptually hard. The operational details, what to expose, where the security boundary sits, how to audit the calls, are where teams get stuck. That's the kind of work we do at Encomage: custom Magento modules that put real store data into your AI tooling without breaking anything. If your team is at capacity, a few weeks of focused outside help is usually cheaper than a quarter of rework.
Let’s build something powerful together - with AI and strategy.
