MCP
Shopify MCP server: store data and ad spend in one agent session
TL;DR
Shopify is unusual in this list: it ships official MCP servers, and they are good at what they do. The gap is not store data — it is that a store server cannot see what you paid to get the visitors, which is the number that decides whether a product is worth selling.
What already exists for this platform
Shopify ships official MCP servers, including a Storefront MCP for catalogue and cart interactions and a development-oriented one. They are genuinely useful and this integration uses the Storefront MCP directly.
- Official servers exist and are maintained by Shopify.
- Storefront MCP covers catalogue and cart operations — the customer-facing surface.
- Admin access is a separate matter, with its own scopes and its own risk profile.
- None of them see ad spend, because ad spend is not in Shopify.
What a full MCP server adds
| Typical option today | Agent Planners MCP | |
|---|---|---|
| Shopify tools | Storefront + dev, official | 20 reads, 21 writes |
| Admin reads (orders, products, inventory) | Separate setup | Included |
| Ad spend in the same session | No | Google Ads, Meta, TikTok on the same key |
| Multiple stores | One connection each | Added alongside, never replaced |
| Approval before a store write | Your own discipline | Queued for approval, or applied at once on a key minted autonomous; deleting anything, refunds and captures, repricing, an absolute stock set, deactivating a code, a discount of 50 % off or more and a product status flip always wait for a person — every write audited |
| Customer names, email and phone | Whatever the tool returns | Never from the customer list over MCP (ids, order counts and spend only); the generic Admin query tool returns what Shopify sends |
Tool counts are derived from the live catalogue rather than typed by hand: this family exposes 21 reads and 20 writes of the 1018 tools on the endpoint — one more read than the table's 20 / 21, because the platform registry files get_cart as a write only so a live cart is never served from the read cache, while the endpoint lists it as the read it is. A key only sees the writes if it carries
tools:write.How to configure it
- 1Create a key in API & MCP.
tools:readfor questions; addtools:writeif the agent should be able to change things. Tools mode needs a paid plan and fails closed. - 2Connect Shopify under Integrations. The store domain alone reaches the catalogue and cart; orders, admin data and store writes need the Admin tier — the Shopify app (OAuth), or a custom app's Admin token or client credentials pasted on the same card. Either way the credential is stored encrypted on our side, which is why the MCP key never carries platform credentials.
- 3Add the server to Claude Code, Claude Desktop or Codex using the snippet below.
- 4Have the agent call
describe_permissionsfirst — it reports the key's mode, scopes, plan entitlement and connected accounts. - 5Call
list_accountsfor the account ids, and scope each call with one. Resolution is exact or it refuses, naming the candidates.
bash
claude mcp add --transport http agent-plannershttps://www.agentplanners.com/api/mcp \
--header "Authorization: Bearer ap_live_…"Claude Desktop and Codex
Claude Desktop takes the same endpoint as JSON:
json
{
"mcpServers": {
"agent-planners": {
"url": "https://www.agentplanners.com/api/mcp",
"headers": {
"Authorization": "Bearer ap_live_…"
}
}
}
}Codex uses the same endpoint from
~/.codex/config.toml, with the key in an environment variable rather than the file: [mcp_servers.agent-planners] / url = "…/api/mcp" / bearer_token_env_var = "AGENTPLANNERS_API_KEY".Connecting a second store used to delete the first
Worth writing down because it is a trap any commerce integration can fall into. Discovery-style OAuth connections — Google Ads, AdMob, Ad Manager — return the COMPLETE list of accounts you can see, so replacing every stored row with the payload is correct: a row that is missing really has gone.
A paste-a-token commerce connection carries exactly one store. Running the same replace-everything logic against it removes every other store silently. The fix is an additive upsert keyed on the store, and a write that refuses rather than guessing when two stores could match.
The refusal matters as much as the upsert: with two stores connected, a write that names no store used to fall back to whichever was first — a coin flip with real consequences.
Use cases
- Product profitability after acquisition cost, joining orders to ad spend — the question Sidekick structurally cannot answer.
- Reconciling platform-reported conversions against settled orders, including refunds and discounts.
- Inventory-driven campaign decisions — pausing ads for products that went out of stock.
- Multi-store reporting for merchants running several shops, with each store addressed explicitly.
Frequently asked questions
- Does Shopify have an official MCP server?
- Yes — Shopify ships official MCP servers, including a Storefront MCP for catalogue and cart operations. This integration uses the Storefront MCP directly for the catalogue and cart, alongside the Admin API — through the Shopify app (OAuth), or a custom app's pasted Admin token or client credentials — for orders, reporting and store changes, the irreversible and money-moving ones held for a person on every key.
- What can't a Shopify-only MCP server do?
- See your ad spend. Google, Meta and TikTok spend is not in the Shopify admin, so questions about whether a product is profitable after acquisition cost need a server that reaches both.
- Can I connect more than one Shopify store?
- Yes. Each store is added alongside the others rather than replacing them, and a write that does not name a store is refused with both stores named rather than defaulting to one.