Claude and ChatGPT connect to a store with a URL and a consent screen. Claude Code and Cursor don't work that way. They are developer tools: they read a config file, and there is no browser in the loop to show an authorization page.
So the BoostEcom relay has two doors into the same endpoint. This post covers the second one, the config file, and mostly what it means: a static key opens the read-only relay without anyone approving it, and nothing beyond it. You want to know both halves before it lands in a repository.
The idea
One endpoint, two ways in
Every connected store gets its own remote MCP server:
https://boostecom.app/api/mcp/v1/<STORE_ID>
Two auth modes reach it:
| Client | Mode | What you do |
|---|---|---|
| Claude, ChatGPT | OAuth 2.1 with PKCE | paste the URL, approve a consent screen |
| Claude Code, Cursor | bst_mcp_ static key | generate a key, declare it in the config |
Either way there is nothing to install and nothing to host. The difference is who approves. With OAuth, a person reads a list of permissions and says yes. With a key, nobody reads anything, and the key itself is the authorization.
Step 1
Generate the key
In the dashboard, open the store's settings, then connectors, and generate an MCP key. The key belongs to that store: two stores means two keys and two entries in your config.
Step 2a
Claude Code
One command:
claude mcp add --transport http boostecom https://boostecom.app/api/mcp/v1/<STORE_ID> \
--header "Authorization: Bearer bst_mcp_<YOUR_KEY>"
If the whole team works on the same store, commit a .mcp.json at the
root of the repository instead, so the server travels with the code:
{
"mcpServers": {
"boostecom": {
"type": "http",
"url": "https://boostecom.app/api/mcp/v1/<STORE_ID>",
"headers": { "Authorization": "Bearer ${BOOSTECOM_MCP_KEY}" }
}
}
}
The committed file shares the URL, not the key. Only the variable name is in git; each developer keeps the value in their own environment.
Then run /mcp in Claude Code to confirm the server is connected. The
first call worth making is getStoreContext: in one round trip it returns
the plan, currency, markets, locales, themes and the scopes granted to the
store.
Step 2b
Cursor
Cursor reads an mcp.json: ~/.cursor/mcp.json for every project, or
.cursor/mcp.json for one.
{
"mcpServers": {
"boostecom": {
"url": "https://boostecom.app/api/mcp/v1/<STORE_ID>",
"headers": {
"Authorization": "Bearer bst_mcp_<YOUR_KEY>"
}
}
}
}
Reopen Cursor's MCP panel and check the server shows as connected. Two stores are two entries: give them distinct names, or the second one silently replaces the first.
That snippet holds the key in plain text. If the file lives in a repository, keep it out of version control, or keep the declaration in the global file.
The limit
What the key opens, and what it doesn't
It opens the relay, and only the relay. A static key never went through a consent screen, so nobody chose a tool list for it. It gets the twelve read-only relay tools (store context, catalogue, orders, pages, themes, analytics, a GraphQL read), and among those only what the store's Shopify custom app permits. Shopify still sets the ceiling: if the custom app was never granted order access, no key conjures it.
It opens nothing beyond the relay. A key names a store, never a user, and no consent ever added a scope to it. Tools whose permission depends on an organization membership (today, reading Studio) require an identified caller, so they are not registered for a key. The documentation tools are not registered for a key either: a client gets them by approving their scope over OAuth. The documentation itself stays public on the site, in a browser.
It writes nothing. The relay is read-only: a mutation is refused before it reaches Shopify, key or no key.
My rule of thumb: OAuth whenever a person can approve, static keys for CI and headless runs. The gates are spelled out in the MCP server reference.
Method
How this post was made
- Sources: the Claude Code and Cursor connect guides, the MCP server reference, the tools and scopes catalogue, and the code that builds the snippets and enforces the gates.
- Automation: an AI assistant drafted the first pass from those sources. Every command, file path and access rule was then checked against the code.
- Not verified: I did not rerun a connection to write this. The commands are the ones in the guides.
- A correction along the way: an earlier draft said a key also reached the documentation tools. The code gives a static key the relay scopes and nothing else, so this version says so.
- What I added: the review, the warning about the plain-text key in Cursor, and the call to publish.
Verified on September 13, 2026.
Paste-ready config, one client at a time
Each guide gives the URL, the auth mode that client supports, and what tends to bite.