Serveur MCP
L'endpoint MCP distant : ses URL, ses deux modes d'authentification, et ce que voit un client quand il se connecte.
BoostEcom fait tourner un serveur MCP distant, avec un endpoint par boutique connectée. C'est par là qu'un client IA lit une boutique Shopify et les données BoostEcom qui lui sont rattachées.
Lecture seule. Chaque outil du catalogue est une lecture, y compris
celui qui accepte un document GraphQL : shopifyAdminGraphQL exécute les
requêtes et refuse les mutations, par leur nom, dans le handler. Aucun
manque à combler ici : c'est la conséquence honnête de ce qu'est un
relais. Écrire sur une boutique en ligne est une décision que quelqu'un
doit approuver, et il n'y a personne dans un relais : un client IA
appelle, l'appel arrive, rien ne s'interpose. Tant qu'il n'existe pas de
circuit d'approbation, refuser est la seule réponse qui ne puisse pas
modifier en silence le catalogue d'un client.
L'endpoint
https://www.boostecom.app/api/mcp/v1/<storeId>
La forme sans version, /api/mcp/<storeId>, est sortie en premier et
figure dans la configuration de chaque client installé depuis. Elle reste
en place, telle quelle. Les deux forment un seul endpoint sous deux
noms : les mêmes handlers, et un jeton émis par l'un fonctionne sur
l'autre.
Utilisez le chemin v1 pour toute nouvelle intégration.
Deux modes d'authentification
| Mode | Identifiant | Familles d'outils ouvertes |
|---|---|---|
| OAuth 2.1 PKCE | Jeton d'accès obtenu via /oauth/authorize | Relay et native. |
| Statique | Bearer bst_mcp_ | Relay uniquement : les 15 outils relais, dans la limite des droits Shopify de la boutique. |
Cette asymétrie est voulue ; elle est expliquée dans Outils MCP et scopes.
Une clé statique ne porte aucune chaîne de scopes : elle est donc lue
comme l'autorisation héritée, qui couvre la famille relay et rien
d'autre. Deux conséquences en découlent. 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, donc ils ne s'enregistrent pas pour elle et n'atteignent un client
que par OAuth. Quant aux outils native, ils ne s'enregistrent jamais
pour une clé statique, quelle que soit l'autorisation, parce qu'ils
exigent un appelant identifié.
Ce qui conditionne un outil
Trois portes, et un outil doit toutes les franchir pour être enregistré sur une session donnée :
- Le scope BoostEcom approuvé : ce à quoi l'utilisateur a consenti.
- Les scopes Shopify de la boutique : un plafond infranchissable. Si
la Custom App ou l'installation OAuth n'a jamais obtenu
read_orders, aucun scope BoostEcom ne le fera apparaître. - Un appelant identifié : exigé seulement par les outils
native, parce que leur permission dépend de l'appartenance à une organisation, et qu'en mode statique il n'y a personne à vérifier.
Un outil qui échoue à l'une des portes n'est pas enregistré : il n'apparaît pas du tout dans la liste d'outils du client, au lieu d'y figurer puis d'échouer à l'appel. C'est le bon comportement pour un client IA : un outil qu'il voit est un outil qu'il essaiera.
Connecter un client
Quatre clients ont un guide pas à pas :
Chacun donne l'URL, le mode d'authentification que ce client prend en charge et un extrait de configuration 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 du catalogue et ne contient aucun secret. C'est ce
que lit chaque boutique Shopify que nous interrogeons pour négocier nos
capacités avant de répondre.
Pour aller plus loin
- Outils MCP et scopes : le catalogue complet.
- Authentification : choisir un identifiant.