Make an e-commerce catalog usable by AI shopping agents

An AI shopping agent needs more than a product page it can read. It needs dependable product details, current availability and a safe way to take the next step. Developers can support that workflow by pairing a machine-readable product catalog with narrowly defined MCP actions.

Markdown gives agents a compact way to read product information. MCP actions let them ask for live data or request a change to a cart. Neither should become a second, manually maintained store. Keep both connected to the same catalog and order logic that the storefront already uses.

Start with one source of truth

Before adding an agent-facing format, identify where the store gets its product name, SKU, description, price, currency, variant options and stock status. Include shipping or return details only when the store has reliable values for them. Decide which fields are public and which should remain private.

Build the Markdown representation from those records at request time or through a process that updates it whenever the underlying product data changes. Do not copy product descriptions into a separate file and expect staff to keep two versions in sync. A stale price or unavailable variant can turn a readable catalog into a bad purchasing experience.

Use a predictable structure for each item. For example, include a product name, SKU, concise description, price and currency, available options, and a link to the corresponding storefront page. State when a field is unknown instead of filling it with an assumption. Keep variants distinct: a shirt’s size and color, for example, are purchase choices, not decorative details.

Make Markdown useful, not verbose

Write for a reader that needs to compare and select products. Put the identifying details near the top. Use consistent labels across the catalog, plain language for option values and stable identifiers such as SKUs. Avoid relying on images, scripts or layout to communicate facts that matter to a purchase.

Keep the format focused on selection. Long promotional copy can bury the details an agent needs to answer questions. A short description, explicit options and a current price are more useful than a page full of repeated sales language. Include a canonical product URL so a shopper can inspect the regular storefront.

If the site serves Markdown to agents while retaining HTML for browsers, make sure both representations come from the same product data. The practical mechanics of serving alternate formats through PHP are covered in this guide to PHP content negotiation. The format change should not create a second catalog with its own update schedule.

Separate catalog reading from store actions

Markdown is a good fit for descriptions and published product facts. It is not a safe substitute for live inventory checks, cart updates or order placement. Expose those operations as MCP actions backed by the store’s own services or database rules.

Start with small actions that do one job. A product lookup can accept a SKU or product identifier and return current price, options and availability. A cart action can accept a product identifier, a chosen variant and a quantity. A checkout action can prepare a summary for review. Use clear input and output schemas, and return errors that distinguish an invalid option from an unavailable item.

Do not let an agent infer required checkout fields from a product description. Define them explicitly. Validate identifiers, quantities and option values on the server, then recheck price and stock when the shopper moves toward checkout. A catalog response can be out of date by the time a cart is submitted.

Put the shopper in control

Reading products and preparing a cart are different from placing an order. Require a clear confirmation before an action commits a purchase or payment. Show the final items, quantities, price and any known delivery charges before asking. If the system cannot calculate a total yet, say so instead of presenting an incomplete figure as final.

Apply the store’s normal authentication, authorization and request limits to MCP actions. Avoid exposing customer records or payment details through general catalog tools. For a deeper look at controlling access to live tools, see the guide to authentication and throttling for an MCP endpoint.

Test the whole purchase path

Test with a small set of products that includes variants, an item with low stock and an unavailable option. Compare the agent-facing Markdown with the storefront. Then test each action with valid and invalid inputs, changed stock and stale prices. Confirm that errors are understandable and that a failed request does not silently alter the cart.

Finally, review what the agent can discover and what the endpoint permits it to do. BuiltToWinWeb’s WebAgentScan is a hosted service that evaluates website readiness for AI agents and scores sites out of 100; its description also covers MCP server quality and security. It can provide an evaluation point, but developers still need to verify catalog accuracy and purchase behavior against their own store.

BuiltToWinWeb’s AI Indexing Pack is described as including a working MCP server with output schemas and annotations, Markdown for agents, discovery files and bot access control. For an e-commerce implementation, treat the store-specific product and order logic as the central engineering task: connect the catalog and actions to authoritative data, keep purchase decisions reviewable, and test the result as inventory changes.