Mago is the open-source admin assistant coming with Mage-OS 4. Who builds it, why it beats the first attempt, the MCP addon I built at the Zwolle hackathon, and what it really costs.
There is a new admin assistant for Magento and Mage-OS called Mago, and it is the first one I would actually put in front of a merchant. You can read about it on askmago.com. Before I tell you what I like about it, what it costs, and what I built on top of it, let's start with the people behind it.
Who builds Mago
Mago is built in the open by the Dutch Magento community, together with Mage-OS Nederland. The partners named on the site are Made by Mouses, Magmodules, Linted, Vendic and Control Alt Delete.
Looking at the GitHub repository, most of the work comes from Michiel Gerritsen (Control Alt Delete), followed by Haimanti Dekker, Marvin Besselsen (Magmodules), Mitchel van Kleef and Lars de Weert (Made by Mouses), Peter Stuifzand, Sean van Zuidam and Henk Valk, with more contributors joining every week. Mago Core is free and MIT-licensed. No seats, no subscription, no paid tier.
And behind all of them is Mage-OS, the community-run distribution of Magento Open Source. If you want to know what Mage-OS is and why we moved all our customers to it, I wrote about it in Why We Migrated All Our Customers to Mage-OS.
Before Mago, there was the Mage-OS Lab admin assistant
Credit where it is due. Mago is not the first attempt. Ryan Sun built the Mage-OS Lab admin assistant back in early 2025: a chatbot in the Magento admin that combined an LLM with Magento domain knowledge. What I found genuinely original was that it did RAG in PHP. You ran bin/magento assistant:train, it built document embeddings, and the chatbot answered with that knowledge behind it. In a world where every AI project starts with a Python service next to the shop, doing it inside Magento itself was a bold choice.
The downside was that it was never really polished. It often got answers wrong, and sometimes even a normal installation failed. We played around with it, but eventually gave up. It simply wasn't good enough compared to a standard Claude Code terminal session on the server.
Mago feels like the version of that idea that grew up.
Why this matters to StoreFrame
At StoreFrame our mission is to bring operations and Magento together through AI and infrastructure. I wrote about this in Agentic Operations, Not Agentic Commerce: everyone talks about AI that shops for the customer, but the real pain sits on the operational side, with the people who run the store every day.
Mago validates that. A whole group of Dutch agencies sat down and built an assistant for the admin, not for the storefront. That tells me the operational need is much larger than the commerce need.
It is not a replacement for what we built in StoreFrame. We work at the infrastructure level: servers, deployments, security, monitoring. Mago works inside the admin, with the merchant. It is a great addition, and the two fit together well.
What makes Mago stand out
There are a lot of AI chat widgets for Magento. These are the things that make Mago different.
- The UI. It is simply good. Answers stream in while Mago works, results come back as proper widgets instead of walls of text, and slash commands like
/cache flushrun directly without an AI call. As someone with an interaction design background, this is the part that made me smile first. - The classifier. Every tool has to classify every field it returns. Names, emails, phone numbers and addresses are stripped before anything reaches the AI provider, order and customer numbers become placeholders like
[order_1], and any field that is not explicitly marked safe never leaves the store. - The safety guardrails. Reads run immediately, every write asks for confirmation. Irreversible actions, like cancelling an order or creating a credit memo, show exactly what will happen first and need an extra acknowledgement. Some settings are not offered at all, such as base URLs, the SMTP host and the store email addresses, because one wrong value there hands over the whole store.
- The ACL. Everything follows Magento's own ACL. Read and write are separate permissions, and skills can be allowed per user. Each admin sees only what their role allows.
Security is not a second-class citizen in Mago. It is designed in from the start, and you can tell.
Logging and audit, done properly
What makes it even more special is the logging. Conversations, tool calls and the queries behind them are recorded, so you can trace back exactly what the LLM did: which tool it called, with what input, and what came back. Together with the detectors and the answer feedback, it is audit-ready out of the box.
When you let an AI touch a production store, this is what you need. It is simply impressive, and honestly, this is what high-end Magento modules look like.
Addons: extend before you modify
Mago has a plugin API, so other modules can add their own skills without touching the core. There are already addons contributed for checking a Dutch company in the KvK register and validating an EU VAT number against VIES, plus ones for reporting issues to GitHub and reading Hypernode server load.
This is how it is meant to grow: build an addon first, and only change the core when you really have to.
Shipping with Mage-OS 4
Mago ships with Mage-OS 4.0.0, released on 30 October. It also runs on Magento 2.4.9 and Mage-OS 3.0, but Mage-OS 4 is where it comes bundled.
Mage-OS 4 is one of the biggest feature releases so far, and it goes deeper into AI. It is built on the same Magento Open Source 2.4.9 base as 3.6, with no change in PHP support, so it is a drop-in upgrade from 3.6.x, and most new features stay off until you turn them on. Next to Mago it brings a shared AI layer that works with whichever LLM provider you choose, llms.txt files and crawler controls for AI discoverability, passwordless login with passkeys, native product feeds for Google, Meta, Pinterest, TikTok and Microsoft, and an overhaul of Multi-Source Inventory that closes a gap where two orders could oversell the same stock. Under the hood, setup:di:compile is faster and WebP and AVIF images are supported natively. The full list is in the release announcement.
Damien Retzinger from Graycore, the creator of Daffodil, shared the video of the Mage-OS meeting where Mago is demoed. It is worth watching to see it in action.
▶ Mago demo at the Mage-OS meeting
The MCP addon: made in Zwolle, perfected in Amsterdam
On 24 September I joined the Mage-OS hackathon in Zwolle, hosted by Made by Mouses, where we sat together and built on Mago. I mentioned it, with photos, in the Mage-OS post. My contribution was one of the MCP addons.
MCP is the protocol AI tools use to talk to other systems. The addon turns every tool from an MCP server into a Mago skill:
- Local MCP servers over stdio are detected automatically, from installed Composer packages and from the
.mcp.jsonfile in the Magento root. - Remote MCP servers, like Context7 for up-to-date documentation, can be added through the admin portal, with no token, a shared bearer token, or OAuth per admin user.
- Nothing is enabled by itself. An admin turns each server on, and every tool is classified as read or write by its name. Anything unrecognised is treated as a write, so it goes through Mago's confirmation card.
- Output stays private by default. Results go through Mago's privacy filter unless an admin switches it off for a server whose answers contain no personal data.
Then, on 4 November, at the hackathon in Amsterdam at the Bold Commerce office, I went back to it and tightened its security and permissions, to make it much harder to break a webshop with it. Every MCP server now starts read-only, so only its read tools are exposed. A write is only offered after an admin unticks read-only and then ticks that one tool. Tools that run code, SQL or shell commands, or that handle credentials, are withheld completely until someone deliberately enables them. So when Bricklayer or n98-magerun is installed, Mago gets their lookups and nothing that can change or run anything.
The output follows the standard set by Mago's core module too. The privacy filter is on for every new server, so results pass through Mago's own scrub, which hides emails, phone numbers and values Mago already knows before anything reaches the AI provider. Passwords, tokens and encrypted config values are masked in every case. And an MCP tool can only read customers, orders or configuration for an admin whose Magento role is allowed to open those screens.
If you would like to test it, this is the branch: mago-assistant/magento2-mcp, feature/mcp-http-and-stdio.
The module is still under development, hence the branch. I have spent quite some time making sure it respects the security guardrails and the system from Mago's core module, but a review from a senior backend developer would make it even better. Any developer is welcome to review it and make changes.
A disclaimer: power comes with great responsibility
With the release of Mage-OS 4, installing the MCP module means Bricklayer MCP, and possibly n98-magerun, will be installed in your vendor folder too. That makes it extremely powerful. It can do many good things, and it can do many bad things too.
I deliberately tried a few techniques to crash the module or shut down the webshop. Somehow the admin assistant was good enough to warn me, prevent it, and refuse certain actions, which makes it even better. But don't take my word for it as a guarantee. Try it on staging, and at your own risk.
The downside: every chat costs money
It is not fair to only talk about the positives. Mago calls an LLM provider's API, so every chat costs something. A simple question might cost from 0.3 cents, up to a euro for a long, complex one. If you run long chats and complex questions several times a day, it can become unsustainable.
To be fair, you pay your provider directly at list price with no markup, and you can set a monthly spending limit. But while developing I am using an Anthropic API key, and it is definitely not cheap.
Claude Subscription: using your Claude plan instead of an API key
So I built magento2-claude-subscription. It is for when you would rather use your Claude subscription than an API key, especially as a developer building Mago features, addons and everything around it, where you chat with the assistant all day.
It plugs into Mage-OS AI Base as just another AI provider, so in Mago you simply pick it as the AI service. Next to the shop runs a small Node host: you log in once with claude auth login on that machine and start it with bin/claude-subscription start. Magento sends every chat turn to that host as a normal chat completion request, and the host runs claude --print for it with your subscription's login. Claude's own tools and MCP servers are switched off for that run, and it starts in an empty folder, so Claude only answers in text. Mago's tool calls are passed through as tags, and Mago still asks an admin to confirm every write.
The downside is that the host is a persistent process you have to start and log in to yourself, and every admin who can open Mago shares that one Claude account. It is perfect for development and testing, but not suited for production. Check your Claude plan's terms too. Again, use it at your own risk, you have been warned.
Closing
Mago is the Magento admin assistant I wish existed when we tried the first one. It has a great UI, it treats privacy and security as first-class, and it is open and easy to extend. The cost is real, so watch it. But if you run a Magento or Mage-OS store, keep an eye on Mage-OS 4, try Mago on staging, and if you can review PHP, have a look at the MCP branch.
