BoostEcom fait tourner un serveur MCP distant, un endpoint par boutique connectée. C'est la surface par laquelle un client IA lit une boutique Shopify et les données BoostEcom qui y sont rattachées.
Lecture seule. Chaque outil du catalogue est une lecture, y compris
celui qui prend un document GraphQL : shopifyAdminGraphQL exécute les
requêtes et refuse les mutations, par leur nom, dans le handler. Une
écriture sur une boutique en ligne est une décision que quelqu'un doit
approuver, et un relais n'a personne dedans : un client IA appelle,
l'appel arrive, rien ne se tient entre les deux. Tant qu'il n'existe pas
de chemin d'approbation, refuser est la seule réponse qui ne peut pas
modifier en silence le catalogue d'un client.
L'endpoint
https://boostecom.app/api/mcp/v1/<storeId>
La forme non versionnée, /api/mcp/<storeId>, a été livrée en premier
et reste portée dans la config de chaque client installé depuis. Elle
reste, exactement telle quelle. Les deux sont un seul endpoint avec
deux noms : les mêmes handlers, et un token émis via l'un fonctionne
sur l'autre.
Utilisez le chemin v1 pour tout ce qui est nouveau.
Deux modes d'authentification
| Mode | Identifiant | Familles d'outils ouvertes |
|---|---|---|
| OAuth 2.1 PKCE | Token d'accès depuis /oauth/authorize | Relay et native. |
| Statique | Bearer bst_mcp_ | Relay uniquement : les 15 outils relais, dans la limite des droits Shopify de la boutique. |
L'asymétrie est délibérée et expliquée dans Outils MCP & scopes.
Une clé statique ne porte aucune chaîne de scopes : elle est lue comme
l'octroi hérité, qui s'étend à la famille relay et à rien d'autre. Deux
conséquences. Les outils de documentation public, searchDocs et
getDoc, accepteraient un appelant que le relais ne sait pas nommer,
mais une clé statique ne nomme jamais leur scope : ils ne s'enregistrent
pas pour elle et n'atteignent un client que par OAuth. Et les outils
native ne s'enregistrent jamais pour une clé statique, quel que soit
l'octroi, parce qu'ils exigent un appelant identifié.
Ce qui verrouille un outil
Trois portes, et un outil doit toutes les franchir pour être enregistré sur une session donnée :
- Le scope BoostEcom approuvé : ce que l'utilisateur a consenti.
- Les scopes Shopify de la boutique : un plafond dur. Si le Custom
App ou l'installation OAuth n'a jamais obtenu
read_orders, aucun scope BoostEcom ne l'invoque. - Un appelant identifié : requis seulement par les outils
native, parce que leur permission dépend d'une appartenance à une organisation, et qu'il n'y a personne à vérifier en mode statique.
Un outil qui échoue à une porte n'est pas enregistré : il n'apparaît pas du tout dans la liste d'outils du client, plutôt que d'apparaître et d'échouer à l'appel. C'est le bon comportement pour un client IA : un outil qu'il peut voir est un outil qu'il va essayer.
Connecter un client
Quatre clients ont un guide pas à pas :
Chacun donne l'URL, le mode d'authentification que ce client supporte, et un extrait de config prêt à coller.
Découverte d'agent
La plateforme publie un profil d'agent UCP sur
/.well-known/ucp-agent. Il déclare une
capacité de lecture de catalogue et ne porte aucun secret. C'est ce que
chaque boutique Shopify que nous interrogeons lit pour négocier nos
capacités avant de répondre.
Suite
- Outils MCP & scopes : le catalogue complet.
- Authentification : choisir un identifiant.