Connect an AI agent to your store

The StoreConnect Model Context Protocol (MCP) server is how an external AI agent connects to your store to work on it. This article explains how the connection works, which agents it supports, and how StoreConnect keeps the connection safe. See also Build on StoreConnect using AI agents. If a connection is refused, or an agent connects and then cannot do what you asked, see Troubleshoot an agent connection.

How the connection works

Each StoreConnect store hosts its own managed MCP endpoint at https://<your-store-domain>/mcp. There is nothing to download or run. The endpoint is part of your store.

Where several stores share one domain, each store is served at its own path, and so is its endpoint. A store served at https://shop.example.com/au has its endpoint at https://shop.example.com/au/mcp. See Stores that share a domain.

Two separate things work together:

• The AI skills toolkit teaches an agent how to work with StoreConnect. Installing it does not connect any store.
• The MCP connection gives the agent the live tools to act in one specific store.

Connecting uses OAuth. You start the sign-in from your agent, giving it your store’s URL with /mcp on the end. That starts authentication, which prompts you to enter your API token in a browser screen. The token is per user, so the agent gets a session as you and works within your permissions.

Everything you need to connect, including the token, the store address and the exact commands for your agent, is in one place: Connect an agent in the StoreConnect Console. See Get your token and connection details.

Because the endpoint belongs to your store, an agent you connect only ever works in that store’s Salesforce org. Connecting a different store means using that store’s own endpoint.

This is deliberate. A per-store endpoint keeps ownership of your data inside your own org: there is no shared gateway that several customers’ stores sit behind, so a connection made for one store cannot reach another store’s data. A single shared endpoint would make every connection a potential path into other customers’ data.

Check your store supports MCP

MCP requires StoreConnect v22 or later. A store on an earlier version has no endpoint to connect to, and the failure looks like a configuration mistake rather than a version gap, so check before you set anything up.

1. Open your store’s discovery address in any browser, replacing the example with your own store’s domain: https://<your-store-domain>/.well-known/mcp.json. If your store is served at a path, the path goes first: https://<your-store-domain>/<your-path>/.well-known/mcp.json.
2. Read what comes back.

A short block of technical text (JSON) naming your store’s endpoint means your store supports MCP, and you can continue. That page is a public signpost: it holds no private information and asks you to sign in to nothing. Checking it is more reliable than checking a version number, because it tells you what your store is serving right now.

Your store’s “page not found” page means your store is on a version earlier than v22. Nothing is broken, and retrying will not change the outcome. Email support@storeconnect.com or ask your implementation partner about upgrading. Once the store is on v22 or later, the connection works with no change to anything you have already installed.

A reply reading No store is configured at this address. means something different again. The store is on v22, but the address you opened names no store on that domain. Check the path, then try again. See Stores that share a domain.

:::note The skills toolkit still works while you wait, because knowledge does not need a connection. An agent with the skills installed can help you write and review theme templates, plan a store build, debug a page, or draft POS configuration, which you then apply through Salesforce or the StoreConnect CLI as you do today. See Install the StoreConnect AI skills. :::

Access and permissions

• A StoreConnect administrator grants and revokes access from the Agent access section of the StoreConnect Console. The agent signs in as a StoreConnect user and inherits that user’s permissions. Record sharing, object and field-level security, and store scope all still apply. See Manage who can use an AI agent.
• The connection uses OAuth. Authentication prompts you to enter your personal API token in a browser screen. Your Salesforce password is never involved. An administrator can revoke or reset the token at any time. See Get your token and connection details.
• The token is per user, which is what ties an agent’s access to one person’s permissions.
• Sign-in sessions expire after about eight hours. When a session expires, sign in again through your agent.
• A session carries the permissions you had when you signed in. If your Store Role, its scopes, or the stores it covers change, sign in again from your agent, using your existing token, so the change takes effect. You do not need a new token for this. Until you sign in again, the agent keeps working with the old permissions.
• Only give an agent the access it needs for the task to be done.

Which agents you can use

There is no tool lock-in. Any MCP-capable client can connect to your store’s endpoint, whether or not a StoreConnect skills package exists for it. What differs between products is whether they can use the browser sign-in or have to send the token as a header.

Sign-in works with no setup for Claude, including Claude Code, and for ChatGPT, Google Antigravity, and Agentforce Vibes. It also works for any client you install on your own machine, such as a desktop app or a command-line tool, whichever product it is.

