Skip to main content
Glama
ecommerce-mcp-automation

ecommerce-mcp-automation

by petrycz

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_ID gesetzt 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 schreibt

  • Liefert 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.-> MC

Die 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.AsyncClient bekommt einen httpx.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.xlsx

Führen Sie die Testsuite genauso aus, keine Einrichtung erforderlich:

pytest

Live-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_1234567890

Als 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 image

Bekannte Vereinfachungen

Hier dokumentiert statt versteckt, denn bei einem solchen Beispiel zählt Präzision mehr als Politur:

  • COGS verwendet das Feld InventoryItem.cost von Shopify über den echten Two-Hop-Lookup (Variante → inventory_item_id → gebündelter inventory_items-Abruf) – Shopify gibt die Kosten nicht direkt auf der Bestellposition an. Sowohl cost als auch die Positions-sku sind 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 purchase aus den Arrays actions/action_values mit 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_range für den Zieltag übergeben.

Lizenz

MIT – siehe LICENSE.

Available Tools

2 tools
get_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.

NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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".

NameRequiredDescriptionDefault
statusNoany

Output Schema

NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updatesv0.1.0
    • First observedget_daily_pnl
    • First observedget_orders

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow the consistent get_<noun> pattern, which is clear and predictable. There is no mixing of styles or ambiguous verbs.

Tool Count3/5

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.

Completeness1/5

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

ActivityStale
ResponsivenessNo recent community issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Connects 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 npm
    2
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Hosted 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.
    -
  • A
    license
    Not graded
    quality
    B
    maintenance
    Connects 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 for
    1
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables AI agents to fetch Xiaohongshu advertising data from Chengfeng, Juguang, and Dandelion platforms via MCP, and supports syncing daily ad reports to Feishu.
    1
    MIT