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're identified by URIs and surfaced into the model's context only when the host or user opts in. 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 hosts must obtain user consent before invoking. That "must" is in the RFC 2119 sense.
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 SQL access.
If you've spent time in code>Magento\Catalog\Api/code>, the mapping writes itself. Most of what code>*RepositoryInterface/code> exposes is a Resource candidate. Service contracts that mutate state are Tool candidates. Admin workflows are Prompt candidates.
Every production-grade Magento MCP I've looked at in 2026 enforces read-only at two layers. The protocol exposes only read tools, and the underlying PHP refuses writes regardless of what the client asks. Freento's open-source Magento 2 MCP 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, LLMs emit malformed tool arguments. Hallucinated field names, wrong enum values, mis-typed numbers. Server-side validation catches most of it, but the model will try things you didn't anticipate. On a read endpoint, the cost of a bad call is a 400 response. On a write endpoint, the cost can be a corrupted order.
Second, the spec treats tool annotations as untrusted. If your server is multi-tenant and a malicious user registers a tool with a misleading description, a downstream agent might call it. Host consent flows are only as strong as the host's UI, and the UI varies wildly across clients.
Third, write access multiplies the audit surface. You need to log who-called-what-when, what changed, and reconcile against Magento's existing change logs. Most teams don't have that ready on day one.
Read-only, scoped narrowly, with an ACL that separates catalog from customer PII 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 ship-ready.
A strict allow-list of mutating tools, each with its own ACL and rate limit. Not "the model can call any service contract." Specific, named tools with bounded behavior. Adjusting stock by ten units or fewer is a different tool from adjusting stock without bounds, and the two have different risk profiles.
Synchronous human approval for anything customer-facing. If the agent wants to issue a refund, apply a discount above some threshold, or change a published price, the workflow goes through a human in Slack or in the admin. MCP supports this through the Elicitation primitive, which lets a server ask the host to surface a confirmation step.
Idempotency keys on every write. The model will retry on transient failures. If code>createOrder/code> isn't idempotent, you'll get duplicates the first time the network blips.
That's three weeks of careful work for an experienced Magento team, on top of however long the read-only server took. Plan accordingly.
OAuth 2.1 is what the spec wants for remote servers. As of the June 2025 spec revision, MCP servers are classified as OAuth Resource Servers and clients are required to implement Resource Indicators per RFC 8707. That's clean for single-tenant deployment. One store, one OAuth client, one set of scopes.
Multi-tenant is messier. The same MCP server endpoint serving multiple stores, with per-store credentials and no cross-tenant token leakage. The 2026 roadmap from the lead maintainer is honest about this: enterprise needs like SSO integration, audit trails, gateway behavior, and configuration portability are listed as a priority area, but a dedicated Working Group "does not yet exist." That's not a knock on the project. It's a fast-moving open standard. It does mean that if you need SSO today, you're building it yourself, and you'll likely refactor when the standard catches up.
In practice, for internal tools where the AI client runs on someone's laptop, Bearer tokens or OAuth 2.0 Authorization Code with PKCE works fine. For a remote, customer-facing server, the realistic answer is either "wait a quarter or two" or "build defensively and expect to redo the auth layer."
Three real options.
Install an existing module. Freento's open-source server covers sales, catalog, customers, marketing, and system info as read-only tools on Magento 2.4.8 and newer. If your need is "let our merchandiser ask Claude what's low on stock," install it Friday and stop reading this. The commercial options add more entity coverage and admin UI, but trade the open-source flexibility.
Build your own. Worth it if you have store-specific entities the off-the-shelf servers don't expose: custom modules, B2B quote workflows, ERP-synced fields, multi-warehouse stock logic. Start with read-only on three or four entities, plug into Claude Desktop or your IDE for testing, and iterate. The official TypeScript and Python SDKs both ship MCP Inspector for development, which is faster than wiring a model in for every iteration. 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 CSV exports into ChatGPT.
A read-only MCP server exposing five resources: products with attribute filters, orders with date and status filters, inventory levels, abandoned carts, and active cart price rules. Bearer token auth. ACL that splits catalog access from customer-PII access. Audit log of every tool call to a separate table, retained ninety days.
Two weeks for an experienced team. It gives merchants, support, and analysts a faster path to store data than the admin grid, and it's small enough that the inevitable spec drift over the next year doesn't break much.
The roadmap names four priority areas: transport scalability, agent communication, governance, and enterprise readiness. Streamable HTTP stays as the only remote transport. The maintainers explicitly rejected adding more. A code>.well-known/code> metadata format for capability discovery is coming, which will let registries and crawlers learn what your MCP server does without connecting to it. That changes the discoverability story. Your MCP 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. Build with that future in mind even if you don't ship for it now.
Building the bridge between Magento and an LLM agent isn't conceptually hard. The operational details — what to expose, where the auth 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.
