MCP: was das Protokoll für Unternehmen bedeutet

Wer KI-Assistenten an eigene Systeme anbinden wollte, hat das bisher je Assistent und je System einzeln gebaut. Das Model Context Protocol — kurz MCP — standardisiert diesen Weg: Ein System stellt seine Fähigkeiten einmal bereit, verschiedene Assistenten können sie nutzen.

Das ist eine Architekturfrage, keine KI-Frage. Und sie ist die Sorte Architekturfrage, deren Wirkung man erst nach dem dritten Assistenten sieht.

Was sich dadurch ändert

Vorher: Drei Assistenten und vier Systeme bedeuten bis zu zwölf Anbindungen, jede mit eigener Wartung, eigener Authentifizierung und eigenem Fehlerverhalten.

Nachher: Vier Server, einer je System. Jeder Assistent, der das Protokoll spricht, kann sie nutzen.

Das ist derselbe Gedanke, der Schnittstellen im Web groß gemacht hat: nicht mehr Funktionalität, sondern weniger Sonderfälle.

Was ein solcher Server anbietet

Drei Arten von Dingen:

Werkzeuge — Aktionen, die etwas tun: eine Bestellung suchen, einen Bestand ändern, ein Dokument erzeugen. Das sind die, bei denen die Rechtefrage brennt.

Ressourcen — Daten, die gelesen werden: Produktlisten, Dokumente, Protokolle. Lesen ist harmloser, aber nicht harmlos: Auch ein Lesezugriff auf Kundendaten ist ein Zugriff auf Kundendaten.

Vorlagen — vorbereitete Abläufe für wiederkehrende Aufgaben, damit der Assistent nicht jedes Mal neu erraten muss, wie etwas gemeint ist.

Was in Shopware davon schon da ist

Wir haben in einer eigenen Runtime nachgezählt, statt Ankündigungen zu zitieren:

Dazu kommen fünf Controller, fünf Admin-Routen, eine Store-Route und 48 CRUD-Routen, über die der Zugriff läuft. Wie wir das erhoben haben und was genau im Kern steckt, steht in Shopware hat einen MCP-Server. Das ist ein solider Anfang und kein fertiges Produkt: Dreizehn Werkzeuge decken die häufigsten Abfragen ab, nicht Ihre Sonderfälle.

Was sich nicht ändert

Das ist der Teil, der in Ankündigungen fehlt, und er ist der wichtigere.

Rechte

Ein Protokoll regelt die Sprache, nicht die Befugnis. Wer darf welche Werkzeuge aufrufen? Mit wessen Konto? Darf der Assistent, der für den Kundenservice eingerichtet wurde, Preise ändern?

Protokollierung

Wenn ein Assistent eine Bestellung ändert, muss nachvollziehbar sein, wer das veranlasst hat. Nicht „der Assistent", sondern welcher Mensch mit welcher Absicht. Das ist keine technische Feinheit, sondern die Grundlage jeder Prüfung — von der internen Revision bis zur Frage eines Kunden, warum seine Bestellung storniert wurde.

Datenqualität

Ein Assistent, der falsche Bestandsdaten liest, gibt falsche Auskunft — schneller und überzeugender als vorher. Das Protokoll transportiert, was da ist; es prüft nicht, ob es stimmt. Warum das die eigentliche Voraussetzung ist, steht in Datenqualität als Voraussetzung jeder Integration.

Was ein MCP-Server von einer API unterscheidet

Die berechtigte Rückfrage lautet: Wir haben doch schon eine Schnittstelle — wozu noch eine Schicht?

Der Unterschied liegt nicht in der Funktion, sondern in der Beschreibung. Eine klassische API beschreibt sich für Entwickler: Endpunkte, Parameter, Rückgabetypen. Ein MCP-Server beschreibt sich für ein Modell: Was kann dieses Werkzeug, wann soll man es benutzen, was bedeuten seine Felder in Worten.

Das klingt nach Dokumentation und ist mehr: Diese Beschreibung ist maschinenlesbar und wird zur Laufzeit mitgeliefert. Ein Assistent, der den Server noch nie gesehen hat, kann daraus ableiten, welches Werkzeug zu einer Frage passt.

Drei Fehler, die wir bei frühen Anbindungen sehen

Zu viele Werkzeuge. Wer dreißig Werkzeuge anbietet, macht die Auswahl schwerer statt leichter. Fünf gut beschriebene schlagen dreißig, die sich überschneiden.

Werkzeuge, die zu viel auf einmal tun. Ein Werkzeug, das sucht und ändert und benachrichtigt, lässt sich nicht sauber berechtigen — und im Fehlerfall nicht sauber zurückdrehen.

Keine Obergrenzen. Eine Abfrage ohne Begrenzung liefert im Zweifel zehntausend Datensätze in ein Modell, das damit nichts anfangen kann. Jedes lesende Werkzeug braucht eine Voreinstellung und ein Maximum.

Was das für Shopbetreiber heißt

Die rechte Spalte ist kein Argument gegen MCP, sondern eine Reihenfolge: Wer Punkt 2 und 3 nicht geklärt hat, sollte sie klären — das ist ohnehin fällig und unabhängig von jedem Protokoll nützlich.

Wie wir vorgehen, wenn wir so etwas bauen

Die Frage, die Sie zuerst beantworten sollten

Nicht „brauchen wir MCP", sondern: Welche Frage wird bei uns so oft an ein System gestellt, dass sie jemanden beschäftigt?

Wenn die Antwort lautet „welcher Bestand steht für Artikel X" oder „wann geht die Bestellung von Kunde Y raus", dann gibt es einen Anwendungsfall — und der ist auch ohne Protokoll ein Argument, die Schnittstelle sauber zu machen. Was dabei sonst noch zu klären ist, steht in Schnittstellen dokumentieren, bevor sie brechen.

Wenn Sie überlegen, ob sich so etwas für Ihr System lohnt: Wir sehen uns an, welche Schnittstellen vorhanden sind und welche Fragen tatsächlich anfallen — und sagen auch, wenn eine gute Dokumentation der vorhandenen API den größeren Teil des Nutzens schon liefert. Mehr dazu unter App- und Plugin-Entwicklung.