MCP interface

In short

MitoOps provides a standard remote MCP server (Model Context Protocol) at /api/mcp, through which a compatible AI application fetches data itself. It sits on the same capabilities as REST — it is not a second interface with its own queries, it is a different way of asking the same question.

MCP is not a property of the model but of the application the model runs in (the client). Any application that supports remote MCP over HTTP with OAuth or with an access key can connect. Claude.ai is the production-verified client — its exact procedure is below; for any other application the general procedure in the next section applies. Clients we have not tested are not declared verified.

There are two ways to identify yourself:

• with an access key you issue in the application — for your own program, or a server calling a server;
• over OAuth, when the connecting AI application supports it — then you sign in yourself and pick, on the consent screen, what it may read.

Either way the token travels in the Authorization: Bearer header, and either way the same scope of permissions applies: what the key or the consent does not cover, no tool returns.

The quickest way to connect is the Connect AI button in the app’s top bar. It is visible to anyone with the right to access keys. The window walks you through three steps: you choose the app (Claude, ChatGPT or another app), copy the MCP address together with short instructions for the chosen app, and in the third step you see the connection status and sentences to try out. The What the AI may change link takes you to the Writing via AI tab, and Manage connections to the list of connections. If your plan does not include MCP, the window says so and offers the plans. Detailed instructions follow below.

Connecting Claude.ai — verified step by step

Claude.ai does not connect to individual stores; it connects to MitoOps — the layer that already brings the data of all your stores together.

You need no key, no Client ID and no secret. Claude.ai discovers everything from the interface address.

1. In Claude.ai open Settings → Customize → Connectors (on a Team plan an owner first adds it under Organization settings → Connectors).
2. Click Add custom connector.
3. In Name enter MitoOps.
4. In URL paste the MCP address from the Connect AI window or from the Settings → API & MCP screen — in the form https://<your address>/api/mcp, for example https://app.mitoops.com/api/mcp.
5. Leave Advanced settings empty: Claude.ai uses its own hosted client metadata (OAuth). Click Add.
6. Click Connect on the connector.
7. The MitoOps sign-in opens (including the second factor if you use one). Sign in.
8. You see the consent screen: which application, which client, what it may read and which shops it applies to. Permissions are grouped by area of the app (sales, stock, shipping, marketing, partner program, automations). Reading is pre-ticked, sensitive data and draft preparation are not; changes with direct impact (for example deleting coupons or approving a send-out) are listed one by one in the collapsed Advanced permissions section. Each group lists exactly what it includes.
9. Review the scopes. The sensitive ones (for example Reports, Purchase prices, Customer personal data, Suppliers and purchasing, Automations – drafts, Availability: change proposals, Reviews: proposed replies and Claims: settings change proposals) are unchecked. If Claude should see margins or personal data, propose automation drafts and revisions or changes to availability or claims settings, tick them deliberately. Claims templates and settings are read with the Claims: settings and templates scope. Pick the shops.
10. Click Allow. Claude.ai returns to its page and the connector is connected.
11. In a conversation click + → Connectors and switch MitoOps on.

Connector added before 2 September 2026

If you connected earlier, Claude.ai has older metadata cached and the consent screen offered only the four basic scopes. Disconnect the connector and Connect it again: all scopes are offered, including the sensitive and the new ones (shipping, analytics, inventory).

What you tick on the consent screen is what applies — and never more than you may see yourself. Whoever has no right to purchase prices in the application cannot pass it on. The token Claude.ai receives carries only the granted scopes.

Another MCP client or AI application over OAuth

You give the application the same /api/mcp address and nothing more — no key. The rest is automatic:

1. The application asks us where to send the sign-in (protected resource metadata, RFC 9728).
2. Your MitoOps sign-in opens.
3. You see the consent screen and pick scopes and shops.
4. After approval the connection is ready and the application sees the tools.

An application that picks scopes itself must list them in its request: the consent screen offers only what the application asked for (and what you are entitled to). The interface advertises all scopes including the sensitive ones — in the WWW-Authenticate challenge and in scopes_supported. Sensitive scopes are still never granted on their own: on the consent screen they are marked and unchecked, and the token is narrowed to what you allowed (scope in the token response).

Connecting with an access key

The assistant or program needs the /api/mcp address on your domain and an access key with MCP among its interfaces. The exact address is shown on the Settings → API & MCP screen under “Where to plug it in”. A key issued for REST only does not work over MCP and vice versa.

Tools

The tool list follows the key or consent scopes: the assistant sees exactly what it was allowed and nothing else. A tool outside the scope does not exist for it.

