Magento Custom Attributes und Drittmodule per MCP nutzen

Magento-Shops enthalten häufig weit mehr Informationen als die üblichen Produkt-, Kunden- und Bestelldaten. Individuelle Produktattribute, zusätzliche Kundenfelder, Daten aus Erweiterungen und eigene Tabellen bilden oft wichtige Geschäftsprozesse ab.

Ein Produkt kann beispielsweise eine interne Materialgruppe besitzen. Ein Kundenkonto enthält möglicherweise eine ERP-Kundennummer oder ein Vertriebsgebiet. Eine Erweiterung verwaltet Reklamationen, Freigaben oder individuelle Liefertermine.

Sollen Mitarbeiter solche Informationen mit einem KI-Assistenten abfragen, entsteht schnell eine entscheidende Frage:

Kann der MCP-Server diese Daten bereits über die Magento-REST-API abrufen oder muss Magento um eigene API-Endpunkte erweitert werden?

Eine allgemeine Antwort gibt es darauf nicht. Entscheidend ist, wie die Daten in Magento gespeichert werden, ob sie Teil eines API-Datenobjekts sind und welche Informationen der jeweilige REST-Endpunkt tatsächlich zurückgibt.

Inhaltsverzeichnis

Warum sichtbare Magento-Daten für die KI fehlen können

Ein Feld kann im Magento-Backend sichtbar sein und trotzdem in der Antwort eines KI-Assistenten fehlen.

Angenommen, ein Mitarbeiter stellt folgende Frage:

Welche aktiven Produkte gehören zur internen Materialgruppe M-42?

Die Materialgruppe ist bei jedem Produkt im Magento-Backend hinterlegt. Der KI-Assistent findet trotzdem keine passenden Produkte.

Die Ursache kann an mehreren Stellen liegen:

Das Attribut fehlt in der REST-Antwort.
Es erscheint nur bei der Abfrage eines einzelnen Produkts.
Der MCP-Server überträgt das Feld nicht.
Der verwendete API-Benutzer besitzt keine ausreichenden Rechte.
Der Attributwert ist nur in einer bestimmten Store View vorhanden.
Das Sprachmodell kennt die fachliche Bedeutung des Attributcodes nicht.

Die gesamte Verarbeitungskette muss daher geprüft werden:

Nutzerfrage → KI-Client → MCP-Tool → Magento-REST-API → Magento-Daten

MCP regelt, wie ein KI-Client verfügbare Tools erkennen und aufrufen kann. Ein Tool kann beispielsweise eine API abfragen, eine Datenbank durchsuchen oder eine Berechnung ausführen. Das Protokoll sorgt jedoch nicht automatisch dafür, dass alle internen Magento-Daten erreichbar sind.

Was Magento unter Custom Attributes versteht

Magento Custom Attribute verstehen abfragen per Rest API

Der Begriff Custom Attribute wird häufig für alle individuell hinzugefügten Felder verwendet. Technisch können jedoch verschiedene Datenarten gemeint sein.

Magento nutzt unter anderem EAV-Attribute. EAV steht für Entity Attribute Value. Dieses Datenmodell wird vor allem bei Produkten, Kategorien und Kunden eingesetzt. Custom Attributes bilden dabei eine Teilmenge der EAV-Attribute. Typische Beispiele sind Material, Hersteller, interne Artikelgruppe oder eine zusätzliche Kundennummer.

Daneben gibt es Extension Attributes. Sie erweitern bestehende Datenobjekte und können komplexere Datenstrukturen enthalten. Ein Magento-Modul kann damit beispielsweise zusätzliche Informationen an ein Produkt-, Kunden- oder Bestellobjekt anhängen. Extension Attributes werden durch Module eingeführt und müssen technisch korrekt in das jeweilige Datenobjekt geladen werden.

Drittmodule können ihre Daten außerdem vollständig unabhängig von EAV- oder Extension-Attributes speichern. Häufig verwenden sie eigene Datenbanktabellen, Models, Repositories und Serviceklassen.

Für die MCP-Anbindung lassen sich deshalb drei zentrale Fälle unterscheiden:

Datenart	Beispiel	Typischer Zugriff
EAV- oder Custom Attribute	Materialgruppe eines Produkts	vorhandener Produkt-Endpunkt
Extension Attribute	zusätzliche Liefer- oder Modulinformation	vorhandener Endpunkt nach technischer Erweiterung
Eigene Moduldaten	Reklamationsfall oder Freigabestatus	eigener oder vom Modul bereitgestellter Endpunkt

Diese Unterscheidung ist wichtiger als die Frage, ob ein Feld im Magento-Backend angezeigt wird.

Wann die Standard-REST-API ausreicht

Viele individuelle Produktattribute werden bereits über die normalen Produkt-Endpunkte ausgegeben. In einer Produktantwort können sie im Bereich custom_attributes erscheinen.

Eine vereinfachte Antwort könnte so aussehen:

{
  "sku": "ABC-123",
  "name": "Industrieprodukt 123",
  "custom_attributes": [
    {
      "attribute_code": "erp_material_group",
      "value": "M-42"
    }
  ]
}

In diesem Fall muss in Magento möglicherweise nichts verändert werden. Der M CP-Server kann das vorhandene Feld auslesen und an den KI-Client weitergeben.

Dafür müssen jedoch mehrere Voraussetzungen erfüllt sein:

Das Attribut ist in der REST-Antwort vorhanden.
Der MCP-Server entfernt das Feld nicht bei der Aufbereitung.
Der Attributcode ist dem Tool bekannt.
Der Wert wird fachlich korrekt beschrieben.
Der API-Zugriff besitzt die notwendigen Berechtigungen.
Die Antwortmenge bleibt für den Anwendungsfall handhabbar.

Die Bezeichnung erp_material_group ist für einen Entwickler verständlich. Ein Sprachmodell benötigt jedoch zusätzlichen Kontext. Die Toolbeschreibung sollte deshalb erklären, dass es sich um die interne Materialgruppe aus dem ERP-System handelt.

Damit steigt die Wahrscheinlichkeit, dass eine Nutzerfrage wie „Zeige alle Produkte aus der Materialgruppe M-42“ richtig in einen API-Aufruf übersetzt wird.

Warum Listenabfragen unvollständig sein können

Ein Attribut kann in der Detailansicht eines einzelnen Produkts vorhanden sein und trotzdem in einer Produktsuche fehlen.

Adobe weist ausdrücklich darauf hin, dass verschiedene Such-Endpunkte weniger detaillierte Informationen zurückgeben, als es automatisch erzeugte API-Dokumentationen teilweise vermuten lassen. Custom Attributes, Extension Attributes und weitere Detailfelder stehen häufig erst bei der Abfrage eines einzelnen Objekts vollständig zur Verfügung. Felder ohne Wert können ebenfalls vollständig fehlen.

Für einen MCP-Server entsteht daraus ein praktisches Problem.

Der Server sucht zunächst 100 Produkte. Die Listenantwort enthält das benötigte individuelle Attribut nicht. Anschließend müsste jedes Produkt einzeln über einen Detail-Endpunkt abgefragt werden.

Aus einer Anfrage werden dadurch möglicherweise 101 API-Aufrufe:

eine Suche nach den Produkten
100 einzelne Detailabfragen

Technisch kann das funktionieren. Bei größeren Datenmengen steigen jedoch Antwortzeit, Serverlast und Fehleranfälligkeit. Außerdem muss der MCP-Server zahlreiche Antworten zusammenführen, bevor das Sprachmodell mit der eigentlichen Auswertung beginnen kann.

Ein eigener Endpunkt kann in solchen Fällen gezielt die benötigten Felder für alle passenden Produkte liefern. Das reduziert die Zahl der Anfragen und hält die übertragene Datenmenge klein.

Warum Extension Attributes leer bleiben können

Extension Attributes benötigen mehr als eine reine Deklaration.

Ein Modul kann festlegen, dass ein Produktobjekt ein zusätzliches Feld erhalten soll. Damit der Wert tatsächlich in einer API-Antwort erscheint, muss das Modul die Daten beim Laden des Produkts ergänzen. Adobe zeigt dafür unter anderem Erweiterungen des Product Repository, die zusätzliche Daten bei Einzel- und Listenabfragen in das Produktobjekt einfügen.

In der Praxis können daher verschiedene Situationen auftreten:

Das Extension Attribute ist definiert, enthält aber keinen Wert.
Es wird bei get geladen, jedoch nicht bei getList.
Die Daten werden nur für bestimmte Store Views ergänzt.
Ein Plugin eines Drittmoduls greift bei REST-Abfragen nicht wie erwartet.
Nach einem Update hat sich die interne Implementierung verändert.

Die Fehlersuche sollte deshalb nicht beim MCP-Server beginnen. Zuerst muss geprüft werden, welche Antwort Magento selbst liefert. Erst danach lässt sich beurteilen, ob das Problem in Magento, im Drittmodul oder in der Aufbereitung des MCP-Servers liegt.

Wann Daten aus Drittmodulen erreichbar sind

Ein installiertes Magento-Modul besitzt nicht automatisch eine REST-API.

Damit ein Magento-Service als Web-API erreichbar wird, muss er entsprechend konfiguriert werden. Magento verwendet dafür unter anderem eine webapi.xml. Dort werden Route, HTTP-Methode, Service und Zugriffsrechte definiert. Ein Service ohne diese Freigabe steht nicht als REST-Endpunkt zur Verfügung.

Bei einem Drittmodul sind drei Fälle möglich.

Das Modul stellt eigene REST-Endpunkte bereit

Der MCP-Server kann diese Endpunkte grundsätzlich verwenden. Vorher sollten Dokumentation, Berechtigungen, Datenumfang und Stabilität geprüft werden.

Das Modul erweitert vorhandene Magento-Datenobjekte

