MCP im Agentic-Commerce-Stack
Ein nützlicher Vergleich: MCP ist die USB-Buchse zwischen Agent und Ihren Systemen. Statt für jedes Tool eine eigene Integration zu bauen, sprechen Agent und Tool ein gemeinsames Protokoll. Während A2A Agenten untereinander verbindet, verbindet MCP einen Agenten mit Werkzeugen.
- Nach innen (MCP): Agent → Produktkatalog, Verfügbarkeit, Preis-API, Bestellsystem.
- Nach außen (A2A): Verkaufs-Agent ↔ Einkaufs-Agent.
- Zahlung (AP2 / ACP): Transaktion absichern und abschließen.
Woraus ein MCP-Server besteht
Ein MCP-Server stellt einem Agenten drei Arten von Fähigkeiten bereit. Die Unterscheidung ist praktisch relevant, weil sie bestimmt, was der Agent selbstständig tun darf:
| Primitiv | Bedeutung | Beispiel im Handel |
|---|---|---|
| Tools | Aktionen, die der Agent ausführen kann – mit Nebenwirkungen | check_availability, create_quote, place_order |
| Resources | Daten, die der Agent lesen kann – ohne Nebenwirkungen | Produktkatalog, Kategoriebaum, Versandkonditionen |
| Prompts | Vorformulierte Abläufe, die der Server anbietet | „Produktberatung für Anwendungsfall X“ |
Der entscheidende Unterschied zu einer gewöhnlichen REST-API: Ein MCP-Server beschreibt sich selbst. Der Agent fragt beim Verbinden ab, welche Tools existieren, welche Parameter sie erwarten und was sie zurückgeben. Es braucht keine vorherige Integration und keine Dokumentation, die jemand gelesen hat.
Beispiel: Tool-Definition eines Commerce-MCP-Servers{
"name": "check_availability",
"description": "Prüft Verfügbarkeit und tagesaktuellen Preis für eine SKU.
Liefert Lieferzeit in Werktagen und Staffelpreise ab Menge 10.",
"inputSchema": {
"type": "object",
"properties": {
"sku": { "type": "string", "description": "Artikelnummer, z. B. XY-500" },
"quantity": { "type": "integer", "minimum": 1, "default": 1 },
"postalCode": { "type": "string", "description": "PLZ für Lieferzeitberechnung" }
},
"required": ["sku"]
}
}
Die description ist hier kein Kommentar, sondern funktionaler Code: Sie ist der
Text, anhand dessen das Modell entscheidet, ob dieses Tool zur Anfrage passt. Eine vage
Beschreibung („prüft Produkte“) führt dazu, dass der Agent das Tool nicht oder falsch
aufruft. Präzise Beschreibungen mit Einheiten, Grenzen und Rückgabeformat sind der
wirksamste Hebel für die Qualität einer MCP-Anbindung – und der am häufigsten
vernachlässigte.
Was ein Commerce-MCP-Server anbieten sollte
Die Versuchung ist groß, den gesamten Shop zu exponieren. Sinnvoller ist ein knapper Satz von Tools, der genau die Fragen beantwortet, die vor einer Kaufentscheidung stehen:
- Suchen und Filtern nach fachlichen Attributen, nicht nur Volltext – ein Agent sucht nach Eignung, nicht nach Marketingbegriffen.
- Verfügbarkeit und Preis in Echtzeit, inklusive Staffeln und Lieferzeit ab Postleitzahl.
- Kompatibilität und Alternativen – gerade im B2B oft der eigentliche Entscheidungsgrund.
- Angebot oder Bestellung anlegen, sauber getrennt von den lesenden Operationen.
Transport, Authentifizierung und Sicherheit
MCP-Server laufen entweder lokal über stdio oder als Remote-Server über
HTTP. Für den Handel ist praktisch nur der Remote-Fall relevant: Der Server läuft bei Ihnen,
fremde Agenten verbinden sich darauf. Damit gelten die üblichen Anforderungen an einen
öffentlichen Endpunkt – plus einige, die im Agenten-Kontext neu sind:
- Schreiben und Lesen trennen. Ein anonymer Agent darf suchen und Preise prüfen. Bestellungen anlegen darf nur ein authentifizierter Aufrufer. Diese Trennung gehört in die Tool-Struktur, nicht in eine Prüfung innerhalb eines Sammel-Tools.
- Rate Limits nach Aufrufer. Agenten fragen anders als Menschen: viele Aufrufe in kurzer Zeit, oft breit streuend. Ohne Limits ist Ihr Katalog eine kostenlose Preisvergleichs-API für den Wettbewerb.
- Beschreibungen als Angriffsfläche behandeln. Tool-Beschreibungen und Rückgabewerte landen im Kontext des Modells. Werden dort ungefilterte Nutzerinhalte ausgegeben – etwa Produktbewertungen –, ist das ein Einfallstor für Prompt Injection. Ausgaben sollten dieselbe Sorgfalt erfahren wie HTML-Escaping im Web.
- Nur exponieren, was gebraucht wird. Interne Margen, Bezugskosten oder Lagerorte gehören nicht in ein Tool, nur weil sie im selben Datensatz stehen.
MCP oder klassische API?
| REST-API | MCP-Server | |
|---|---|---|
| Entdeckung | Über Dokumentation, von Menschen gelesen | Zur Laufzeit, vom Agenten abgefragt |
| Integration | Muss pro Konsument geschrieben werden | Einmal bereitgestellt, von jedem MCP-Client nutzbar |
| Semantik | Im Zweifel implizit | Explizit in Beschreibungen und Schemata |
| Reifegrad | Zwei Jahrzehnte Werkzeuge und Praxis | Jung, Ökosystem noch in Bewegung |
Die Entscheidung ist kein Entweder-oder. Ein MCP-Server lässt sich als dünne Schicht über eine bestehende Katalog-API legen; die Arbeit steckt weniger im Transport als in den präzisen Beschreibungen und der Frage, welche Operationen ein fremder Agent überhaupt auslösen darf.
Grenzen – was MCP nicht löst
MCP regelt den Zugriff auf Werkzeuge, sonst nichts. Es enthält keine Zahlungslogik: Ein Kauf wird über ACP oder AP2 abgeschlossen. Es sorgt nicht dafür, dass ein Agent Sie findet – dafür braucht es auffindbare, strukturierte Daten im offenen Web. Und es ersetzt keine Datenqualität: Ein MCP-Server über einem lückenhaften Katalog liefert lückenhafte Antworten, nur schneller.
Was das für Händler heißt
Wer einen MCP-Zugang zu seinem Sortiment bereitstellt, macht es Agenten leicht, korrekte, aktuelle Informationen zu ziehen – statt sich auf veraltete oder halb verstandene Webseiten zu verlassen. Das erhöht die Chance, dass ein Agent Ihr Produkt überhaupt korrekt vergleicht und auswählt. Als Reihenfolge bewährt: erst die Datenbasis und Auffindbarkeit klären, dann den MCP-Server als Echtzeit-Ergänzung darüberlegen. Umgekehrt investiert man in eine Schnittstelle, die niemand ansteuert.