MCP tool	Scope	REST	What it returns
account_connection	stores:read	GET /account/connection	Diagnostics of this connection: the app, who granted access and when, granted and missing scopes by area, stores and the AI write mode.
account_entitlements	account:read	GET /account/entitlements	The client’s plan, features and limits with current usage.
account_team	team:read	GET /account/team	The client’s team: names, roles, active accounts, last sign-in and who manages whom; e-mail only with the personal data permission.
affiliate_articles_create	affiliate:write	—	write: Creating a custom help article in all languages at once (title and body in the given language); HTML is sanitised.
affiliate_articles_get	affiliate:read	GET /affiliate/articles/:key	One help article with its HTML wording in all or one language; variables not substituted.
affiliate_articles_list	affiliate:read	GET /affiliate/articles	Help-centre articles of the partner portal: key, default/custom, enabled, order, per-language status.
affiliate_articles_set_state	affiliate:write	—	write: Enabling or disabling a help article for all languages at once; default articles are disabled, never deleted.
affiliate_articles_update	affiliate:write	—	write: Editing a help article in one language (title, slug, body; HTML sanitised) or restoring the default wording; returns unknown variables.
affiliate_campaigns_create	affiliate:write	—	write: Creating a campaign on a shop: name, reward (never invented), attribution window, availability, conversion approval.
affiliate_campaigns_get	affiliate:read	GET /affiliate/campaigns/:campaignId	One affiliate campaign.
affiliate_campaigns_list	affiliate:read	GET /affiliate/campaigns	Affiliate campaigns of a shop with reward, availability and counts.
affiliate_campaigns_update	affiliate:write	—	write: Editing a campaign: name, reward, attribution window, availability, approval, enabling/disabling, partner description per language.
affiliate_code_requests_decide	affiliate:write	—	write: Handling a partner code request: rejection with a reason (the partner is e-mailed). Approval and retry create a code for the whole shop, so AI never performs them: the request waits for a person in the app.
affiliate_code_requests_list	affiliate:read	GET /affiliate/code-requests	Partner requests for a custom discount code with state and reason; pending first.
affiliate_conversions_decide	affiliate:approve	—	write: A decision on one commission by id: approve (new → approved), reject (new → rejected, reason required), cancel (approved → cancelled, reason required); a paid commission is never reverted, the same decision twice changes nothing; the partner is e-mailed.
affiliate_conversions_get	affiliate:read	GET /affiliate/conversions/:conversionId	Detail of one conversion: amounts, commission, commission state with reason, order status in the shop, credit note, payout.
affiliate_conversions_list	affiliate:read	GET /affiliate/conversions	Affiliate conversions of a shop: commission base and order total incl. VAT, commission, commission state with reason, order status in the shop, link to the payout.
affiliate_discount_codes_ensure	coupons:write	—	write: Make sure the partner has a discount code on the shop: the scope is required, preview first, then confirmation; the coupon is created through canonical coupons (or an existing one is reused) and linked to the partner. Depends on the AI write mode (Coupons): with Manual approval a proposal is stored for a person; a code for the whole shop is always approved by a person.
affiliate_discount_codes_list	affiliate:read	GET /affiliate/discount-codes	Partner discount codes on a shop with usage count and revenue.
affiliate_documents_draft_create	affiliate:write	—	write: Proposal of a new legal document wording as a draft; the live wording is unchanged — a human publishes it in the app with a diff and audit trail.
affiliate_documents_get	affiliate:read	GET /affiliate/documents/:key/content	One legal document of the programme with wording per language (stored text, public wording, version, hashes, source, PDF metadata) and open drafts.
affiliate_documents_list	affiliate:read	GET /affiliate/documents	Programme documents (terms, agreements): confirmation policy, signed copy, e-mail attachment, versions per language, readiness and acceptance counts.
affiliate_documents_update	affiliate:write	—	write: Programme document policy (who it applies to, when it is confirmed, confirmation mode: acknowledgement / electronic signature / uploaded copy, e-mail attachment, enabled); the wording is uploaded in the app.
affiliate_email_templates_list	affiliate:read	GET /affiliate/email-templates	Partner e-mail templates per language (subject, enabled, body with an event) and automatic attachments of the Account approved e-mail.
affiliate_email_templates_update	affiliate:write	—	write: Editing a partner e-mail template in one language (subject, body) or enabling/disabling an event.
affiliate_links_generate	affiliate:read	GET /affiliate/links/generate	Tracked affiliate link to the campaign shop home, a product or a category; keeps partner attribution after the click.
affiliate_partners_get	affiliate:read	GET /affiliate/partners/:partnerId	One programme partner with the campaigns available to them.
affiliate_partners_list	affiliate:read	GET /affiliate/partners	Programme partners with state, performance and commissions; contacts only with personal data.
affiliate_partners_set_market	affiliate:write	—	write: Partner membership in a store: enable (active, also approves a portal request) or revoke; store campaigns, coupons and documents apply to the partner only with active membership.
affiliate_partners_set_state	affiliate:write	—	write: Partner account decision (approve, reject, suspend, return to waiting); approval sends the e-mail with the agreement.
affiliate_payouts_list	affiliate:read	GET /affiliate/payouts	Commission payouts to partners with state; without bank and billing data.
affiliate_portal_get	affiliate:read	GET /affiliate/portal	Public partner portal: addresses per shop, registration openness with reason, custom domains, contact person, appearance and text status per language.
affiliate_portal_pages_update	affiliate:write	—	write: Custom public portal texts in one language (login/register/dashboard pages, privacy notice, programme description); HTML is sanitised.
affiliate_settings	affiliate:read	GET /affiliate/settings	Affiliate programme settings: commissions, clicks, payout minimum, referrals.
affiliate_settings_update	affiliate:write	—	write: Non-financial programme settings: name, registration, auto-approval, contact person, colours, privacy policy link.
affiliate_signatures_get	affiliate:read	GET /affiliate/signatures/:signatureId	One electronic signature with the signed wording and value snapshot; an immutable record, the PDF is generated in the app.
affiliate_signatures_list	affiliate:read	GET /affiliate/signatures	Electronically signed partner documents (who, document, version, language, store, time, method, verification, hashes, state) and partners with a missing signature; read only — a signature is created solely in the portal.
affiliate_statistics	affiliate:read	GET /affiliate/statistics	Affiliate statistics: daily timeline, attribution sources, partner ranking.
affiliate_summary	affiliate:read	GET /affiliate/summary	Affiliate programme overview of a shop for a period: clicks, conversions, commissions, partners.
affiliate_variables_list	affiliate:read	GET /affiliate/variables	Registry of content and e-mail variables of the partner programme: canonical names, aliases, type, surfaces, example; optional text check for unknown variables.
ai_instructions_get	ai-instructions:read	—	Read the instructions of an AI module (AI Copywriter, the shop’s website chatbot, internal assistant).
brand_soul_change_draft	brand-soul:draft	—	write: A PROPOSED change to the shop heart with an expected version; only a person makes it effective by approving it in MitoOps.
brand_soul_get	brand-soul:read	—	The shop heart: the brand profile the AI tools write by, effective values for the shop with their origin, versions, a pending proposal and readiness.
analytics_advertising	reports:read	GET /analytics/advertising	Advertising: spend, budget, ROAS, cost of sale, CPA, average order value and MER with comparison; Google Ads, Meta Ads and OpenAI Ads, clicks from GA4, 6 months.
analytics_channels	analytics:read	GET /analytics/channels	Traffic channels including ChatGPT and other AI sources.
analytics_comparison	reports:read	GET /analytics/comparison	Revenue with comparison: revenue, orders, AOV, sessions, CR and AI/LLM against the previous period or year.
analytics_daily	reports:read	GET /analytics/daily	Revenue and orders by day (up to 92 days), total across shops or one shop.
analytics_funnels_catalog	analytics-funnels:read	GET /analytics/funnels/catalog	Events, parameters and user properties from the shop GA4 for setting up a funnel.
analytics_funnels_change	analytics-funnels:write	—	write: Creates, edits or archives a GA4 funnel. Preview, write with confirmation; MCP only in “Autonomous execution” mode for Funnels.
analytics_funnels_get	analytics-funnels:read	GET /analytics/funnels/:id	A funnel for a period: step visitors from GA4, purchases and revenue from orders, split by channel, comparison.
analytics_funnels_list	analytics-funnels:read	GET /analytics/funnels	GA4 funnels (for example a website quiz): steps, visitor marker, status and last import.
analytics_monthly	reports:read	GET /analytics/monthly	Revenue, orders and sessions by month (up to 24), for example year over year.
analytics_order_coverage	analytics:read	GET /analytics/order-coverage	Order coverage by tracking; without a shop, the total across shops and a per-shop breakdown.
analytics_order_heatmap	reports:read	GET /analytics/order-heatmap	When orders come in: day of week × hour, busiest day and hour.
analytics_overview	analytics:read	GET /analytics/overview	Visits, orders, revenue, conversion rate, AOV, share of AI sources.
analytics_revenue_sources	reports:read	GET /analytics/revenue-sources	Where revenue came from: channels, AI/LLM, MitoOps and affiliate subtotals, GA4 acquisition breakdown.
analytics_seo	analytics:read	GET /analytics/seo	Search Console by query or page.
approvals_pending	approvals:read	GET /approvals/pending	What awaits a person’s approval: AI steps in the AI change log and AI suggestions.
automations_catalog	automations:read	GET /automations/catalog	Automation catalogue: triggers, condition fields, operators, actions, templates and catalogVersion.
automations_create_draft	automations:write	—	write: Creates a DISABLED automation draft. Does not enable or run anything.
automations_get	automations:read	GET /automations/:workflowId	One automation with DSL and validation result.
automations_list	automations:read	GET /automations	The client’s automations with state and shop scope.
automations_options	automations:read	GET /automations/options	Option list for an automation field (statuses, shipping, payments, templates, claims…): the DSL value and a name.
automations_revision_create_draft	automations:write	—	write: Proposes a change to a published automation as a revision for a person to approve; the running version does not change.
automations_revision_discard_draft	automations:write	—	write: Withdraws an open revision of a published automation.
automations_revision_update_draft	automations:write	—	write: Updates an open revision of a published automation.
automations_runs	automations:read	GET /automations/:workflowId/runs	Run history of one automation.
automations_templates	automations:read	GET /automations/templates	Ready-made automation templates with DSL.
automations_update_draft	automations:write	—	write: Updates an unpublished automation draft with optimistic concurrency.
automations_validate_draft	automations:read	—	Validates an automation draft without writing.
campaigns_discount_compute	campaign-rules:read	GET /campaigns/discount-compute	Real discount off the full price for a sale and a code (they multiply), or the missing part for a target discount; compared with the store limit.
campaigns_discount_rules	campaign-rules:read	GET /campaigns/discount-rules	Discount rules of the stores: whether the limit is on, the maximum combined discount off the full price, scope, mode and partner commission.
campaigns_discount_rules_configure	campaign-rules:write	—	write: Changes a store’s discount rule: first a before and after preview, written only after confirmation. Existing codes and prices stay unchanged.
chatbot_conversations_get	chatbot-conversations:read	GET /chatbot/conversations/:sessionId	Transcript of one web chatbot conversation including the sources of the bot’s answers.
chatbot_conversations_list	chatbot-conversations:read	GET /chatbot/conversations	Customer conversations with the web chatbot from the most recently active, with the first question; cursor.
chatbot_outcomes	chatbot:read	GET /chatbot/outcomes	How web chatbot conversations ended: since when the outcome is measured, measured and unmeasured conversations, known and unknown outcome, resolved, unresolved, bot error and resolution rate with its denominator; N/A with a reason when the denominator is zero. Totals only.
chatbot_stats	chatbot:read	GET /chatbot/stats	Web chatbot statistics for a period: the teaser funnel from a single measurement (older counts come alongside as historical), chat open rate, conversations, conversation-level outcome, ratings.
chatbot_topics	chatbot:read	GET /chatbot/topics	What the conversations were about: topic shares from a closed taxonomy, resolution rate and knowledge-gap candidates per topic, the most frequent products, the start page type and a day-by-day trend. Shares are computed from the analysed conversations and that count is returned too. Totals only.
claims_config_change_draft	claims-settings:draft	—	write: Proposes a change to claim processes, statuses, tags, templates, form texts and module settings; a person writes it by approving it in the app.
claims_config_draft_get	claims-settings:read	GET /claims/config-drafts/:draftId	Status of a proposed claim settings change (pending, written, rejected).
claims_configuration	claims-settings:read	GET /claims/configuration	Claim settings: tags, fields, return shipping, the shop form and form types.
claims_deadlines	claims:read	GET /claims/deadlines	Open claims by deadline: overdue and due soon, most urgent first, with counts per shop.
claims_get	claims:read	GET /claims/:code	One claim with items, refunds, return shipments, tags, timeline and sent e-mails.
claims_list	claims:read	GET /claims	Claims and returns of one shop with links to the order.
claims_refund_options	claims-settings:read	GET /claims/refund-options	Refunds: variable symbol source, refund coupon validity, coupon in the form, when the form asks for an account number.
claims_refund_readiness	claims:read	GET /claims/:code/refund-readiness	Claim before a refund: what the customer requests, masked account, variable symbol, mode and whether the claim can be deleted.
claims_refund_settings	claims-settings:read	GET /claims/refund-settings	Claim refunds: mode, bank accounts with payment-order eligibility (masked), default and manual account.
claims_routes	claims-settings:read	GET /claims/routes	Claims return shipping: routes, addresses, carrier profiles with IDs and return support, case types.
claims_routes_change_draft	claims-routes:draft	—	write: Proposes a return route (also for the whole EU or world) and a recipient address; a person writes them by approving (or autonomous writing, if the client switched it on).
claims_settings	claims:read	GET /claims/settings	Claim processes with IDs and names (types, steps, statuses, deadlines), tags; module settings with the claims-settings:read scope.
claims_statistics	claims:read	GET /claims/statistics	Claims and returns statistics for a period: counts, resolution times, types, ratings, reasons.
claims_templates	claims-settings:read	GET /claims/templates	Claim e-mail templates (subject, text, when and whether they are sent automatically) and document templates.
content_articles_search	products:read	GET /content/articles	Blog articles and shop content from the canonical mirror by title or text.
coupons_activation_link	coupons:read	GET /coupons/activation-link	A link that applies an EXISTING coupon in the customer’s cart. Does not create coupons.
coupons_activation_status	coupons:read	GET /coupons/activation-status	Whether a coupon can be used on the shop via the activation link: coupon mirror + web code status.
coupons_capabilities	coupons:read	GET /coupons/capabilities	What the shop’s platform can do with coupons. Read before creating.
coupons_ensure	coupons:write	—	write: Make sure the coupon exists on selected shops; the scope (categories, products or explicitly the whole shop) is required, preview first, then confirmation. With a different discount it is NOT overwritten. Depends on the AI write mode (Coupons): with Manual approval a proposal is stored for a person; a coupon for the whole shop is always approved by a person.
coupons_get	coupons:read	GET /coupons/:code	One coupon by code.
coupons_list	coupons:read	GET /coupons	The shop’s discount coupons with discount type and amount, validity and derived state.
coupons_remove	coupons:delete	—	write: Irreversible deletion of a coupon on the selected shop: without confirmation only a preview with dependencies, with confirmation the deletion; a coupon with a live dependency is not deleted. Depends on the AI write mode (Coupons): with Manual approval a proposal is stored for a person.
coupons_templates_cleanup	coupons:delete	—	write: Cleans up unused coupon templates created by MitoOps on the shop; the merchant’s templates and templates in use stay. Preview, deletion with confirmation. Depends on the AI write mode (Coupons): with Manual approval a proposal is stored for a person.
coupons_update	coupons:write	—	write: Explicit update of an existing coupon including product and category restrictions; preview, then confirmation. Depends on the AI write mode (Coupons): with Manual approval a proposal is stored for a person; a coupon for the whole shop is always approved by a person.
coupons_web_box_overview	coupons:read	GET /coupons/web-box	Price-after-code boxes next to products on the shop: main switch, coupons, settings and state.
coupons_web_box_preview	coupons:read	—	Shows how a product card on the website will look with the price-after-code box under the proposed settings; read-only, changes nothing.
coupons_web_box_set	coupons:write	—	write: Turns on, off or edits the price-after-code box for an existing coupon; preview, then confirmation. Depends on the AI write mode (Coupons): with Manual approval a proposal is stored for a person.
coupons_web_box_stats	coupons:read	GET /coupons/web-box/stats	Box views, code copies and cart applications by coupon and product.
customers_get	customers:read	GET /customers/:customerKey	One customer from the directory — identity, shops, lifetime and optional period money, broken down per shop.
customers_list	customers:read	GET /customers	Customer directory: identity (with personal-data masking), shops, language, lifetime counts and revenue by currency; optional purchase-activity filter for a period.
customers_performance	reports:read	GET /customers/performance	Customers as pseudonyms: orders, revenue, LTV, new and returning.
credit_notes_search	invoices:read	GET /credit-notes	Search in credit notes.
documents_list	invoices:read	GET /documents	Accounting documents of one type (invoices, proforma invoices, credit notes) page by page with lifecycle, source state, validity filter and PDF availability.
documents_pdf_link	invoices:read	—	Short-lived link (10 minutes) to the PDF of an invoice, proforma invoice or credit note to open in a browser.
invoices_get	invoices:read	GET /invoices/:invoiceCode	One invoice with document items, credit notes, proforma invoices and the order number.
invoices_search	invoices:read	GET /invoices	Search in invoices; a payment filter (paid, unpaid, overdue) with count and total per shop.
payments_matching	payments:read	GET /payments/matching	Matching of received payments to orders: counts by result and unmatched, ambiguous and failed payments.
inventory_movements	inventory:read	GET /inventory/movements	History of stock movements: when, what, how much, kind, origin, order.
inventory_product_availability	inventory:read	GET /inventory/availability	Stock level of several items at once.
inventory_product_statistics	inventory:read	GET /inventory/product-statistics	Per product for a period: stock level, units sold, units claimed as faulty and returned, claim rate.
inventory_stock	inventory:read	GET /inventory/stock	Stock level of one item including the source of the value.
inventory_sync_status	stock-sync:read	GET /inventory/sync-status	Stock synchronisation status between shops: queue, conflicts, last run and reconciliation, mapping, connection health.
inventory_valuation	inventory:read	GET /inventory/valuation	Stock value as on screen: purchase and sale value, gross and net potential, below minimum, negative, largest items; without sets and bundles.
messaging_deliveries	messaging:read	GET /messaging/deliveries	Delivery of e-mails about shipments, orders, claims and partners: summary, statuses and errors (bounced, spam, blocked).
notifications_list	notifications:read	GET /notifications	Notifications from the bell: what modules report, severity, status, unread count and the screen that resolves it.
orders_get	orders:read	GET /orders/:orderCode	One stored order including items.
orders_line_discounts	orders:read	GET /orders/:orderCode/line-discounts	Historical prices and discounts per order line: original price, discount, coupon, amount paid and confidence.
orders_list	orders:read	GET /orders	Stored orders, newest first; status filter, search, payment, period and the full count in the filter.
orders_packing_queue	orders:read	GET /orders/packing-queue	Packing queue by the statuses the client set as ready to pack: count and orders per shop.
availabilities_change_draft	availabilities:draft	—	write: A PROPOSED change to the availability list (create, update, delete). A person writes it to the shop by approving it in MitoOps.
availabilities_draft_get	products:read	GET /availabilities/drafts/:draftId	Status of a proposed availability list change: awaiting approval, written with a result, rejected, expired.
availabilities_history	products:read	GET /availabilities/history	Availability synchronisation history: what was carried from which shop to which, with the result; period, cursor.
availabilities_list	products:read	GET /availabilities	The shop’s availability list: name, description, restock and delivery time, Google meaning, colour, default role.
availabilities_pairing	products:read	GET /availabilities/pairing	Availability matching between shops: rows with each shop’s item, suggestions, unmatched items, synchronisation status.
availabilities_pairing_change_draft	availabilities:draft	—	write: A PROPOSED change to availability matching (a cell, a custom row). A person saves it by approving it in MitoOps; it never switches synchronisation on.
availabilities_pairing_draft_get	products:read	GET /availabilities/pairing-drafts/:draftId	Status of a proposed availability matching change: awaiting approval, saved, rejected, expired.
catalog_reconcile	products:write	—	write: Reconciles the catalog mirror with the shop: products and categories the shop demonstrably no longer has (two independent observations) get a tombstone in MitoOps. Preview with evidence, write with confirmation.
categories_content_change_draft	category-content:draft	—	write: PROPOSED new category texts (up to 30 at once); a person writes them to the shop by approving them in MitoOps.
categories_content_draft_get	category-content:read	GET /catalog/category-content-drafts/:draftId	Status of a category text proposal: awaiting approval, written, rejected, expired.
categories_content_get	category-content:read	GET /categories/:guid/content	A category’s texts (top and bottom description, SEO title and description) with a hash and field writability.
categories_create	categories:write	—	write: Creates a store category (hidden by default). Preview first, write with confirmation.
categories_get	category-content:read	GET /categories/:guid	One category with live state from the shop including visibility (true/false, null = the platform does not track it) and from–to schedules.
categories_list	products:read	GET /categories	Shop categories with product counts, paged with a full count.
categories_products_assign	product-categories:write	—	write: Adds products to a category or removes them in bulk (a list of codes or a one-time copy from a source category). Preview with counts, write with confirmation, per-product result and retry of failed items.
categories_products_list	products:read	GET /categories/:guid/products	Products assigned to a category, paginated, live from the shop (during an outage from the mirror with the source marked).
categories_remove	categories:write	—	write: Deletes only an empty category (no products or subcategories), otherwise recommends hiding it. Preview, write with confirmation.
categories_update	categories:write	—	write: Edits a category: name, parent, address, visibility, texts, SEO and image; changed fields only. Before and after preview, write with confirmation.
categories_visibility_plan	categories:write	—	write: A from–to visibility schedule for a category, or cancelling it. Preview, write with confirmation.
categories_visibility_plans_list	category-content:read	GET /categories/visibility-plans	Category from–to visibility schedules: time, state, original visibility, last write and error.
product_logistics_get	product-logistics:read	GET /product-logistics/:code	Weight and dimensions of a variant’s sales packaging live from the shop (kg, cm), inherited fields, revision and recent writes.
product_logistics_list_missing	product-logistics:read	GET /product-logistics/missing	Shop codes without weight or dimensions (or with unverified units); with codes, values from the copy with source and certainty.
product_logistics_update_confirmed	product-logistics:write	—	write: Writes the weight and dimensions of a variant’s sales packaging to the shop after a preview with confirmation and revision; read back from the shop.
product_logistics_update_preview	product-logistics:read	—	Preview of a weight and dimensions change without writing: before and after, warnings (units, checkout shipping, 30 kg), revision.
products_availability_update	product-stock:write	—	write: Changes product availability in stock and when sold out and ordering when sold out; not the quantity. Preview, write with confirmation.
products_categories_get	products:read	GET /products/:code/categories	All categories of a product per shop, live from the shop: main and additional assignments including hidden categories.
products_categories_update	product-categories:write	—	write: Adds and removes additional categories of a product and optionally changes the main one; other assignments are kept. Before and after preview, write with confirmation.
products_category_assign	product-categories:write	—	write: Changes a product’s main category in the chosen shops. Before and after preview, write with confirmation.
products_changes	products:read	GET /products/changes	Product card change log: field, shop, when, where from and a preview of the old and new value; prices only with permission.
products_content_change_draft	product-content:draft	—	write: PROPOSED new product texts (up to 30 at once); a person writes them to the shop by approving them in MitoOps.
products_content_draft_get	product-content:read	GET /catalog/product-content-drafts/:draftId	Status of a product text proposal: awaiting approval, written with shop warnings, rejected, expired.
products_content_get	product-content:read	GET /products/:code/content	A product’s texts from the shop (description, short description, SEO title and description) with a hash and field writability.
products_content_policy	product-content:read	GET /product-content/policy	Content policy for a shop without calling the shop: what this access may read and propose, which fields the platform writes, the approval mode and autonomous writing, limits and hashes.
products_create	products:write	—	write: Creates a new product in the chosen shops, always HIDDEN; a person publishes it. Preview, write with confirmation.
products_gallery_edit	product-gallery:write	—	write: Product gallery as in the editor: add from an https address, replace, remove, order, main image, description. Preview, write with confirmation.
products_get	products:read	GET /products/:code	One product by code including category and the price from the card.
products_offer	products:read	GET /products/:code/offer	The product offer in the shop: whether the shop still has it, visibility, orderability, availability and the price with currency, VAT and the price in the shop’s selling currency.
products_prices_update	product-prices:write	—	write: Changes product prices (price, crossed-out, sale with from and to dates, ratio; purchase price only with permission). Before and after preview, write with confirmation.
products_remove	products:write	—	write: Irreversible deletion of a product, only one that is live hidden, without stock and without sales (for example a test product). Preview, deletion with confirmation.
products_search	products:read	GET /products	Product search by name, code, EAN or PLU; category, active and below-minimum filters with a full count; shop state, products deleted in the shop only on request.
products_update	products:write	—	write: Edits a product in the chosen shops: name, texts and SEO, identifiers and manufacturer details; not prices, availability or category. Before and after preview, write with confirmation.
products_visibility_get	products:read	GET /products/:code/visibility	Live product state per shop: visibility (including the raw platform state), orderability and indexability read-only, running from–to schedule.
products_visibility_plans_list	products:read	GET /catalog/products/visibility-plans	Product from–to visibility schedules: time, state, original shop state, last write, error and the last scheduler run.
products_visibility_plan	product-visibility:write	—	write: A product from–to visibility schedule or its cancellation with a mode (safe publishes nothing). Preview, write with confirmation.
products_visibility_update	product-visibility:write	—	write: Hides or shows a product in the chosen shops; does not change orderability or indexing. Preview from the live state, write with confirmation and a read-back.
reports_cost_groups	reports:read	GET /reports/cost-groups	Cost categories and tags and the group layout in Costs.
reports_costs_change	report-costs:write	—	write: Creates, edits or retires a manual cost. Preview, write with confirmation; executed by the assistant after the card is approved or by MCP in “Autonomous execution” mode for Costs.
reports_costs_list	reports:read	GET /reports/costs	Manual and automatic costs with the amount counted in the period; company-wide and per shop.
reports_export_create	report-exports:write	—	write: Generates a report (xlsx, docx, pdf) for a period; returns runId, the file is downloaded over REST. Changes no data.
reports_financial_summary	reports:read	GET /reports/financial-summary	Financial summary of a period; with purchase-prices:read also cost of goods, gross profit and margin.
reports_history_get	reports:read	GET /reports/history/:runId	Status of one export and its files with the REST download address.
reports_history_list	reports:read	GET /reports/history	History of generated reports with files, size and SHA256.
reports_layout_get	reports:read	GET /reports/layout	Report export layout: cover, order and inclusion of sheets and sections, page breaks.
reports_layout_update	reports:write	—	write: Saves the export layout (order and inclusion of sheets and sections). Preview, write with confirmation.
reports_notes_get	reports:read	GET /reports/notes	The report note that goes into the Word and PDF report.
reports_notes_update	reports:write	—	write: Replaces the report note (HTML is sanitised). Preview, write with confirmation.
reports_order_status_rules	reports:read	GET /reports/order-status-rules	Which order statuses count towards revenue, per shop, with the count and revenue in each status.
reports_summary_all	reports:read	GET /reports/summary-all	Summary of several shops as with “All”: total, breakdown per shop, company-wide costs once, computedAt and dataAsOf.
sales_order_performance	reports:read	GET /sales/order-performance	Revenue per order with totals for the whole period; with purchase-prices:read also cost, profit and margin.
sales_product_performance	reports:read	GET /sales/product-performance	Sales per product with totals for the whole period.
reviews_get	reviews:read	GET /reviews/:kind/:reviewId	One review with its reply history, the shop’s language, tone and signature, and a pending proposed reply.
reviews_list	reviews:read	GET /reviews	Shop and product reviews of one shop: stars, text, product, the shop’s reply, a pending proposal; filters and period.
reviews_reply_create_draft	reviews:draft	—	write: A PROPOSED reply to a review. A person publishes it by approving it in MitoOps (or autonomous mode, if the owner switched it on).
reviews_reply_draft_get	reviews:read	GET /reviews/reply-drafts/:draftId	Status of a proposed review reply: awaiting approval, published, rejected, expired.
reviews_statistics	reviews:read	GET /reviews/statistics	Review statistics of a shop for a period: count, unanswered, average, count by stars and by kind.
reviews_web_overview	reviews:read	GET /reviews/web-display	Review block on the product page (website script): whether it is on, platform support and settings.
reviews_web_set	reviews-web:write	—	write: Turns the review block on the product page on, off or edits it; preview, then confirmation. Writes nothing to the shop.
search_console_query	search-console:read	GET /search-console/query	Search Console by day, query, page, country and device, with pagination and a content hash.
search_console_status	search-console:read	GET /search-console/status	Search Console status of a shop: connection, property, permission level, sync and archive range.
shipping_carriers	shipping:read	GET /shipping/carriers	Connected carriers and profiles, without credentials.
shipping_overview	shipping:read	GET /shipping/overview	Shipping overview: to pack, awaiting hand-over, in transit, carrier errors, cash on delivery, broken down per shop.
shipping_packing_performance	shipping:read	GET /shipping/packing-performance	Packing performance per person: orders packed, packing time (average and median), time to pack and to hand-over, comparison with the team.
shipping_pickups	shipping:read	GET /shipping/pickups	Courier pickups per carrier: order-by and latest pickup time, what is waiting for pickup and booked pickups.
shipping_returns	shipping:read	GET /shipping/returns	Return shipments with status and claim, totals in transit and open per shop.
shipping_shipment_detail	shipping:read	GET /shipping/shipments/:shipmentId	One shipment with all tracking events.
shipping_shipments	shipping:read	GET /shipping/shipments	Shipments with carrier, country, hand-over and delivery time, paged.
shipping_stats	shipping:read	GET /shipping/stats	Delivery statistics per carrier: counts, success rate, median and p90 delivery time, countries.
stores_integration_status	stores:read	GET /stores/integration-status	MitoOps web code status per shop: installed, version, modules, readiness of coupon-from-link.
stores_list	stores:read	GET /stores	The client’s shops with their code.
purchasing_advisor	purchasing:read	GET /purchasing/advisor	Purchase proposal: what to reorder and how much, urgency, stock, minimum and projected need; globally for one warehouse.
suppliers_get	purchasing:read	GET /suppliers/:supplierId	One supplier with offers and cost components.
suppliers_list	purchasing:read	GET /suppliers	Suppliers with offers and cost components, paged with a full count.
webhooks_deliveries	webhooks:read	GET /webhooks/endpoints/:endpointId/deliveries	Delivery log of one endpoint without bodies.
webhooks_endpoint	webhooks:read	GET /webhooks/endpoints/:endpointId	One webhook endpoint with the number of pending deliveries.
webhooks_endpoints	webhooks:read	GET /webhooks/endpoints	The client’s webhook endpoints without secrets and the queue state.
webhooks_events	webhooks:read	GET /webhooks/events	The catalogue of outbound webhook events, envelope and signature.

