ChatGPT quoted our client a price from six months ago. The issue wasn't with ChatGPT, but with the fact that the AI couldn't read our store. We measured and fixed this using numbers from logs and code you can verify.
The client showed us a conversation with ChatGPT. The number was clear: our Magento module was supposed to cost 190 euros. The actual price was already 240 at that time.
ChatGPT wasn't hallucinating. Our site couldn't show it the price.
The configurator calculates it in JavaScript after the page loads. A spider that doesn't run JavaScript gets 63 kilobytes of HTML with the title "Calculate the approximate price of your online store" and no number. Since it couldn't read the live price, ChatGPT quoted the last one it had in its index.
This led us to a question that no one on the team had asked:
What does an AI agent actually see when it visits our store?
So we started measuring.
Which AI agents visit the online store?
July 2026, degriz.net logs:
| Agent | Requests | What it read |
|---|---|---|
| ClaudeBot | 1,934 | 400 times sitemap.xml, then the homepage |
| OAI-SearchBot | 763 | 77 times configurator, otherwise robots.txt and homepage |
| ChatGPT-User | 67 | homepage, blog, store creation page |
| GPTBot | 10 |
Three things surprised us.
ClaudeBot hardly reads content. It pulls the sitemap. What is in it, it finds; what isn't, doesn't exist for it. Our configurator wasn't in the sitemap.
ChatGPT-User means a real person. This agent appears when someone in a conversation asks something that causes ChatGPT to visit your site. 67 visits aren't many, but it's 67 people who were deciding at that moment.
llms.txt wasn't read by any AI agent in all of July. Twelve requests in total, seven of which were our tests. A file that half the industry declares mandatory had no readers on our store. We publish this too because a measurement you only share when it suits you isn't a measurement.
From all this came an unpleasant realization:
It's not enough for information to be on the website. AI must be able to read it mechanically.
From SEO to agent commerce
To be clear about what we're talking about, three steps that have happened in the last two years.
Classic SEO. Google finds the page, a person opens and reads it. You optimize for Google to show you.
AI search. The model reads the page instead of the person and answers them. No one clicks. You optimize for the model to understand and correctly cite you.
Agent commerce. The model finds the product, checks the price, assembles the cart, and leads the buyer to payment. You optimize for it to work with your store, not just read it.
The third step is the one that needs something new, and that's where protocols come in.
What is what: five technologies in one table
The store owner doesn't need to know this by heart, so here it is:
| Technology | What it does | Who uses it |
|---|---|---|
| JSON-LD (schema.org) | writes data on the page so that a machine understands it | every spider and search engine, already today |
| llms.txt | a short summary of the store for AI, in text | so far, few |
| MCP (Model Context Protocol) | AI can use the store's functions, not just read | Claude, ChatGPT via plugin |
| UCP (Universal Commerce Protocol) | a standardized checkout that the agent finds on its own | new standard, April 2026 |
| ACP feed | catalog in machine-readable form, one line per product | platforms that import catalogs |
The most important difference is between MCP and UCP. MCP must be manually added by the user to their AI tool settings. UCP discovers itself via a fixed path /.well-known/ucp, without user intervention. The first works today for those who set it up. The second is a bet that platforms will indeed start discovery.
What we built
1. Machine-readable prices where traffic already is
The most boring and by far the most effective.
The configurator now carries schema.org data with 117 offers: twelve packages and all individual modules, each with a price, description, and what the package includes. Nothing has changed for the visitor because the data is in JSON-LD and in a noscript block.
Why not a visible table with prices? Because it's a sales page, and a table with 117 rows in the middle of it destroys what the page exists for. Our first attempt was exactly that, and we reverted it in half an hour.
The prices here aren't created separately. They come from the same calculation that drives the configurator, the PDF offer, and the confirmation email. We set this rule at the start and haven't broken it: one path to the price. If an agent quotes a price that differs from the checkout by one cent, the entire project is harmful instead of helpful.
2. MCP: what an agent can actually do in the store
| Tool | What it enables |
|---|---|
store_info | currency, language, whether prices include VAT |
search_products | search the catalog |
get_product | product details and price |
create_cart | assemble a cart and return a link |
configurator_open | open the store creation configurator |
configurator_quote | calculate an offer for selected modules |
configurator_checkout_link | link to submit an inquiry |
The last three are special. The configurator, with which a visitor assembles their online store and gets a price, is accessible within the conversation. The model asks what you need, assembles a package, and quotes a price that is the same as you would get with an hour of clicking.
3. UCP: standardized checkout

