MCP and APIs for ecommerce
How AI assistants reach store data, and why the API underneath does not go away
Published
An API and an MCP server are two ways into the same ecommerce data. An API is an interface developers build against in code, and it is how a feature gets into a live storefront. An MCP server exposes that same functionality as tools an AI assistant can call in plain language, so a person can ask a question and get an answer without writing anything. Underneath, the MCP server is calling that same API.
The two are often presented as competing options. They are layers, and most ecommerce teams end up using both. This guide explains what each one actually does, when to reach for which, and what to check before connecting an AI assistant to live store data.
What an API does
An API is a contract. It defines the exact requests a system accepts and the exact responses it returns, so that other software can rely on it. When a shopper types into a search box and results appear, an API call produced those results. When a product feed syncs overnight, an API call moved the data.
The strength of an API is that it is deterministic. The same request returns the same shape of response every time, which is what makes it safe to put in front of customers. The cost is that every question has to be expressed as code first. Someone has to know the endpoint, write the request, handle the response, and deploy it. For a one-off question about last week's search behavior, that is a lot of work for a small answer.
This is why APIs are built for engineering teams and shipped features, and why they remain the foundation of every ecommerce integration.
What an MCP server does
The Model Context Protocol is an open standard for letting an AI assistant call an external system's functionality as tools. A vendor runs an MCP server that describes what its tools do and what inputs they take. An assistant connects to that server, reads the descriptions, and from then on can use those tools to answer questions.
The important part is who does the planning. With an API, a developer decides in advance which calls to make and in what sequence, then writes that sequence down. With an MCP server, the assistant works it out at the moment the question is asked. A request like "which of my searches return nothing, and are those products even indexed" can pull from more than one tool and combine the results, without anyone having designed that particular combination beforehand.
That flexibility is also the limitation. An assistant reasoning its way to an answer is excellent for exploring, checking, and diagnosing. It is the wrong mechanism for anything that has to behave identically on every one of a million page loads.
API and MCP server: Side by side
| API | MCP server | |
|---|---|---|
| Who calls it | Code you write and deploy | An AI assistant, on your behalf |
| How a request is formed | A developer writes it in advance | The assistant decides at question time |
| Best for | Live storefront features, scheduled jobs, anything customer facing | Exploring data, diagnosing problems, one-off questions, editing configuration |
| Predictability | Identical every run | Varies with how the question is phrased |
| Who uses it day to day | Developers | Anyone who can ask a clear question |
| What sits underneath | The platform itself | The same API |
The last row is the one that settles most of the confusion. An MCP server is not a separate product with its own data. It is a way of reaching functionality that already exists, packaged so an assistant can use it.
When to use which
Building something customers touch
Use the API. A search results page, a recommendation slot, a checkout step, or a scheduled feed sync has to behave the same way on every request, and it has to keep working when nobody is watching. This is what a documented, versioned interface exists for.
Answering a question about the store
Use the MCP server. Which queries came back empty last month, whether the feed synced, which fields are sortable, what a template currently says. These are questions, and turning each one into code before it can be answered is the slow path.
Making a configuration change
Usually the MCP server, and this is where it earns its place. Describing a change once and letting the assistant apply it beats clicking through the same configuration screens repeatedly, and that advantage grows with the number of changes rather than shrinking. Each write still asks for confirmation, so a run of changes is a run of approvals. Code against the API is the better choice when a change has to be version controlled, reviewed before it ships, or replayed identically as part of a deployment.
Exploring a platform before committing
Use the MCP server. Connecting an assistant and asking it what is available is a faster way to understand what a platform can do than reading reference documentation and writing test calls against it.
How this works at Hello Retail
Hello Retail runs both layers. The REST and GraphQL APIs are what integrations are built against, and the Hello Retail MCP server connects AI assistants to the same functionality. It works with Claude (Code, Desktop, and Projects), OpenAI Codex, and ChatGPT.
Seven tool categories are documented today, with more rolling out:
- •Website management. List a company's websites and their configurations.
- •Search. Read and edit search templates.
- •Search analytics. Analyze zero-result queries, top searches, and filter and sort usage.
- •Feeds. Check the sync status of the last product feed.
- •Product data. View indexed product information and pricing.
- •Data fields. Identify which product and content fields are searchable and sortable.
- •Recommendations. Read and edit recommendation templates.
On permissions, the thing to understand is whose access the assistant is using. You sign in with your own Hello Retail account, and from then on the assistant acts on your behalf, with the same access that account already has and no more. There is no separate key to issue or share. Beyond that, most tools are read-only, and the write-enabled ones, editing a search or recommendation template, ask for confirmation before they run.
Setup needs a Company ID, found in my.helloretail.com under the profile icon and then Company Profile. A sensible first request is to list the websites for that company, then use one of the returned sites to explore its search or analytics tools. Full setup steps for each assistant are in the Hello Retail developer documentation.
For what to do once the connection is made, see the companion guide to what to ask an AI assistant about your store.
Why the distinction between MCP and API matters now
Store data now has a second audience, and it is machines. Shopping assistants read catalogs to advise buyers. Merchant-side agents read store data to decide what to send and when. Our guide to agentic commerce covers both, and both need data a machine can reach and make sense of.
An MCP server is the version of that shift you can use today. It does not change what your store knows. It changes who can ask and how fast they get an answer. A merchandiser who can check empty searches by asking will check them weekly rather than quarterly, and those searches are the clearest record a catalog keeps of what shoppers wanted and could not find.
What has not changed is the requirement underneath. Clean, well-described product data is what makes any of this useful. Point a capable assistant at a badly structured catalog and you get quick answers about a store customers still cannot navigate.
Frequently asked questions
What is the difference between an MCP server and an API?
An API is an interface that software calls in code. A developer writes against it to build a feature into a storefront, an app, or a backend job, and that code runs the same way every time. An MCP server sits on top of the same functionality and exposes it as tools an AI assistant can call in plain language. The assistant decides which tools to use and in what order, based on the question a person asked. You use the API to build something into your store, and the MCP server to ask something of it.
Does an MCP server replace an API?
No. An MCP server needs an underlying API to call. It is an additional access layer for AI assistants, not a replacement for the programmatic interface. Anything that has to run reliably in production, a storefront search box, a checkout flow, a nightly product feed sync, still belongs in code against the API. Hello Retail documents both, side by side, for exactly this reason.
What can an ecommerce team do with an MCP server?
Ask questions of live store data without opening a dashboard, and get answers assembled from several sources in one request. Typical examples are finding which searches return no results, checking whether the last product feed synced, seeing which fields are searchable and sortable, and reading or editing a search or recommendation template. The Hello Retail MCP server exposes seven documented tool categories: website management, search, search analytics, feeds, product data, data fields, and recommendations.
Is it safe to connect an AI assistant to ecommerce data?
It depends on how the server is built. The two things to check are whose access the assistant is using and what it is allowed to change. On the Hello Retail MCP server you sign in with your own Hello Retail account, and the assistant then acts on your behalf with the same access that account already has, so there is no separate key to issue or share. Most of its tools are read-only, and the write-enabled tools, such as editing a search or recommendation template, ask for confirmation before they run.
Which AI assistants can connect to an ecommerce MCP server?
That is set by the server. The Hello Retail MCP server works with Claude (Code, Desktop, and Projects), OpenAI Codex, and ChatGPT. Because the Model Context Protocol is an open standard, any assistant that implements it can, in principle, connect to any server that implements it.
Do we need developers to use an MCP server?
Not to use it day to day. Someone technical usually does the first connection, since it needs a Company ID and an OAuth login, but the questions afterwards are asked in ordinary language. That is the practical difference from an API, where every question has to be turned into code before it can be answered.
Ask your store a question
Connect Hello Retail to Claude, ChatGPT, or OpenAI Codex and query your search analytics, product data, and templates in plain language.
Read the MCP setup guide