The customer’s name, e-mail, phone and street appear in orders_list, orders_get, claims_list and claims_get only with the personal-data:read scope; without it the response carries the country and city. The same applies to supplier and affiliate partner contacts (affiliate_partners_*). The scope has no tool of its own.

In the customer directory (customers_list, customers_get) the same scope governs the name, company, e-mail, phone and marketing gender; without it what remains is the pseudonym, shops, country, language, counts and dates. Revenue and LTV sit behind reports:read on top of that. Marketing gender is an inference from the first name (genderSource: "name_inference"), not something the customer stated — and an assistant should present it that way. Bank and tax data of partners are never returned.

Web chatbot — conversation topics. chatbot_topics (the same chatbot:read scope) answers “what were they about?” in a single call: the share of conversations per topic from a closed taxonomy, the resolution rate and the number of knowledge-gap candidates per topic, the most frequent products (asked about by customers and recommended by the bot), the type of page the conversations start from and a day-by-day trend. The evaluation is deterministic, so two calls over the same period return the same numbers. It returns totals only — customer text never reaches it, not even as a “most frequent question”. Every share comes with its count. chatbot_conversations_list gained topic and knowledgeGapCandidate filters; the transcript of a specific conversation stays behind the sensitive scope and within the retention window.

Web chatbot. Statistics (chatbot_stats, scope chatbot:read) return totals only: how many page visits saw the teaser and how many clicked it, window opens, conversation and message counts, what the bot resolved, customer ratings and the newsletter sign-up funnel. Customer conversations (chatbot_conversations_list, chatbot_conversations_get) sit behind their own sensitive scope chatbot-conversations:read, which you tick deliberately on the consent screen: the customer is only a random conversation key in the records (no IP, cookie, name or e-mail); an e-mail, phone or IBAN the customer typed into the text is returned only with personal-data:read — otherwise the assistant sees the placeholders [e-mail], [telefón], [iban]. Conversations are returned only within the shop’s retention (the History setting in the AI centre); a shop with retention zero returns nothing. Until 21 Sep 2026 teaser impressions were counted on every pop-up of the message; since 22 Sep 2026 an impression is one page visit and measurementChanges in the response says whether the chosen period mixes both measurements.

