Claude connects to ecommerce data through a remote MCP server (Model Context Protocol) and OAuth, with no keys to copy. In MitoOps, orders, products, inventory, documents, shipments, analytics and reports from all stores already flow into one normalised layer, and Claude connects to that layer once instead of to every system separately. The first production version started with six read-only tools; today MitoOps exposes 84 tools across 20 permission scopes, of which 67 read and 17 write: a disabled automation draft that only a person can enable, or a discount coupon with a preview and confirmation. The test ran in the live operations of Mitochondriak, an independent MitoOps customer with four stores in four markets, using an ordinary Claude.ai account and a custom connector.
What is MCP for ecommerce?
MCP, the Model Context Protocol, is an open standard that lets an AI application discover and call the tools of another system. Instead of a large data export in every conversation, the assistant asks the connected system for exactly the information it needs.
An ecommerce MCP server is the part that exposes business data as such tools: a structured bridge between an AI assistant and the systems that hold orders, products, stock, documents, shipments and measurements.
The key architectural question is where that server should stand. AI can be attached directly to a single ecommerce platform. Or MCP can be built on top of an operations system that already joins several stores and operational systems. MitoOps takes the second path.
For an online store, the assistant's requests over MCP look like this:
- list the stores I have access to,
- show orders for a chosen period and open one with its items,
- find a product by name, code or EAN and tell me how much is in stock,
- list August shipments by carrier with the median delivery time,
- how many orders came from ChatGPT and which queries had the highest CTR,
- what were revenue, gross profit and the margin of a product over the last month.
Why not connect Claude separately to every ecommerce system?
Picture a growing ecommerce company selling in several markets. Its operational data is scattered across a long list of systems, each with its own access, API, data structure and permission model:
A direct AI integration with every source repeats the problem system integrations have always had. And the assistant usually needs to join information from these systems before it can even answer a business question.
- one or more ecommerce platforms,
- stock and product data,
- invoices and credit notes,
- several carriers,
- shipment tracking events,
- Google Analytics 4,
- Google Search Console,
- financial reports,
- purchase prices and margins.
Take the question “Which countries are still profitable after real shipping costs?”. The ecommerce platform alone cannot answer it. Neither can the carrier or GA4. It takes an understanding of business data, costs, logistics and often attribution, all at once.
Without a normalised layer, an AI audit like that would often require several systems, CSV and PDF exports and manual joining of data in a spreadsheet. Every separate AI connector is also a separate place where access has to be granted, reviewed and revoked.
The alternative is to normalise first and connect AI second.
The MitoOps approach: normalise first, connect AI second
MitoOps is an ecommerce operations platform that sits above the systems a merchant already uses. Orders, products, stock, invoices, shipping, analytics and reports are handled over one operational data model, and a merchant with several stores works in one account.
MCP is one more controlled way to ask that same layer for data. The chain looks like this:
- Stores send orders, products and documents to MitoOps; carriers deliver tracking events, GA4 and Search Console deliver measurements.
- MitoOps normalises them and applies its model of customer spaces, stores and permissions.
- An MCP server exposes a set of tools over this model, from one catalogue shared with the REST API — reading plus one narrow write of an automation draft.
- The user authorises the AI application over OAuth and chooses what it may read and from which stores.
- Claude calls the tools and works with the answers in the conversation, joining them with a document the person uploaded where needed.
The advantage is not just that Claude has an MCP connection. The advantage is that Claude gets one consistent business layer instead of having to understand every system above it separately.
The same layer serves the screens of the application itself and its REST API, so AI does not get a second, separately maintained view of the business.
The case study: MitoOps and Mitochondriak
Mitochondriak is an independent ecommerce company and a MitoOps customer with four stores in live operation: in Slovakia, the Czech Republic, Poland and an international store. A fifth, German store is in preparation. It uses MitoOps every day to run several stores from one account, for stock and inventory, shipping, reporting, analytics and, since September 2026, for access over MCP and API.
That makes it a useful place to test an ecommerce AI integration under real operating conditions, with real order volumes and real permission boundaries.
The test question was simple: can an ordinary Claude.ai account connect safely to live MitoOps business data without anyone pasting an API token into Claude, and without Claude getting write access?
The answer was yes. Claude first listed the stores, then pulled seven days of orders from each of the four stores and summarised activity by market in one answer. In the following questions it worked with the carrier split, delivery times, traffic channels and the period report.
The main benefit for the customer: without a normalised layer, an audit like that would mean logging into four admin panels, carrier portals, GA4 and Search Console, exporting spreadsheets and joining them by hand. With MitoOps, Claude reads the permitted business data through one layer with one permission model.
The image above is an illustration from that test; it carries no figures or customer names. What Claude used in the session:
- the list of stores and their market codes,
- orders for a period, per store, and an order detail with items,
- delivery statistics by carrier and shipments with handover and delivery times,
- a traffic overview, channels including AI sources and Search Console queries,
- a financial summary for the period and sales by product,
- stock levels of selected items.
How to connect Claude to MitoOps over MCP
For the test we used the customer account's remote MCP address in the form https://app.mitoops.com/api/mcp. Every MitoOps customer sees the exact address of their account under Settings → API & MCP. The connection is available from the Start plan; connecting over OAuth does not use an access key from the plan's limit.
On the Claude side, a custom connector in Claude.ai is used:
- Open Claude.ai and go to Settings → Connectors.
- Choose Add custom connector.
- Name it MitoOps and paste the MCP address.
- Start the connection.
- Claude redirects you to MitoOps.
- Sign in to MitoOps with your own account, second factor included.
- Review the consent screen: it lists what the connector asks to read.
- Tick the scopes and stores the connector may access. Sensitive scopes are not pre-selected.
- Confirm. MitoOps sends Claude back with an authorisation, never with your password.
- Ask Claude a question about your stores.
At no step is a MitoOps API token copied into Claude.ai. Claude receives an OAuth authorisation bound to the person who approved it, to their customer space and to the stores they ticked.
Under the hood it is standard OAuth 2.1: authorisation code with PKCE (S256 only), token binding to the resource, dynamic client registration and discovery metadata, so the Claude connector finds the authorisation server itself and no manual client configuration is needed. The step-by-step guide with screenshots is in the MCP interface documentation.
This matters because an MCP connection must not bypass the access model of the business system behind it — nor the plan: an account without API & MCP does not open the consent screen.
What Claude can read from MitoOps today
Here we want to be precise — including about how it changed. The first production version (1 September 2026) started with six read-only tools: stores, orders, products, invoices and credit notes. Since then the public capability layer has grown in several waves: shipping, analytics, reports and inventory; invoice detail, stock movements, suppliers, customers and claims; automations, webhooks and the account plan with the first narrow write; claims statistics and the affiliate programme; and finally the customer directory with a scope of its own.
Today the MitoOps MCP layer exposes 84 tools across 20 permission scopes and 17 data areas — 67 tools read and 17 write: a disabled automation draft, or a discount coupon (creation, explicit update and deletion, always with a preview and confirmation). These numbers are not typed into the article: they are derived from the application catalogue when the page is built, just like in the documentation. The areas by scope:
| Scope | What Claude gets |
|---|---|
| stores:read, orders:read | Stores with market codes; orders for a period with paging and an order detail with items. Totals in the bulk list only with reports:read, item purchase prices only with purchase-prices:read. |
| products:read, inventory:read | Search by name, code, EAN or PLU, a product detail, categories; the stock level with its source and the history of stock movements. |
| shipping:read | Carriers without credentials, shipments with hand-over and delivery times, a detail with tracking, statistics: counts, delivery rate, median and p90 delivery time, countries. |
| analytics:read | Sessions, orders, revenue and conversion from GA4, channels including ChatGPT and AI sources, Search Console queries and pages, order coverage by tracking. |
| invoices:read, reports:read | Invoices with items, credit notes, proforma invoices; a financial summary for the period, sales by product, performance per order and customers as pseudonyms. Totals always cover the whole period. Cost of goods and margin only with purchase-prices:read. |
| purchasing:read, claims:read | Suppliers with offers and cost components; claims and returns linked to the order, credit note and return shipment, claims statistics and the module's processes. |
| affiliate:read | The affiliate programme: overview, partners, campaigns, discount codes, conversions, payouts, statistics and settings — partner contacts only with personal-data:read, bank and tax data never. |
| customers:read | The customer directory: pseudonym, shops, country, language, lifetime counts and dates; an optional purchase-activity filter adds period figures alongside the lifetime ones. Name, company, e-mail and phone only with personal-data:read, revenue and LTV only with reports:read. Money always per currency, never one mixed number. |
| automations:read, webhooks:read, account:read | The catalogue and list of automations with runs, draft validation; webhook endpoints without secrets and the delivery log; the account plan with limits and usage. |
| automations:write | Creating or updating a DISABLED automation draft. Only a person in the app can enable it. |
| coupons:write | Creating a discount coupon from the parameters you give, and explicitly updating an existing one (discount, validity, product and category restrictions) — always with a preview of the changes and only after confirmation. On creation an existing coupon is never overwritten — the difference is reported instead; this scope cannot delete. |
| coupons:delete | Explicit deletion of a coupon after a preview and confirmation. A coupon used by AI Mailing, the newsletter popup, a scheduled campaign or a partner is not deleted — the interface returns the dependencies. |
The purchase-prices:read and personal-data:read scopes have no tool of their own; they decide which fields appear in the other answers (purchase prices, margins; the customer's name, e-mail, phone and street, supplier and partner contacts). A missing field in an answer is not zero — it is missing.
The tool list the assistant sees follows the granted scopes. A connector authorised only for orders does not even see the shipping tools.
Summary tools (delivery statistics, analytics overview, financial summary, claims statistics, affiliate overview) return finished figures from the application. Claude does not need to pull thousands of records and compute on its own; raw lists remain for the detailed view.
The full, generated list of tools with parameters is in the MitoOps MCP interface documentation, and the same catalogue describes the REST API in OpenAPI.
What Claude and MitoOps can actually do: live examples
All of the following cases are in operation today, not on a roadmap. The questions are phrased the way a merchant asks them; the results are deliberately given without the customer's figures.
| Question for Claude | MitoOps tools | What comes out |
|---|---|---|
| What was the carrier split in August, per market? | shipping_stats | Share of shipments by carrier and country, without opening four portals. |
| What was each carrier's median and p90 delivery time? How many were undelivered or returned? | shipping_stats, shipping_shipments | A carrier comparison on the same metric, from tracking events rather than the carrier's promise. |
| Here is the DHL invoice — compare it with the shipments for that month. | shipping_shipments + uploaded document | The invoice as the external source of truth for costs, MitoOps shipments as context; mismatches and the average per parcel. |
| What is the margin on product X over the last month? | sales_product_performance (with purchase-prices:read) | Sales, purchase price at document time and margin — only for a person entitled to purchase prices. |
| Compare revenue and conversion of the four stores for Q3. | analytics_overview, reports_financial_summary | A multi-store overview from one layer with one report currency. |
| How many orders and how much revenue came from ChatGPT and other AI sources? | analytics_channels | AI channel attribution next to organic and paid search. |
| Which Search Console queries have high impressions and low CTR? | analytics_seo | Candidates for better titles and descriptions, straight from GSC. |
| How many units of product Y do we have and where does that number come from? | inventory_stock | Stock level with the source of the value — variants, store balance or product card. |
The common denominator: Claude does not guess from a picture of a dashboard. It works with structured operational data and, when needed, with an external document the merchant supplied.
What Claude cannot do over MitoOps MCP — and what the single write is
Claude cannot change operational data in MitoOps over this MCP connection. There is no MCP tool to:
- change an order,
- change an order status,
- edit a product,
- change a price,
- change stock,
- create a refund or credit note,
- issue a document, delete records or enable an automation.
| Where | What prevents writes |
|---|---|
| Capability kernel | Every capability available over REST is declared without side effects; the only two with a write (the automation draft) are available exclusively over MCP, and an automated test guards that invariant. |
| Catalogue | One closed list defines what is exposed, under which tool name and which REST path. Nothing outside it can be called. |
| Adapters and service | The REST adapter answers anything other than GET with 405 before it even looks at the credential; the MCP adapter offers only tools from the catalogue, and the automation service writes nothing but a disabled draft. |
Since 3 September 2026 MCP has one narrow write — a deliberate decision, not a switch on the read tools. With the sensitive automations:write scope, which is never pre-selected on the consent screen and is offered only to a person with the right to edit automations, Claude can propose a rule from the catalogue and save it as a DISABLED draft, or edit a draft nobody has published yet. The draft appears in Automations like any other work in progress; only a person in the app can enable, publish or run it. AI proposes, a person activates.
The security boundary is enforced by the server at three levels, not by a request in a prompt. “AI runs the store by itself” does not happen in MitoOps: orders, stock, products, prices, documents, refunds and workflow activation cannot be changed over MCP.
Is MCP safe for ecommerce? Six layers in MitoOps
MCP on its own does not make an integration safe. Safety depends on how the server handles authentication, permissions and the tools it exposes. In MitoOps, six layers apply to every connector:
- Tenant isolation. Every customer works in a separate space with its own database. The credential carries that space, so a connector authorised in one account has no path into another.
- Store selection. The authorisation covers only the stores ticked on the consent screen and the list is stored explicitly. A store connected later does not join an existing grant on its own.
- Scopes. Access is divided into 20 scopes, 6 of them sensitive (reports, purchase prices, personal data, purchasing, automation drafts, coupons and affiliate programme management): they are never pre-selected and a person has to tick them deliberately.
- User permissions. The consent screen offers only the scopes the signed-in person has. A warehouse worker who cannot see purchase prices in MitoOps cannot grant them to an AI assistant either; whoever may not edit automations does not even see the draft scope.
- Tools mostly read. Of 84 tools, 67 only read and 17 write: a disabled automation draft that a person enables, and a discount coupon from the parameters given — including explicit update and deletion with a preview and confirmation. On creation an existing coupon is never overwritten — the difference is reported instead; deletion has its own scope and refuses a coupon with a live dependency. Tool annotations (readOnlyHint) tell the client, the service holds the line — and the REST API has no write at all.
- Validity and revocation. The access token lives for an hour and the refresh token for 30 days; the standard OAuth revocation endpoint is implemented and a revoked grant stops every token that came from it. Access keys issued in the app can be revoked or rotated instantly on the API & MCP screen.
Two things follow from the fourth layer. Nobody can raise their own rights through AI, and the security review of a connector is the same review MitoOps already does for people.
What is the difference between an API and MCP?
API and MCP are often described as competing technologies. In this use, that is the wrong model. In MitoOps both REST and MCP sit on the same business capabilities and read from one shared catalogue:
| REST API | MCP |
|---|---|
| A program explicitly calls an endpoint | An AI client discovers and calls a tool |
| Ideal for software-to-software integration | Ideal for an AI assistant's work |
| The developer decides which call is made | The model picks the suitable exposed tool |
| A structured HTTP interface with an OpenAPI contract | A structured tool interface with JSON schemas |
| Authenticated with an access key | Authenticated with an access key or over OAuth on a person's behalf |
Both paths use the same scopes (20) and the same store selection. The envelopes differ; the business data is identical. REST is read-only; the single write, an automation draft, is available only over MCP.
So for us MCP is not a replacement for the MitoOps API. It is one more controlled way to ask the same operations system for data. An overview of both paths is on the API & MCP page, details in the developer documentation.
AI shipping cost analysis: a carrier invoice plus MitoOps data
A strong example that works today is AI shipping analytics. A store owner receives a monthly invoice from a carrier, say DHL. Instead of exporting six spreadsheets, they upload just that invoice to Claude. The operational context around it comes from MitoOps through the tools the person allowed:
- shipments for the period with carrier, service, country and handover and delivery times,
- carrier statistics: counts, delivery rate, median and p90 delivery time,
- orders for the period and their markets,
- sales by product and margins, if the user is entitled,
- GA4 attribution data and Search Console queries.
Claude reads the invoice, MitoOps supplies structured context and the analysis runs over both: the real average cost per parcel, the countries with the highest cost-to-revenue ratio, the carrier that is faster for a given country, and whether the free-shipping threshold makes sense at real costs.
The carrier invoice matters for another reason: MitoOps does not pretend to know every merchant's real shipping costs. In reports, the shipping cost is a customer setting with four modes — the actual cost per shipment from a connected source, a percentage of revenue, a fixed amount per order, or off. The external document is therefore the honest source of truth for costs, and MitoOps supplies what it knows with certainty: shipments, times and orders.
Can AI analyse GA4 and ecommerce data together?
Yes, and in MitoOps it is in operation today. The analytics and tracking layer joins store orders with Google Analytics 4 and Search Console: it tracks attribution and measurement coverage against orders, revenue by channel and Search Console metrics such as clicks, impressions, CTR and average position. How this layer treats orders that analytics never sees is described in our article on measurement coverage.
Over MCP the same data is available in the analytics:read scope: a period overview, channels including ChatGPT and other AI sources, Search Console queries and pages, and order coverage by measurement. So Claude does not need a separate GA4 connector and a separate store connector to answer a cross-system question — it asks the MitoOps operations layer with its existing permission system.
What about Shoptet, WooCommerce and PrestaShop?
The same distinction between architecture and deployment status applies to ecommerce platforms.
Shoptet is connected to MitoOps in live operation today. For a merchant on Shoptet, MitoOps is therefore the operations layer between the ecommerce platform and the AI assistant. That is a different idea from attaching Claude directly to the Shoptet API: the store sends business data to MitoOps and Claude reads the normalised form in MitoOps over MCP.
WooCommerce is connected the same way: a store connects with a single click, MitoOps reads its orders, catalogue and reviews from it, and writes back order status, stock and the tracking number. Claude reaches it through the same operations layer, not through the WooCommerce API.
The Shopify and PrestaShop integrations are in development and marked as coming soon on our site. We therefore do not claim that MitoOps offers a live Shopify MCP or PrestaShop MCP integration today.
When those ship too, the architecture towards AI stays the same: the ecommerce platform at the input changes, Claude keeps talking to the MitoOps operations layer with the same tools and scopes.
Can Claude connect to an ERP over MCP?
Yes, if the ERP or a middle layer exposes a suitable MCP server.
MitoOps itself does not position itself as a general ERP. It is a system for ecommerce operations. The principle behind connecting an ERP over MCP is the same, though: AI should ask a business layer that already understands the meaning of orders, products, invoices, stock and permissions, rather than get raw database access.
MitoOps deliberately gives no direct database access through the public interface, and undocumented application routes are not part of the contract. The interface is /api/v1 for REST and /api/mcp for MCP, nothing else.
Which plan includes API & MCP?
From the Start plan. Plans differ by the number of active access keys: Start has one, Growth two, Pro five and the Custom plan by agreement. The free trial and Beginner do not include the interface.
Connecting Claude.ai over OAuth does not use a key. A Start customer with one issued key connects Claude without revoking it. The key limit is enforced by the server; a downgrade does not revoke existing keys, it only stops new ones until the count drops below the new limit. Current values are in the pricing.
Why MitoOps MCP reads — and writes only a draft
The easiest AI demo is an agent that changes something. The harder question is whether it should.
An ecommerce system holds live data. A wrong price, a wrong stock level or a changed order status is not a cosmetic AI mistake. It is an operational incident with a customer at the other end.
The public MitoOps MCP layer therefore follows one rule: let AI understand the business first, then let it propose, and leave operating it to a person. Reading already covers useful work today:
- find an operational fact without opening five screens,
- summarise orders, shipments, claims or a report for a period or market,
- compare carriers and markets on the same metrics,
- look up products by code or EAN and check stock,
- find invoices, credit notes and the affiliate programme's performance,
- join MitoOps data with documents the user uploads,
- propose an automation as a disabled draft that a person reviews and enables.
The write was designed as a separate problem, not as a switch on the read tools: a single action (the draft), its own sensitive scope, idempotency via clientRequestId, optimistic concurrency via expectedVersion, the catalogue version and an audit of every call. Further writes, if any, will arrive the same way — one at a time, with a boundary held by the server.
What we learned from the MitoOps and Mitochondriak test
The main result was not that Claude can list an order. Technically that is the easy part.
The more important result is that an ordinary AI application could connect to the live operational data of four stores through a familiar OAuth flow while MitoOps remained the authority for:
- who is connecting,
- which customer space they belong to,
- which stores they may expose,
- which scopes they may grant,
- which financial data they may see,
- which tools physically exist,
- whether the plan allows it at all.
And a second result: questions that used to need four admin panels, carrier portals, GA4, Search Console and a spreadsheet are now asked in one sentence. Not because AI got smarter, but because it was given one normalised layer with clear boundaries.