There are two ways to connect. One installs a local helper and the client talks to it over stdio. The other has the client connect straight to a remote endpoint and authorise in a browser.
Querying Amazon data in Claude Code takes the first. This post takes the second.
When the remote path is the only one
The local installer needs you to run a command on the same machine as the client. Three situations rule that out:
- ChatGPT on the web — it runs in a browser, there is no local process to install into
- A shared team setup — you do not want everyone installing separately, nor to distribute keys
- Keys in config files — the local path writes a key into local configuration; the remote path does not
The third is the practical reason. An OAuth connection binds your account, the key ID you chose and the current credential fingerprint; the API key itself is never sent to the client. There is no key in the client to leak.
Client support
| Client | Remote browser OAuth | Local stdio | Recommended |
|---|---|---|---|
| ChatGPT web | Supported | Not applicable | Remote OAuth |
| Claude Code | Supported | Supported | Either |
| WorkBuddy | Preferred where compatible | Depends on support | Remote OAuth |
| Hermes | Depends on Streamable HTTP OAuth support | Depends on stdio support | OAuth where supported |
Claude Code works both ways, so it can follow the previous post or this one. For the other three, remote is effectively the only route.
The endpoint is https://ecommercedataapi.com/mcp, Streamable HTTP, OAuth 2.1 with PKCE.
Connecting from ChatGPT on the web
- Open the web settings and enable Developer mode
- Add a remote MCP server with the address above and choose OAuth
- Sign in to Ecommerce Data API
- Select an existing key and confirm, or explicitly create and authorise one
Step 4 has a snag worth knowing: even with a single key already selected by default, you still have to confirm. The authorisation screen will not choose for you.
A first prompt that costs nothing
Do not go straight to a data call. Send this instead:
Connection check
Reads the account balance only, and consumes no call credits.
Use ecommerce_account to check my remaining credits. Do not call any paid data endpoint yet.
A balance coming back tells you three things at once: OAuth completed, the tools loaded, and the account binding is right. And it spent nothing.
If you get a sign-in prompt or "tool not found" instead, the problem is in the authorisation, not the data endpoint — do not start adjusting request parameters.
What actually loads
A remote connection loads 49 tools: 45 business endpoints plus four generic ones.
| Generic tool | What it does |
|---|---|
ecommerce_api_search | Search the API catalogue |
ecommerce_api_describe | Read one endpoint's description and parameters |
ecommerce_api_call | Call an endpoint by code and input |
ecommerce_account | Check account credits |
Those four are the ones to remember. You do not need to memorise the business endpoints — let the model find one with ecommerce_api_search, read its parameters with ecommerce_api_describe, then call it.
That is why this route does not require knowing endpoint paths: the catalogue is itself queryable.
Remote MCP setupFull steps per client, copyable configuration, and the order to check things in when authorisation failsBilling and revocation are two different things
Billing follows the calls, not the connection method. Remote OAuth costs neither more nor less than local stdio; both draw on the same balance. ecommerce_account and the account page show the same number.
Revoking an MCP connection is not the same as disabling a REST key:
- Disconnect the MCP connection in settings → that client can no longer call, but the key still works for direct REST requests
- Disable the key → everything stops, including MCP connections bound to it
That distinction matters for a team. When someone leaves, decide whether you are withdrawing one client's authorisation or retiring the key entirely.
When not to use MCP
MCP suits exploratory work — when you are not sure what to look up, or the question changes every time.
Not for scheduled jobs. A monitoring flow that runs every day should call the REST endpoint directly rather than have a model re-decide which endpoint to use each morning. Model choices vary slightly between runs, and consistency is exactly what a scheduled job needs.
Not for volume. Processing a few hundred ASINs one model call at a time is slow and expensive. Write a script.
The dividing line is roughly: MCP for deciding, REST for repeating.
If yours is the second kind, The complete Amazon data API guide breaks the 46 endpoints down by the job each one does.
Questions
Is developer mode required? On ChatGPT web, currently yes. Other clients differ — follow their configuration docs.
Can I skip OAuth and just use a key?
Some clients accept an Authorization: Bearer header in the configuration as a fallback. That puts the key back into a config file, which gives up the main advantage of this route.
How many clients can one account connect? Several. Each connection binds the key you selected for it, and each can be viewed and disconnected separately in settings.
The model still says the tools are missing. Check that the connection shows as authorised, then start a new conversation — an existing one does not pick up newly connected tools.