Magento 2 Agentic Commerce - Get Found by AI
More and more shoppers ask AI assistants to find and choose products for them.
Magento 2 Agentic Commerce makes your store readable to those assistants. It publishes a UCP merchant profile, an MCP server, and llms.txt, so ChatGPT, Claude, and other agents can search your catalogue, quote your real prices, build a cart, and send the shopper to your checkout. The Agent Activity dashboard shows which orders and revenue came from agents.
With this extension, you can:
- Be discoverable by AI assistants like Claude and ChatGPT
- Let AI agents build a cart your shopper pays for on your checkout
- See which orders and revenue came from AI agents
- Speak the open agentic-commerce standards: UCP, MCP, WebMCP, and OpenAI ACP
- Publish llms.txt and other agent discovery files automatically
- Get ready for Google's agent-readiness check in PageSpeed Insights
Shoppers Now Ask AI What to Buy
Shoppers ask AI, not search boxes
A growing number of customers ask an assistant to find, compare, and recommend products, then buy what it surfaces.
AI recommends only what it can read
An assistant can only recommend products it is able to read. If your catalogue isn't in a form it understands, your products don't appear in its answers.
Google already grades agent readiness
PageSpeed Insights now has an Agentic Browsing category that checks whether a page is ready for AI agents.
Magento 2 Agentic Commerce brings today's agentic-commerce standards together in a single extension, so AI agents can search your catalogue, compare products, build a cart, and send the shopper to your checkout. It runs on open, industry-backed protocols and handles the parts that trip up simpler integrations: configurable products and products with required options go into an agent's cart as the exact variant, at the right price.
It is built by the team behind our AI Agent Connector (MCP) and Advanced SEO Suite, and it keeps moving with the standards: 18 releases since launch in June 2026.
What benefits do you get?
Works Today with Claude and ChatGPT
Connect your store to an AI assistant like Claude or ChatGPT today, and it will browse your catalogue, compare products, and recommend them to shoppers in a normal conversation.
The assistant replies with your real products: names, prices, and links, so the shopper finds what they need without leaving the chat. The next step is letting your customers' own assistants find you automatically, as more people shop with AI.
Looking for a chatbot on your own storefront instead? That is our AI Chatbot for Magento 2.
Agents Build the Cart, Your Checkout Takes the Payment
When a shopper decides, the assistant doesn't stop at a product link. It creates a cart in your store, adds the exact items and quantities, and updates or cancels it as the conversation goes on. The shopper opens the cart with one link and pays on your usual checkout.
- Configurable products and products with required options (size, edition, engraving) go in as the exact variant, at the right price.
- Cart totals include tax and cart price rule discounts, so the agent quotes what the shopper will actually pay.
- A retried request never creates a second cart, and an unused agent cart expires on its own.
- Your checkout, your payment provider, your conversion data: the order lands in Magento like any other.
Full checkout inside the conversation is on the roadmap and will build on the same setup.
Set Up Once, Discoverable Everywhere Agents Look
Your store automatically publishes everything an AI shopping agent needs to find it: a Universal Commerce Protocol (UCP) merchant profile at /.well-known/ucp that tells agents what your store supports, plus agent instructions in llms.txt and agents.md.
UCP is an open, industry-backed standard for how AI agents discover and transact with merchants, supported by major commerce, payment, and AI companies including Amazon, Mastercard, Meta, Microsoft, Shopify, Stripe, Visa, Walmart, and Google. Because your store speaks it, it is ready for the next wave of AI shopping agents the moment they arrive, with no extra configuration.
You Stay the Merchant
Being present in AI conversations does not mean giving up control. Agents read your catalogue and build carts; orders, payments, and customer accounts stay in your Magento checkout. The extension runs on your own server and domain, with no platform in between and no fee per agent sale. Nothing about your store changes except that it can now be used by the assistants your customers already rely on.
See What Agents Do in Your Store
The Agent Activity dashboard (Marketing → Agentic Commerce → Agent Activity) shows how AI agents use your store, by period and store view:
Calls and agents
How many requests agents made, which endpoints they used, and how many different agents visited.
Attributed orders and revenue
Orders placed from agent-built carts are tagged, so you see the revenue the AI channel brings and which agent brought it.
Top agent queries
What agents searched for, including searches that returned nothing: demand your catalogue doesn't meet yet.
Test with an agent
One click runs a real agent through your store: it searches the catalogue, fetches a product, and builds a cart step by step.
How Magento 2 Agentic Commerce Works
Your catalogue is exposed to agents once, drawing directly on the products and search you already manage in Magento. Four protocol adapters sit in front of it, so every AI client sees the same products and behaves the same way.
UCP
The open Universal Commerce Protocol. Lets any UCP agent discover your store with no pre-registration. This is our main focus.
Generic MCP
A storefront Model Context Protocol server exposing the same catalogue tools, so clients like Claude and ChatGPT can connect to your store directly.
OpenAI ACP
The product-feed and catalogue side of OpenAI's Agentic Commerce Protocol, to reach shoppers using ChatGPT.
WebMCP
In-browser MCP. Once you switch it on, your storefront exposes the same catalogue tools right on the page, so an AI agent working in the shopper's own browser can use your store directly. It is also what Google's PageSpeed Insights checks for in its Agentic Browsing audit.
Through these protocols, an agent can:
- search your catalogue, with filters such as a price range;
- look up products by SKU;
- read full product details, including variants, options, and stock;
- create, update, and cancel a cart;
- read your return, shipping, and warranty terms.
Each protocol can be turned on or off separately from the Magento admin, so you can start with just UCP and add the rest when you need them.
Everything AI Needs, Published Automatically
Once installed, your store serves a complete agent-facing surface automatically:
llms.txt: agent instructions
Plain-language guidance that tells AI agents your store is agent-ready and how to read it. Also served at /agents.md.
UCP merchant profile
/.well-known/ucp lists the supported versions, capabilities, and the signing key an agent reads first. Every agent response is signed with that key, so an agent can verify it came from your store.
Agent-discovery sitemap
A dedicated sitemap for agents, announced in robots.txt alongside an agent block.
Public JSON read API
Product lists, single products, category listings, and search results at /agent/*.json, served by the module itself with no authentication required.
Your store policies
Pick your CMS pages, and agents receive links to your refund, shipping, terms, and privacy pages, plus the full text of your return and warranty terms, marked for the agent to show the buyer.
The product text you choose
Decide which attribute agents read for search results and which for product details, such as a short summary you keep in a custom attribute.
Every setting is covered in the Agentic Commerce setup guide.
Want to get cited in AI search answers (ChatGPT, Perplexity, Google AI Overviews) through rich structured data? That is the job of our Advanced SEO Suite.
Safe to Open to Agents
- A built-in rate limit stops any single client from flooding your store with agent requests.
- Agent requests skip Magento sessions and catalogue answers are cached, so agent traffic stays light.
- A retried request replays the first answer instead of acting twice.
- Disabled products and products from another website are never sent to agents, and products hidden from search stay out of agent searches too.
- Prices come from the same pricing as your storefront: tax display, special prices, and catalog price rules.
Pass Google's Agent-Readiness Check
Agent readiness is now something Google measures. PageSpeed Insights added an Agentic Browsing category (Lighthouse 13.3, May 2026) that grades how ready a page is for AI agents. Among its signals are an llms.txt file at the domain root and WebMCP tools registered on the page.
Magento 2 Agentic Commerce publishes llms.txt right after installation, with the links Lighthouse looks for.
WebMCP is one setting away: switch it on and add your Chrome origin-trial token. WebMCP is still a Chrome origin trial, and Lighthouse only sees it with the token.
Then run your storefront through PageSpeed Insights and see for yourself. The category is still marked experimental, and the remaining checks (accessibility tree, layout stability) depend on your theme.
Want your team's own AI agent to manage the store, rather than shoppers' agents to buy from it? See our comparison of Magento 2 MCP servers.
Be where buying decisions now happen.
Make your catalogue discoverable by the assistants your customers already use. Pairs naturally with AI Agent Connector (MCP) for Magento 2: shopper-facing discovery and admin-side AI in one stack.
Highly recommend it!
Save time by starting your support request online and we'll connect you to an expert.
What is agentic commerce, and why now?
Agentic commerce is shopping through AI assistants: shoppers ask an assistant like Claude or ChatGPT to find, compare, and recommend products instead of browsing websites themselves. Why now? In March 2026, Shopify switched on Agentic Storefronts for its merchants, putting their products in ChatGPT by default. Magento 2 Agentic Commerce brings the same capability to Magento, so your store can be ready now too.
Can Claude or ChatGPT really do this today, or is it just hype?
It works today. Connect your store to an AI assistant like Claude or ChatGPT and it will search your catalogue and reply with your real products: names, prices, and links. Your store speaks MCP, the standard these assistants already use to connect to tools.
Can shoppers actually buy through AI, or only find products?
Yes, up to the cart. AI assistants find, compare, and recommend your products, then build a cart in your store with the exact items, variants, and quantities. The shopper opens it with one link and pays on your checkout, so you capture the sale and own the payment. Full checkout inside the conversation is on the roadmap and will build on the same setup.
Do my shoppers need a special app or AI agent?
No. Your store exposes its catalogue over open protocols, so any compatible AI assistant can read it. There is nothing your customers need to install, and agents need no pre-registration.
How do I check that my store is agent-ready?
Run your storefront through Google PageSpeed Insights and open the Agentic Browsing category (added in Lighthouse 13.3). It checks for llms.txt, which the extension publishes right after installation, and for WebMCP tools, which you switch on in one setting together with a Chrome origin-trial token. There is also a built-in test: go to Marketing → Agentic Commerce → Agent Activity and click "Test with an agent" to watch a real agent search your catalogue, fetch a product, and build a cart step by step.
Does it work with configurable products and products with options?
Yes. Agents see each configurable product with its variants, and products with required custom options (size, edition, engraving) are expanded into purchasable variants with their own prices. When an agent adds a variant to the cart, that exact choice carries through to your checkout.
Can I run agentic commerce on my own Magento server?
Yes. The extension runs inside your Magento installation (Magento Open Source, Adobe Commerce, Adobe Commerce Cloud, or Mage-OS) and publishes the UCP profile, the MCP server, and llms.txt on your own domain. There is no external platform between the agent and your store, and no fee per agent sale.
Is this based on real open standards, and how does it relate to your AI Agent Connector (MCP)?
Agentic commerce is still taking shape, so the boundaries between the emerging standards are not fixed yet. Rather than bet on one, we implemented the standards that have settled enough to build on: UCP (Universal Commerce Protocol), generic MCP, WebMCP, and OpenAI ACP, so your store is ready whichever way the market settles. These are open, industry-backed standards (UCP alone is backed by Amazon, Mastercard, Meta, Microsoft, Shopify, Stripe, Visa, Walmart, and Google), not a proprietary format, so there is no lock-in. The same MCP standard also powers our admin-facing AI Agent Connector (MCP), but that is a separate, operator-side product, while this one is shopper-facing.
search_catalog filter on a dropdown or multiple-select attribute (for example "color": ["Red"]) always returned no products, and a Yes/No filter of "No" returned the products set to "Yes". Both now return the matching products. Stores on standard Magento search are not affected.mst:agentic:search no longer fails on ElasticSuite with a cold cache - The bin/magento mst:agentic:search command answered "Catalog search failed" on ElasticSuite stores right after a cache flush, because it ran without a store area. It now runs in the storefront area, as mst:agentic:cart already did.search_catalog could only narrow results by category and price, so a request like "red jackets in size M" returned jackets of every colour and size. Filters now also accept any product attribute the store uses in search results layered navigation (Use in Search Results Layered Navigation), with the option labels as shoppers see them, for example "color": ["Red", "Blue"]. A product matches any label within one attribute, and must match every attribute given. A label the store does not have returns no products, and an attribute that is not filterable in search is refused with a message listing what filters accept.in_stock, backorder or out_of_stock) next to its availability, so an agent can tell the shopper that an item ships later instead of only that it can be bought.get_product also lists the product's related products, up-sells and cross-sells with their names and links, limited to products that are enabled, visible, in stock and sold in the current store, so an agent can suggest alternatives and add-ons the merchant chose.search_catalog failed when a category filter named a category that does not exist, served the first page again when an agent asked for the next one, and ignored the price filter. Unknown categories are now skipped (a filter with only unknown categories returns no products, as on standard Magento search), each page continues where the previous one ended, and price_min/price_max narrow the results, with the upper bound inclusive. A price range whose minimum is above its maximum returns an empty page, and a very large maximum price no longer causes an error. Stores on standard Magento search are not affected.price_availability signal carrying the status login_required and a message the merchant can edit. Each variant of a configurable product is checked on its own, and the product price range is built from the variants that still have a price. While the setting is on, /llms.txt and /agents.md explain the signal to agents. By default only a product whose regular price is above 0 counts as hidden, so genuinely free products keep their 0 price. The setting is off by default and is set per store view.var/log/exception.log.setup:static-content:deploy after upgrading, as for any module JavaScript change.search_catalog failed with "Internal error" on every call when ElasticSuite was the search engine. Search now works with ElasticSuite and any other engine that replaces Magento's standard search request with its own./llms.txt and /agents.md show only the current store's categories - On an installation with several websites, each with its own root category, categories.all and categories.level_N listed active categories from every root, so one shop's file listed another shop's categories. Each store view now lists only the categories under its own root category. Category items in the template also expose id, parent_id and path, so a template can filter categories further.get_product reported as out of stock, and failed on every such store. It now checks stock the same way get_product does, so the product it picks is always one an agent can actually buy. It looks at no more than 200 candidates, so a catalogue that is entirely out of stock cannot make it run long./llms.txt always contains at least one link — The endpoint list in /llms.txt and /agents.md (the UCP discovery profile, the MCP endpoint, and the product, search, category and sitemap JSON endpoints) was written as plain text addresses. On a store with no policy pages selected (the default) and no categories, the served /llms.txt therefore had no links at all, and Lighthouse flagged it with "File does not appear to contain any links". These endpoints are now written as clickable Markdown links./sitemap_agentic_discovery.xml) was added to the main /sitemap.xml as an ordinary page entry, so crawlers treated it as a page rather than a sitemap. It is no longer added to /sitemap.xml. Instead, robots.txt now carries a standard Sitemap: line with its full address. This is controlled by the existing Enable agentic discovery sitemap setting and works whether or not the robots.txt agent block is turned on. The setting's help text has been updated to match.cancel_cart retires a cart the shopper decided against and answers with its final contents, so the agent can say what was dropped. The response carries no link back to the cart and no expiry date, because neither is true of a cart that is gone; the cart id stops working afterwards, and cancelling twice returns exactly the same answer as the first time. A cart the shopper has already opened in the browser is refused — from that point it is theirs, and an agent holding the old link must not be able to empty it. Cancelled carts are now picked up by the existing cleanup cron instead of lingering./.well-known/ucp profile, which is how the protocol lets an AI agent confirm it is really talking to this store, but nothing was ever signed with it: the key advertised a guarantee the answers did not carry. Every /agent/mcp response now ships the RFC 9421 Signature, Signature-Input and Content-Digest headers, so an agent can check both that the answer came from this store and that nothing altered it on the way — using the key it already fetched. Stores without a keypair, or with the profile document switched off, keep answering exactly as before, unsigned: a signature is never allowed to turn an answer into an error.messages[] carried plain strings, which no platform can act on: the schema has required an object with a type, a machine-readable code and the text since before the version this store advertises, and a string could only ever be printed. Each message now states whether it is a warning, what kind it is, and how it must be presented — which is also what lets a compelled policy disclosure say which term it refers to. An integration reading messages[] as a list of strings must read the content field of each entry instead.search_catalog or lookup_catalog result carried its full description — on a typical catalogue that is roughly nine thousand characters each, so ten results spent a fifth of an AI agent's working memory before it had even chosen a product. Results now carry a short plain-text summary instead, trimmed to 400 characters, with the full description still returned by get_product. Variants also stop repeating the product's own image list when it is identical to the product's, which on a search page was another quarter of the response; get_product still returns every variant complete. Measured on a real catalogue, a ten-product search response dropped by 72%.expires_at, the moment an un-picked-up agent cart is cleaned up (its last update plus the configured lifetime), so an agent coming back later knows whether the link it holds is still good. A cart the shopper has already opened in the browser states no expiry, because from that point it lives by the store's ordinary cart lifetime rather than this one.cost amount, which the UCP cart schema does not define; that field is gone, replaced by the totals breakdown the schema requires. A line now reports its subtotal, its share of an automatic discount, its tax and its total — so an agent can tell the shopper which line the discount applied to, not just that the cart total is lower than the sum of its parts. An integration reading cost off a line item must read totals instead.create_cart; they are now read from the product the extension has already loaded.get_cart, update_cart and cancel_cart advertised the cart id inside cart, while the UCP method signature puts it at the top level. The store had already started accepting both, but the advertised shape is what a conformant agent validates its own request against — so a strict client refused to send the call at all, and three of the four cart operations were unreachable from it. The schemas now describe exactly what UCP describes: get_cart(id), cancel_cart(id), update_cart(id, cart). Clients written against the older shape keep working: cart.id is still accepted.meta.idempotency-key with every call that changes something, precisely so a lost response can be retried safely; this extension ignored it, so a retried create_cart left the shopper with two carts and a retried update_cart applied its change twice. The key is now honoured: repeating a call with the same key replays the first answer instead of acting again, and reusing a key for a different request is refused rather than quietly doing something the agent did not intend. Keys are remembered for 24 hours and cleared by the existing hourly cleanup. Adds a new mst_agentic_idempotency table (applied on setup:upgrade).lookup_catalog names the ids it could not find — Ids that matched nothing were dropped from the answer without comment, so an agent that mistyped one SKU got a shorter list with no way to tell "this product does not exist" apart from "you asked for six and got five". Unmatched ids are now reported in messages.search_catalog applied two different visibility rules depending on the request: a call with filters and no search words listed products that the very same tool refused to return for any wording, because it mirrored the storefront's split between a category page and the search box. An AI agent has no category page to browse — every call it makes is a search — so a product hidden from search is now hidden from the agent as well, whichever way it asks. Stores that keep superseded products visible in the catalogue but out of search will see those products leave agent results; they remain fully available by SKU, which is how an agent reaches a product a shopper named.create_cart came back reporting success with an empty cart and the note "The product's required option(s) weren't entered". On a catalogue where every product carries a required option, no product could be bought through an agent at all. The catalogue tools now list each custom option with its selectable values, and expand the required ones into real purchasable variants — one per choice, each with its own price including the option's price modifier, so price_range finally spans what the product actually sells for. Adding a variant to a cart carries that choice through; referencing the bare SKU takes each required option's default. The cart echoes the full choice back in line_items[].item.id and spells it out in the item title, so an agent replaying a cart into update_cart rebuilds the same one instead of silently falling back to the defaults.get_product reports the option with its input type and character limit, and a required one left blank is refused by name with the exact syntax that answers it. Date and file-upload options still cannot be answered through an agent and say so.totals carried only a subtotal and a total, so an automatic cart price rule (or tax, or a store-credit total) appeared as an unexplained difference between the two and an AI agent had nothing to tell the shopper about it. Every total Magento collects is now reported, with discounts as their own negative entry named after the rule that applied them, and the breakdown is guaranteed to add up to the total the agent quotes. Zero-valued tax and shipping lines are left out rather than implying "no tax" / "free shipping" before the shopper has given an address.success with zero items and buried the reason in messages, which reads to an AI agent as "added to the shopper's cart". Such a request now fails with the actual reason, and an update_cart that resolves to nothing leaves the shopper's existing cart untouched instead of emptying it.agentic_masked_id column and a supporting index to the quote table (applied on setup:upgrade), which is what lets the two cases be told apart after the handoff.pagination.cursor quietly restarted the listing at page one, so an agent walking a large result set was served the same page over and over while believing it was making progress. The restart still happens — page one is the only page that can be trusted at that point — but the response now says so.get_product returned disabled products (marked unavailable, but described in full) and would let one into a cart, while lookup_catalog of the same SKU returned nothing — the same product, two answers. The listing tools were always store-scoped; the by-SKU ones went straight to the product repository, which filters nothing. Disabled products, and products belonging to another website, are now refused on every path. Visibility is deliberately not part of this: naming a SKU is a direct reference, so a Catalog only product is still returned and still purchasable, exactly as it is from its own product page.get_product for a SKU that does not exist answered with an opaque "Internal error" and a correlation id, which an AI agent cannot tell apart from the store being broken — so it had no way to know that suggesting something else was the right move. It now returns a distinct "Resource not found" naming the id, the same treatment an expired cart id already had.search_catalog's price_min and price_max were ignored outright: on a catalogue of $20/$32/$34/$45 products, asking for everything under $10 returned all four, and so did asking for everything over $1,000. An agent asked for "bags under $10" therefore offered the shopper $45 bags as matches, with nothing in the answer to suggest the budget had been dropped. Both bounds are now applied as a real price range, so a price-constrained request returns only products inside it.0 — which is how an agent client says "drop this line" — and a malformed one such as "two" were both silently rounded up to a quantity of one, so a client-side mistake turned into a real order for an amount nobody asked for. Such a request is now rejected, naming the line item at fault and pointing at update_cart for removals, so the agent can correct itself instead of confirming a purchase the shopper did not want. Leaving the quantity out still means one, as the tool has always documented.get_product no longer looks like a product with no description — Search and lookup results carry the description as description.plain, but the single-product tool returned only description.html, so a client that read the plain text off a listing and then asked for the full detail found the key missing and reported the product as having no description at all — the detail tool looking emptier than the search that led to it. get_product now returns both forms, with the plain text complete and untrimmed (the 400-character summary exists to keep ten product pages out of one search response, which does not apply to a single product).get_product on a product with a media gallery (around 9,000 characters on a typical catalogue) failed outright rather than arriving shortened. Browser results are now built to fit rather than cut: the store leaves out the HTML copy of the description, then the product and variant images beyond the first, then shortens the description to a summary, and names in messages what it left out - so what the agent receives is always complete, valid JSON, and it knows to follow the product's url for the full version. Nothing an agent needs in order to sell is ever removed: a product view keeps its whole variant list, and no product is ever dropped from a page of search results, because the agent's next page would start past it. A search asked for more products than fit says so and points at pagination.limit. The size is a new WebMCP output budget (characters) setting (Stores > Configuration > Mirasvit Extensions > Agentic Commerce > HTTP surfaces, store-view scoped), defaulting to 1500 because that is Google's recommended limit for one in-browser tool output; raise it to give agents more detail per product, lower it to give them less, or set 0 to send everything. Direct /agent/mcp responses are unchanged unless the client asks for a size of its own.{{ categories.all }} directly — which the field's own help text encouraged — raised the same "Array to string conversion" warning once per category, so saving or previewing the template produced a wall of 35–50 identical lines that buried the one sentence explaining the mistake. Repeated warnings are now collapsed and the summary capped at three distinct problems (with a "+N more" marker; the full list still goes to the log), and the actionable advice comes first with the raw engine error after it. The field's help text has also been rewritten to separate the variables you output directly from the collection variables that must be looped with {% for %}, with a worked example for each and a link to the variables manual./.well-known/ucp profile that was a byte short, because of how the key material was encoded. An AI agent reading that profile could not use the key: with this release signing responses, it would have rejected every answer the store gave as unverifiable. Affected stores are fixed by upgrading, with no need to regenerate the key.search_catalog describes its query, filters and pagination as optional, then refused any call that used none of them. That is exactly the call an indexing agent makes to pull the catalogue a page at a time, so a feed crawler read zero products from a fully stocked store and had no way to tell that from an empty catalogue. Such a request is now answered as a browse of the store's root category — the same listing the JSON API returns — and the schema says plainly that all three are optional.structuredContent, which the protocol defines as the structured form of a tool's output, found nothing there and read zero products from a search that had in fact succeeded. Both forms are now produced in a single pass, so they can never disagree, and an over-budget notice appears in each.Blog
Andriy Kovalenko 
Oleksandr Drok 
We are committed to being open and transparent with our customers. When you purchase our module, you automatically receive one year of free support service and free updates.
Why is this important?
- Seamless Installation and Configuration: We understand that setting up a new module can take time to configure according to your specific needs. That’s why we offer a full year of free support. Our experienced team is here to assist you with installation, configuration, and any questions you might have. We're eager to share our expertise to ensure you get the most out of your purchase.
- Stay Updated with Magento (Adobe Commerce) Releases: Magento releases new versions approximately every three months. These updates can sometimes introduce compatibility challenges. To keep your store running smoothly, we provide a year of free access to the latest versions of our modules, ensuring that you can upgrade Magento and our modules without encountering any obstacles.
- Subscription Included: Renewing your subscription ensures continued access to the latest updates and support from our team. This means you can be confident that any issues you encounter with the extension will be resolved quickly and efficiently. You can cancel your subscription at any time without any additional fees.
These are our primary. A major portion of our new clients come from referrals from our existing clients. Our professional team of developers, marketers and support staff have invested the best knowledge and experience in the field into our work, so you know you can come back to us again and again.
One year free and high quality support. We go to great lengths to provide maximum satisfaction with every module you have purchased in our store. By helping you with installation, configuration, answering your every question, we do all our best to eliminate any possible problems.
30-days money back guarantee. If you are not satisfied with our Magento AI shopping agent performance for any reason, we provide a full refund.
We constantly add new features to all our modules, and are always interested in hearing your opinion and implementing your suggested features in our future developments.
We provide an expanded user guide for every aspect of our Magento MCP storefront, so you can find answers for all your burning questions.
You can customize Magento UCP integration according to your needs and requirements.
The Module is easy to install and upgrade, just follow our step-by-step user guide. Additionally, the extension is ready to use with the Hyvä theme.
No core modifications. The AI commerce for Magento has been tested in a Magento Cloud environment and is fully compatible with it.