22 strumenti distribuiti su 11 scope. Entrambe le cifre sono derivate dal catalogo di scope nel repository, quindi questa pagina non può mai deviare da ciò che un client può effettivamente ricevere.
Il catalogo contiene anche strumenti riservati al team BoostEcom. Sono esclusi dalla schermata di consenso e ricontrollano il ruolo del chiamante a ogni chiamata: nessun permesso di questa pagina ne apre uno, e non sono contati qui sopra.
Il catalogo
| Scope | Famiglia | Strumenti | Permesso Shopify richiesto |
|---|---|---|---|
| boostecom:store.read | relay | getShopInfo, getStoreContext, introspectSchema | — |
| boostecom:catalog.read | relay | listProducts, getProduct | read_products o write_products |
| boostecom:orders.read | relay | listOrders | read_orders o write_orders |
| boostecom:content.read | relay | listPages | read_content o write_content |
| boostecom:metadata.read | relay | getMetafields, listMetaobjectDefinitions, listMetaobjects | — (Shopify decide per query) |
| boostecom:themes.read | relay | listThemes, getTheme, runAudit | read_themes, write_themes o write_theme_code |
| boostecom:analytics.read | relay | runShopifyQL | read_analytics o read_reports |
| boostecom:graphql.read | relay | shopifyAdminGraphQL | — |
| boostecom:studio.read | native | getStudioSection, getStudioProduction, listStudioGenerations, getStudioPricing | — (vedi sotto) |
| boostecom:intelligence.read | native | getStoreIntelligence | — (vedi sotto) |
| boostecom:docs.read | public | searchDocs, getDoc | nessuno (niente da concedere) |
Uno qualsiasi dei permessi Shopify elencati soddisfa una riga. Un trattino significa che Shopify non ha voce in capitolo: o lo strumento non richiede alcun permesso particolare, o Shopify applica il proprio limite per query.
Le tre famiglie
Non è cosmetico. La famiglia decide a chi risponde uno strumento:
relay raggiunge Shopify tramite il ponte. Un bearer statico
bst_mcp_ la soddisfa, perché la chiave è delimitata allo store e
possederla è l'autorizzazione.
native raggiunge un sistema che BoostEcom possiede. Richiede un
chiamante identificato, quindi una chiave statica non la
soddisfa mai. Il motivo vale la pena dirlo chiaramente:
getStudioSection protegge una risorsa la cui autorizzazione dipende
da una riga OrganizationMember. Senza utente, non c'è nessuno da
verificare, e un'autorizzazione non verificabile deve rifiutare, mai
lasciar passare.
public raggiunge qualcosa di già leggibile senza sessione. La
famiglia ammetterebbe una chiave statica, perché non c'è alcun permesso
da verificare: searchDocs restituisce ciò che /docs serve a
uno sconosciuto. Una chiave statica però oggi non ottiene questi
strumenti: non porta alcuna stringa di scope, quindi si espande alla sola
famiglia relay, di cui boostecom:docs.read non fa mai parte.
Raggiungono un client tramite OAuth, una volta che l'utente approva lo
scope.
Perché studio.read mostra una colonna Shopify vuota
shopify: [] su uno scope native non significa "non richiede
permesso". Significa che Shopify non ha voce in capitolo. La porta è
il permesso studio.* proprio del chiamante, richiesto per sezione al
momento della chiamata: la stessa verifica che fanno le pagine della
dashboard.
Lo scope è offerto sulla schermata di consenso a qualsiasi utente, a differenza di uno scope relay che la Custom App di uno store non può soddisfare. È deliberato: un permesso Shopify è un tetto rigido che si muove solo riconnettendo l'app, mentre un permesso Studio è un'appartenenza che può cambiare domani. Rifiutare lo scope al momento del consenso congelerebbe una concessione di lunga durata contro un permesso che l'utente potrebbe presto ottenere, e la verifica per chiamata risponde correttamente in entrambi i casi.
Lo scope ereditato mcp
I client che hanno acconsentito prima che il catalogo esistesse
portano un unico scope mcp. Si espande alla famiglia relay e lo
farà sempre: è stato acconsentito quando il catalogo era solo il
ponte Shopify e nient'altro, quindi può significare solo quello. Non
raggiunge né gli strumenti native né quelli public.
Cosa BoostEcom sa del tuo stesso negozio
getStoreIntelligence risponde, per il negozio a cui la connessione è
vincolata, ciò che la piattaforma ha osservato del suo dominio:
traffico, economia inferita, catalogo, stack tecnico, creatività
pubblicitarie, velocità delle recensioni, audience social, marca e
prontezza agentica.
Ogni campo porta la sua unit, e non è decorazione. visitsChange è un
rapporto con segno; momGrowth è in punti. Entrambi si mostrano
come «−19,9 %» e scambiarli è silenzioso. Un campo che la piattaforma non
ha osservato mantiene il suo posto con valore null e, quando il record
lo dice, un motivo di assenza: l'assenza è informazione, mai una cifra
tolta in silenzio.
Restringi la risposta con sections (traffic, economics, catalog,
stack, ads, reviews, audience, brand, agentic); omettilo per averle
tutte. Un negozio senza record risponde observed: false invece di uno
vuoto, perché «niente osservato» non si legga mai come «zero».
Lo strumento legge lo stesso record, tramite lo stesso lettore, che il pannello Store details della tua dashboard e l'estensione del browser leggono. Una domanda, una cifra, chiunque chieda.
Poiché il record appartiene al negozio, la risposta dipende da chi chiede: il relay ha già provato, alla porta, che appartieni all'organizzazione che lo possiede. Un negozio con record privato risponde per intero al proprio commerciante.
Passthrough GraphQL
shopifyAdminGraphQL è un passthrough verso l'API Admin GraphQL di
Shopify, accoppiato con introspectSchema per la scoperta. Il
proprio modello di permessi di Shopify si applica per query: il ponte
non lo amplia.
Stringhe di scope sul filo
Gli scope viaggiano come stringa separata da spazi o virgole. L'elenco annunciato nei metadati del server di autorizzazione è lo scope ereditato più i 12 scope del catalogo: i 11 elencati, e 1 riservato al team BoostEcom.