ecommerce-mcp-automation
Ecommerce MCP Automation
Ein Beispiel für eine Claude Code + MCP-Integration: Shopify und Meta Ads als MCP-Tools bereitgestellt, plus ein Reporting-Agent, der beides in eine formatierte tägliche P&L- und Anzeigenleistungs-Tabelle zusammenführt – kein manuelles Kopieren und Einfügen zwischen den Plattformen.
Dies ist eine Demonstration, die anhand der öffentlichen Shopify Admin API und der Meta Marketing API-Dokumentation entwickelt wurde – nicht etwas, das ein echtes Geschäft betrieben hat. Es ist ein Clean-Room-Beispiel: echte Endpunkte, echte Authentifizierung, echte Paginierung, echte Fehlerbehandlung, frisch geschrieben, um genau zu zeigen, wie diese Art von Automatisierung aufgebaut wird. Es läuft durchgängig im Mock-Modus ohne Zugangsdaten (realistische Fixture-Daten als Stellvertreter für Live-Antworten) und wechselt pro Integration in den Live-Modus, sobald echte Zugangsdaten gesetzt sind – siehe So führen Sie es aus.
Der Shopify-Client wurde live gegen einen echten Shopify-Partners- Entwicklungs-Store (einen Sandbox-Store, kein Produktionsgeschäft) ausgeführt – echte Authentifizierung, eine echte Bestellung, echte API-Antworten. Dabei wurden zwei echte Nullability-Grenzfälle aufgedeckt und behoben (siehe Bekannte Vereinfachungen), die die Mock-Fixtures allein nicht abgedeckt hatten. Meta Ads läuft in diesem Repository standardmäßig gegen den Mock-Transport; der Client-Code ist genauso geschrieben und wechselt in den Live-Modus, sobald
META_ACCESS_TOKEN/META_AD_ACCOUNT_IDgesetzt sind.
Was es macht
Stellt Shopify-Bestellungen, Umsatz und COGS als MCP-Tools bereit (
get_orders,get_daily_pnl)Stellt Meta-Ads-Ausgaben, Impressionen, Käufe und ROAS als MCP-Tools bereit (
get_insights,get_daily_ad_performance)Führt einen Reporting-Agent (
daily_report.py) aus, der beide gleichzeitig abruft und eine formatierte.xlsx-Arbeitsmappe mit Summary-, Orders- und Ad-Performance-Blättern schreibtLiefert eine Claude Code Skill mit, die den gesamten Workflow hinter einem natürlichsprachlichen Auslöser („Tagesbericht ausführen") kapselt
Enthält eine eingecheckte Beispielausgabe, damit das Ergebnis sichtbar ist, ohne etwas auszuführen
Related MCP server: Ask AI
Beispielausgabe
Gerenderte Vorschau des Summary-Tabs – öffnen Sie die tatsächlich generierte Arbeitsmappe für die Live-Datei (mit den Orders- und Ad-Performance-Blättern, Währungs-/ROAS-Formatierung und eingefrorenen Kopfzeilen).
Architektur
flowchart LR
subgraph Shopify["Shopify Admin API"]
SO[orders.json]
SI[inventory_items.json]
end
subgraph Meta["Meta Marketing API"]
MI[act_id/insights]
end
SO --> SC[shopify_client.py]
SI --> SC
MI --> MC[meta_ads_client.py]
SC --> SS[shopify_server.py<br/>MCP tools]
MC --> MS[meta_ads_server.py<br/>MCP tools]
SC --> DR[daily_report.py]
MC --> DR
DR --> SPX[spreadsheet.py]
SPX --> XLSX[(sample_daily_report.xlsx)]
Mock[["mock_api.py<br/>(ASGITransport, in-process)"]] -.mock mode.-> SC
Mock -.mock mode.-> MCDie beiden API-Clients (clients/shopify_client.py, clients/meta_ads_client.py) sind echter Integrationscode – echte Endpunkt-URLs, echte Auth-Header, echte Paginierungsschleifen, echtes 429-Backoff. Das einzige, was sich zwischen Mock- und Live-Modus ändert, ist der HTTP-Transport (clients/http.py):
Live:
httpx.AsyncClientöffnet eine echte Verbindung zu Shopify / Meta.Mock:
httpx.AsyncClientbekommt einenhttpx.ASGITransport, der auf eine In-Process-FastAPI-App (fixtures/mock_api.py) zeigt, die realistische Fixture-Payloads ausliefert. Es wird kein Port gebunden, kein Subprozess gestartet – aber Anfragen durchlaufen weiterhin echtes HTTP/ASGI-Routing, Header und JSON-Kodierung.
Das bedeutet, dass der Client-Code, den ein Prüfer liest, derselbe Code ist, der gegen einen Live-Store laufen würde – kein Mock, der nur so aussieht. Siehe CLAUDE.md für die vollständigen Konventionen.
So führen Sie es aus
Mock-Modus (Standard – keine Zugangsdaten)
git clone <this-repo> && cd ecommerce-mcp-automation
python -m venv .venv && source .venv/bin/activate # or: uv sync && source .venv/bin/activate
pip install -e ".[dev]"
python -m ecommerce_mcp.reporting.daily_report
# -> Wrote examples/sample_daily_report.xlsxFühren Sie die Testsuite genauso aus, keine Einrichtung erforderlich:
pytestLive-Modus
Kopieren Sie .env.example in .env und füllen Sie aus, was Sie haben – jede Integration wechselt unabhängig in den Live-Modus, sobald ihre eigenen Zugangsdaten vorhanden sind. So können Sie Shopify live ausführen, während Meta noch gemockt ist (oder umgekehrt):
cp .env.example .env
# SHOPIFY_STORE_DOMAIN=your-dev-store.myshopify.com
# SHOPIFY_ACCESS_TOKEN=shpat_... (Partners dev store -> custom app -> Admin API token)
# META_ACCESS_TOKEN=EAA... (System User token, ads_read scope)
# META_AD_ACCOUNT_ID=act_1234567890Als MCP-Server (Claude Code / Claude Desktop)
Fügen Sie dies zu Ihrer MCP-Konfiguration hinzu (.mcp.json für Claude Code oder die Konfigurationsdatei von Claude Desktop). Setzen Sie command direkt auf den venv-Interpreter des Projekts – MCP-Clients laden Ihr Shell-Profil nicht, daher sieht ein bloßes python kein aktiviertes venv:
{
"mcpServers": {
"shopify": {
"command": "/path/to/ecommerce-mcp-automation/.venv/bin/python",
"args": ["-m", "ecommerce_mcp.mcp_servers.shopify_server"],
"cwd": "/path/to/ecommerce-mcp-automation"
},
"meta-ads": {
"command": "/path/to/ecommerce-mcp-automation/.venv/bin/python",
"args": ["-m", "ecommerce_mcp.mcp_servers.meta_ads_server"],
"cwd": "/path/to/ecommerce-mcp-automation"
}
}
}Fragen Sie Claude dann Dinge wie „Wie ist die heutige Shopify P&L?" oder „Hol mir die Meta-Werbeleistung von gestern" – Claude ruft die Tools direkt auf, standardmäßig im Mock-Modus.
Als Skill
skills/daily-report/SKILL.md kapselt den Workflow zur Berichtserstellung, sodass Claude Code ihn über einen natürlichsprachlichen Auslöser („Tagesbericht ausführen") ausführt, anstatt den genauen CLI-Befehl zu benötigen. Der Pfad für den vollständigen Bericht benötigt die obige MCP-Konfiguration überhaupt nicht – er führt daily_report.py direkt aus, das die Clients als normales Python aufruft, ganz ohne MCP. Die MCP-Konfiguration wird nur für den anderen Skill-Pfad benötigt: die Beantwortung einer einzelnen Kennzahl („Wie hoch ist der heutige ROAS?") durch den Aufruf von get_daily_pnl / get_daily_ad_performance als MCP-Tools, anstatt den gesamten Bericht auszuführen.
Projektstruktur
src/ecommerce_mcp/
clients/ Typed, async API clients (Shopify + Meta), transport-swappable
mcp_servers/ MCP tool servers wrapping the clients
reporting/ daily_report.py (orchestration) + spreadsheet.py (openpyxl)
fixtures/ Realistic mock payloads + the in-process mock API app
skills/daily-report/ Claude Code Skill for the reporting workflow
tests/ pytest suite (all run against mock mode)
examples/ Committed sample .xlsx + README preview imageBekannte Vereinfachungen
Hier dokumentiert statt versteckt, denn bei einem solchen Beispiel zählt Präzision mehr als Politur:
COGS verwendet das Feld
InventoryItem.costvon Shopify über den echten Two-Hop-Lookup (Variante →inventory_item_id→ gebündelterinventory_items-Abruf) – Shopify gibt die Kosten nicht direkt auf der Bestellposition an. Sowohlcostals auch die Positions-skusind in einem Live-Store nullable (ein Händler hat sie möglicherweise nie gesetzt) – gefunden durch Live-Tests gegen einen echten Dev-Store, nicht allein durch die Doku. Beide werden als Null-Kosten / fehlende SKU behandelt, anstatt einen Fehler zu werfen.Erstattete Bestellungen werden in
daily_pnl()vollständig aus Umsatz/COGS/Bestellanzahl ausgeschlossen. Die Berücksichtigung von Teilerstattungen/Rücksendungen würde die Refund-Ressource erfordern – hier nicht im Umfang.Meta-Kaufattribuierung verwendet den Aktions-Typ
purchaseaus den Arraysactions/action_valuesmit dem Attributionsfenster, das für das Werbekonto konfiguriert ist – dieser Client überschreibt es nicht.Der Reporting-Agent ruft derzeit alle verfügbaren Bestellungen/Insights ab, anstatt nach Datumsbereich zu filtern; ein täglicher Produktions-Cron würde
created_at_min/time_rangefür den Zieltag übergeben.
Lizenz
MIT – siehe LICENSE.
Available Tools
2 toolsget_daily_pnlA
Revenue, COGS, and gross profit across the current order set.
COGS is resolved per line item via the Shopify inventory item cost field. Refunded orders are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully explains that COGS is resolved per line item and that refunded orders are excluded. However, it does not define what 'current order set' means or how the 'daily' period is determined, leaving ambiguity in the tool's scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core metrics stated in the first sentence. Every subsequent line adds distinct value: cost-resolution method and refund exclusion. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema or annotations, so the description must communicate both the result metric and behavioral caveats, which it does adequately for a zero-parameter tool. The main gap is that the exact time period of 'current order set' is left undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers everything about parameters, so the description does not need to explain parameter semantics. It still adds meaning by describing what the computed values represent, which is sufficient given no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific metrics 'Revenue, COGS, and gross profit' and names the resource 'current order set.' This clearly distinguishes the tool from its sibling get_orders, which would return orders rather than a financial summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives helpful context such as 'across the current order set' and 'Refunded orders are excluded,' but it does not explicitly state when to use this tool versus get_orders or when not to use it. Usage guidance is implied rather than clearly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ordersA
Fetch Shopify orders (paginated automatically).
Args: status: Order status filter — "any", "open", "closed", or "cancelled".
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | any |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that pagination is handled automatically, which is a non-obvious behavior an agent needs to know. It does not mention auth or rate limits, but for a simple fetch operation the pagination disclosure is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover purpose, pagination behavior, and the parameter's allowed values. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter fetch tool with an output schema, this description is complete. It covers what the tool does, the parameter semantics, and a key behavioral detail (automatic pagination). The sibling tool is clearly distinct, so no additional routing context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully defines the only parameter, status, and lists all allowed values: 'any', 'open', 'closed', or 'cancelled'. This adds clear meaning beyond the schema, which only shows type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action and resource: 'Fetch Shopify orders'. The automatic pagination note adds scope, and the sibling get_daily_pnl is clearly a different resource, so an agent can distinguish them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when order data is needed and offers a status filter, but it does not explicitly say when to use this tool versus get_daily_pnl or any other alternative. There are no exclusions or conditional routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0- First observed
get_daily_pnl - First observed
get_orders
TDQS
Scored across 2 tools
get_orders returns raw order data, while get_daily_pnl computes financial metrics. Their purposes are entirely distinct with no overlap, making tool selection unambiguous.
Both tools follow the consistent get_<noun> pattern, which is clear and predictable. There is no mixing of styles or ambiguous verbs.
With only two tools, the set feels thin for a server labeled 'ecommerce automation'. However, it is not a single trivial tool, so borderline is appropriate.
The server provides only read-only order access and a PnL report. There are no create/update/delete operations, product or customer tools, refund handling, or broader automation workflows, making the surface severely incomplete for ecommerce automation.
Maintenance
Related MCP Connectors
Remote MCP for Shopify, Meta Ads, Google Ads and TikTok Ads with human approval for writes
Connects Amazon Seller Central and Amazon Advertising to any MCP client. Settlement-accurate P&L - every fee, refund and reimbursement as Amazon posted it - plus contribution margin and breakeven per product, per marketplace, per day. Full Sponsored Products, Brands and Display management: search terms, placements, keyword and competitor research, dayparting, automation rules. 110 tools: 78 read-only (P&L, PPC at every grain, SQP/Brand Analytics, inventory, forecasting), 28 staged writes (every change is a proposal you review and confirm before it reaches Amazon - there is no autonomous-write mode), and 4 confirmation & support tools. 4 additional AI Workforce tools appear once a client is connected.
Run Meta Ads and Google Ads for your Shopify store from Claude, ChatGPT or Cursor, with the store's own Shopify, Stripe or Klaviyo revenue next to ad spend. New campaigns are created paused.
Meta Ads MCP (Facebook + Instagram) - analyze performance, manage budgets, pause campaigns.
Related MCP Servers
AlicenseNot gradedqualityDmaintenanceConnects e-commerce and marketing data sources like Shopify, GA4, Google Ads, and Meta Ads to AI assistants, enabling natural language queries about store performance, ad campaigns, and customer behavior.11 npm2MIT- FlicenseNot gradedqualityDmaintenanceHosted MCP server connecting Shopify, Klaviyo, GA4, Meta Ads, Google Ads, Xero, Gorgias and 20+ e-commerce data sources so AI assistants can answer merchant questions that span every source at once.-
- AlicenseNot gradedqualityBmaintenanceConnects Amazon Seller Central and Amazon Advertising to any MCP client, with a settlement-accurate P&L underneath: every fee, refund and reimbursement as Amazon actually posted it, so contribution margin and breakeven are per product, per marketplace, per day. 107 tools spanning P&L, full Sponsored Products/Brands/Display management, Search Query Performance and Brand Analytics, inventory and for1MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to fetch Xiaohongshu advertising data from Chengfeng, Juguang, and Dandelion platforms via MCP, and supports syncing daily ad reports to Feishu.1MIT