Explorar a documentação
MCP server

Ferramentas e escopos MCP

As 22 ferramentas que um cliente pode receber, os 11 escopos que as abrem, e as permissões Shopify que cada uma exige.

22 ferramentas distribuídas em 11 escopos. Ambos os números são derivados do catálogo de escopos no repositório, então esta página nunca pode se desviar do que um cliente pode de fato receber.

O catálogo também traz ferramentas reservadas à equipe BoostEcom. Elas são retiradas da sua tela de consentimento e verificam de novo o papel do chamador a cada chamada: nenhuma permissão desta página abre uma delas, e elas não são contadas acima.

| Escopo | Família | Ferramentas | Permissão Shopify exigida | |---|---|---|---| | 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 | — (a Shopify decide por query) | | 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 | — (veja abaixo) | | boostecom:intelligence.read | native | getStoreIntelligence | — (veja abaixo) | | boostecom:docs.read | public | searchDocs, getDoc | nenhuma (nada a conceder) |

Qualquer uma das permissões Shopify listadas satisfaz uma linha. Um travessão significa que a Shopify não tem voz: ou a ferramenta não exige nenhuma permissão específica, ou a Shopify aplica o limite por query.

As três famílias

Não é cosmético. A família decide a quem uma ferramenta responde:

relay alcança a Shopify através da ponte. Um bearer estático bst_mcp_ a satisfaz, porque a chave é escopada à loja e possuí-la é a autorização.

native alcança um sistema que o BoostEcom possui. Exige um chamador identificado, então uma chave estática nunca a satisfaz. Vale a pena dizer o motivo claramente: getStudioSection protege um recurso cuja permissão depende de uma linha OrganizationMember. Sem usuário, não há ninguém para verificar, e uma permissão que não pode ser verificada deve recusar, nunca deixar passar.

public alcança algo que já pode ser lido sem sessão. A família aceitaria uma chave estática, porque não há nenhuma permissão a verificar: searchDocs retorna o que /docs serve a um desconhecido. Mesmo assim, uma chave estática não recebe essas ferramentas hoje: ela não carrega nenhuma string de escopos, então se expande só para a família relay, da qual boostecom:docs.read nunca faz parte. Elas chegam a um cliente via OAuth, quando o usuário aprova o escopo.

Por que studio.read mostra uma coluna Shopify vazia

shopify: [] em um escopo native não significa "não exige permissão". Significa que a Shopify não tem voz. O portão é a própria permissão studio.* do chamador, verificada por seção no momento da chamada: a mesma verificação que as páginas do dashboard fazem.

O escopo é oferecido na tela de consentimento a qualquer usuário, ao contrário de um escopo relay que o Custom App de uma loja não consegue satisfazer. Isso é deliberado: uma permissão Shopify é um teto rígido que só se move reconectando o app, enquanto uma permissão Studio é uma associação que pode mudar amanhã. Recusar o escopo no momento do consentimento congelaria uma concessão de longa duração contra uma permissão que o usuário pode logo ter, e a verificação por chamada responde corretamente em ambos os casos.

O escopo legado mcp

Clientes que consentiram antes do catálogo existir carregam um único escopo mcp. Ele se expande para a família relay e sempre vai: foi consentido quando o catálogo era a ponte Shopify e nada mais, então só pode significar isso. Não alcança ferramentas native nem public.

O que a BoostEcom sabe da sua própria loja

getStoreIntelligence responde, para a loja à qual a ligação está limitada, o que a plataforma observou do seu domínio: tráfego, economia inferida, catálogo, stack técnico, criativos publicitários, velocidade de avaliações, audiência social, marca e preparação agêntica.

Cada campo traz a sua unit, e isso não é decoração. visitsChange é um rácio com sinal; momGrowth vem em pontos. Ambos aparecem como «−19,9 %» e trocá-los é silencioso. Um campo que a plataforma não observou mantém o seu lugar com valor null e, quando o registo o diz, um motivo de ausência: a ausência é informação, nunca um número apagado em silêncio.

Limite a resposta com sections (traffic, economics, catalog, stack, ads, reviews, audience, brand, agentic); omita-o para obter tudo. Uma loja sem registo responde observed: false em vez de um vazio, para que «nada observado» nunca se leia como «zero».

A ferramenta lê o mesmo registo, pelo mesmo leitor, que o painel Store details do seu dashboard e a extensão de navegador leem. Uma pergunta, um número, seja quem for que pergunta.

Como o registo pertence à loja, a resposta depende de quem pergunta: o relay já provou, à porta, que pertence à organização que a detém. Uma loja com registo privado responde por inteiro ao seu próprio comerciante.

Passthrough GraphQL

shopifyAdminGraphQL é um passthrough para a Shopify Admin GraphQL API, emparelhado com introspectSchema para descoberta. O próprio modelo de permissões da Shopify se aplica por query: a ponte não o amplia.

Strings de escopo no fio

Os escopos viajam como uma string separada por espaço ou vírgula. A lista anunciada nos metadados do servidor de autorização é o escopo legado mais os 12 escopos do catálogo: os 11 acima, e 1 reservado à equipe BoostEcom.

Construiu com estas docs?

Passe pelo fórum se algo não estiver claro ou estiver errado. A documentação melhora mais depressa quando quem lê assinala as lacunas.

Abrir o fórum