novalo-dev/Prestashop-MCP-Server

A PrestaShop module that turns a shop into an MCP
server. Claude, ChatGPT or any MCP client can then work with the shop's orders,
through a standard protocol, with OAuth 2.1 and the employee's own back office
permissions, instead of a database login or an API key that can do everything.
The module folder is somcp; in the back office it is called **O'So MCP Server**.
This repository is looking for PrestaShop developers who want to build it with
us. See Where to help.
---
What it does
- **Serves MCP from inside PrestaShop.** No separate service, no Node process,
no dependency beyond PrestaShop itself. The endpoint is a module front
controller.
- **Runs its own OAuth 2.1 authorization server**: discovery documents (RFC 9728
and RFC 8414), PKCE S256, dynamic client registration and client ID metadata
documents, refresh token rotation with reuse detection. Tokens are stored
hashed and bound to the shop they were issued for.
- **Uses PrestaShop permissions as they are.** An employee connects an assistant
on their own behalf, on a consent screen in the back office. The assistant
then holds exactly that employee's rights: each tool is tied to a back office
page and one of the four rights PrestaShop already manages, view, add,
edit or delete.
- **Supports multistore natively.** Each shop has its own address, its own
tokens and its own settings with the usual inheritance. An employee only
reaches the shops they are attached to.
- **Lets any module publish tools and prompts** through two hooks, by returning
arrays. No dependency on somcp's classes, so those modules still pass the
Addons validator. See docs/EXTENDING.md.
- **Speaks both eras of the protocol** from one endpoint: the stateless
2026-07-28 revision, with questions in the middle of a call, and the
2025-11-25, 2025-06-18 and 2025-03-26 revisions.
Compatibility
| | |
|---|---|
| PrestaShop | 8.0.0 to 9.x (ps_versions_compliancy 8.0.0 - 9.99.99) |
| PHP | 8.1 or later |
| Multistore | supported |
| Languages | English, French, Spanish, German |
The shop has to be reachable over **HTTPS**, with **friendly URLs** enabled, and
installed at the **root of its domain**: OAuth anchors one of its discovery
documents there. The diagnostic button in the settings checks all of this by
calling the shop's own addresses.
Tools
| Tool | Scope | Back office right | Nature |
|---|---|---|---|
| somcp_ping | mcp.access | none | read |
| somcp_search_orders | mcp.orders.read | view on AdminOrders | read |
| somcp_get_order | mcp.orders.read | view on AdminOrders | read |
| somcp_list_order_statuses | mcp.orders.read | view on AdminStatuses | read |
| somcp_set_order_status | mcp.orders.write | edit on AdminOrders | write |
**Reads** are flagged read-only and safe to repeat. **Writes** are flagged
destructive, which is what MCP clients use to ask the merchant before running
them; each write changes one object per call and is never retried on a lost
answer.
somcp_ping is outside the permission system on purpose: it reads no shop data
and only says what the assistant is connected to (shop, account, language,
currency), so an assistant can always tell which account it is using, even one
with no rights at all.
Three prompts ship with the module: checking the connection, finding an order,