Das Model Context Protocol hat den Weg von interessant zu strukturell schneller zurückgelegt als die meisten Integrationsstandards. Shopify liefert MCP-Server an jeden Shop aus; die großen Assistenten können Tools in externen Systemen aufrufen; und ein spürbarer Teil des Web-Traffics kommt inzwischen von etwas Automatisiertem statt von einer Person, die surft.
Wer eine Commerce-Plattform oder ein SaaS-Produkt betreibt, steht damit vor einer praktischen Frage mit einer nicht offensichtlichen Antwort: Sie haben bereits eine API — warum braucht ein Agent etwas anderes?
Warum Ihre REST-API nicht ausreicht
Eine REST-API ist für Entwickler gemacht, die eine Dokumentation lesen, Ihre Domäne verstehen und Code schreiben, der die richtigen Endpoints in der richtigen Reihenfolge aufruft. Ein Agent hat keinen dieser Vorteile. Er hat eine Tool-Liste, eine Beschreibung je Tool und einen Versuch, richtig zu wählen.
Die Unterschiede, auf die es ankommt:
- Discovery. Ein Agent muss zur Laufzeit aus der Schnittstelle selbst lernen, was Ihr System kann. Ihre OpenAPI-Spezifikation beschreibt Endpoints; sie beschreibt keine Absicht.
- Granularität. REST-APIs sind ressourcenorientiert: Bestellung abrufen, Kunden abrufen, Positionen abrufen, selbst zusammenführen. Ein Agent will einen Aufruf, der beantwortet, wie der Status der letzten Bestellung dieses Kunden ist — aufgabenorientiert, nicht ressourcenorientiert.
- Mehrdeutigkeit. Entwickler lösen das blaue, Größe M auf, indem sie Ihr Variantenmodell lesen. Ein Agent braucht ein Tool, das diese Formulierung annimmt und die Auflösung selbst übernimmt.
- Fehlerbehandlung. Ein
422mit einem Validierungsobjekt hilft Entwicklern. Ein Agent braucht einen Fehler, der in Worten sagt, was er anders machen soll. - Schadensradius. Der Fehler eines Entwicklers wird von der Testsuite abgefangen. Der Fehler eines Agenten passiert in Produktion, im Namen eines Kunden, in hohem Tempo.
Ein MCP-Server ist kein Wrapper um Ihre API. Er ist eine andere Schnittstelle für einen anderen Konsumenten, die zufällig auf derselben Domänenlogik aufsetzt.
Entwerfen Sie die Tools um Aufgaben herum, nicht um Ressourcen
Ob ein Agent Ihr Produkt gut nutzt, hängt vor allem davon ab, wie Sie die Tools benennen und zuschneiden. Wenige, gut beschriebene, aufgabenorientierte Tools sind besser als eine getreue Abbildung Ihres Datenmodells.
Der Startsatz eines Commerce-Produkts sieht meist so aus:
- search_products — natürlichsprachige Abfrage hinein, nach Relevanz sortierte Ergebnisse mit den Attributen heraus, die man zur Auswahl braucht. Kein roher Katalogauszug.
- get_product_details — alles, was für die Entscheidung nötig ist: Varianten, Verfügbarkeit, erwarteter Liefertermin, Retourenbedingungen.
- check_availability — Menge und Standort, direkt beantwortet statt aus einem Bestandsobjekt abgeleitet.
- get_order_status — die Frage, die Kunden tatsächlich stellen, in einem Aufruf beantwortet.
- start_return — ein abgesicherter Schreibzugriff, der Ihren tatsächlichen Anspruchsregeln unterliegt.
- get_policy — Retouren-, Versand- und Garantiebedingungen als Text, damit der Agent Ihre Richtlinie zitiert und nicht seinen Eindruck davon.
Schreiben Sie die Tool-Beschreibungen wie für einen fähigen neuen Kollegen an dessen erstem Arbeitstag: was das Tool tut, wann man es einsetzt, wann nicht, und was es ablehnen wird. Diese Beschreibungen sind das gesamte Handbuch, das der Agent je zu lesen bekommt, und sie tragen mehr zur Korrektheit bei als jede Modellqualität.
Geben Sie Ablehnungen zurück, aus denen der Agent lernt. No product matched. Try a broader query, or call search_products with fewer attribute filters. ist mehr wert als ein 404, weil der Agent damit etwas anfangen kann.
Was niemals ein Tool sein darf
Was Sie weglassen, zählt mehr als das, was Sie aufnehmen: Ein Tool, das Sie bereitstellen, wird irgendwann auf eine Weise aufgerufen, die Sie nicht vorhergesehen haben.
- Alles, was Zahlungsmittel berührt. Tokenisieren, delegieren und Kartendaten vollständig außerhalb der Agentenfläche halten.
- Massenexport von Daten. Ein Tool, das Ihren gesamten Katalog oder Ihre Kundenliste zurückgeben kann, ist ein Scraping-Endpoint mit besseren Manieren.
- Administrative Operationen. Preisänderungen, Bestandskorrekturen, Benutzerverwaltung. Was in Ihrem Backend liegt, gehört nicht in Ihren MCP-Server.
- Alles ohne Rechteprüfung pro Mandant, serverseitig durchgesetzt bei jedem einzelnen Aufruf.
- Kundenübergreifende Abfragen. Ein Agent, der für einen Kunden handelt, muss strukturell außerstande sein, die Daten eines anderen zu sehen — nicht bloß unwahrscheinlich danach fragen.
Behandeln Sie jedes Argument, das ein Agent sendet, als nicht vertrauenswürdige Benutzereingabe — genau das ist es, denn es stammt aus etwas, das eine Person getippt hat. Prompt Injection erreicht Sie über Tool-Argumente. Validieren Sie serverseitig genau so, wie Sie es bei einem öffentlichen Formular tun würden.
Authentifizierung, Berechtigungen und Limits
Hier sind die meisten Implementierungen am schwächsten, weil der interessante Teil der Tool-Entwurf ist und der mühsame Teil alles andere.
- Authentifizieren Sie den Agenten, und stellen Sie getrennt davon fest, für wen er handelt. Das sind zwei verschiedene Tatsachen, und sie zu vermischen ist der Weg, auf dem Zugriffe über Kundengrenzen hinweg entstehen.
- Schneiden Sie Zugangsdaten eng zu. Ein Agent, der Produkte sucht, braucht keinen Zugriff auf die Bestellhistorie. Vergeben Sie Zugangsdaten je Zweck und lassen Sie sie ablaufen.
- Setzen Sie Rate Limits pro Mandant und pro Tool. Agenten wiederholen Aufrufe mit Begeisterung. Ein Limit, das für einen Menschen großzügig ist, überschreitet eine Schleife mühelos.
- Protokollieren Sie jeden Aufruf mit Argumenten und Ergebnis. Wenn etwas schiefgeht, müssen Sie genau nachvollziehen können, was gefragt und was zurückgegeben wurde. Dieses Protokoll ist zugleich Ihre erste Verteidigungslinie gegen Missbrauch.
- Versionieren Sie Ihre Tools. Wer das Verhalten eines Tools stillschweigend ändert, bricht Agenten, die gelernt haben, sich darauf zu verlassen — und anders als bei einer Entwickler-Integration liest niemand Ihr Changelog.
- Geben Sie Schreib-Tools Idempotency Keys. Ein Agent, der in ein Timeout läuft und es erneut versucht, darf nicht zwei Retouren anlegen.
Die Daten darunter entscheiden alles
Ein MCP-Server stellt Ihre Produktdaten bereit. Sind diese Daten dünn, inkonsistent oder falsch, gibt der Agent sie getreu wieder — überzeugt, schnell und direkt an den Kunden.
Bevor Sie die Schnittstelle bauen, sollten Sie ehrlich prüfen, ob der Katalog dahinter sie trägt. Vollständigkeit der Attribute, eine konsistente Taxonomie, korrekte Daten zu Lagerbestand und Lieferung sowie Retourenbedingungen, die als strukturierter Text und nicht als PDF vorliegen, sind allesamt Voraussetzungen. Wir haben die Pipeline beschrieben, mit der wir einen Katalog in diesen Zustand bringen; sie ist unspektakulär, und sie ist das eigentliche Projekt.
Lohnt sich das jetzt schon?
Eine ehrliche Einschätzung, denn das Feld bewegt sich schnell, und früh dran zu sein kostet tatsächlich etwas.
Bauen Sie jetzt, wenn: Sie auf einer Plattform arbeiten, die MCP bereits bereitstellt, und diese erweitern; Ihr Produkt sich an Entwickler richtet, wo agentengestützte Nutzung längst normal ist; oder Sie etwas verkaufen, von dem ein Assistent plausibel im Auftrag eines Kunden gebeten wird, es zu finden.
Warten Sie, wenn: Ihre Produktdaten noch nicht in einem Zustand sind, in dem Sie sie eine Maschine gern wörtlich zitieren lassen würden; Ihnen die Kapazität fehlt, eine live geschaltete Agentenfläche zu überwachen und weiterzuentwickeln; oder Ihre Kunden Sie nachweislich nicht auf diesem Weg erreichen — nachgeprüft, nicht angenommen.
In beiden Fällen: Erledigen Sie die Vorarbeit jetzt. Saubere Produktdaten, strukturierte Richtlinien und eine aufgabenorientierte Domänen-API sind wertvoll, unabhängig davon, welches Protokoll sich durchsetzt, und sie dauern am längsten. Die MCP-Schicht obendrauf ist vergleichsweise schnell fertig.
Unsere Node.js-Entwicklung baut solche Schnittstellen, und die größere Frage, wo Agentenkanäle in eine Commerce-Strategie gehören, beantworten unsere KI-Integration und unser KI-Engineering-Team. Wenn Ihre Priorität darin liegt, von Assistenten gefunden zu werden, statt über sie zu verkaufen, ist das ein verwandtes, aber anderes Projekt — siehe Ihre Produkte von ChatGPT und Perplexity empfehlen lassen.
Häufige Fragen
Was ist ein MCP-Server, einfach erklärt?
Eine standardisierte Schnittstelle, über die ein KI-Assistent zur Laufzeit Tools in Ihrem System finden und aufrufen kann. Anders als eine REST-API ist sie darauf ausgelegt, von einem Modell verstanden zu werden, das Tool-Beschreibungen liest — und nicht von Entwicklern, die eine Dokumentation lesen.
Können wir einen Agenten einfach auf unsere bestehende REST-API richten?
Sie können, und es wird schlecht funktionieren. REST-APIs sind ressourcenorientiert und setzen Entwickler voraus, die Ihre Domäne verstehen; Agenten brauchen aufgabenorientierte Tools, Beschreibungen, die auch sagen, wann man sie nicht einsetzt, und Fehler, die als Anweisung formuliert sind statt als Statuscode.
Welche Sicherheitsrisiken gibt es?
Vor allem zu weit geöffnete Schnittstellen und Prompt Injection. Jedes Tool-Argument stammt letztlich aus etwas, das eine Person getippt hat: Validieren Sie es serverseitig als nicht vertrauenswürdige Eingabe, prüfen Sie die Rechte pro Mandant bei jedem Aufruf statt nur zu Sitzungsbeginn, und stellen Sie niemals Massenexporte oder administrative Operationen bereit.
Wie verhindern wir, dass ein Agent teure Fehler macht?
Halten Sie die Zahl der Schreib-Tools klein und sichern Sie sie eng ab; die Grenzen setzt das Tool selbst durch, statt sie in einem Prompt zu beschreiben. Vergeben Sie Idempotency Keys, damit ein erneuter Versuch keine Aktion doppelt auslöst, und protokollieren Sie jeden Aufruf, damit Sie nachvollziehen können, was passiert ist.
Ist es zu früh, hier zu investieren?
Die MCP-Schicht ist der schnelle Teil, und die Standards bewegen sich noch — früh dran zu sein bringt also ein gewisses Risiko für Nacharbeit mit sich. Die Voraussetzungen — saubere Produktdaten, strukturierte Richtlinien, eine aufgabenorientierte Domänen-API — bringen keines mit sich, und sie dauern am längsten. Fangen Sie in jedem Fall dort an.
Beginnen Sie mit der Tool-Liste
Bevor Sie eine Zeile Code schreiben, notieren Sie die sechs Dinge, die ein Agent mit Ihrem Produkt tun können soll, und die sechs, die er niemals tun darf. Dieses Dokument ist der größte Teil des Entwurfs. Wir schreiben es gemeinsam mit Ihnen. Sprechen Sie mit unserem Team; wir antworten innerhalb eines Werktags.