Any other hosted product needs its sign-in address added by StoreConnect before the browser sign-in will work. The list is StoreConnect’s own configuration, so a store administrator cannot add to it. Until the address is added, the sign-in screen refuses the connection with This client's redirect address is not on this store's allow list. and names the address it turned away. Email support@storeconnect.com with the product name and that address. In the meantime, the product can still connect by sending the bearer credential as a header. See Bearer credential format.

The StoreConnect skills toolkit also ships as native packages for a range of AI products, plus an experimental recipe for Agentforce Vibes. For the current product list and the install command for each one, see Install the StoreConnect AI skills and Agentforce AI agents.

Before you connect

You need these things:

• A store on StoreConnect v22 or later, confirmed by the check above.
• Your store’s MCP URL, in the form https://<your-store-domain>/mcp, or https://<your-store-domain>/<your-path>/mcp if your store is served at a path. Ask your StoreConnect administrator, and see Stores that share a domain.
• A Store Role of type Content Changes on your Salesforce user, scoped to the store you want to work on. Editor level lets an agent create and stage changes; Approver level is also needed to approve and publish them. See Store roles.
• Agent access switched on for you by a StoreConnect administrator. See Manage who can use an AI agent.
• An AI agent or coding assistant that supports MCP.

The StoreConnect skills toolkit installed in that agent is optional but recommended, since it gives the agent the StoreConnect know-how to work well.

Get your token and connection details

Your token is personal. It carries your permissions and nobody else’s, so an agent using it can only do what your Store Role allows, on the stores that role covers.

:::note StoreConnect support does not issue this token, and there is no key to request from anyone outside your business. It is generated in your own Salesforce org when an administrator turns on agent access for you, and you retrieve it yourself in about a minute. :::

1. Open the StoreConnect Console.
2. In the header actions bar, open Agents, then select Connect an agent.

The Your agent access panel shows three things:

• Your personal access token. Select Reveal your token to show it, then copy it. It is hidden again when you select Hide your token or close the panel.
• Your stores: every store your Content Changes role reaches. Each has a Store URL, which is the MCP address ending in /mcp, and a Bearer credential for agents that cannot sign in. Both have a copy button.
• How your agent connects: the setup for Claude Code, Claude on web and desktop, and Other MCP clients, with the commands already filled in for the store you pick.

If the panel says Agent access is not turned on for you, ask a StoreConnect administrator to enable it. If it shows a token but says your token starts working as soon as an administrator gives you a role, you have access but no store yet, and need a Content Changes store role. Both are done from the Console’s Agent access section. See Manage who can use an AI agent.

:::warning Treat your token like a password. Anyone who has it can act as you, within your Store Role permissions, on every store that role covers. Store it in a password manager or secrets vault, such as 1Password, so you can retrieve it without generating a new one. Do not paste it into a chat message, a support ticket, or a file you commit to source control. If it is exposed, ask an administrator to reset it. :::

Find the token on your User record instead

The token also lives in the API Token field on your own Salesforce User record, alongside API Token Active and API Token Expires At. If you cannot open the Console, copy it from there. The fields are custom and are not on the standard User page layout, so if you cannot see them, ask your Salesforce administrator to add them.

Do not clear API Token Active while looking. Clearing it revokes your access immediately and removes the token.

Bearer credential format

Agents that send a header rather than signing in need a three-part bearer credential, separated by colons. The Console assembles it for you under Your stores; the parts are:

```text

org_id:store_sfid:api_token ```

Part	Where to find it
org_id	Setup, then Company Information, then Salesforce Organization ID
store_sfid	The Id of the Store record, also visible in the record URL
api_token	Your personal access token

Revoke or expire a token

A StoreConnect administrator disables, expires or resets your token from the Agent access section of the Console. See Manage who can use an AI agent. If you are working on your own User record instead: clear API Token Active to revoke access immediately; set API Token Expires At to have it stop automatically on a date; or clear API Token Active, save, then select it again to generate a fresh token.

For the underlying field definitions, see User object reference.

Stores that share a domain

Several stores can share one domain, each served at its own path: shop.example.com for the store at the root of the domain, shop.example.com/au for another. Each store has its own endpoint, and the store’s path comes before /mcp:

Store at the root of the domain	Store at /au
https://shop.example.com/mcp	https://shop.example.com/au/mcp
https://shop.example.com/.well-known/mcp.json	https://shop.example.com/au/.well-known/mcp.json

Your store’s path is the Path field on its Store record (s_c__Store__c.s_c__Path__c). A store with nothing in that field is the one served at the root of the domain.

:::warning The Store URL in the Console leaves the path out, so on a shared domain it shows the root store’s address for every store in the list. Add your store’s path yourself, immediately after the domain and before /mcp. :::

