Was ist ein ERP MCP-Server?

Ein Server, der ein System in Werkzeuge verwandelt

Das Model Context Protocol hat drei Rollen. Ein Host ist eine KI-Anwendung wie Claude oder ChatGPT. Innerhalb des Hosts wird pro Server ein Client erstellt, der nur mit diesem Server kommuniziert. Ein Server ist ein Dienst, der dem Host durch eine kleine Anzahl von Primitiven Kontext und Fähigkeiten bietet. Die Entwurfsprinzipien der Spezifikation besagen, dass Server einfach zu erstellen, zusammensetzbar und nicht in der Lage sein sollten, die gesamte Konversation oder andere Server zu sehen; der Host behält die Konversation und setzt die Zustimmung durch, der Server sieht nur die an ihn gerichteten Anrufe.

Ein ERP MCP-Server ist daher nicht das ERP. Es ist die Aktionsoberfläche des ERPs, ausgedrückt als Werkzeuge mit typisierten Eingaben, die unter einer URL bereitgestellt werden. Die interessante Designentscheidung ist, was ein Werkzeug ist. Ein Wetterserver hat eines; ein Geschäftssystem hat Hunderte, und die nützlichen sind Aktionen, die eine Person durchführen könnte (eine Rechnung erstellen, eine Zahlung erfassen, einen Deal verschieben, Lagerbestand reservieren) anstatt Zeilen in Tabellen. Der Workspace-Server von Sois veröffentlicht beispielsweise Werkzeuge mit Namen wie Rechnung erstellen, Zahlung erfassen, searchContacts und Kontakt prüfen gruppiert nach Modul, und die genaue Liste, die ein Anrufer erhält, hängt davon ab, wer er ist.

Werkzeuge, Ressourcen und Eingabeaufforderungen

Die Spezifikation definiert drei Server-Primitiven, die sich darin unterscheiden, wer ihre Nutzung kontrolliert. Werkzeuge sind modellgesteuert: das Modell entscheidet, wann eines aufgerufen wird. Ressourcen sind anwendungsgetrieben: der Host entscheidet, welchen Kontext er anfügt, oft mit der Auswahl des Benutzers aus einer Liste. Eingabeaufforderungen sind benutzergesteuerte Vorlagen. Ein ERP benötigt das erste, kann vom zweiten profitieren und benötigt selten das dritte.

Zwei Merkmale der Werkzeugergebnisse sind für ein Geschäftssystem wichtig. Ein Werkzeug kann deklarieren, dass ein Ausgabeschema und zurückgeben strukturierter Inhalt der dem entspricht, zusammen mit dem Text, den ein Modell liest, sodass eine Integration das Ergebnis ohne das Parsen von Prosa verwenden kann. Und ein Werkzeug, das aus geschäftlichen Gründen fehlschlägt (eine Rechnung im falschen Zustand, ein Datum in der Vergangenheit, eine fehlende Berechtigung), gibt ein normales Ergebnis mit zurück isError: true und einer Erklärung zurück, anstatt eines Protokollfehlers, sodass das Modell seine Eingabe korrigieren und es erneut versuchen kann. Protokollfehler sind für fehlerhafte Anfragen und unbekannte Werkzeuge reserviert.

Der Transport und die aktuelle Spezifikation

Zwei Transportarten sind standardmäßig. Stdio ist für einen Server, den der Client als lokalen Prozess startet, was der Funktionsweise von Desktop-Werkzeugen wie dem Dateizugriff entspricht. Streamable HTTP ist für Remote-Server und wird von einem ERP verwendet: Der Server stellt einen Endpunkt bereit, der eine HTTP-POST-Anfrage pro JSON-RPC-Nachricht akzeptiert und entweder mit einem JSON-Objekt oder einem Server-Sent Events-Stream antwortet, der auf diese Anfrage beschränkt ist, sodass ein langer Aufruf Fortschritte senden kann, bevor das endgültige Ergebnis vorliegt. Der frühere HTTP-Transport mit SSE ist veraltet.

Die aktuelle Revision, 2026-07-28, hat den Transport in einer Weise geändert, die für jeden, der einen Server hinter einem Lastenausgleich bereitstellt, von Bedeutung ist. Sie hat die Protokollebene-Sitzungen entfernt: Es gibt keinen Initialisierungs-Handschlag oder einen Sitzungsbezeichner-Header mehr, jede Anfrage trägt ihre Protokollversion und Client-Fähigkeiten in ihren eigenen Metadaten, und ein Server, der Zustand über Aufrufe hinweg benötigt, gibt einen expliziten Handle zurück, den das Modell als Argument übergibt. Server, die gegen die Revision vom 2025-11-25 geschrieben wurden, die Sitzungen verwendeten, funktionieren weiterhin, da die Clients verpflichtet sind, die ältere Ära zu erkennen und zurückzufallen; ein neuer Server sollte keine Sitzungen übernehmen.

Autorisierung: Für wen der Anruf ist

Für HTTP-Transporte definiert die Spezifikation einen OAuth 2.1-Flow. Der Server ist ein Ressourcenserver und muss geschützte Ressourcenmetadaten (RFC 9728) veröffentlichen, die seinen Autorisierungsserver benennen; wenn eine Anfrage ohne Token eintrifft, antwortet er mit 401 und einem WWW-Authenticate-Header, der auf diese Metadaten verweist und idealerweise den geringsten benötigten Scope angibt. Der Client entdeckt die Endpunkte des Autorisierungsservers, identifiziert sich (Dokumente zu Client-ID-Metadaten sind der empfohlene Weg; die dynamische Registrierung bleibt aus Kompatibilitätsgründen erhalten), führt einen Autorisierungscode-Flow mit PKCE durch und muss die kanonische URI des Servers als Ressourcenparameter einfügen, damit das Token nur an diesen Server gebunden ist. Der Server muss dieses Publikum validieren, muss Tokens, die für etwas anderes ausgestellt wurden, ablehnen und darf niemals ein Token an einen anderen Dienst weitergeben.

