Search for an Amazon Seller MCP server and you will find three kinds of answer on the first page: hosted relays that sell you a connection, open-source repositories you run yourself, and directory listings that index both. They all describe the same capability in almost the same words: ask questions about your store in plain English and get answers from your real data.
That capability is real, and it is worth having. It is also narrower than the phrasing suggests, and the gap between the two is where most of the disappointment lives.
What an Amazon Seller MCP server actually is
The Model Context Protocol is a way for an AI client to call tools that someone else defined. An Amazon Seller MCP server is a small program that wraps Amazon's Selling Partner API, SP-API, and exposes its endpoints as tools your client can call. Nothing about it is Amazon-specific in design; the same shape is being applied to Shopify, eBay, Stripe and a hundred other APIs.
The examples used to sell them are consistent and honest about what they do: total sales and units by marketplace for last month, which SKUs are at risk of a stockout, return rate by category over ninety days. These are all read queries against endpoints that already existed. The MCP layer removed the step where you export a report and open a spreadsheet.
The three shapes, and what each one costs
A hosted relay. A vendor runs the server and you authorise it. Fastest to start and the only option that requires no local process. In exchange, your seller data passes through a third party you now have to evaluate, and you pay per seat or per call.
A repository you run yourself. There are several on GitHub, some written explicitly for Claude Desktop. Nothing sits between you and Amazon, which is the point. You are now operating a service: keeping the process alive, tracking upstream SP-API changes, and rotating credentials when they expire.
A client that speaks the protocol natively. No separate server to run because the client is already an MCP client and ships the connector. Fewer moving parts, but you are choosing the client rather than adding to the one you have.
The part that gets skipped
All three routes converge on the same prerequisite, and almost no guide leads with it: you need an SP-API application of your own. That means developer registration, choosing the roles your application requests, and holding LWA credentials that expire and have to be rotated.
Two consequences follow that are easy to discover late. First, roles are granted per category, and the restricted ones covering buyer personally identifiable information are a separate approval track that most sellers neither get nor need. Second, SP-API is rate limited per endpoint, so a question phrased as one sentence can turn into a sequence of throttled calls, and a chat client that retries silently will burn tokens waiting.
None of this is an argument against doing it. It is an argument against the ten-minute-setup framing.
The ceiling on what retrieval gives you
Suppose it all works. You now have a chat window that can tell you your return rate by category is 8.4% and that four SKUs will stock out inside three weeks.
Neither number is a decision. The return rate matters only once you know whether it is a sizing complaint, a packaging failure or a promise the listing should never have made, and all of that lives in the review text rather than the returns endpoint. The stockout matters only against a lead time and a season. And when you decide to rewrite the listing, the model needs to know that Amazon wants keyword-dense titles and five bullets under a character budget, that efficacy claims need evidence, and which superlatives will get the listing suppressed.
That knowledge is domain knowledge. MCP is a transport. It was never going to supply it, and it is a category error to expect it to.
Where Orkas sits in this
Orkas is an MCP client, so any server described above works with it the way it works with other clients. It also ships the Amazon Seller Central connector itself, running through your own SP-API private application, with credentials encrypted on your device and buyer PII neither requested nor exposed. For that particular integration there is no separate server to keep alive.
The part that matters more is the layer above. Orkas ships four merchandising skills that carry the domain knowledge the protocol does not: category research with the profit assumptions written down, listing generation with the per-platform rules and a compliance pass, creative planning from selling-reason cards through image prompts and video storyboards, and review analysis that redacts buyer identifiers before clustering complaints into things you can change.
They run on whatever you can supply. With a connector configured, the data arrives by API. Without one, they read the reports you exported yourself. That is how most sellers already work, and it is a perfectly good place to start.
What this does not cover
An MCP server, ours or anyone else's, reads the data your seller account already holds. It does not give you marketplace-wide search volume, BSR history or competitor sales estimates; those are licensed datasets, and tools that sell them are not replaced by a protocol. If your question needs that data, buy that data. If your question is what to do with the numbers you already have, that is a different tool and a different article.