Every tool has a REST counterpart over the same capability. The envelopes differ, the business data is identical. Period, pagination and the meaning of the financial fields are described in the REST interface.

Summary tools (shipping_stats, analytics_*, reports_financial_summary) return finished figures from the application — the assistant does not have to download thousands of records and compute them itself. Raw listings (shipping_shipments, orders_list) remain for drill-down.

What you can ask

Once connected, Claude.ai answers from MitoOps data, for example:

• “What was the carrier split in August?” — shipping_stats
• “What was the median delivery time of DHL and GLS?” and “How many were undelivered or returned?” — shipping_stats
• “Which countries did we ship to via DHL?” — shipping_stats (field countries)
• “What were revenue and conversion rate in August?” — analytics_overview or reports_financial_summary
• “How many orders and how much revenue came from ChatGPT?” — analytics_channels
• “Which queries had the highest CTR?” — analytics_seo
• “What is the margin of product X last month?” — sales_product_performance (with purchase-prices:read)
• “What did customers ask the chatbot most this month, and what should the next blog article cover?” — chatbot_conversations_list and chatbot_conversations_get (with chatbot-conversations:read)
• “How many conversations did the chatbot handle and how many did it resolve without support?” — chatbot_stats
• “Which availabilities does the SK shop have and which are the defaults?” (availabilities_list)
• “Add a Preorder October availability to the SK shop, meaning preorder, delivered within 14 days” (availabilities_change_draft with availabilities:draft; a proposal is created, which you write by approving it in the app)
• “Which availabilities on the CZ shop are not matched with SK?” (availabilities_pairing)
• “Which 5★ reviews on the SK shop have we not replied to yet? Prepare replies.” (reviews_list, then reviews_reply_create_draft with reviews:draft; this creates proposals you publish by approving them in the app)
• “Change the enabled automation 12 so that it only notifies for the Courier shipping method” (automations_options for shipping, then automations_revision_create_draft; the running version stays unchanged until you publish the revision in the editor)
• “Which claim e-mails are sent automatically and what do they say in German?” (claims_templates with claims-settings:read)
• “Rename the claim status Waiting for goods to Waiting for the parcel” (claims_settings for the ID, then claims_config_change_draft with claims-settings:draft; you write it by approving it in the app)

