22 outils répartis sur 11 scopes. Les deux chiffres sont dérivés du catalogue de scopes dans le dépôt, donc cette page ne peut pas dévier de ce qu'un client peut réellement recevoir.
Le catalogue porte aussi des outils réservés à l'équipe BoostEcom. Ils sont retirés de votre écran de consentement et revérifient le rôle de l'appelant à chaque appel : aucun droit de cette page n'en ouvre un, et ils ne sont pas comptés ci-dessus.
Le catalogue
| Scope | Famille | Outils | Droit Shopify requis |
|---|---|---|---|
| boostecom:store.read | relay | getShopInfo, getStoreContext, introspectSchema | — |
| boostecom:catalog.read | relay | listProducts, getProduct | read_products ou write_products |
| boostecom:orders.read | relay | listOrders | read_orders ou write_orders |
| boostecom:content.read | relay | listPages | read_content ou write_content |
| boostecom:metadata.read | relay | getMetafields, listMetaobjectDefinitions, listMetaobjects | — (Shopify tranche par requête) |
| boostecom:themes.read | relay | listThemes, getTheme, runAudit | read_themes, write_themes ou write_theme_code |
| boostecom:analytics.read | relay | runShopifyQL | read_analytics ou read_reports |
| boostecom:graphql.read | relay | shopifyAdminGraphQL | — |
| boostecom:studio.read | native | getStudioSection, getStudioProduction, listStudioGenerations, getStudioPricing | — (voir plus bas) |
| boostecom:intelligence.read | native | getStoreIntelligence | — (voir plus bas) |
| boostecom:docs.read | public | searchDocs, getDoc | aucun (rien à accorder) |
N'importe lequel des droits Shopify listés satisfait une ligne. Un tiret signifie que Shopify n'a pas son mot à dire : soit l'outil n'a besoin d'aucun droit particulier, soit Shopify applique sa propre limite par requête.
Les trois familles
Ce n'est pas cosmétique. La famille décide à qui un outil répond :
relay atteint Shopify via le pont. Un bearer statique bst_mcp_
la satisfait, parce que la clé est cantonnée à la boutique et la
détenir est l'autorisation.
native atteint un système que BoostEcom possède. Elle exige un
appelant identifié, donc une clé statique ne la satisfait jamais.
La raison mérite d'être dite clairement : getStudioSection protège une
ressource dont la permission dépend d'une ligne OrganizationMember.
Sans utilisateur, il n'y a personne à vérifier, et une permission
invérifiable doit refuser, jamais laisser passer.
public atteint quelque chose de déjà lisible sans session. La
famille admettrait une clé statique, parce qu'il n'y a aucune permission
à vérifier : searchDocs rend ce que /docs sert à un inconnu.
Une clé statique n'obtient pourtant pas ces outils aujourd'hui : elle ne
porte aucune chaîne de scopes, donc elle s'étend à la seule famille
relay, dont boostecom:docs.read ne fait jamais partie. Ils atteignent
un client par OAuth, une fois que l'utilisateur approuve le scope.
Pourquoi studio.read affiche une colonne Shopify vide
shopify: [] sur un scope native ne veut pas dire « ne demande
aucune permission ». Ça veut dire que Shopify n'a pas son mot à dire. La
porte, c'est la permission studio.* propre à l'appelant, demandée par
section au moment de l'appel : la même vérification que font les pages
du dashboard.
Le scope est proposé sur l'écran de consentement à tout utilisateur, contrairement à un scope relay que le Custom App d'une boutique ne peut pas satisfaire. C'est délibéré : un droit Shopify est un plafond dur qui ne bouge qu'en reconnectant l'app, tandis qu'une permission Studio est une appartenance qui peut changer dès demain. Refuser le scope au moment du consentement figerait un octroi de longue durée contre une permission que l'utilisateur pourrait bientôt détenir, et la vérification à chaque appel répond correctement dans les deux cas.
Ce que les quatre outils Studio lisent, et ce qu'aucun ne fait
getStudioSection lit une section du back-office agence : pipeline,
clients, concepts, qc ou cockpit. Chaque section a sa propre
permission, et une section que vous ne pouvez pas lire répond comme si
elle n'existait pas.
getStudioProduction lit le tableau de production de la boutique à
laquelle la connexion est cantonnée : le gate de production, ce qui est
en vol, les rendus, les livraisons, les concepts et l'économie. Un bloc
que vous ne pouvez pas lire est absent, jamais désactivé, et la
réponse porte un deniedCount plutôt que de laisser croire que la
marque ne produit rien.
listStudioGenerations lit le journal des générations : chaque rendu
demandé par la boutique, son état réel, son modèle et l'URL de son
artefact. Aucun pourcentage n'est rendu, parce que le fournisseur n'en
publie pas et qu'une barre inventée vaut moins qu'un état. Les champs
de coût (chargedCostUsd, estimatedCostUsd) exigent une seconde
permission, studio.economics.read, et sont retirés de la réponse
sans elle plutôt que mis à zéro : un zéro se lit « gratuit ».
getStudioPricing répond à ce que coûte une génération, par mode du
composeur, en USD, avant de la demander. La liste de prix est choisie
côté serveur depuis l'organisation à laquelle la boutique appartient,
jamais depuis un argument.
Aucun n'écrit, et aucun outil MCP ne lance de génération. Une
génération dépense de l'argent : la placer derrière un accord durable
qu'un agent exerce sans surveillance est une décision qui a un prix,
pas un ajout au passage. Tant qu'elle n'est pas prise il n'existe pas
de scope studio.write, et un scope qu'on ne peut pas exercer n'a rien
à faire sur un écran de consentement.
Le scope hérité mcp
Les clients qui ont consenti avant que le catalogue n'existe portent un
seul scope mcp. Il s'étend à la famille relay et le fera toujours :
il a été consenti quand le catalogue n'était que le pont Shopify et rien
d'autre, donc il ne peut vouloir dire que ça. Il n'atteint ni les
outils native ni les outils public.
Ce que BoostEcom sait de votre propre boutique
getStoreIntelligence répond, pour la boutique à laquelle la connexion
est rattachée, ce que la plateforme a observé de son domaine : trafic,
économie inférée, catalogue, stack technique, créatives publicitaires,
vélocité des avis, audience sociale, marque et préparation agentique.
Chaque champ porte son unit, et ce n'est pas de la décoration.
visitsChange est un ratio signé ; momGrowth est en points.
Les deux s'affichent « −19,9 % » et les intervertir est silencieux. Un
champ que la plateforme n'a pas observé garde sa place avec une valeur
null et, quand le record le dit, une raison d'absence : une absence
est une information, jamais un chiffre supprimé en silence.
Restreignez la réponse avec sections (traffic, economics, catalog,
stack, ads, reviews, audience, brand, agentic) ; omettez-le pour tout
obtenir. Une boutique sans record répond observed: false plutôt qu'un
record vide, pour que « rien d'observé » ne se lise jamais « zéro ».
L'outil lit le même record, par le même lecteur, que le panneau Store details de votre tableau de bord et que l'extension navigateur. Une question, un chiffre, quel que soit le demandeur.
Comme le record appartient à la boutique, la réponse dépend de qui demande : le relais a déjà prouvé, à la porte, que vous appartenez à l'organisation qui la détient. Une boutique dont le record est privé répond en entier à son propre marchand.
Passerelle GraphQL
shopifyAdminGraphQL est une passerelle vers l'API Admin GraphQL de
Shopify, appariée avec introspectSchema pour la découverte. Le propre
modèle de permission de Shopify s'applique par requête : le pont ne
l'élargit pas.
Les chaînes de scope sur le fil
Les scopes voyagent en chaîne séparée par des espaces ou des virgules. La liste annoncée dans les métadonnées du serveur d'autorisation est le scope hérité plus les 12 scopes du catalogue : les 11 ci-dessus, et 1 réservé à l'équipe BoostEcom.