Una vecchia API REST e un agente AI moderno: come abbiamo collegato uno store PrestaShop a Claude

Il setup che sembra antico (e per alcuni aspetti lo è davvero)

Quando ho aperto il dashboard di PrestaShop per collegare lo store di un cliente a Claude via MCP, mi aspettavo il setup più semplice della serie. Avevo già fatto WordPress, Shopify e Google Ads. PrestaShop ha un’API REST documentata da quindici anni, una sezione “Webservice” nel pannello, una pagina di permessi molto chiara. Cosa poteva andare storto?

Mezza giornata dopo, con un parser XML aperto in un tab e ?output_format=JSON attaccato a ogni URL, ho capito che PrestaShop non è il setup più complicato della serie — è il setup che richiede di disimparare più cose. Buona parte del modello mentale costruito su Shopify e WordPress non vale qui. Bisogna riadattarlo.

Questo articolo racconta il diario di quel setup. Cliente anonimizzato: uno store PrestaShop B2B nel packaging industriale, catalogo di migliaia di referenze tecniche, audience di buyer professionali. Non racconto il sorgente del server custom MCP — quello è lavoro di sviluppo. Racconto le tre differenze concettuali rispetto a Shopify e WordPress, e cosa cambia operativamente nel lavoro SEO una volta superate.

Il caso: catalogo grande, audience tecnica, cicli lunghi

Lo store in questione vende prodotti industriali a buyer professionali. Catalogo di migliaia di referenze, schede prodotto tecniche, mercato italiano con presenza europea. Caratteristiche tipiche del B2B online che cambiano completamente il modo in cui MCP genera valore rispetto a uno store consumer.

Su un B2C con 500 prodotti di moda, MCP brilla nelle micro-ottimizzazioni: meta description curate, alt text per Google Immagini, A/B test di descrizioni emozionali. Su uno store B2B con migliaia di referenze tecniche, la sfida è diversa: portare in ordine sistematicamente l’intero catalogo per query commerciali ad alta intenzione che nessun copywriter umano scriverebbe a mano per ogni singolo SKU. È esattamente il tipo di lavoro per cui MCP, su scala, fa la differenza.

L’obiettivo del setup, quindi, non era “provare Claude su PrestaShop”. Era poter eseguire in due-tre settimane operazioni di SEO tecnica massiva che a mano richiederebbero tre mesi.

Setup tecnico in quattro step

Step 1 — Abilitare il Webservice di PrestaShop

Dal pannello admin: Advanced Parameters → Webservice (su PrestaShop 8.x: Configura → Parametri avanzati → Webservice). Attivare il toggle “Enable PrestaShop Webservice”. Sembra banale, ma è il primo punto di rottura tipico: alcuni hosting bloccano per default il .htaccess con RewriteEngine on che serve a PrestaShop per esporre le rotte API.

Se al primo test ricevi un 404 su /api/, è quasi sempre questo: il rewrite delle URL non è abilitato a livello server. Soluzione: contatta l’hosting o, su VPS, verifica che mod_rewrite sia attivo e che la direttiva AllowOverride All sia presente per la directory dello store.

Step 2 — Generare una API key con permessi granulari

Sempre dalla schermata Webservice, “Add new webservice key”. Generata la chiave (40 caratteri alfanumerici, da copiare subito in un posto sicuro), si arriva alla parte interessante: la matrice dei permessi.

A differenza di Shopify (che usa “scope” macro, tipo read_products, write_products) e WordPress (che eredita dai ruoli utente), PrestaShop espone una matrice puntuale: per ogni risorsa esposta (products, categories, customers, orders, cms, manufacturers, attributes, e decine altre) decidi individualmente se concedere GET, POST, PUT o DELETE.

Per un setup SEO completo, una configurazione ragionevole:

• GET: su tutto (read-only di base, niente rischi)
• PUT: su products, categories, cms, manufacturers (modifiche ai contenuti SEO)
• POST: su products solo se vuoi che Claude possa creare nuovi prodotti (raramente serve all’inizio)
• DELETE: mai. Quasi nessun caso d’uso richiede che l’agente cancelli risorse

Bonus di sicurezza: nella schermata della key c’è anche un campo “IP allowed”. Se sai da quali IP statici il server MCP farà chiamate, mettili. Riduce drasticamente la superficie di attacco se la chiave dovesse mai trapelare.

Step 3 — Configurare il server MCP