Reading and narrow writes: automations, coupon, affiliate programme, availability, claims

Operational data (orders, stock levels, products, documents, shipments) is read-only over MCP. Every write sits behind its own sensitive scope: an automation draft, a discount coupon, affiliate programme management, a commission decision, a proposed change to the availability list, which a person writes to the shop, and a proposed change to the claims settings, which a person also has to approve.

Automation draft — with the automations:write scope it is a disabled draft: with the automations:write scope the assistant can design a rule from the catalogue (automations_catalog) and save it as a draft, or edit a draft nobody has published yet. The draft appears in Automations like any other work in progress — only you can enable, publish or run it in the application. The assistant cannot change a published automation directly.

Revision of a running automation. With automations:write the assistant can also change a published, enabled automation, but only as a proposal: automations_revision_create_draft (input workflowId, expectedPublishedVersion from automations_get, catalogVersion, the complete new dsl, note and clientRequestId) stores a revision next to the running version. The running automation does not change and keeps working. An automation has at most one open revision; it is edited with automations_revision_update_draft and expectedRevisionVersion and discarded with automations_revision_discard_draft. The response carries approvalUrl, a link to the automation editor. There a person allowed to edit automations sees the revision in the top panel, loads it into the editor (Load proposal into editor), reviews it and publishes it with the usual button; the automation stays enabled. Or they reject it. If someone published another version in the meantime, the revision is closed (REVISION_STALE) and a new one has to be prepared. automations_get returns the open revision and the history (openRevision, revisions).