Signing in binds the session to the store at the path you signed in at. A session started at https://shop.example.com/au/mcp is refused at any other path, which is what keeps an agent working on one store out of another store’s data. The bearer credential works the other way around: it names its own store, so it reaches that store whatever path you paste it against. Use the path that matches the credential, or sign in instead.

The sign-in screen names the store it is about to grant access to, shows that store’s address underneath, and names where the access is being sent. Read all three before you paste your token.

Two messages on that screen mean the address named no store:

• No store is configured at <your domain>/<path>. The path is wrong, or the store at it is not live. Check the Path field on the Store record.
• Several stores share <your domain> and none is marked as the default. You used the domain with no path on it, and more than one store answers to that domain. Connect using your store’s own path, or ask your administrator to mark one store as the default.

A client pointed at the wrong endpoint is turned away with the right one named: This client asked to connect to a different endpoint than this store's, which is <address>. Correct the address in the client and start the sign-in again.

One address does not take the path. The website API at /api/v1 sits outside it, so a sign-in session issued for a store at a path is refused there, while a bearer credential reaches its own store as usual. Neither limit affects the MCP endpoint or anything an agent does through it.

Connect and verify

The exact steps depend on your agent, but the flow is the same everywhere:

1. Open Agents > Connect an agent in the StoreConnect Console and reveal your token, so it is ready when you are prompted for it. See Get your token and connection details.
2. Add a remote MCP server named “storeconnect” in your agent, using the Store URL from the Console: your store’s address with /mcp on the end. If your store is served at a path, add that path to the address yourself, because the Console leaves it out. Do not include a credential in the URL.
3. Start the sign-in from your agent. This begins authentication.
4. Enter your API Token value when you are prompted for it, in the browser screen that opens. Your token goes into the browser, never into a chat message.
5. Confirm the connection shows as active in your agent.
6. Ask the agent to run a read-only check to confirm it is connected to the intended store and environment.
7. Only after that check, ask the agent to make a change.

Use this sign-in wherever your product offers one. A few clients cannot complete it, and a hosted product whose address StoreConnect has not yet added cannot either. Those send the same token as a header instead: Authorization: Bearer org_id:store_sfid:api_token, in the three-part format described above. Treat the header as the fallback, not the default.

:::tip The Console’s How your agent connects section gives you these steps with your own store address filled in. In Claude web or desktop, open Settings, then Connectors, then Add custom connector, enter your store’s /mcp URL, and complete sign-in. Enable the connector only in conversations that need it. In Claude Code, add the server and then sign in:

```bash

claude mcp add –transport http –scope local storeconnect https:///mcp claude mcp login storeconnect claude mcp list ```

If your store is served at a path, put that path into the address in both places, so it reads https://<your-store-domain>/<your-path>/mcp. :::

If your product cannot sign in and needs the bearer header instead, copy the Bearer credential from the Console rather than assembling it by hand, and avoid typing it into a command, because it lands in your shell history. Set it in the product’s own settings. Where to set a header differs by product and changes over time, so check your agent’s current MCP documentation for the exact field.

If the sign-in screen refuses the connection, it names what failed. Each message has its own fix, so read it rather than retrying: see Troubleshoot an agent connection.

A successful connection is not approval to make changes. Always verify the store and environment first.

How changes are made safely

By default, a person approves every change an agent makes to themes and design. Changes are staged, so you can review exactly what an agent will do before anything reaches your live store:

1. The agent confirms which store and environment it is connected to.
2. It reads the current records it needs, rather than guessing.
3. It stages one related change at a time.
4. It shows you a summary of what will be added, updated, or removed.
5. It shows a preview where one is available.
6. You approve the change explicitly.
7. The agent submits the staged change.
8. It rechecks the result, because publishing can finish in the background.
9. It confirms the live storefront reflects the approved change.

Treat all changes as high-impact and review them closely before approving: deletions, bulk edits, price changes, activating a theme, and any change to navigation or checkout.

:::note Keeping a person in the loop is the default, not a hard limit. A Store Role at Approver level lets an agent publish records live as you, and most agent clients can be set to approve tool calls automatically. Combine the two only where you intend an agent to publish without a review step, and keep that setup out of your live store while you are still learning how an agent behaves. :::

If something does not work

The sign-in screen names what failed when a connection is refused, and an action an agent cannot perform is usually a permissions boundary rather than a fault. Work from the message you were shown: see Troubleshoot an agent connection.

:::warning Try agent-driven changes in a test store or Salesforce sandbox before you run them against your live store. See Set up your test store and Move data from sandbox to production. :::