Ein Shopware Merchant Agent ist etwas anderes als ein Shopping-Agent. Der eine liest Ihren Katalog und beantwortet Käuferfragen. Der andere hat Zugangsdaten zu Ihrem Admin und kann ändern, was Ihre Produkte kosten.
Shopware hat am 4. September 2026 ein funktionierendes Beispiel für den zweiten Fall veröffentlicht. Interessant daran ist die Mechanik zwischen dem Modell und Ihrer Datenbank.
Ich habe die Agent-Hosts nicht auf einem Kundenshop betrieben, das Verhalten von Guardrails und Ledger ist also aus Shopwares eigener Referenzimplementierung gelesen. Die Shopware-Seite habe ich geprüft: Admin-MCP-Oberfläche, Tool-Liste und der Dry-Run-Vertrag sind gegen einen 6.7.13.0-Shop verifiziert, und die eine Aussage, die den Test nicht überstanden hat, ist gekennzeichnet.
Was ein Shopware Merchant Agent wirklich macht
Das Repository stellt zwei Agenten auf denselben Shopware-6.7-Shop, beide auf Basis von Anthropics Commerce-Agents-Blueprint. Die Shopping-Hälfte habe ich im Artikel zur UCP-Einrichtung auseinandergenommen. Die Merchant-Hälfte spricht mit der Admin API statt mit der Storefront.
Der Ablauf ist unspektakulär. Ein Operator fragt in normaler Sprache: Was braucht heute Morgen meine Aufmerksamkeit, welche Produkte sind knapp, erhöhe das Olivenöl um 50 Cent. Der Agent antwortet aus Live-Daten, und wenn die Anfrage einen Schreibvorgang bedeutet, liefert er eine Karte mit vorbereiteter Änderung: Vorher-Wert, Nachher-Wert, Guardrail-Hinweis und zwei Buttons.
Die Lesezugriffe laufen über Shopwares eigene Aggregationen. Umsatz und Bestellzahlen kommen aus shopware-entity-aggregate über order für den aktuellen und den vorherigen Zeitraum, stornierte Bestellungen ausgenommen. Ladenhüter sind eine Terms-Aggregation über order_line_item.productId mit verschachtelter Mengensumme über 30 Tage. Niedrige Bestände kommen aus einer Schwellenwertdatei, Standard 8, pro Produkt überschreibbar.
Das Vorbereiten einer Änderung schreibt nichts. Genau das ist der Punkt.
Der Dry Run in Shopwares Admin MCP ist der eigentliche Trick
Shopwares Admin-MCP-Server gibt seinen schreibenden Tools ein dryRun-Flag und setzt es standardmässig auf true. Auf einem 6.7.13.0-Shop tragen genau fünf Tools dieses Flag: shopware-entity-upsert, shopware-entity-delete, shopware-order-state, shopware-system-config-write und shopware-theme-config, jeweils mit default: true im Input-Schema. shopware-media-upload ist die Ausnahme, die man kennen sollte. Es schreibt, und es hat gar kein dryRun.
Der Dry Run ist ein echter Schreibvorgang. Shopware führt ihn in einer Transaktion aus, rollt die Transaktion zurück und meldet, welche Zeilen betroffen gewesen wären. Die Vorher- und Nachher-Werte auf der Karte sind damit das Urteil des Servers und nicht etwas, das sich das Modell zusammengereimt hat.
Das lässt sich prüfen, also habe ich es geprüft. Ein Dry-Run-Upsert, der den Bestand eines Produkts auf 999 setzt, kam mit der Liste der Zeilen zurück, die er in product und product_translation geschrieben hätte, und die Datenbank stand danach weiterhin auf 50. Danach habe ich einen mit einer taxId geschickt, die es nicht gibt:
{"success": false, "error": "An exception occurred while executing a query:
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update
a child row: a foreign key constraint fails (`db`.`product`, CONSTRAINT
`fk.product.tax_id` FOREIGN KEY (`tax_id`) REFERENCES `tax` (`id`))"}Das ist MySQL, das den Schreibvorgang ablehnt, durchgereicht vom Dry Run. Etwas, das nur die Payload prüft, kann diese Meldung nicht erzeugen.
Daraus folgen zwei Dinge, und beide wiegen schwerer als das Chatfenster.
Eine Payload, die Shopware ablehnen würde, scheitert schon beim Vorbereiten. Fehlerhafter Schreibvorgang, fehlende verschachtelte Zeile, verletzte Bedingung: Die Änderung wird mit Shopwares eigener Meldung abgelehnt, während der Operator noch auf den Bildschirm schaut. Der Fehler landet dort, wo ihn jemand lesen kann.
Angewendet wird die gespeicherte Payload. Das Vorbereiten legt die exakte Payload im Ledger ab, und das Anwenden spielt genau diese Payload mit dryRun=false ab. Das Modell bekommt zwischen Vorschau und Schreibvorgang keinen zweiten Zug, um sie neu zu erzeugen. Was Sie freigegeben haben, läuft auch.
Drei Sperren zwischen Modell und Datenbank
- Guardrails, zweimal geprüft. Preisdelta, Rabatthöhe, Nachbestellmenge, geschützte Felder und Positionen pro Änderung werden beim Vorbereiten geprüft und beim Anwenden erneut. Eine Änderung, die im Ledger lag, während sich das Produkt darunter bewegt hat, wird neu geprüft statt geglaubt.
- Freigabe im Host.
MERCHANT_REQUIRE_HOST_APPROVAL=1ist der Standard. Das Anwenden ist eine HTTP-Route, die eine bereits vom Host freigegebene Änderung verlangt, und Anwenden wie Verwerfen lehnen alles ab, was nicht im StatusSTAGEDsteht. - Identität. Der Host authentifiziert sich als Shopware Integration über
client_credentialsmit eigener ACL-Rolle. Der Passwort-Grant des Admin-Benutzers wird ausdrücklich nicht akzeptiert. Wird der Host kompromittiert, geht eine eng geschnittene Integration verloren.
Die Rechteliste ist die eigentliche Grenze
Alles bisher Genannte ist Anwendungslogik, und Anwendungslogik hat Fehler. Die ACL-Rolle ist die Schicht, die Shopware unabhängig davon durchsetzt.
Die Tool-Allowlist der Integration im Admin MCP umfasst sechs Core-Tools:
shopware-entity-search
shopware-entity-read
shopware-entity-aggregate
shopware-entity-upsert
shopware-entity-delete
shopware-entity-schemaDarunter liegt die Rechteliste: product:read und product:update, die promotion- und rule-Familien für den Aufbau einer Aktion, dazu Lesezugriff auf order, order_line_item, order_transaction und order_delivery. customer:read fehlt, weil kein Aufruf des Merchant Agent es braucht. product_manufacturer:read ebenfalls.
Dieses Fehlen ist der nützliche Teil. Shopwares Datenschicht prüft über den AclWriteValidator jede verschachtelte Zeile erneut, die ein Schreibvorgang berührt, also braucht das Anlegen einer Aktion die verschachtelten Rechte einzeln aufgeführt. Einem Agenten eine breite Rolle zu geben und darauf zu hoffen, dass die Anwendungsschicht ihn schon bremst, ist eine Entscheidung, und Sie sind dazu nicht gezwungen.
Die Rollenvorlage bringt ausserdem eine Trennung nach Vier-Augen-Prinzip mit: eine Rolle, die Änderungen ohne agent_change:update vorbereitet, und eine separate Freigeber-Rolle, die es hat, für Shops, in denen die Freigabe in Shopware selbst passieren soll statt in einem separaten Portal. Das ist die Form, die sich die meisten Händler, mit denen ich spreche, tatsächlich wünschen.
Wo es noch nicht reicht
- Traffic und Conversion kommen als nicht verfügbar zurück, mit einer Notiz dazu. Shopware hat keine Traffic-Quelle, der Agent kann also die Frage nicht beantworten, die die meisten Händler zuerst stellen.
- Das Merchant-Eval-Set besteht 34 von 38 Fällen nach einer Runde Prompt-Arbeit, vorher waren es 23. Das ist ein Demo-Wert, und das Repository benennt ihn auch so.
SwagCommerceAgentTools, das Plugin, das diese Fähigkeiten nach Shopware selbst verlagert, ist ein erster Ausbauschritt und im gemeinsamen Container des Projekts noch nicht installiert.- Das UCP SDK unter der Shopping-Hälfte steht auf Version 0.0.5. Vor 1.0 heisst: Breaking Changes kommen noch.
- Shopware kennzeichnet den MCP-Server als experimentell, in der Beschreibung des Feature-Flags im Core. Tool-Namen und Datenformate sind entsprechend ein bewegliches Ziel.
Das ist eine Referenzimplementierung. Niemand sollte sie in diesem Quartal auf einen Kundenshop stellen, und das Repository behauptet auch nichts anderes.
Was heute schon baubar ist
Nehmen Sie das Modell heraus und schauen Sie, was übrig bleibt: ein Ledger für vorbereitete Änderungen, eine ACL-begrenzte Integration, servergeprüfte Vorschauen und eine Freigabe-Route. Alle vier gibt es auf Shopware 6.7 heute, und keines davon braucht einen KI-Agenten, um sich zu lohnen.
Es ist dieselbe Architektur wie bei freigabegesteuerter Automatisierung, die ich bereits ausgeliefert habe. Zero-Touch-Bestellabwicklung für einen deutschen Dropshipper fährt dieselbe Form mit einer Regel-Engine am Steuer, und der Readiness-Auditor bewertet einen Katalog gegen Shopwares Feed-Validator, ohne je in den Shop zu schreiben. Wenn Sie noch früher stehen, ist was Agentic Commerce für die Sichtbarkeit Ihres Shops bedeutet der Startpunkt.
Mein Rat an alle, die das abwägen: Bauen Sie zuerst die Sperren. Die Sperren sind der haltbare Teil. Welches Modell auch immer dahinter sitzt, es wird zweimal ausgetauscht sein, bevor sich das Ledger-Schema einmal ändert.
Wenn Sie den Freigabeprozess gebaut haben wollen, mit oder ohne Agent am Steuer, nehmen Sie Kontakt auf.
Häufige Fragen
Was ist ein Shopware Merchant Agent? Ein KI-Agent, der auf Shopwares Admin API zeigt statt auf die Storefront. Er liest Umsatzzahlen, niedrige Bestände und Bestellprobleme über Shopwares Aggregationen, und wenn Sie eine Änderung verlangen, schlägt er eine Preis-, Bestands- oder Aktionsänderung als vorbereitete Änderung mit Vorher-Nachher-Vorschau vor. Ein Mensch gibt sie frei, bevor irgendetwas geschrieben wird.
Kann ein KI-Agent in Shopware Preise ohne Freigabe ändern? In Shopwares Referenzimplementierung nicht. Das Vorbereiten schreibt nichts: Die echte Payload läuft über Admin MCP mit dryRun=true, und Shopware führt sie in einer Transaktion aus und rollt sie zurück. Das Anwenden ist eine eigene Route, die eine vom Host freigegebene Änderung verlangt, und im Standard hat das Modell keinen Weg zu dryRun=false. Ob Ihr eigenes Setup so arbeitet, hängt allein davon ab, wie es gebaut wurde.
Was macht dryRun in Shopwares Admin MCP? Fünf schreibende Tools tragen dryRun, standardmässig auf true. shopware-media-upload schreibt ohne eines. Shopware führt den Schreibvorgang in einer Transaktion aus, rollt ihn zurück und meldet, welche Zeilen betroffen gewesen wären. Die Vorschau ist damit das Urteil des Servers, und eine Payload, die Shopware ablehnen würde, scheitert, solange noch jemand hinschaut.
Welche Shopware-Version brauche ich für Admin MCP? 6.7.11 bis 6.7.13 liefern den MCP-Server hinter dem Feature-Flag MCP_SERVER aus, standardmässig ausgeschaltet. Wo der Wert stehen muss, hängt vom Stack ab: Auf meiner ddev-Umgebung genügte eine Container-Umgebungsvariable, in Shopwares dockware-Notizen funktionierte nur die .env des Projekts. Ab 6.7.14 entfällt das Flag und die Tool-Liste wird progressiv. Shopware 6.5 und 6.6 haben keinen MCP-Server im Core.
