PrestaShop with AI: Store Operations Need Workflows, Not Just Product Lookups

Most "AI for e-commerce" demos stop at the same trick: ask for a product, get a row back. That demos well. It does not run a store.

Picture this instead. Your summer collection went live yesterday. Half the size and colour combos are silently set to hidden. Two of the categories on the homepage are empty because every product underneath is active=0. A "Mother's Day -20%" cart rule expired last week but is still showing on the storefront. Customers are checking out, but the carrier for one shipping zone has been disabled. Nobody noticed.

That is not a screenshot question. That is what a useful agent has to walk: products, variants, stock, categories, prices, cart rules, carriers, zones, and the customer messages people are leaving when checkout breaks.

We rebuilt the PrestaShop MCP server around that shape. Catalog, order book, and localization get separate tools per resource, not one flat JSON blob.

The PrestaShop server now covers the main store-operations lifecycle:

• Catalog: read products with translatable names and descriptions, walk categories and the parent tree, list manufacturers, suppliers, product features, options, and tags.
• Variants and stock: pull combinations (size, color, variant) for a product and inspect per-product, per-combination, per-shop stock levels.
• Pricing: list specific prices and price rules to see promotions, group pricing, and volume discounts that would otherwise hide inside the back office.
• Orders: read orders with their inline line items, shipment carriers, payments, invoices, and credit slips, and walk the status-change history of any order.
• Customers and support: pull customers, their addresses, and the customer-service threads and messages attached to an order or account.
• Carts: inspect open and abandoned carts with their currency, customer, and totals.
• Carriers and shipping: list carriers, deliveries, weight and price ranges, and zones to explain shipping cost and coverage.
• Localization and tax: read languages, currencies, countries, states, taxes, tax rules, and tax rule groups to explain how a checkout will compute.
• Multi-shop: list the shops, shop groups, and shop URLs on a multi-shop install, and pass the shop id on each read when the API key has access.

A category is not a product, a combination is not a stock row, and a customer message is not an order. Mix them up and the agent returns a product when you asked for stock, or a customer record when you meant an order. Keep them separate and the same prompt produces row ids and IDs you can act on.

From catalog audit to a clean store

Pre-campaign cleanup is the first workflow worth automating. Ask the agent to find products without images, SKUs with zero stock, empty categories, and expired cart rules before launch.

It lists active categories and walks the parent tree to map the merchandising hierarchy. It pulls products under each category and projects to the fields that matter to a campaign reviewer (reference, name, active, id_default_image, meta_description). It cross-references combinations and stock to flag SKUs with zero availability or missing variants. It reads specific prices and cart rules to see which promotions are still valid and which have lapsed. Finally, it surfaces manufacturers and suppliers that products still reference but that are themselves inactive.

The output names rows: product id 4218 missing id_default_image, combination 1903 set to hidden on shop 2, cart rule 71 expired on 2026-04-18, supplier 14 inactive but still attached to nine live products. That is a checklist, not a vibe.

Orders carry line items, shipping, and a history

A PrestaShop order ties to a customer, an invoice, one or more carriers with tracking, payment transactions, optional credit slips, and a full status-change audit trail. Line items are inlined on the order itself, so reconstructing the order's lifecycle does not need a tour through five admin tabs.

Here is the kind of order-triage question an ops lead might fire on a Friday afternoon. Find recent orders still in "Awaiting payment", show what was in the cart, which carrier was picked, whether the customer has a support thread open against the order, and what the last status change was. Focus on the unpaid ones older than 14 days first.

The answer comes back grounded in the actual rows — order id, line items, customer thread id, carrier name, payment row, the date and id of the last order_history entry. For refunds, the agent can list orders with a credit slip in the last 30 days, summarise what was refunded, and pull customer messages that have not yet been replied to. The refund queue gets separated from the daily order noise.

Variants and stock are different objects

