Browse documentation
MCP server

MCP tools & scopes

All 15 registered tools, the 9 scopes that open them, and the Shopify grants each one needs.

15 tools across 9 scopes. Both figures are derived from the scope catalogue in the repository, so this page cannot drift from what the server actually registers.

The catalogue

| Scope | Family | Tools | Shopify grant needed | |---|---|---|---| | boostecom:store.read | relay | getShopInfo, getStoreContext, introspectSchema | — | | boostecom:catalog.read | relay | listProducts, getProduct | read_products or write_products | | boostecom:orders.read | relay | listOrders | read_orders or write_orders | | boostecom:content.read | relay | listPages | read_content or write_content | | boostecom:themes.read | relay | listThemes, getTheme, runAudit | read_themes, write_themes or write_theme_code | | boostecom:analytics.read | relay | runShopifyQL | read_analytics or read_reports | | boostecom:graphql.read | relay | shopifyAdminGraphQL | — | | boostecom:studio.read | native | getStudioSection | — (see below) | | boostecom:docs.read | public | searchDocs, getDoc | — (nothing to grant) |

Any one of the listed Shopify grants satisfies a row. A dash means Shopify has no say: either the tool needs no particular grant, or Shopify enforces per query.

The three families

Not cosmetic. The family decides who a tool answers:

relay reaches Shopify through the bridge. A static bst_mcp_ bearer satisfies it, because the key is store-scoped and holding it is the authorization.

native reaches a system BoostEcom owns. It requires an identified caller, so a static key never satisfies it. The reason is worth stating plainly: getStudioSection guards a resource whose permission hangs off an OrganizationMember row. With no user, there is nobody to check, and an uncheckable permission must refuse, never pass.

public reaches something already readable without a session. A static key satisfies it, because there is no permission to be uncheckable: searchDocs returns what /docs serves to a stranger.

That last family is the honest answer to an obvious question: if the documentation is public, what does its scope protect? Nothing. It lets a client decline the two tools and keep its tool list small, and it puts them on the consent screen where you can see what you are taking. A declaration of intent, not a gate.

Why studio.read shows an empty Shopify column

shopify: [] on a native scope does not mean "needs no permission". It means Shopify has no say. The gate is the caller's own studio.* permission, asked per section at call time: the same check the dashboard pages make.

The scope is offered on the consent screen to any user, unlike a relay scope a store's Custom App cannot satisfy. That is deliberate: a Shopify grant is a hard ceiling that moves only by reconnecting the app, while a Studio permission is a membership that can change tomorrow. Refusing the scope at consent time would freeze a long-lived grant against a permission the user may soon hold, and the per-call guard answers correctly either way.

The legacy mcp scope

Clients that consented before the catalogue existed hold a single mcp scope. It expands to the relay family and only ever will: it was consented to when the catalogue was the Shopify bridge and nothing else, so it can only mean that. It does not reach native tools.

Reading the documentation from a client

searchDocs takes a question in plain words and returns the passages that answer it, each with a deep link to the exact section. The anchors come from the same function that renders them, so they resolve. getDoc takes a slug from those results and returns the page in full.

They exist for one reason: an agent asked how the escrow window works can either read the page that states it or infer it, and inference is how a confident wrong answer reaches a merchant.

A page an admin withdrew from the CMS answers as "not found", the same as a slug that never existed, so the tool is not an index of what was once published.

GraphQL passthrough

shopifyAdminGraphQL is a passthrough to the Shopify Admin GraphQL API, paired with introspectSchema for discovery. Shopify's own permission model applies per query: the bridge does not widen it.

Scope strings on the wire

Scopes travel as a space- or comma-separated string. The advertised list in the authorization-server metadata is the legacy scope plus all nine above.

Built on these docs?

Drop into the forum if something's unclear or wrong. Docs improve faster when readers flag the gaps.

Open the forum