An MCP server that reads your orders, not just your store
Point any agent at one endpoint and it can list orders, read funnel stats, browse the catalog and publish pages. Shopify stays the catalog and the order backend; the funnel context comes along for free.
{ "mcpServers": { "autonnel": {
"url": "https://your-deploy.example.com/api/mcp",
"headers": { "Authorization": "Bearer <scoped-api-key>" }
} } }Tool names, descriptions and input schemas are read on connect. Nothing to paste into a prompt, nothing to keep in sync.
The actual editor, unedited. No mockups on this page.
Autonnel vs A hand-rolled Admin API script
The right-hand column describes the usual alternative: a bespoke wrapper around the Shopify Admin API maintained by whoever wrote it.
| Autonnel | A hand-rolled Admin API script | |
|---|---|---|
| What the agent connects to | Your Autonnel deployment at /api/mcp. Orders, products, funnels, pages, templates and stats behind one endpoint. | The Shopify Admin API directly, wrapped in whatever script you wrote this week. |
| Where the order data comes from | Autonnel funnel orders. Payment state, delivery state, tracking number and customer contact come back on one object, and the stored order also keeps the backend order reference for the record created in Shopify. | Shopify orders, in a separate call from anything that tells you which page produced them. |
| Tool surface | 20 tools, including list_orders, deliver_order, get_stats, list_products, list_funnels, create_page and get_template. | Whatever you hand-rolled, re-described in a prompt every time it changes. |
| Auth | Scoped Bearer API keys with feature-level permissions. A read-only key cannot write. | An Admin API token whose scopes you granted once and rarely revisit. |
| Write safety | Every tool declares writeAccess and a required feature. Write tools are refused outright when the key lacks the feature. | Enforced by whatever your script remembered to check. |
| Schema drift | Tools are self-describing. The client reads names, descriptions and input schemas on connect, so the agent never works from a stale parameter table. | A markdown file that was accurate the day it was written. |
| Source code | Apache-2.0. The tool definitions are readable files you can extend. | Yours to maintain, forever. |
list_orders returns the sales with their payment and delivery state; get_stats returns step-by-step funnel performance over a date range. The agent reaches both through the same connection and the same key it uses to create and publish pages, so reading what happened and changing what happens next are not two integrations.
The MCP client reads tool names, descriptions and input schemas when it connects. Nothing has to be re-pasted into a prompt, and nothing goes stale when a schema changes. The schemas are strict on purpose: a silently dropped filter that returns the whole tenant would look like it worked.
Tools carry a writeAccess flag and a required feature, and the Bearer key carries permissions. Handing an agent a read-only key is a real boundary enforced server-side, not an instruction in a system prompt that a confused model can talk itself past.
If your orders originate in the Shopify checkout and no funnel layer exists, an Autonnel MCP server has nothing extra to tell you, and a thin Admin API wrapper is less to run. This is worth adopting when the funnel is the thing you are optimising: when you want an agent that can read the step-by-step conversion, spot the drop-off, generate a replacement page and publish it, all against the same deployment that took the money.
FAQ
Is this an MCP server for the Shopify Admin API?
No, and the distinction matters. It is an MCP server for your Autonnel deployment, which sits in front of Shopify. The orders it returns are funnel orders, each carrying a saleRef to the corresponding Shopify record, and the products it lists come from Shopify through the catalog adapter. If you want raw Admin API access, use Shopify tooling directly.
What tools does it expose?
20 in total. Orders and reporting: list_orders, deliver_order, get_stats. Catalog: list_products. Funnels: list_funnels, get_funnel, create_funnel, update_funnel, delete_funnel, add_funnel_page, replace_funnel_page, remove_funnel_page, set_funnel_step_slug. Pages and media: list_pages, get_page, create_page, update_page, list_templates, get_template, upload_media.
How does an agent authenticate?
A scoped Bearer API key created in Settings. Permissions are feature-level, and each tool declares the feature it needs plus whether it writes, so a read-only key is refused at the tool boundary rather than trusted to behave.
Does it work with WooCommerce or without any store?
Yes. The commerce adapter is pluggable: Shopify, WooCommerce, or Picocart, our own open-source commerce backend. The MCP surface is the same in all three cases.
Is there a REST API as well?
Yes. The MCP server and the REST surface are two front doors onto the same application, and the REST endpoints are documented separately. MCP is the one worth pointing an agent at.
Do I need the cloud version?
No. The MCP server ships in the open-source package and runs in any self-hosted deployment.