Option lists and value checks. Fields picked from a list in the editor (order status, shipping, payment, carrier profile, notification template, claim type, status, tag and templates, webhook endpoint and more) have a source in the catalogue. automations_options with source and market returns their values [{ value, name }] in exactly the shape the editor stores (status ID, shipping and payment GUID, claim status ID); without source it lists the sources and whether they differ per shop (perShop). Validation (automations_validate_draft) and saving a draft or revision reject a value that does not exist in the shop (FIELD_UNKNOWN_OPTION) and placeholder text such as DOPLNIT_… or TODO (FIELD_PLACEHOLDER). When the list cannot be checked (the shop did not answer, the list is truncated), only a FIELD_OPTIONS_UNVERIFIED warning is returned. orders_get and orders_list carry statusId, shippingGuid and paymentGuid, the same values automation conditions work with.

The automations:write scope is sensitive: it is not pre-checked on the consent screen, it is offered only to a person allowed to edit automations, existing connections do not inherit it and a token refresh cannot widen it. Orders, products, stock levels, documents, refunds, claim cases and shipments cannot be changed over MCP; a shop’s availability list and the claims settings change only through a proposal that a person approves in the app (below). Webhook endpoints are read-only over MCP. Credentials for carriers, the shop or analytics cannot be read over MCP.

