MCP-Server für JTL-Wawi

Was ist ein MCP-Server für JTL-Wawi?

JTL-Wawi ist die meistgenutzte Warenwirtschaft im deutschen E-Commerce-Mittelstand — von der Ein-Personen-Shop-Manufaktur bis zum Versandhändler mit eigenem Logistikzentrum. Sie bündelt Artikel, Bestände, Aufträge, Kunden, Versand und Multichannel-Anbindung an Shop, Amazon und eBay in einem System. Ein MCP-Server für JTL-Wawi stellt diese Daten und Aktionen über das offene Model Context Protocol einem KI-Agenten zur Verfügung — standardisiert, sodass Sie nicht für jedes Modell und jeden Anwendungsfall ein eigenes Skript pflegen.

Wichtig und ehrlich vorweg: Einen offiziellen, fertigen MCP-Server von JTL gibt es derzeit nicht, und ein verbreiteter Community-Server existiert ebenfalls noch nicht. Was es gibt, ist die moderne JTL-Wawi-REST-API — ein Dienst, der auf dem JTL-Server läuft (typischerweise Port 5883) und über eine Swagger-Oberfläche dokumentiert ist. Genau darauf setzen wir den MCP-Layer projektspezifisch auf. JTL-Wawi ist also nicht „MCP-ready von Haus aus", sondern sauber über die offizielle API anbindbar — und das ist der entscheidende Unterschied, den viele Anbieter verschweigen.

Typische Nutzer: Onlinehändler, Multichannel-Versender, Hersteller mit eigenem D2C-Shop. Wer JTL-Wawi betreibt, will Routine-Klicks loswerden — Bestandsabfragen, Auftragsstatus, Reporting — ohne das gewohnte System zu verlassen.

Use Cases: Was kann ein JTL-MCP-Server konkret?

1. Bestands- & Verfügbarkeitsabfragen „Wie viele Stück von SKU 4711 liegen über alle Lager verteilt?" Der Agent liest Bestände aus der Wawi, berücksichtigt reservierte Mengen aus offenen Aufträgen und meldet, was real verfügbar ist — ohne Lagerverwaltungs-Maske.
2. Auftrags-Monitoring & Eskalation „Welche Aufträge von gestern hängen noch im Status ‚in Bearbeitung'?" Der Agent filtert Aufträge nach Status, Plattform und Datum, erkennt Versandverzüge und schlägt eine Priorisierung vor — gerade in Peak-Phasen wertvoll.
3. Artikelpflege & Stammdaten Neue Artikel anlegen oder bestehende anreichern: Der Agent füllt Beschreibung, Kategorie, Maße und Attribute vor, prüft auf Dubletten anhand der Artikelnummer — und legt nach Freigabe an. Stammdatenqualität ohne Copy-Paste.
4. Kunden- & Bestellhistorie „Was hat Kunde Mustermann in den letzten zwölf Monaten bestellt und gibt es offene Reklamationen?" Der Agent zieht Kundendaten und verknüpfte Aufträge und liefert eine Zusammenfassung für den Support — statt manueller Suche.
5. Nachbestell- & Dispo-Vorschläge Der Agent vergleicht Verkaufsgeschwindigkeit, aktuellen Bestand und Mindestbestand, identifiziert Artikel kurz vor dem Ausverkauf und erstellt einen Bestellvorschlag je Lieferant — als Entwurf, den der Einkauf nur noch prüft.
6. Reporting im Klartext „Wie hat sich der Umsatz Kategorie X gegenüber dem Vormonat entwickelt?" Der Agent aggregiert Auftragsdaten und antwortet in Sätzen statt in einer Pivot-Tabelle — der schnelle Liquiditäts- und Performance-Blick zwischendurch.

So funktioniert die Integration

Architektur-Bild für JTL-Wawi:

KI-Agent ↔ MCP-Server (Ihr EU-Host) ↔ JTL-Wawi-REST-API (auf dem JTL-Server, Swagger-dokumentiert) ↔ JTL-Datenbank (Microsoft SQL Server)

Konkrete technische Schritte:

• API-Instanz einrichten: Die JTL-Wawi-API wird als Dienst auf dem JTL-Server aktiviert und über den JTL-Administrator gestartet. Wir verbinden den MCP-Server gegen diesen Endpunkt — bei On-Premise-Installationen abgesichert über VPN oder Reverse-Proxy.
• Tool-Mapping: Wir definieren MCP-Tools wie get_stock, list_orders, get_customer, create_item_draft — jedes mit JSON-Schema, validierten Eingaben und klaren Fehlermeldungen, damit der Agent nicht ins Leere greift.
• Mapping auf das JTL-Datenmodell: JTL trennt sauber zwischen Artikel, Bestand, Auftrag und Kunde. Wo die REST-API (noch in der Beta-Reifung) ein Feld nicht abdeckt, ergänzen wir gezielt den klassischen JTL-Connector oder einen lesenden SQL-View.
• Read- vs. Write-Trennung: Standardmäßig liefert der Agent Auswertungen und Entwürfe. Buchungsrelevante Schreibaktionen — etwa Bestandskorrekturen oder Auftragsstatus-Änderungen — erfordern eine explizite Freigabe, konfigurierbar je Tool.
• Logging: Jede API-Aktion wird mit Zeitstempel, Benutzer und Diff protokolliert — wichtig, weil Bestands- und Auftragsdaten direkt geschäftskritisch sind.