Die zusätzlichen Daten können als Extension Attributes in bekannten Produkt-, Kunden- oder Bestellantworten erscheinen. Ob dies zuverlässig funktioniert, hängt von der konkreten Implementierung ab.

Das Modul verwendet nur interne Tabellen und Models

Dann gibt es keinen direkten REST-Zugriff. Für eine MCP-Anbindung wird ein zusätzlicher Magento-Service benötigt.

Ein typisches Beispiel wäre ein Reklamationsmodul. Es verwaltet Fälle in einer eigenen Tabelle mit Bestellnummer, Status, zuständigem Mitarbeiter und interner Bewertung. Ohne veröffentlichten Service kann der MCP-Server diese Informationen nicht über die Magento-REST-API abrufen.

Wann ein eigener Magento-Endpunkt sinnvoll wird

Magento Open Source und Adobe Commerce stellen zahlreiche REST-Endpunkte bereit. Adobe dokumentiert zugleich die Möglichkeit, eigene APIs für individuelle Moduldaten und besondere Anwendungsfälle zu entwickeln. Ein solcher Endpunkt basiert üblicherweise auf einem Service Contract, einer Route und einer eigenen ACL-Ressource.

Ein eigener lesender Endpunkt ist besonders sinnvoll, wenn

Daten ausschließlich in einer eigenen Tabelle liegen,
mehrere Magento-Objekte verbunden werden müssen,
Listen-Endpunkte wichtige Attribute nicht ausgeben,
sehr viele einzelne Detailabfragen notwendig wären,
interne Codes vor der Ausgabe übersetzt werden sollen,
nur ausgewählte Felder an den MCP-Server gelangen dürfen,
umfangreiche Daten bereits in Magento gefiltert werden können,
eine fachliche Berechnung Magento-Geschäftslogik benötigt.

Eine mögliche Nutzerfrage verdeutlicht den Bedarf:

Welche aktiven Gefahrgutprodukte haben weniger als zehn verkaufbare Einheiten und wurden innerhalb der letzten 90 Tage bestellt?

Für die Antwort werden Produktattribute, Lagerdaten, Bestellungen und Bestellpositionen benötigt. Die vorhandenen REST-Endpunkte können viele dieser Einzelinformationen bereitstellen. Die vollständige Auswertung würde jedoch mehrere Suchen, Zuordnungen und Detailabfragen erfordern.

Ein spezialisierter Endpunkt könnte direkt eine kleine Ergebnisliste ausgeben:

{
  "items": [
    {
      "sku": "ABC-123",
      "name": "Industrieprodukt 123",
      "salable_quantity": 6,
      "last_order_date": "2026-06-18"
    }
  ]
}

Das Sprachmodell erhält nur die Informationen, die es für die Antwort benötigt.

Welche Logik gehört in Magento und welche in den MCP-Server

Eine klare Aufgabenteilung erleichtert Wartung und Fehlersuche.

Magento sollte die Magento-spezifische Datenlogik übernehmen. Dazu gehören Berechtigungen, Datenbankzugriffe, Service Contracts, Geschäftsregeln und effiziente Filter.

Der MCP-Server übernimmt die Verbindung zum KI-Client. Er beschreibt verfügbare Tools, validiert Eingaben, ruft freigegebene Magento-Endpunkte auf und bereitet Ergebnisse für das Sprachmodell auf.

Aufgabe	Geeignete Ebene
Daten aus einer eigenen Magento-Tabelle lesen	Magento
Lagerbestand nach Magento-Regeln berechnen	Magento
Nutzerfrage in Suchparameter übersetzen	MCP-Server
Mehrere einfache API-Abfragen koordinieren	MCP-Server
Große Datenmengen vorfiltern	Magento
Fachliche Ergebnisse zusammenfassen	KI-Client
Zugriffe protokollieren	Magento und MCP-Server

Diese Trennung verhindert, dass Magento-Geschäftslogik mehrfach im MCP-Server nachgebaut wird.

Fazit

Viele individuelle Produkt- und Kundenattribute können bereits über vorhandene Magento-Endpunkte abgerufen werden. Ob dies für einen MCP-Anwendungsfall ausreicht, zeigt jedoch erst eine Prüfung des konkreten Shops.

Besondere Aufmerksamkeit benötigen Listenabfragen, Extension Attributes und Daten aus Drittmodulen. Ein im Backend sichtbares Feld garantiert noch keine vollständige REST-Ausgabe.

Eigene Magento-Endpunkte werden dann interessant, wenn Daten fehlen, über zahlreiche Abfragen verteilt sind oder bereits vor der Übergabe an den KI-Assistenten gefiltert und zusammengeführt werden sollten.

Eine saubere Lösung beginnt daher mit der Datenquelle und dem fachlichen Anwendungsfall. Erst danach wird entschieden, ob eine Anpassung im MCP-Server genügt oder Magento um einen kontrollierten, lesenden Service erweitert werden sollte.