Qui PrestaShop si differenzia da Shopify e WordPress, dove esistono già moduli MCP pronti. Per PrestaShop, al momento, l’ecosistema MCP non è ancora maturo: si parte da implementazioni open-source esistenti (alcune disponibili su GitHub) oppure si scrive un wrapper sottile in Node o Python che traduce le chiamate MCP in HTTP requests verso l’endpoint Webservice di PrestaShop.

L’endpoint base ha questo schema:

https://NOMESTORE.it/api/RISORSA?ws_key=LA-TUA-KEY

Oppure, in modo più pulito, con autenticazione HTTP Basic:

GET https://NOMESTORE.it/api/products/123
Authorization: Basic [base64(LA-TUA-KEY:)]

Nota il : finale dopo la key. PrestaShop usa la chiave come username, e si aspetta una password vuota. Sembra una sottigliezza, ma è il secondo punto di rottura tipico: molti wrapper HTTP standard pretendono entrambe le componenti, e vanno configurati esplicitamente.

Step 4 — Aggiungere l’entry in claude_desktop_config.json

Schema simile a Shopify e WordPress ma con variabili d’ambiente diverse:

{
  "mcpServers": {
    "prestashop-NOMESTORE": {
      "command": "node",
      "args": ["/path/al/server-mcp-prestashop/index.js"],
      "env": {
        "PS_BASE_URL": "https://NOMESTORE.it/api",
        "PS_WS_KEY": "LA-TUA-API-KEY"
      }
    }
  }
}

Riavvio completo di Claude Desktop (quit dal menu, non minimizzazione). Al primo prompt — “elenca i primi 10 prodotti dello store con titolo, prezzo, link_rewrite” — se tutto è a posto, il modello restituisce la lista. Tempo medio dal click “salva config” al primo risultato: meno di un minuto.

Le tre differenze concettuali rispetto a Shopify e WordPress

Una volta che il setup gira, la parte interessante è capire dove PrestaShop si comporta diversamente dai due CMS più moderni. Sono tre differenze, e tutte e tre cambiano il modo in cui i prompt vanno costruiti.

Differenza 1 — XML invece di JSON

PrestaShop Webservice risponde di default in XML. Si può forzare JSON con ?output_format=JSON sul singolo endpoint, ma molte risorse hanno output JSON incompleto: le relazioni nidificate (es. associazioni prodotto-categoria, immagini multiple, varianti) sono rappresentate male o parzialmente. Il pattern di lavoro più stabile è: GET in XML, parse, modifica, PUT in XML.

Conseguenza pratica: il server MCP deve gestire bene il parsing XML, e il modello deve essere consapevole che alcuni campi richiedono manipolazione di struttura, non solo lettura di valori. Non è una difficoltà insormontabile, ma è una skill in più rispetto al “JSON sempre e ovunque” del mondo Shopify.

Differenza 2 — HTTP Basic auth invece di Bearer

Niente Bearer token. La chiave si passa come username, password vuota, in HTTP Basic. È un dettaglio, ma fa parte del modello mentale da riadattare: le librerie HTTP standard la gestiscono, ma molti wrapper MCP scritti per Shopify/WordPress presumono Bearer e vanno configurati esplicitamente per Basic.

È il tipo di dettaglio che, se non lo sai, ti fa perdere un’ora a debug del server prima di accorgerti che l’header che mandavi era nel formato sbagliato.

Differenza 3 — Permessi granulari per risorsa

La sicurezza diventa più chirurgica (puoi essere preciso su cosa concedere) ma più complessa da setup (se manca un permesso, l’errore arriva al primo tentativo di modifica, non al setup). Consiglio operativo: prima generazione della key con tutti i permessi su uno staging environment, calibrazione dei prompt, e solo dopo restrizione mirata in produzione con i permessi che effettivamente servono.

Le aziende che invece partono in produzione con permessi parziali finiscono per perdere giornate a capire perché “il modello non vede il campo X” — quando il problema è che alla key manca il permesso GET sulla risorsa che contiene X.

Il pattern operativo: GET → modifica → PUT

Una specificità importante di PrestaShop rispetto a Shopify: per modificare un singolo campo serve scaricare l’intera risorsa, modificarla e rispedirla. Non esiste un equivalente del productUpdate(input: { id, field }) di Shopify, che accetta solo i campi che cambiano. Su PrestaShop, ogni modifica costa due chiamate HTTP: una GET per scaricare, una PUT per rimandare l’XML intero.

Su catalogo grande questo si nota. Su 5.000 prodotti, una sistemazione massiva di meta description significa 10.000 chiamate HTTP. La soluzione si articola su tre livelli:

• Batching intelligente lato server MCP: raggruppa più risorse in una sola chiamata dove l’API lo permette.
• Filtri con display=full o display=[campo1,campo2]: limita i campi scaricati a quelli che servono davvero, riducendo overhead di rete e di parsing.
• Esecuzione spalmata nel tempo: invece di tutto in una sessione, programmare le operazioni massive in finestre orarie con basso traffico utente.

Campi tipicamente esposti per ottimizzazione SEO via Webservice: meta_title, meta_description, meta_keywords, link_rewrite (lo slug URL), name, description_short, description. Tutti i meta SEO standard sono lì, accessibili e modificabili.

Cosa cambia operativamente sullo store B2B

Una volta che il setup funziona, il valore concreto su uno store B2B con migliaia di referenze diventa visibile in poche settimane:

• Riscrittura massiva di meta description: su uno store con anni di storia, una larga parte dei prodotti ha description vuote o duplicate. Il refactoring completo, alternato uomo-modello, occupa una decina di sessioni di lavoro su catalogo grande.
• Pulizia di link_rewrite (slug URL) con creazione automatica di redirect 301 sulle URL vecchie. PrestaShop ha la tabella nativa per i redirect, e si può popolare via API.
• Schema markup Product + Offer: PrestaShop non ha gestione nativa dei dati strutturati come Shopify. Si inietta via description HTML o tramite metafield se il tema lo prevede. Con MCP, l’operazione è automatizzabile su tutto il catalogo.
• Internal linking categoria→prodotto e prodotto→prodotto correlato: PrestaShop ha la tabella accessory_product per gli accessori. Si presta bene per costruire un grafo di link interni coerente, basato su categorie tecniche affini.
• Audit di prodotti orfani: prodotti in catalogo ma non raggiungibili da menu visibile. Capita più spesso di quanto si pensi negli store con anni di vita.

Tempo realistico per portare in ordine un catalogo di 5.000 referenze con questo workflow: due-tre settimane di lavoro alternato, dove l’umano dedica forse 30-40 ore complessive (il resto è esecuzione del modello). A mano, lo stesso lavoro è tre mesi pieni di una persona dedicata.

Limiti onesti

Quattro punti che vale la pena dire chiaramente prima che qualcuno tenti il setup con aspettative sbagliate.

1. L’ecosistema MCP per PrestaShop è meno maturo di quello Shopify/WordPress. Meno plugin pronti, maggior probabilità che serva un developer per scrivere il wrapper. Trenta minuti diventano una giornata, almeno la prima volta.
2. Performance API più basse: la Webservice di PrestaShop è strutturalmente più lenta della Shopify Admin API (carico server PHP, overhead XML, query database non sempre ottimizzate). Su hosting condiviso, le operazioni massive vanno spalmate nel tempo.
3. Differenze tra versioni: PrestaShop 1.6, 1.7 e 8.x hanno differenze API non trascurabili. Verificare sempre la documentazione corrispondente alla versione effettivamente installata sul proprio store.
4. I moduli custom restano fuori: molti store PrestaShop hanno funzionalità chiave gestite da moduli di terze parti che non espongono via Webservice. Quelle restano fuori dal raggio d’azione MCP, e per ora vanno gestite con altri strumenti.

Vecchia API, agente nuovo

Alla fine del setup la sensazione è curiosa: hai collegato un agente AI di ultima generazione a un’API REST che ha l’architettura di vent’anni fa, con XML, HTTP Basic, e un modello di permessi che ricorda i forum amministrativi del 2008. Funziona. Funziona davvero bene, una volta superato lo straniamento iniziale.

E forse è proprio questo il punto più interessante di MCP come standard: si adatta alla tecnologia che trova, non chiede di rimpiazzarla. Uno store su PrestaShop 1.7 con dieci anni di storia, sviluppato quando l’AI generativa non esisteva, oggi può beneficiare di operazioni SEO automatizzate che a mano costerebbero mesi. Senza migrare a un altro CMS, senza riscrivere il tema, senza nemmeno aggiornare la versione PrestaShop se questo non era nei piani.

PrestaShop è stato uno dei primi CMS eCommerce europei a fare seriamente B2B in API. Anche da MCP si vede — nei vantaggi e negli intoppi.

Per completare la serie “connettere il tuo stack a Claude”: la procedura per WordPress, dove l’ecosistema è già pronto e il setup è più lineare.