# Making a shop queryable and operable by an AI assistant

> Setting up an MCP server that exposes a shop's catalogue, orders or stock as tools an AI assistant can call is still a recent type of project, but demand for it is growing fast.

- Source canonique : [https://allaux.fr/en/expertises/serveur-mcp-boutique-pilotable](https://allaux.fr/en/expertises/serveur-mcp-boutique-pilotable)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The typical need

More and more teams use AI assistants internally to query their data or trigger routine actions, without switching back to the back-office interface every time. The typical need is to expose certain shop functions — checking stock, looking up an order, getting a delivery status — in a form the assistant can call directly, rather than having a person hop between tools for every check.

## How I approach this kind of need

The MCP (Model Context Protocol) standardises how an AI assistant can discover and call tools exposed by an external system. In practice, I define a set of tools matching precise actions or queries on the shop — never generic, uncontrolled access to the database — with a clear description of what it does and its limits for each tool.

The most decisive question is around permissions: which actions can an assistant carry out on its own, and which need to stay read-only or require human confirmation. Looking up stock or an order carries little risk; changing a price or cancelling an order via an assistant needs a much stricter framework, with systematic logging of every call to keep full traceability of what the assistant actually did.

## Factors that affect the quote

- **Number of tools exposed** — Exposing three simple lookups is quicker than a broad set covering catalogue, orders, stock and write actions.
- **Level of write access allowed** — Read-only tools sharply limit risk and the securing work compared with tools able to modify data.
- **Authentication requirements** — Internal use restricted to a handful of people is simpler to secure than access meant for several profiles with different rights.
- **Call volume and frequency** — Occasional use is handled differently from heavy use, which needs particular attention to the performance of the exposed tools.

## Questions worth asking before starting

> Which actions need to stay read-only, and which can genuinely be delegated to an assistant? Who should be able to use this access, and how is it authenticated? How can you review the history of what the assistant actually requested or changed?

## MCP server by platform

- **PrestaShop MCP** — Official PrestaShop MCP Server module, bespoke module from 1.7 and tools for your modules. ([/prestashop/mcp](/prestashop/mcp))
- **WordPress and WooCommerce MCP** — Abilities API, MCP Adapter and WooCommerce MCP integration, with limited rights. ([/wordpress-woocommerce/mcp](/wordpress-woocommerce/mcp))
- **Shopify MCP** — Storefront MCP, Dev MCP and a private server on the Admin API. ([/shopify/mcp](/shopify/mcp))

## FAQ

### Does an MCP server give full access to the database?

No, and that's a deliberate choice: only precise, delimited tools are exposed, each with a defined scope of action, rather than generic, uncontrolled access.

### Can this access be limited to certain people?

Yes, authentication and the associated rights are configured by user profile, exactly as for any sensitive access to an information system.

### What happens if the AI assistant makes a mistake?

That's precisely why high-stakes actions (changing, deleting) are deliberately kept outside the automatable scope, or made subject to confirmation, depending on the level of trust established.

### Does this kind of integration work with any AI assistant?

MCP is designed to be independent of the assistant used, as long as it supports the protocol; it's an open standard rather than a solution proprietary to a single vendor.