Discount coupon — with the coupons:write scope the assistant creates a coupon from the parameters you give it (coupons_ensure, including a partner coupon via affiliate_discount_codes_ensure) and explicitly updates an existing one (coupons_update, preview and confirmation); deletion has its own coupons:delete scope and a coupon with a live dependency is not deleted.

Affiliate programme management — with the affiliate:write scope the assistant decides on a partner account (affiliate_partners_set_state: approve, reject, suspend; the partner receives an e-mail, with the agreement PDF according to the document policy), handles a custom code request (affiliate_code_requests_decide), updates non-financial programme settings (affiliate_settings_update: name, registration, contact person, colours), portal texts in one language (affiliate_portal_pages_update), help articles (affiliate_articles_create, affiliate_articles_update including restoring the default wording, affiliate_articles_set_state; no deletion from outside), e-mail templates (affiliate_email_templates_update), campaigns (affiliate_campaigns_create, affiliate_campaigns_update), document policy (affiliate_documents_update) and partner store membership (affiliate_partners_set_market: enable or revoke). It reads legal document wording (affiliate_documents_get: text per language, version, hashes, drafts) and proposes new wording only as a draft (affiliate_documents_draft_create; privacyNotice in affiliate_portal_pages_update is a draft as of this version too) — a human publishes the live wording in the app with a diff and audit trail. The registry of content and e-mail variables (canonical names, aliases, type, surfaces) comes from affiliate_variables_list; affiliate_email_templates_list returns variable names, not indexes. Payouts, the commission base and document file upload do not exist over MCP — they stay in the app.

Commission decisions — with its own sensitive scope affiliate:approve (the commission approval right, not programme management) the assistant first reads pending commissions together with the order status in the shop (affiliate_conversions_list with state=new, detail affiliate_conversions_get: commission base revenue, order total incl. VAT revenueTotal, orderState open/completed/cancelled, orderPaid, credit note), summarises them and only on the user’s explicit instruction decides on one specific conversion (affiliate_conversions_decide: approve, reject or cancel; rejection and cancellation require a reason the partner receives by e-mail). The same state machine as in the app applies: a paid commission is never reverted, cancelled and rejected are terminal, the same decision twice changes nothing (changed: false). Bulk approval does not exist externally — a hundred conversions means a hundred calls, each audited. Since W-AFF10 every conversion also carries approvalPolicy (the campaign’s approval mode, period, allowed order statuses, payment requirement) and approvalEligibility — whether the hourly automation would approve it right now and why not (minimum_age_not_reached, order_state_not_allowed, order_not_paid, order_cancelled, fully_refunded, approval_manual…), the same calculation as in the app; the list has the filters orderPaid, minCommission, orderState and paging with offset + hasMore, so “go through new conversions of the last two months, show the unpaid ones or those above €20” is one or a few reads. Campaign conditions are set with affiliate_campaigns_update (approval, approveAfterDays, requiredOrderStatusIds, paidRequired) under the affiliate:write scope. Payouts to partners are read-only through MCP (affiliate_payouts_list) — the assistant cannot create a payout batch, generate its document, send it to the partner or submit a bank order; that stays in the app under the operator’s hand.

Proposed change to the availability list. With the sensitive availabilities:draft scope the assistant prepares a proposal to create, update or delete availabilities on one shop (availabilities_change_draft, MCP only). It writes nothing to the shop: it validates the proposal, stores it in MitoOps for 24 hours and returns the draftId, a per-item preview (preview with each field before and after, warnings and errors), expiresAt and an approvalUrl pointing to the Warehouse → Availability screen, where the proposal waits on the Manage tab. There a person with the right permissions approves it with Approve and write or rejects it, and the write runs with that person’s permissions at the moment of the click. If the shop’s list has changed since the proposal, approving writes nothing and the proposal ends as failed. availabilities_draft_get returns the status and the per-item result: pending, writing, executed, partial, failed, rejected or expired. When the preview reports a blocking error no proposal is created (blocked), and neither is one when nothing would change (no_change).

