BoostEcom runs a remote MCP server, one endpoint per connected store. It is the surface through which an AI client reads and acts on a Shopify store.
The endpoint
https://boostecom.app/api/mcp/v1/<storeId>
The unversioned form, /api/mcp/<storeId>, shipped first and is held in
the config of every client installed since. It stays, exactly as it is.
The two are one endpoint with two names: the same handlers, and a
token minted through either works on either.
Use the v1 path for anything new.
Two auth modes
| Mode | Credential | Tool families it opens |
|---|---|---|
| OAuth 2.1 PKCE | Access token from /oauth/authorize | Relay and native. |
| Static | bst_mcp_ bearer | Relay only. |
The asymmetry is deliberate and explained in MCP tools & scopes.
What gates a tool
Three gates, and a tool must clear all of them to be registered for a given session:
- The approved BoostEcom scope: what the user consented to.
- The store's Shopify scopes: a hard ceiling. If the Custom App or
OAuth install never got
read_orders, no BoostEcom scope conjures it. - An identified caller — required only by
nativetools, because their permission hangs off an organisation membership and there is nobody to check in static mode.
A tool that fails any gate is not registered: it does not appear in the client's tool list at all, rather than appearing and failing on call. That is the right behaviour for an AI client: a tool it can see is a tool it will try.
Connecting a client
Four clients have a step-by-step guide:
Each gives the URL, the auth mode that client supports, and a paste-ready config snippet.
Agent discovery
The platform publishes a UCP agent profile at
/.well-known/ucp-agent. It declares catalogue
read capability and carries no secrets. It is what every Shopify store
we query reads to negotiate our capabilities before answering.
Next
- MCP tools & scopes: the full catalogue.
- Authentication — picking a credential.