22 herramientas repartidas en 11 scopes. Ambas cifras se derivan del catálogo de scopes en el repositorio, así que esta página nunca puede desviarse de lo que un cliente puede recibir realmente.
El catálogo también incluye herramientas reservadas al equipo de BoostEcom. Se retiran de su pantalla de consentimiento y vuelven a verificar el rol del llamante en cada llamada: ningún permiso de esta página abre una, y no se cuentan arriba.
El catálogo
| Scope | Familia | Herramientas | Permiso de Shopify necesario |
|---|---|---|---|
| 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 por consulta) |
| 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 | — (ver más abajo) |
| boostecom:intelligence.read | native | getStoreIntelligence | — (ver más abajo) |
| boostecom:docs.read | public | searchDocs, getDoc | ninguno (nada que conceder) |
Cualquiera de los permisos de Shopify listados satisface una fila. Un guion significa que Shopify no tiene voz en el asunto: o la herramienta no necesita ningún permiso concreto, o Shopify aplica su propio límite por consulta.
Las tres familias
No es cosmético. La familia decide a quién responde una herramienta:
relay alcanza Shopify a través del puente. Un bearer estático
bst_mcp_ la satisface, porque la clave está acotada a la tienda y
poseerla es la autorización.
native alcanza un sistema que posee BoostEcom. Requiere un
llamante identificado, así que una clave estática nunca la
satisface. La razón vale la pena decirla claramente:
getStudioSection protege un recurso cuyo permiso depende de una fila
OrganizationMember. Sin usuario, no hay nadie que verificar, y un
permiso no verificable debe rechazar, nunca dejar pasar.
public alcanza algo que ya se puede leer sin sesión. La familia
admitiría una clave estática, porque no hay ningún permiso que
verificar: searchDocs devuelve lo que /docs sirve a un
desconocido. Aun así, una clave estática no obtiene hoy estas
herramientas: no lleva ninguna cadena de scopes, así que se expande solo
a la familia relay, de la que boostecom:docs.read nunca forma parte.
Llegan a un cliente por OAuth, una vez que el usuario aprueba el scope.
Por qué studio.read muestra una columna de Shopify vacía
shopify: [] en un scope nativo no significa "no necesita
permiso". Significa que Shopify no tiene voz en el asunto. La puerta
es el propio permiso studio.* del llamante, solicitado por sección
en el momento de la llamada: la misma verificación que hacen las
páginas del dashboard.
El scope se ofrece en la pantalla de consentimiento a cualquier usuario, a diferencia de un scope relay que la Custom App de una tienda no puede satisfacer. Eso es deliberado: un permiso de Shopify es un techo duro que solo se mueve reconectando la app, mientras que un permiso de Studio es una pertenencia que puede cambiar mañana. Rechazar el scope en el momento del consentimiento congelaría una concesión de larga duración contra un permiso que el usuario podría obtener pronto, y la verificación por llamada responde correctamente en ambos casos.
El scope heredado mcp
Los clientes que dieron su consentimiento antes de que existiera el
catálogo llevan un único scope mcp. Se expande a la familia
relay y siempre lo hará: se consintió cuando el catálogo era solo
el puente de Shopify y nada más, así que solo puede significar eso. No
alcanza ni las herramientas nativas ni las públicas.
Lo que BoostEcom sabe de tu propia tienda
getStoreIntelligence responde, para la tienda a la que está limitada
la conexión, lo que la plataforma ha observado de su dominio: tráfico,
economía inferida, catálogo, stack técnico, creatividades publicitarias,
velocidad de reseñas, audiencia social, marca y preparación agéntica.
Cada campo lleva su unit, y no es decoración. visitsChange es una
razón con signo; momGrowth va en puntos. Ambos se muestran como
«−19,9 %» e intercambiarlos es silencioso. Un campo que la plataforma no
ha observado conserva su lugar con un valor null y, cuando el registro
lo dice, un motivo de ausencia: la ausencia es información, nunca una
cifra suprimida en silencio.
Acota la respuesta con sections (traffic, economics, catalog, stack,
ads, reviews, audience, brand, agentic); omítelo para obtenerlo todo.
Una tienda sin registro responde observed: false en lugar de uno
vacío, para que «nada observado» nunca se lea como «cero».
La herramienta lee el mismo registro, por el mismo lector, que el panel Store details de tu panel y la extensión de navegador. Una pregunta, una cifra, sea quien sea el que pregunta.
Como el registro pertenece a la tienda, la respuesta depende de quién pregunta: el relé ya ha probado, en la puerta, que perteneces a la organización que la posee. Una tienda con registro privado responde entera a su propio comerciante.
Passthrough de GraphQL
shopifyAdminGraphQL es un passthrough a la API GraphQL Admin de
Shopify, emparejado con introspectSchema para descubrimiento. El
propio modelo de permisos de Shopify se aplica por consulta: el puente
no lo amplía.
Cadenas de scope en el cable
Los scopes viajan como una cadena separada por espacios o comas. La lista anunciada en los metadatos del servidor de autorización es el scope heredado más los 12 scopes del catálogo: los 11 anteriores, y 1 reservado al equipo de BoostEcom.