A product can be active and visible while its only stocked combination is hidden, or while every combination is marked out-of-stock. That is where catalog mistakes hide.

The PrestaShop webservice keeps combinations and stock availability in separate endpoints from products. Combinations carry their own reference, EAN, and price; stock availability is a row keyed by product, combination, and shop. The agent uses both, so a question like "for my summer collection, list every product whose combinations are all out of stock and tell me which suppliers those products are sourced from" turns into a join across three reads instead of a question with no answer.

Localization is where checkout actually breaks

For international stores the localization layer is the part that quietly produces wrong totals. Languages, currencies, countries, states, zones, taxes, tax rules, and tax rule groups each have their own tools, so the agent can audit how a checkout will compute for a given destination.

A localization sweep looks like asking the agent to review currencies, countries, taxes, and tax rules and to surface destinations a customer can technically check out from where the tax rate is inconsistent or the zone assignment is missing. That is the audit a developer normally runs by clicking through twelve admin pages. The agent does it in one prompt and names the rows that need fixing.

Multi-shop is shop-scoped, not store-scoped

On a multi-shop install, the API key is entitled to one or more shops, not all of them. The same product can carry different categories, different stock levels, and different specific prices on shop 1 versus shop 2. The agent lists the shops first, then passes the shop id on each read. Asking for "all products" without scoping the install produces a mixed result that hides the inconsistencies the audit was meant to find.

What to try first

Three prompts that cover the lifecycle, in increasing order of breadth.

For a read-only catalog review, ask the agent to review your products, categories, stock availability, and specific prices and identify the items that need cleanup before the next campaign. The output should be a ranked list with explicit row ids, not a generic "make sure your data is clean" answer.

For order triage with support context, ask for recent orders that have customer messages, carrier details, or payment records pointing at a fulfillment or support issue, ordered by the ones the team should pick up first. The agent walks orders, threads, and order_history to produce that ordering.

For a localization sweep, point at languages, currencies, countries, zones, taxes, and translated configuration, and ask which destinations have inconsistent tax or missing zone assignment. That one tends to surface the longest list of fixable issues, especially on stores that grew into new markets without a developer rerunning the localisation matrix.

Reference docs and live example prompts live on the product page: PrestaShop MCP server.

FAQ

Can an AI agent read both products and their variants?

Products are the master record. Combinations are the per-variant rows (size, color, etc.). Stock availability is its own row keyed by product, combination, and shop. All three are exposed, so the agent can answer both "is this product live?" and "is this specific size/colour combo in stock on shop 2?" without conflating them.

Can it walk orders end-to-end?

An order read returns the inline line items plus links to the customer, carrier, payments, invoices, and any credit slips. The order_history endpoint returns every status change, so reconstructing an order's lifecycle is a join, not a guess.

Does it respect multi-shop installs?

Shops, shop groups, and shop URLs each have their own tools, and shop-scoped reads take an explicit shop id. The API key's shop entitlements are honoured — a request against a shop the key is not authorised for returns a clear "no permission" error instead of a silently mixed result.

Can it manage translatable fields like product names and descriptions?

Translatable fields come back in the requested language when one is specified, and as the underlying multi-language structure when not. Filtering on translatable text is a known PrestaShop API limitation, so the agent filters on stable identifiers (reference, id_category_default, id_manufacturer) and then reads translatable fields back per language.

Does it cover writes, not just reads?

Writes are available on the resources where they are useful: products, categories, combinations, stock availability, specific prices, orders, customers, addresses, manufacturers, suppliers, content pages, and cart rules. Derived rows (deliveries, order histories, taxes, configurations) stay read-only because they are computed by PrestaShop, not authored.

Is this only for developers?

Developers will use it for store automation, but the strongest workflows are operator-led. Catalog audits before a campaign, order triage during a busy week, localization reviews before a market launch, and finance reviews tying orders to invoices and credit slips all fall to people who do not normally write API calls. The agent clicks through the admin. The operator reads the answer.