Connect your own AI client
You can connect your own Claude to StorePilot and ask it about your shops directly — "why did conversions drop last week", "what broke on the checkout page yesterday", "which products nobody is looking at". StorePilot is a remote MCP server (Model Context Protocol), so the connection is made in Claude's own settings and the data flows to your AI client, on your instruction.
This is not StorePilot calling an AI on your behalf. Nothing here is enabled by default, and nothing is sent anywhere until you connect a client and choose which sites it may read.
The address
https://api.store-pilot.net/mcp
Claude (web, desktop, mobile)
- Open Settings → Connectors → Add custom connector.
- Paste the address above.
- Claude opens StorePilot's sign-in, then a consent screen.
- Tick the sites this connection may read, and allow.
Claude Code
claude mcp add --transport http storepilot https://api.store-pilot.net/mcp
Then run /mcp inside a session and sign in through the browser.
To connect without a browser sign-in — in CI, or from a client that sends a header — use a personal key instead.
:::note What changed on 11 September 2026
A connected client now also reads names, chat transcripts, survey free text, visitor and session identifiers, and a description of a recorded visit. Because consent had named the narrower list, every existing connection was ended — your client will ask you to sign in again, and the consent screen will show the new list before you approve it.
:::
What it can read
| Traffic | sessions, pageviews, bounce, top pages, devices, browsers, countries, traffic channels |
| Commerce | revenue, average order value, abandonment rate, orders, abandoned checkouts, per-product performance |
| Issues | errors grouped by fingerprint, with their stacks, releases and occurrence counts — narrowed, if asked, by kind, by where in the code (theme, plugin, core…), by the release that introduced them, to the ones that came back, or to what was seen since a moment — and for one issue its context (file, line, page, browser), the trail of steps before it and links to up to 3 recordings that open at the moment the visit met the fault; see Hand a bug to a coding agent |
| Releases | each deploy in a window — announced by your deploy pipeline with its commit, repository and link, or first seen from a browser or a server — and how many issues each release introduced and how many came back in it |
| Health | uptime, incidents, response times |
| Findings | the derived insight cards, and the daily fact sheet behind them |
| Visits | recorded visits — score, pages, duration, device, errors — and the narrative summary written about one, where the AI writer has written it |
| Visitors | who came back, on what device, from where, and what they did |
| Chats | transcripts from the storefront chat widget |
| Surveys | scores, distributions, and the free text people typed |
It sees the names and contact details on a checkout or an order, chat transcripts, survey answers including free text, and the pseudonymous identifiers that link a visit to a purchase. Raw form contents ride only where you hold the admin role — the same bar as the dashboard's own export — and any field whose name looks like an address is masked even then.
What it never receives
Postal addresses and postcodes. Not because a tool declines to send them — because they are never stored. The platform writes a marker in place of a street and a postcode before the record is saved, so there is nothing for any reader to be given.
IP addresses. Not even the truncated form the platform keeps for its own country lookups.
Session-recording footage. A recorded visit is described — its pages, duration, device, errors, and the narrative summary when one has been written — and linked back to the player here. The recording itself is never returned: one visit runs to tens of megabytes of frames, and a partial one would be a replay claiming a visit it does not contain.
That is not a setting — it is how the data is built. Each tool returns a fixed set of fields named in the code, so a field that is not on the list cannot be returned by adding a parameter.
Reading, and the changes you can allow
A connected client reads. It cannot resolve an issue, delete an order or edit a setting — with two exceptions, a site's notification destinations and its uptime monitors, which are off by default and need two people's decisions:
- The organization's owner switches on changes from connected AI clients, on the organization's Settings → General, and lists the webhook hosts such a change may point at. Only the owner can do this, and only in the dashboard.
- The person connecting the client ticks Also allow it to make changes on the consent screen and enters their password again. Without the tick the connection reads only.
With both, the client can do what a site's Notifications tab does, through six tools:
| Tool | What it does |
|---|---|
list_notification_destinations | Lists a site's destinations: channel, events, on or off — and where each sends, as a webhook's or Slack's host, an email's recipients or a Telegram chat id. Tokens and signing secrets are never returned. |
save_notification_destination | Adds a destination, or changes any existing one — email, Slack, Telegram or webhook, any of the events, the severity floor, the webhook version and payload. |
test_notification_destination | Sends one test message to a destination and says what happened. |
copy_notification_destination | Copies a destination to other sites of the same organization, as Copy to sites does. |
delete_notification_destination | Removes a destination. |
set_notification_channel | The first of them, kept as it was: adds or updates a webhook for new leads, abandoned carts and paid orders, upserted by name over the destinations a client created. |
And what a site's Uptime page does, through three more:
| Tool | What it does |
|---|---|
list_uptime_monitors | Lists a site's monitors: name, kind, the address without its query string, what it expects, whether it is on. |
save_uptime_monitor | Adds a monitor (a page or an API), or changes any existing one — including switching it off. |
delete_uptime_monitor | Removes a monitor and its history. |
A monitor makes StorePilot request an address every five minutes, so a client may only point one at the site's own domain or one of its subdomains. A monitor a person set up for another address keeps working and can be renamed, switched off or deleted by a client, but not aimed elsewhere or switched back on.
The rules are the same for all nine:
- A webhook or Slack address must be
https://, on the default port, on exactly one of the hosts the owner approved. A destination left sending anywhere else cannot be saved, tested or copied from a client — only switched off or deleted. To let a client set up Slack, the owner approveshooks.slack.com. Email and Telegram have no host to approve; the notice below names their recipients instead. - It needs the admin role on the site — on every site, for a copy — and only sites the connection can reach.
- A connection makes at most 30 changes an hour; a test counts as one.
- Every owner and admin of the organization gets an email and a notification for each change, naming the connection, the action and where the destination sends or what the monitor checks. The destinations list marks the ones an AI client added, and a monitor changed by a client is written to the organization's audit log.
A personal key can do the same, under the same conditions, only if it was created with changes allowed — a choice that cannot be changed afterwards.
The sites are the permission
A connection reads only the sites you ticked when you connected it, and only while you are still a member of the organization those sites belong to. Two consequences worth knowing:
- Remove somebody from an organization and their AI client loses access to it on its next call, without anybody touching the connection. Lower their role and a change they try next is refused at once.
- A site you add later is included only if you granted its whole organization. The consent screen asks one question first — whole organizations or specific sites — and then shows that list. An organization means every site you can reach there, including ones added later; a connection that names specific sites does not gain new ones, so connect it again to add them. A personal key asks the same question.
Disconnecting
Your profile → Connected AI clients → Disconnect. It stops reading immediately. Disconnect all ends every connection at once — useful when you cannot tell which one you no longer trust.
Six account-security actions end every AI connection — and every personal key — as well: "Sign out everywhere else", changing your password, resetting it through the emailed link, turning two-factor authentication off, an operator resetting it, and moving the account to a new email address. Each client then asks you to connect again the next time you use it, and your profile says why the list emptied. Confirming the address you already have ends nothing.
Seeing what a connection read
Your profile → What keys and AI connections read counts every tool call each connection made — per day, per tool and per site, with what we refused. An organization's owner sees the calls made about its sites under Team → API and AI usage. See Seeing what it read.
Several connections, and naming them
One account may hold up to ten connections at a time — two Claude accounts, Claude Code and Cursor are four. Connecting the same client again replaces its previous connection rather than adding one. Rename a connection on your profile to tell them apart; the client's own name stays beside yours.
The consent screen shows which StorePilot account you are signed in as — if it is the wrong one, Not your account? signs you out and brings you back to the same request — and where the access goes: the address the client registered. If that address is not one we recognise as an AI client's, the screen says so in red; allow it only if you set the connection up yourself.
Who is the sub-processor
The provider of the AI client you connect — Anthropic, if you connect Claude — receives this data because you instructed it to. They are your sub-processor for that data, not ours, and they belong in your own record of processing. See the Data Processing Agreement §4.