Die Konsequenz für ein ERP ist die wichtige. Da das Token eine Person identifiziert, kann der Server das Ergebnis von tools/list den Anmeldeinformationen in der Anfrage variieren, und die Spezifikation sagt dies ausdrücklich. Das ist der Mechanismus für rollenbasiertes Filtern: Die Liste eines Finanznutzers und die Liste eines Lagerbenutzers stammen vom selben Server und sind unterschiedlich. Unzureichender Scope zur Laufzeit wird mit einem 403 und einer Scope-Herausforderung signalisiert, von der der Client aufsteigen kann, obwohl für die meisten Geschäftssysteme die tatsächliche Grenze die Rolle im ERP und nicht der grobe OAuth-Scope ist.

Der schwierige Teil: Berechtigungen und Transaktionen

Alles oben Genannte kann an einem Nachmittag mit einem SDK implementiert werden. Was einen ERP MCP-Server von einer Demo trennt, ist die Behandlung der beiden Dinge, die das Protokoll dem Server überlässt: ob ein Aufruf erlaubt ist und was ein Aufruf bedeutet.

Die Berechtigung muss zweimal überprüft werden. Das Filtern der Tool-Liste verhindert, dass das Modell etwas auswählt, das es nicht sollte, was Tokens und Verwirrung spart. Eine erneute Überprüfung, wenn das Tool ausgeführt wird, ist die tatsächliche Grenze, da ein Client jeden beliebigen Aufruf senden kann. Eine Ablehnung wird am besten als Fehler bei der Toolausführung zurückgegeben, sodass das Modell es liest und meldet, anstatt als Transportfehler, der den Zug beendet. So sieht ein abgelehnter Aufruf aus einem Sois-Arbeitsbereich aus: ein normales Ergebnis, markiert, mit einem Grund.

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Tool not permitted for this account: approveInvoice requires the finance approver role."
      }
    ],
    "isError": true
  }
}

Eine Berechtigungsablehnung, die als Fehler bei der Toolausführung zurückgegeben wird. Das Modell lernt, warum, und kann die Person stattdessen um Genehmigung bitten; es wurde nichts geschrieben. Sois reserviert auch JSON-RPC-Fehlercodes für nicht autorisierte Sitzungen, unzureichende Guthaben, nicht erlaubte Tools und erreichte Budgetobergrenzen.

Transaktionen sind die zweite Hälfte. Ein Tool sollte einer Geschäftstransaktion mit einem klaren Vorher und Nachher zugeordnet werden: Rechnung erstellen erzeugt einen Entwurf mit einer Kennung, Zahlung erfassen wendet eine Zahlung auf eine Rechnung an, und keiner hinterlässt einen halbgeschriebenen Zustand, wenn er fehlschlägt. Modelle wiederholen, daher sollten Schreibvorgänge sicher wiederholt werden können oder eine Wiederholung mit einer klaren Nachricht ablehnen; die Anmerkungen der Spezifikation ermöglichen es einem Server, ein Tool als schreibgeschützt, idempotent oder destruktiv zu deklarieren, und Clients wie ChatGPT verwenden diese Hinweise, um zu entscheiden, ob sie um Bestätigung bitten sollen. Wo ein Schritt eine Entscheidung erfordert, die über die Autorität des Agenten hinausgeht, kann der Server ein Ergebnis zurückgeben, das eine Eingabe erfordert und die Person über den Client eine Frage stellt, anstatt zu raten.

Wie Sois eine implementiert

Ein Sois-Arbeitsbereich ist ein MCP-Server unter einer einzigen URL, gefolgt von der Arbeitsbereichsadresse: /api/mcp. Es beantwortet die 401-Herausforderung mit Metadaten geschützter Ressourcen, veröffentlicht die Metadaten seines Autorisierungsservers, erfordert PKCE und gibt Tokens aus, die auf den Arbeitsbereich beschränkt sind; ein Connector in Claude oder ChatGPT vervollständigt die Anmeldung ohne Einfügen. Ein Bearer-Token mit einem API-Schlüssel ist für Skripte verfügbar, die kein OAuth verwenden, wobei Identität und Ausgaben absichtlich in separaten Anmeldeinformationen gehalten werden.

Die Werkzeugliste wird aus den aktuellen Werkzeugdefinitionen generiert und nach Rolle und installierten Apps gefiltert. Jeder Aufruf wird bei der Ausführung auf Berechtigungen überprüft und schlägt im Fehlerfall sicher fehl. Aufrufe sind pro Verbindung begrenzt, werden gemessen, wenn der eigene Agent des Arbeitsbereichs die Logik übernimmt, und sind ohne KI-Kosten, wenn der Agent des Anrufers dies tut, begrenzt durch ein Budget, das der Arbeitsbereich festlegt, und protokolliert mit Eingaben und Ergebnissen gegen die Person, die sie gemacht hat. Apps, die im Marktplatz veröffentlicht werden, fügen ihre Werkzeuge derselben Liste unter denselben Regeln hinzu, sodass die App eines Entwicklers von einem Agenten bedient werden kann, sobald sie installiert ist.

Fragen, die Menschen stellen

Dieser Artikel wird überprüft, wenn sich die beschriebenen Produkte ändern. Nächste geplante Überprüfung: 4. Dezember 2026.