AI agent -> /.well-known/ucp -> checkout session -> continue_url -> cart -> payment The agent checks the fixed path, learns what the store can do, and opens a checkout session. Our store opens five operations: create, read, update, complete, and cancel.
The goal is clear: for the AI agent to complete the purchase, including payment. UCP anticipates this. The merchant publishes payment processors, the agent assembles the payment method, and the order is completed programmatically, without the buyer even opening the store.
We don't offer this yet because a payment provider that speaks the protocol on their side is missing. This step doesn't depend on us.
What we've done until then isn't a makeshift solution but a branch that the specification explicitly anticipates. The session responds with status requires_escalation and provides continue_url; the buyer clicks, lands in the cart with selected products, and pays normally. All mandatory protocol requirements are met, a store without payment integration is a full-fledged UCP participant, and when the payment part becomes available, it lights up as an additional capability. Nothing will need to be rebuilt.
4. Catalog and discovery files
We publish the catalog as an ACP feed: 117 products, one line per product, price, stock, image, link. Additionally, llms.txt and agents.json, generated dynamically and separately for each store, which is important if you have multiple languages.
How this connects into a chain
The most beautiful thing isn't any single surface, but that they close the loop. The product code from the catalog is the same code that the checkout accepts. A real output of a real run against our store:
1. DISCOVERY GET /llms.txt
catalog: .../acp/si/products.jsonl
2. CATALOG 117 products
selected: Magento technical support, 60 EUR
3. UCP SESSION POST /ucp/checkout-sessions -> 201
subtotal 60,00 VAT 13,20 total 73,20
match: catalog price == checkout price
4. BUYER continue_url from a fresh browser
302 -> /checkout/cart/
product in cart, amounts 73,20 / 60,00 / 13,20 The agent knew nothing. It started with the file, found the catalog, sent the code to the checkout, and got a link. A click from a completely new browser deposits the product in the cart with the correct amount.
The piece ChatGPT needs
During testing, we encountered an obstacle that no protocol solves. An agent browsing the web can only read. It can't send a request to open a checkout session. So even a completely correct UCP doesn't help as long as the agent can only read.
What such an agent can do is give a link to a human. So we added an address that the model assembles itself from codes found in our public data:
/ucp/cart?sku=CODE1,CODE2&qty=1,2 The server builds a cart from it and redirects to the checkout. It works on the first click from a browser that hasn't seen our store yet. It's not part of any standard, and we don't claim it is.
Five things to check on your store
We found all of the following on ours when we started measuring. None were visible in analytics, and none reported an error.
1. Are prices in HTML or only in JavaScript? Open a product page and view the source code in the browser, not developer tools. If the price isn't there, AI doesn't see it. Our entire pricing page was like this.
2. Are important pages in sitemap.xml? ClaudeBot pulled our sitemap 400 times in July and almost nothing else. What isn't in it doesn't exist for this type of visit. Our configurator wasn't.
3. Does your machine catalog really contain the entire catalog? Our export once contained 29 products instead of 117. We only discovered it when we compared the number with a count in the database. Compare every published quantity with the source.
4. Which countries do you have listed as delivery areas? Magento has all enabled by default. Our store was telling agents it delivers to 246 countries, including Afghanistan. The agent cites this as a fact.
5. Does each store have its own data? If you have multiple languages on one installation, check if each gets its own. Our English store was telling agents Slovenian language, Slovenian currency, and Slovenian endpoint address because both got the same file.
For developers building this themselves, it's helpful to know that the most expensive mistakes here aren't those that break the response, but those where the response is the correct form and wrong content. Our best such: an offer without an address in Magento doesn't sum anything, so a module for 240 euros in a completely valid response cost 0.00.
What this means for your Magento store
Today, measurably:
- AI sees your current prices, not last year's
- finds your products and knows what's in stock
- can use store functions, not just read pages
- can give the buyer a link that already contains the cart
The next step we're working on:
- payment directly in the conversation. UCP anticipates this; a payment provider that speaks the protocol on their side is missing. When available, it lights up as an additional capability, and nothing will need to be rebuilt.
- when any platform starts discovery via
/.well-known/ucp, you're there from day one - the store becomes a point with which software does business, not just a page someone reads
What we don't promise: that ChatGPT will submit an order in your store tomorrow. Today it can't, because agents browsing the web can only read. Therefore, we won't sell this until it really works.
Frequently asked questions
What is the Universal Commerce Protocol (UCP)? An open standard from April 2026 for communication between an AI agent and a store. The agent learns what the store can do at the fixed path /.well-known/ucp and then assembles a checkout session through five operations. The key difference from other approaches is that discovery requires nothing from the user.
What is MCP for Magento? Model Context Protocol is how AI uses external tools. An MCP server in Magento means the model can search the catalog, read prices and stock, and assemble a cart directly from the conversation. The user must add the plugin to their AI tool settings once.
Can an AI agent create a Magento cart? Yes. In our implementation, the create_cart tool assembles a real Magento offer and returns a link that deposits the buyer in the cart with the same amounts. Nothing is reserved or charged until the buyer opens the link and completes the purchase at checkout.
How to prepare a Magento store for AI agents? Five steps in order of impact: put prices and product data in JSON-LD on the page, ensure important pages are in sitemap.xml, publish a machine-readable catalog, add an MCP server for tools, and finally a UCP manifest for discovery.
Is this necessary for every store? No. If you have ten products and all content in HTML, AI probably already reads you correctly. It's sensible for stores with a large catalog, content behind JavaScript, or prices that change frequently.
Check for yourself
Everything is public:
https://www.degriz.net/llms.txt
https://www.degriz.net/.well-known/ucp
https://www.degriz.net/media/agentcommerce/acp/si/products.jsonl
https://www.degriz.net/agents.json We've put the entire chain from discovery to cart into a script that you can run against our store, which prints what happened at each step, along with a comparison of the catalog price and the checkout price.
The online store is slowly changing from a page visited by a human to a system with which software communicates.
For Magento merchants, this doesn't mean you need to change platforms tomorrow or enable AI shopping. But it does mean it's worth checking something quite basic:
Can an AI agent today find your products, understand their prices, and reach a purchase?
We first checked this on our own store and found five things that didn't work. Only then did we start building a solution for other Magento stores. If you're interested in what such a measurement would show for you, we'll do it.
