As of our most recent scan across 3,235 domains, we have not verified a single Magento or Adobe Commerce store with a live UCP implementation. Magento UCP adoption is effectively zero today. That doesn’t mean it’s impossible — the platform has the technical foundation for it — but this guide is written based on technical analysis of the platform’s architecture, rather than observed monitoring data from live stores.
The gap between configuration and runtime reality is what we expect will be the defining challenge of Magento UCP deployments. A Shopify store either has UCP working or it doesn’t. A Magento store — given the platform’s infrastructure complexity — can appear to have a valid manifest, pass a surface-level check, and still deliver broken agent sessions at runtime because of Varnish caching, REST API restrictions, or module interceptors modifying response payloads. This guide is written in anticipation of these deployments.
This guide covers what we've learned monitoring Magento and Adobe Commerce stores: what the platform requires, what the manifests actually look like at enterprise scale, where things break, and what it takes to run reliably for AI agents. The audience here isn't a solo merchant toggling a plugin — it's the dev team that owns the platform and needs to understand what UCP compliance means in a heavily customized environment.
What Magento Requires
Magento has no native UCP support. Unlike Shopify, which ships the Universal Commerce Agent capability as a first-party app, Magento requires a Composer-installable module that integrates with the platform's service layer. There is no admin panel toggle, no app store install, no one-click activation.
The module handles three things: registering a custom controller route that serves the /.well-known/ucp manifest, wiring up an MCP transport endpoint through Magento's REST API layer, and exposing catalog, cart, and checkout operations as structured MCP tools. Installing it requires Composer access, a code deployment pipeline, and a developer who understands Magento's dependency injection framework.
Minimum requirement for stable compatibility is Magento 2.4.7. Earlier versions of the 2.4.x line have known issues with the REST API authentication flow that the UCP module depends on, and anything pre-2.4 is not supported. Adobe Commerce Cloud deployments on the current managed stack are generally compatible out of the box.
Beyond the module itself, your infrastructure stack determines how hard UCP implementation actually is. The full Magento production stack — PHP-FPM, MySQL or MariaDB, Elasticsearch or OpenSearch, Redis, Varnish, and optionally RabbitMQ for async processing — has multiple layers that can interfere with how the manifest is served and how MCP requests are handled. Each component needs to be explicitly configured to let UCP traffic through correctly. This is not a concern on Shopify or a basic WooCommerce stack. On Magento, it is the central implementation challenge.
The Manifest: What We See Across Enterprise Monitoring
Your UCP manifest at /.well-known/ucp is the entry point for every AI agent that discovers your store. On Magento, the manifest is generated by the module and served via the custom controller route. What agents actually receive, however, depends heavily on what your infrastructure does with that request before it hits the controller — and on Magento stores, the infrastructure layer is rarely neutral.
The first thing we check is whether the manifest is actually being served dynamically. In a correctly configured Magento stack, /.well-known/ucp bypasses Varnish and is served directly from the application. In incorrectly configured stacks — the most common misconfiguration on this type of infrastructure — Varnish is likely to cache the response. We'll cover this in detail in the failure modes section, but the practical consequence is that manifest updates (new capabilities, key rotations, payment provider changes) don't propagate to agents until the cache expires or is manually purged.
The protocol version field is likely to be more variable on Magento than on any other platform. Because there is no platform-managed update cycle, stores running the UCP module must manually update it to stay current with the specification. We’d expect a wider spread of protocol versions on Magento than on Shopify — stores that install the module and don’t maintain it will fall behind the current spec, which well-implemented agents may reject during version negotiation.
The capabilities array on Magento manifests requires explicit configuration. The module does not infer capabilities from your store's installed feature set the way Shopify's app does. A store with B2B shared catalogs enabled will not automatically declare a B2B capability unless the module is configured to do so. This creates a predictable pattern: Magento manifests that are technically valid but undersell the store’s actual capabilities, causing agents to attempt simpler workflows than the store could support.
The payment handlers section requires manual maintenance. When you add Adobe Payment Services, Braintree, Adyen, or any other payment extension, the UCP module does not automatically detect the change. Someone needs to update the manifest configuration. Stale payment declarations are likely to be the second most common issue after Varnish caching problems.
Finally, for stores using multi-website or multi-store architecture, each storefront needs to declare its own manifest correctly. A single Magento instance running three storefronts with different product catalogs, currencies, and payment methods has three distinct UCP configurations to maintain. We frequently see stores where the default website has a current manifest but secondary store views are serving outdated or incorrectly scoped declarations.
Common Manifest Issues We Flag
Based on the platform’s architecture, the most likely issues to encounter in a Magento UCP deployment are: Varnish-cached manifests (the manifest was correct when deployed but changes haven't propagated because the cache was never purged), stale payment declarations (payment methods added or removed after initial module setup without a manifest update), missing or expired signing keys (particularly on stores that had a security audit requiring key rotation but didn't update the UCP configuration), undersized capabilities arrays (the manifest declares fewer capabilities than the store actually supports), and incorrect transport URLs (the MCP endpoint URL in the manifest points to a path that's been modified by a third-party security extension or WAF rewrite rule).
None of these produce a hard manifest validation error. An agent will fetch the manifest, parse it, and attempt to start a session — only to encounter failures that trace back to the manifest not accurately describing the store's current state.
Runtime Performance: Infrastructure-Dependent
Magento's performance profile is fundamentally different from Shopify's. Shopify stores the infrastructure and its performance profile is relatively consistent across merchants. Magento performance is as variable as the hardware it runs on — which ranges from shared hosting running a decade-old stack to Adobe Commerce Cloud backed by managed Fastly CDN.
Based on Magento’s infrastructure characteristics, we’d expect MCP tool call response times between 600ms and 1,500ms on self-hosted infrastructure — significantly slower than Shopify’s median of 146ms. For agent workflows that execute multiple sequential tool calls, this compounds: a product search → variant resolution → cart add → checkout sequence that takes well under a second on Shopify could take 8–12 seconds on a heavily customized Magento store without full-page cache warming.
Adobe Commerce Cloud deployments should perform substantially better. The managed Fastly CDN layer, optimized PHP-FPM configuration, and managed Elasticsearch should reduce median response times to the 350–600ms range — considerably closer to Shopify territory. If you have the option to migrate to Commerce Cloud and runtime performance for agent sessions is a concern, the infrastructure improvements are well-established.
On self-hosted Magento, the configuration decisions that most affect agent session performance are: Redis for session and full-page cache (dramatically reduces PHP processing per request), Elasticsearch or OpenSearch properly indexed and warmed (product search latency drops from 800ms+ to under 100ms), and PHP OPcache enabled and sized correctly (eliminates per-request compilation overhead). These aren't UCP-specific recommendations — they're standard Magento performance practices — but their absence is directly visible in agent session benchmarks.
Tool availability is likely to vary significantly on Magento. On stores with incomplete ACL permission configurations, agents attempting to call the catalog or checkout MCP tools receive authorization errors even for unauthenticated browsing operations. On stores where a third-party security extension has rewritten API routes, the tool endpoints declared in the manifest don't respond. tools/list returning a complete tool set doesn't mean those tools work — we validate this separately in our benchmark checks.
Configuration Checklist
Based on our monitoring data, here are five configuration steps that separate Magento stores that perform reliably for agent sessions from those that pass manifest validation but break at runtime.
First, exclude /.well-known/ucp from Varnish caching. This is the single most impactful configuration change you can make. Add the path to your Varnish VCL exclusion list and verify the exclusion is active. The check is simple: deploy a manifest change, wait 30 seconds, and fetch the URL directly from an IP that isn't cached — if you see the old manifest, Varnish is still serving it. Our monitoring catches this automatically: if we detect a manifest change lag of more than 5 minutes between deployment and propagation, we flag the store.
Second, audit your REST API ACL permissions. Magento's ACL system controls which API resources are accessible to which user roles. The UCP module requires specific REST API routes to be available for anonymous or token-authenticated access depending on your configuration. After installation, explicitly verify that the MCP endpoint routes are accessible without triggering a 401 or 403. Test from an IP with no prior Magento session — stores frequently work in testing because the tester is authenticated as an admin, but fail for agents that arrive unauthenticated.
Third, verify your manifest at ucpchecker.com/check. Run the check immediately after initial setup and after every deployment that touches payment configuration, API routes, or security settings. Review the capabilities and transport sections specifically. If you're running multi-website architecture, check each storefront URL independently — manifests are per-website, not per-instance.
Fourth, test your MCP endpoints through your WAF and CDN, not just locally. The most common source of "works in staging, broken in production" issues on Magento is a WAF or CDN rule that blocks or modifies the MCP traffic. Agent requests look different from browser requests — different headers, different user-agent strings, different request patterns. Run a validation check from outside your network before declaring the implementation complete.
Fifth, set up UCP Alerts. Magento deployments involve many moving parts — module updates, security patches, payment gateway updates, infrastructure changes. Any of these can silently alter your manifest or break your MCP endpoints. Alerts catch regressions before they compound into sustained agent session failures that affect real transactions.
Multi-Store and B2B Considerations
Magento's multi-website and multi-store architecture is one of its defining enterprise capabilities — and one of the most significant sources of UCP complexity we see in our monitoring data. A single Magento instance can serve multiple storefronts, each with its own domain, product catalog, pricing, currency, and payment configuration. Each of those storefronts is a distinct UCP entity that requires its own manifest.
The practical challenge is that Magento's multi-store architecture was designed for human shoppers navigating a browser. AI agents don't have sessions. They don't follow store-switcher UI. They access a domain, fetch the manifest, and connect via MCP. If your secondary storefronts don't have correctly configured manifests at their respective /.well-known/ucp paths, agents reaching those storefronts get nothing — or get the wrong manifest if Magento defaults to the primary website's response.
A common pattern to watch for: the flagship storefront has a current, valid manifest while the B2B portal on a subdomain serves a stale manifest because the dev team configured the primary instance and assumed it propagated. It doesn’t. Each store view with a distinct domain requires explicit manifest configuration and independent monitoring.
B2B features add further complexity. Adobe Commerce's B2B module supports shared catalogs (different product visibility and pricing per company account), company accounts and approval workflows, and requisition lists that function as persistent carts. These capabilities aren't part of the base UCP specification — agents that encounter them need the manifest to correctly declare what B2B features are available and what they require in terms of authentication. A B2B buyer whose agent tries to add an item to a requisition list that requires company account authentication will get an authorization error with no clear indication of why.
The current best practice for B2B Magento UCP implementations is to declare B2B capabilities explicitly in your manifest if they're enabled, provide clear authentication scope requirements, and test agent sessions with both unauthenticated and authenticated company account contexts. The authenticated path is often where the enterprise GMV lives — if agents can't reliably complete approved purchases through the company account flow, the UCP implementation has limited value for your actual buyer population.
Common Failure Modes
Four failure patterns are likely to appear in Magento UCP deployments, based on the platform’s architecture and infrastructure complexity. Each is distinct from what we observe on other platforms.
Varnish serving stale manifests. This is the most predictable failure mode on Magento infrastructure and the one most likely to catch merchants off-guard. Varnish's default behavior is to cache everything it can, including responses from paths that look like static files. /.well-known/ucp looks like a static resource to Varnish. Without an explicit exclusion in your VCL, every manifest update you deploy will be invisible to agents until the cached response expires — which, depending on your TTL configuration, could be hours or days. It’s entirely possible for a key rotation deployed on Monday to go unnoticed by agents until Wednesday if Varnish TTLs are measured in days. Agents encountering an expired key receive authentication failures with no indication that the manifest itself is the problem.
REST API routes disabled or restricted. Magento's REST API can be restricted at the module level, at the ACL level, and at the server level (by a WAF or reverse proxy rule). The UCP module uses REST as its MCP transport layer. When any of these restrictions unexpectedly blocks MCP traffic, agents receive errors that look like authentication or authorization failures — not like "the endpoint doesn't exist." Diagnosing this requires tracing the request from the agent through your full infrastructure stack, which on a heavily customized Magento deployment can involve six or more layers. The shortest path to a diagnosis is running a raw REST API call to your MCP endpoint from an external IP with no cached credentials and checking the actual HTTP response.
DI interceptors silently modifying response payloads. Magento's dependency injection and plugin/interceptor system allows any installed module to modify the inputs or outputs of any service class without touching the original code. This is a powerful extension mechanism for human-facing commerce features — and a significant source of unpredictable behavior for AI agents. A payment module’s interceptor can add a custom field to the checkout response payload that breaks the MCP tool’s JSON schema validation. The checkout would work fine for human shoppers because browser-side JavaScript would ignore the extra field — but the agent, expecting a strict schema, would fail. Identifying these interceptors requires code-level investigation: run bin/magento dev:di:info for the service classes your MCP module uses and audit every registered plugin for potential payload modifications.
Elasticsearch index lag causing catalog discrepancies. Magento's product search runs through Elasticsearch or OpenSearch. When you update product data — price changes, availability updates, new variants — those changes don't immediately appear in search results. They propagate through an indexing queue, which on a busy store with a large catalog can lag 15–60 minutes behind the source of truth in MySQL. An agent running product discovery through the MCP search tool may find a product at yesterday's price, add it to a cart, and then receive a different total at checkout because the MySQL price was updated in the interim. This isn't a UCP-specific problem — it's a fundamental characteristic of Magento's search architecture. The mitigation is ensuring your indexer is running on a tight schedule (bin/magento indexer:set-mode schedule) and configuring realtime reindex triggers for high-velocity data like price and inventory.
Product Feed Best Practices
Magento's Extended Attribute Value (EAV) data model gives merchants fine-grained control over product attributes — more flexibility than Shopify or WooCommerce. It also means product data quality varies more widely across Magento stores than on any other platform we monitor. Custom attributes are easy to add and easy to leave half-configured. When agents try to navigate that data, the gaps show up immediately.
Here's what matters for agent-readable product feeds on Magento:
Configurable products need complete variant trees. Magento's configurable product type is how most stores handle size/color/material combinations. Each configuration attribute needs to be properly linked to child simple products, with every variant having an explicit SKU, price, and stock status. Agents resolving a "blue size L" request need to follow the configurable → simple product tree cleanly. We see stores where variants were deleted from the admin but not delinked from the parent, leaving the MCP tool returning variant options that point to nonexistent products.
Keep custom attributes typed correctly. EAV's flexibility means merchants add custom attributes without thinking carefully about data type. A numeric attribute stored as a varchar, a boolean attribute that contains "Yes"/"No" strings instead of 1/0, a multiselect attribute whose option values are internal IDs instead of human-readable labels — all of these create parsing problems for agents that expect structured, typed data. Audit your product attribute configuration and ensure the attributes exposed via MCP have predictable, correctly typed values.
Set priceCurrency on every offer. On multi-website Magento setups with multiple base currencies, this is especially important. Each store view may have its own currency and pricing tier. Agents that receive product data without explicit currency context can't reliably present pricing to buyers or compare across session contexts. Every product offer exposed through the MCP catalog tool should declare its currency explicitly.
Filter your MCP-facing catalog to match the public storefront. Magento's attribute set and product visibility settings control what appears on the storefront. The MCP module needs to apply the same visibility filters. Disabled products, products assigned to inactive websites, and products with “Not Visible Individually” visibility settings can surface in MCP catalog responses if the module doesn’t correctly apply visibility filters. An agent that finds a product, adds it to a cart, and receives an error at checkout because the product isn't purchasable is delivering a broken session — and that store is the one the agent won't recommend.
Ensure Elasticsearch index freshness matches your commerce velocity. If you run flash sales, daily pricing changes, or frequent inventory updates, your search index needs to reflect those changes on a timeline compatible with agent session behavior. Agents don't tolerate stale data the way human shoppers do — a shopper who sees a sale price and gets a different total at checkout might complete the purchase anyway. An agent validating totals before confirmation will abort. Run your indexers on schedule mode and monitor for queue backlog during high-traffic periods.
Images need descriptive alt text. This is standard accessibility practice and equally important for agent sessions. "product-image-1.jpg" gives an agent nothing to work with. "Adobe Indigo slim-fit chino — front view — ink blue" gives it everything. On Magento, images are often managed through a bulk import process where alt text is omitted. Review your image metadata, particularly for high-velocity product categories where agents are most likely to be doing visual confirmation before adding to cart.
Structured data on product pages matters for discovery. Agents that discover products through web crawling before connecting via MCP rely on Schema.org Product markup on your storefront pages. Magento's default themes include some structured data but it's often incomplete or misconfigured, especially on heavily customized storefronts. Ensure your product pages include: name, description, price with currency, availability, brand, SKU, image URLs, and if you're running B2B, appropriate organization-level restrictions. This creates a discovery path that doesn't depend on the MCP module being correctly configured before an agent can find your store.
What's Coming
Two developments in the UCP specification are particularly relevant for enterprise Magento deployments. The first is persistent cart and session handoff — the ability for an agent to build a cart that a human buyer can then complete in a browser. For B2B scenarios where purchase approval is required, this is the capability that makes agentic commerce actually practical: an agent qualifies the order and builds the cart, a purchasing manager reviews and approves it, checkout completes with human authorization. Magento's existing quote management system maps well to this model.
The second is identity linking — agents authenticating as known customers and accessing account history, loyalty tiers, saved addresses, and company account context. On Adobe Commerce's B2B module, this is where the real enterprise value is. An agent that can access a company's purchase history, check requisition list contents, and complete a reorder against a negotiated catalog price is dramatically more useful than one that can only browse the public catalog. The infrastructure for this exists in Commerce today — the UCP specification is catching up to it.
We track adoption of emerging capabilities through our stats dashboard and publish deeper analysis in the State of Agentic Commerce reports. Enterprise adoption tends to lag consumer platforms by 12–18 months on new protocol features — but the GMV concentration in enterprise Magento accounts means when adoption does happen, it moves markets.
Check Your Store
If you're running Magento or Adobe Commerce and haven't run a UCP check yet, start there. The check validates your manifest, verifies your MCP endpoints are reachable from outside your network, and surfaces the most common configuration issues. It will tell you things your internal staging environment won't, because it tests from the perspective of an agent arriving at your store cold — no cached credentials, no prior session, no whitelisted IP.
If you're already in our directory, set up UCP Alerts. The failure modes that matter most on Magento — Varnish cache serving stale manifests, REST API routes unexpectedly going offline after a deployment, signing keys expiring — are invisible unless you're monitoring continuously. A valid manifest at launch doesn't stay valid indefinitely on a platform that gets as many security patches and third-party module updates as Magento does.
And if you want to see how AI agents actually experience your store end-to-end — not just whether the manifest validates, but whether agents can complete product discovery, variant resolution, and checkout on your specific implementation — UCP Playground runs real agent sessions against live stores. Enterprise Magento customizations create edge cases that manifest validation can't surface. Real session benchmarks find them before your buyers' agents do.
References & Official Resources
- Adobe Commerce Commits to Agentic Commerce Standards — Adobe’s official commitment to UCP, ACP, and AP2
- Adobe Commerce Catalog Optimization for AI Agent Discoverability
- Google: New Tech and Tools for Retailers in an Agentic Shopping Era
- Under the Hood: Universal Commerce Protocol — Google Developers Blog
- UCP Specification — ucp.dev
Further Reading
- The First Fully Autonomous AI Agent Purchase Through UCP — end-to-end autonomous checkout using identity linking and wallet payment
- UCP Now Supports Identity Linking — particularly relevant for B2B Magento deployments with company accounts and negotiated pricing
- The State of Agentic Commerce — March 2026 — latest ecosystem data including enterprise adoption trends
- How a Browser Extension Became Our Biggest Discovery Engine — how we discover and monitor stores across platforms
Related Platform Guides
Exploring UCP across other platforms? These guides cover what we’ve learned about each platform’s implementation:
Top comments (0)