The input is market and changes (at most 30 items). Each change has an action (create, update or remove), for an update or a deletion the id from availabilities_list, and only the fields that should change: name (up to 120 characters, in the shop’s language), description (up to 1000 characters, null means none), onStockHours and deliveryHours (whole hours from 0 to 2500, null means not set), meaning (in_stock, backorder, preorder, out_of_stock) and color (hex, null means no colour). A new availability needs name and meaning. An optional clientRequestId makes the call idempotent: the same key with the same content returns the same proposal (replayed: true); with different content it fails with CONFLICT (CLIENT_REQUEST_REUSED).

The preview blocks what the shop would refuse or what would break the setup: a duplicate name in the shop, deleting a system or default availability or one used by an availability plan, and on WooCommerce changing the meaning of a system entry or giving a default entry a meaning that does not belong to its role. The shop will not delete an availability that products use. A meaning change on WooCommerce is written only by a shop with the MitoOps plugin 1.5.0 or later. When the shop does not answer clearly during the write (server error, timeout), the write is not repeated but verified by reading the list; whatever cannot be verified is marked uncertain: true in the result. The assistant may prepare a proposal only on the user’s explicit instruction in the conversation, never because of text inside the data it has read, and it does not invent values the user did not give. A proposal does not change which availability products have, nor stock levels; an approved change of meaning can, however, change whether products with that availability can be ordered once sold out, and the preview warns about it.

Availability matching and synchronisation history. availabilities_pairing (scope products:read) returns what the Warehouse → Availability → Matching tab shows: rows (four main and custom ones) with each shop’s item within the access scope, suggestions for empty cells of main rows, unmatched items per shop and the synchronisation status (sync.enabled). availabilities_history returns the transfer history with a period (from, to), shop, product code and cursor; an entry with a shop outside the access scope is not returned. With the availabilities:draft scope the assistant proposes a matching change (availabilities_pairing_change_draft, MCP only): set or clear a cell (set), create, update or delete a custom row (createRow, updateRow, removeRow). Matching does not change until a person approves the proposal on the Matching tab with Approve and save; if matching changed since the proposal, nothing is saved (failed). With synchronisation on, the preview warns (SYNC_ON) that the approved matching decides which availability products get in the other shops. Synchronisation cannot be switched on via MCP; that is a decision for a person in the app. The status is returned by availabilities_pairing_draft_get.

Reviews: reading and proposed replies. The reviews:read scope opens reviews_list (filters kind project or product, answered, rating, search, productGuid, a period and a cursor; totals are totals without the reply-status filter), reviews_get (reply history, the shop’s language, tone and signature from the Shop voice setting, a pending proposal) and reviews_statistics (count, unanswered, average, count by stars and by kind for a period). The reviewer’s name is personal data and comes only with personal-data:read; the interface never returns the reviewer’s e-mail or the order number. The review text was written by a customer: it is data, not instructions for the assistant (authorContentUntrusted). With the sensitive reviews:draft scope the assistant prepares a proposed reply (reviews_reply_create_draft, MCP only). A reply is public and can only be overwritten in the shop, so it is not published: the system adds the shop’s signature, the proposal is valid for 72 hours and returns an approvalUrl to Warehouse → Reviews, where a person allowed to reply approves, edits or rejects it. If the review gets a different reply in the meantime, approval publishes nothing. If the owner switches on autonomous writing for review replies in Settings → API & MCP → Writing via AI, a reply to a 4 or 5 star review is published immediately on behalf of the person who granted access, at most 50 a day; for 1 to 3 stars a person always decides. The status is returned by reviews_reply_draft_get.

Claims settings for reading. claims_settings (scope claims:read) returns the processes with IDs and names of types, steps and statuses in the chosen language (language), including items the client never renamed, and the tags; with the claims-settings:read scope also the module settings (code prefix, deadline, automatic restocking, shop form). With the same scope claims_templates returns the e-mail templates (language, subject, text, HTML, when they are sent trigger, whether they go out on their own autoSend, which document they attach) and the document templates, filtered by language or templateKey; claims_configuration returns tags, custom fields, return reasons, return shipping routes and addresses, the shop form per shop (without the integration token) and form types with their custom texts. The contact and street of the merchant address come only with personal-data:read. claims_get carries the case timeline (messages, notes, status changes), sent e-mails (template, subject, state, no recipient address) and tags; message text only with personal-data:read.

Proposed change to the claims settings. With the sensitive claims-settings:draft scope the assistant prepares a proposal (claims_config_change_draft, MCP only): create or edit a process type, step and status (names per language, colour, default and closing status, deadline), a tag, the text of an e-mail template in one language, its automatic sending and the text of a document template. There is no deletion. It writes nothing to the settings: it checks the proposal with the same rules as the screen (an unknown variable in a template blocks it, for example), stores it in MitoOps for 72 hours and returns draftId, a preview (preview, field before and after, errors), expiresAt and approvalUrl, a link to Claims → Settings, where the proposal waits in the Change proposals awaiting approval panel. A person allowed to manage the settings approves it (Approve and write) or rejects it. The proposal is written in full or not at all: if any value changed since the proposal was prepared, nothing is written and the proposal ends as failed. claims_config_draft_get returns the state (pending, executed, failed, rejected, expired); when the preview reports an error no proposal is created (blocked), and none either when nothing changes (no_change). The assistant takes IDs and keys from claims_settings and claims_templates; clientRequestId makes the call idempotent.

Recipes. The server offers the MCP prompts sales_drop_diagnosis, winback_campaign, weekend_promotion and campaign_360 (a campaign with a hidden category, products, banner, coupon and from–to display). A recipe is only a procedure: it tells the assistant which tools to use and in what order. It carries no extra permission; every step goes through the scope, plan and confirmation of its own tool.

Tools carry annotations per the protocol revision (readOnlyHint, destructiveHint, idempotentHint); automations_create_draft is idempotent through clientRequestId, automations_update_draft requires expectedVersion and returns CATALOG_CHANGED when the catalogue changed; automations_revision_create_draft is idempotent through clientRequestId and automations_revision_update_draft requires expectedRevisionVersion.

Consent can be revoked

Revoking the consent under Settings → API & MCP ends every access created from it — immediately, not on expiry. The same happens when you disconnect the connector in Claude.ai.

Protocol revisions

The server speaks revision 2026-07-28 as well as older ones (2025-11-25, 2025-06-18, 2025-03-26). The client chooses by what it sends, so older client libraries connect without modification.

The newer revision has no initial handshake and no session: every request carries its own version and the mandatory headers MCP-Protocol-Version, Mcp-Method and, for a tool call, Mcp-Name. If a header disagrees with the body the response is 400 — routing by headers while executing by the body would mean two sources of truth about the same call.

Related

• Overview
• REST interface
• Outbound webhooks
• Availability