MCP Account Linking – Definition and How a Store Should Do It
MCP account linking is how an AI connector gets permission to act for one signed-in shopper: their orders, their cart, their prices. The shopper signs in on the store and approves. The connector receives a token made for the MCP endpoint only.
The password stays on the store, the connector gets a narrow token, and the shopper can switch it off at any time.
Why a normal login token is not enough
Most anonymous MCP tools need no identity: search, product details, store info. But “reorder what I bought last month” or “what is in my cart” needs to know who the shopper is.
The easy shortcut is to hand the connector the shopper’s ordinary API token. That is the wrong shortcut. A Magento customer token works for the whole REST and GraphQL API: it can change addresses and read every order. The MCP specification says a server must only accept tokens issued for it, and must not pass a received token on to other APIs. A connector should hold no more power than its job needs.
The flow
- The connector sends the shopper’s browser to the store’s linking page, with a
redirect_uri, astatevalue and a PKCE challenge. - The shopper signs in on the store, on the normal login page, and approves a screen that names the connector and says what it may do.
- The store sends the browser back with a one-time code. It works once, for a short time, and only with the PKCE verifier.
- The connector exchanges the code for a grant and a first short-lived token for the MCP endpoint.
- When that token expires, the connector uses the grant to get a new one.
- The shopper can see and disconnect linked assistants in their account. That stops the grant and its tokens at once.
What makes it safe
| Rule | Why |
|---|---|
| Password only on the store | The connector never sees it |
| Token works only at the MCP endpoint | A leaked token cannot reach the rest of the API |
| Grant bound to one connector | Another integration cannot use a stolen grant |
Exact redirect_uri match | No open redirect to a phishing page |
| Only hashes stored | A database leak gives no working codes or grants |
| Identity never from tool arguments | No tool accepts a customer id; it comes only from the verified token |
A Magento example
In the MCP Server module for Magento 2, a connector such as mcp.angeo.dev sends the shopper to /mcp/link. After sign-in and approval it calls POST /mcp/link/exchange and gets a grant and an amc_ token. It sends that token as X-Customer-Token next to its own integration token. The amc_ token works only at /mcp. Shoppers manage connected assistants under My Account → AI assistants. The MCP Reorder module builds on this: a business buyer asks the assistant to repeat last month’s order, and the lines go into their own cart at their own prices.
Questions
- Does the AI connector see my password?
- No. You type the password only on the store’s own login page. The connector receives a token that works only at the store’s MCP endpoint.
- How do I disconnect an assistant?
- In the store account, in the list of connected assistants. Disconnecting stops the grant and every token made from it at once.
- Why not give the connector a normal customer API token?
- Because that token can do much more than the connector needs, such as changing addresses. The MCP specification also says a server must only accept tokens issued for it.
- Is account linking needed for anonymous shopping?
- No. Search and guest checkout work without it. It is only for tools that act for one signed-in shopper.
Related
- MCP for commerce – definition
- Magento MCP server
- B2B AI visibility for Magento
- MCP Reorder module
- MCP Server reference: account linking
- MCP glossary