DSGVO, Hosting & Sicherheit

JTL-Wawi läuft in den meisten Betrieben on-premise oder im EU-Hosting — Kunden-, Bestell- und Bestandsdaten liegen also ohnehin in Ihrer Hand. Damit die KI-Erweiterung diese Eigenschaft nicht aushebelt, achten wir bei jedem MCP-Server für JTL-Wawi auf:

• EU-Hosting des MCP-Servers (Hetzner oder Azure Germany) bzw. Betrieb direkt neben der Wawi im eigenen Netz — kein US-Edge.
• Abgesicherter API-Zugang: kein offen erreichbarer Port 5883, sondern VPN, Reverse-Proxy mit Auth und IP-Whitelisting.
• AVV mit KI-Anbieter in EU-Datenresidenz — Claude über AWS Bedrock (EU-Region Frankfurt), Google Vertex AI (EU), OpenAI Enterprise EU oder Azure OpenAI Deutschland.
• Datenminimierung: Der Agent sieht nur die Felder, die der jeweilige Use-Case braucht — Bestandsabfragen brauchen keine Kunden-Klartextdaten.
• Mandanten- und Rollentrennung, falls mehrere JTL-Mandanten oder Lager über eine Instanz laufen.

Was kostet das?

Weil JTL-Wawi keinen fertigen MCP-Server mitbringt, ist der API-Anbindungs- und Mapping-Anteil hier etwas größer als bei reinen Cloud-Tools — dafür bleibt das System nach dem Aufbau sehr robust. Konkret:

• Erste Use-Cases in 2–3 Wochen produktiv — typischerweise Bestandsabfragen oder Auftrags-Monitoring als Einstieg, weil rein lesend und schnell wirksam.
• Festpreis pro Use Case, kein Stundenroulette. Skalierung danach in 1-Wochen-Inkrementen.
• Beratungs- und Konzeptionsanteile sind unter Umständen förderfähig — das klären wir im Audit individuell.

Eine konkrete Zahl nennen wir in der Erstberatung — abhängig von Auftragsvolumen, Anzahl der Lager, gewünschten Tools und davon, ob neben der REST-API der JTL-Connector eingebunden wird.

Häufige Fragen

Gibt es einen fertigen MCP-Server für JTL-Wawi?

Nein. Einen offiziellen MCP-Server von JTL gibt es derzeit nicht, und ein etablierter Community-Server existiert ebenfalls noch nicht. Wir binden JTL-Wawi über die offizielle REST-API an und bauen den MCP-Layer projektspezifisch darauf — sauber dokumentiert und versioniert, statt undurchsichtiger Bastellösung.

Welche JTL-Wawi-Schnittstelle wird genutzt?

Primär die moderne JTL-Wawi-REST-API, die als Dienst auf dem JTL-Server läuft und über Swagger dokumentiert ist. Sie deckt Artikel, Bestände, Aufträge und Kunden ab. Wo die noch in Beta befindliche REST-API ein Feld nicht abbildet, ergänzen wir den klassischen JTL-Connector.

Kann der Agent direkt Aufträge oder Bestände ändern?

Technisch ist das möglich. In der Praxis empfehlen wir bei geschäftskritischen Schreibaktionen — Bestandskorrekturen, Statuswechsel — einen kurzen Freigabe-Schritt. Lesende Abfragen und Vorschläge laufen vollautomatisch, die Buchung bleibt unter Kontrolle.

Läuft das auch mit On-Premise-JTL-Installationen?

Ja, das ist sogar der Regelfall. Da JTL-Wawi häufig lokal oder auf einem eigenen Server läuft, sichern wir den API-Zugang über VPN oder einen authentifizierten Reverse-Proxy ab — der Port 5883 ist nie offen im Netz erreichbar.

Ist JTL-Wawi + MCP DSGVO-konform?

Ja. JTL-Wawi liegt meist in Ihrer eigenen Infrastruktur in der EU, der MCP-Server läuft in der EU, der KI-Anbieter wird mit EU-Datenresidenz und AVV eingebunden. So bleibt die gesamte Verarbeitungskette in Europa.

Wie schnell ist eine JTL-MCP-Integration produktiv?

Erste, rein lesende Use-Cases typischerweise in 2–3 Wochen. Schreibende Workflows mit Freigabe-Logik und Connector-Ergänzungen brauchen je nach Umfang etwas länger.

Welche KI-Modelle funktionieren?

Alle MCP-kompatiblen Modelle: Anthropic Claude, OpenAI GPT, Google Gemini, Microsoft Copilot. Ein Modellwechsel ist ohne neue Integration möglich.