MCP für ERP: ein praktischer Leitfaden

Beginne mit der Transaktion, nicht mit der Tabelle.

Der erste Instinkt beim Exponieren eines ERP ist, ein Werkzeug pro Tabelle mit Erstellen, Lesen, Aktualisieren und Löschen für jede zu generieren. Das erzeugt eine große, einheitliche Liste, die ein Modell schlecht verarbeitet, weil die Geschäftsregel, dass eine Rechnung einen Steuersatz auf jeder Zeile benötigt, oder dass Waren nicht versendet werden können, bevor sie reserviert sind, nirgendwo existiert, wo das Modell sie sehen kann. Exponiere stattdessen die Aktionen. Ein nützlicher Test ist, ob eine Person das Werkzeug als etwas beschreiben könnte, das sie heute getan hat: eine Rechnung erstellt, eine Zahlung erfasst, einen Deal verschoben, eine Verfolgung pausiert. Jede dieser Aktionen trägt ihre Regeln, validiert ihre Eingaben und gibt ein lesbares Ergebnis zurück.

Füge neben den Aktionen eine kleine Anzahl von Zusammenfassungswerkzeugen hinzu, die die Fragen beantworten, die ein Modell vor dem Handeln stellt. Ein Aufruf, der das Profil, den Status, offene Posten und die jüngste Historie eines Kontos zurückgibt, spart dem Modell vier Aufrufe und mehrere tausend Tokens an Kontext und informiert die nächste Aktion besser. Kontakt prüfen und Buchhaltungsübersicht abrufen Es sind zwei. Halten Sie auch die gesamte Oberfläche im Blick: Claude Code begrenzt standardmäßig die Ausgabe eines Servers pro Aufruf, und sowohl Claude als auch OpenAI bieten verzögertes Laden oder Toolsuche für große Listen an, sodass ein Server mit mehreren hundert Tools diese in einer deterministischen Reihenfolge zurückgeben sollte (die Spezifikation verlangt dies, damit die Clients cachen können) und vor der Auflistung nach Rolle filtern sollte.

Benennung von Werkzeugen, damit ein Modell das richtige auswählt.

Die Spezifikation schränkt Namen leicht ein: eins bis 128 Zeichen, Buchstaben, Ziffern, Unterstrich, Bindestrich und Punkt, Groß- und Kleinschreibung beachten, einzigartig innerhalb des Servers. Alles andere ist Konvention, und die funktionierende Konvention ist ein Verb, gefolgt von dem Geschäftsnomen in einer konsistenten Schreibweise, wobei dieselben Verben überall dieselben Bedeutungen haben. Ein Modell, das zwischen Rechnungen suchen, Rechnung abrufen und Rechnung erstellen wählt zwischen einer Liste, einem Datensatz und einem Schreibvorgang, und es lernt dieses Muster einmal für den gesamten Server.

Beschreibungen werden von einem Modell gelesen, das unter Druck steht zu handeln, also schreibe sie als Anweisungen. Beschreibe, was das Tool im ersten Satz tut, dann die Bedingungen. Wenn ein Geschwister-Tool die richtige Wahl für eine nahe Anfrage ist, nenne es beim Namen. Wenn ein Feld gesetzt werden muss, damit das Ergebnis korrekt ist, sage das in GROSSBUCHSTABEN, wenn nötig; das Rechnungstool von Sois teilt dem Modell mit, dass der Steuersatz in jeder Zeile gesetzt werden muss und dass die genauen Sätze von Steuerarten auflisten, denn eine Rechnung ohne Mehrwertsteuer ist ein schlimmerer Fehler als ein abgelehnter Anruf. Fügen Sie einen Beispielaufruf hinzu. Alles, was das Modell benötigt, um das Tool korrekt aufzurufen, sollte im Tool enthalten sein, da es Ihre Dokumentation niemals öffnen wird.

Eine Beispiel-Werkzeugdefinition:

Dies ist ein Sois-Rechnungstool, wie es ein Client von tools/list, auf die relevanten Felder beschränkt, mit Anmerkungen und einem Ausgabeschema, das in der Form hinzugefügt wurde, die die aktuelle Spezifikation definiert. Es zeigt das Muster: einen Verb-Nomen-Namen, eine instruktive Beschreibung, ein Schema, dessen Eigenschaftsbeschreibungen die Fehlervermeidung des Modells gewährleisten, und Hinweise, die ein Kunde nutzen kann, um zu entscheiden, ob er bestätigen möchte.

{
  "name": "createInvoice",
  "title": "Create invoice",
  "description": "Create a new invoice of any type and return the draft with its auto-generated number. TAX: set tax_rate on each line (for example 20 for 20% VAT); call listTaxTypes for this workspace's exact rates. If the user says 'plus VAT' you MUST set tax_rate or the invoice goes out with no VAT. To email the result use sendInvoice. Example: createInvoice({ type: \"sales_invoice\", contact_id: \"uuid\", currency: \"GBP\", lines: [{ description: \"Consulting\", quantity: 10, unit_price: 150 }] })",
  "inputSchema": {
    "type": "object",
    "properties": {
      "type": { "type": "string", "description": "sales_invoice, purchase_invoice, sales_credit_note or purchase_credit_note" },
      "contact_id": { "type": "string", "description": "Contact UUID (bill-to for sales, bill-from for purchases)" },
      "currency": { "type": "string", "description": "ISO code, for example GBP. Uses the workspace default if omitted" },
      "invoice_date": { "type": "string", "description": "ISO date. Defaults to today" },
      "reference": { "type": "string" },
      "lines": {
        "type": "array",
        "description": "Line items. Every line MUST carry the numeric unit_price the user asked for",
        "items": {
          "type": "object",
          "properties": {
            "description": { "type": "string" },
            "quantity": { "type": "number", "description": "Defaults to 1" },
            "unit_price": { "type": "number", "description": "NUMBER only: no currency symbols, no thousands separators. Use the exact amount stated; never guess or round" },
            "tax_rate": { "type": "number" },
            "discount_percent": { "type": "number" }
          },
          "required": ["description", "unit_price"]
        }
      }
    },
    "required": ["type"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "invoice_id": { "type": "string" },
      "number": { "type": "string" },
      "status": { "type": "string" },
      "total": { "type": "number" }
    },
    "required": ["invoice_id", "number", "status"]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": false,
    "idempotentHint": false,
    "openWorldHint": false
  }
}

Die Anmerkungen besagen: dies schreibt, es fügt nur (einen Entwurf) hinzu, zweimal aufrufen erstellt zwei Entwürfe, und es berührt nichts außerhalb des Systems. Kunden müssen Anmerkungen als unzuverlässig behandeln, es sei denn, der Server ist vertrauenswürdig, daher sind sie Hinweise für das Bestätigungsverhalten, kein Ersatz für die eigenen Prüfungen des Servers.

Drei Entscheidungen in dieser Definition sind absichtlich. Das Ergebnis gibt einen Identifikator zurück, den das Modell mitführen muss in Rechnung senden und Zahlung erfassen, was die empfohlene Vorgehensweise der Spezifikation ist, um Aufrufe zu verknüpfen, da Server keinen Sitzungsstatus halten. Das Tool erstellt einen Entwurf, keine veröffentlichte Rechnung, sodass der Schreibvorgang additiv ist und eine Person oder ein separates Genehmigungstool dies abschließt. Und das Ausgabeschema bedeutet, dass eine Integration die Nummer und den Gesamtbetrag als Daten lesen kann, während das Modell dasselbe Ergebnis als Text liest.

Werkzeuge auf den Benutzer zuschneiden.

Über HTTP kommt der Anrufer mit einem OAuth-Zugriffstoken, das an Ihren Server gebunden ist, und dieses Token identifiziert eine Person. Die Spezifikation erlaubt das Ergebnis von tools/list je nach den Anmeldeinformationen der Anfrage variieren, sodass die erste Eingrenzungsentscheidung darin besteht, die Liste nach der Rolle dieser Person zu filtern, bevor sie zurückgegeben wird: ein Lagerbenutzer erhält nicht Rechnung genehmigenDie Liste darf sich nicht je nach Verbindung oder als Nebenwirkung anderer Aufrufe ändern, sondern nur durch Autorisierung, was sie cachebar macht.

Die zweite Entscheidung besteht darin, bei der Ausführung erneut zu überprüfen. Ein Kunde kann jeden gewünschten Aufruf senden, und ein Modell kann durch Text in einem Toolergebnis manipuliert werden, um einen Versuch zu starten. Bestätigen Sie den Benutzer anhand des Tokens bei jedem Aufruf, überprüfen Sie die Berechtigung, die das Tool benötigt, und verweigern Sie mit einem Ausführungsfehler des Tools, den das Modell lesen kann. Halten Sie die OAuth-Bereiche grob (Sois gibt Lese-, Schreib- und Offline-Bereiche aus) und lassen Sie die eigenen Rollen des ERP die feingranulare Grenze sein, da diese Rollen bereits existieren, bereits verwaltet werden und bereits etwas für das Geschäft bedeuten. Ordnen Sie jeden Aufruf der Person im Protokoll mit seinen Argumenten und Ergebnissen zu, damit die Arbeit eines Agenten genau so überprüfbar ist wie die einer Person.

1. Token ist eingetroffenÜberprüfen Sie die Signatur und dass die Zielgruppe dieser Server ist, wie in RFC 8707 gefordert; alles andere mit 401 ablehnen.
2. Die Person identifizierenOrdnen Sie das Token einem Benutzer im Arbeitsbereich zu und laden Sie dessen Rolle und installierte Apps.
3. Filtern Sie die ListeGeben Sie nur die Werkzeuge zurück, die die Rolle verwenden darf, in einer stabilen Reihenfolge aus tools/list.
4. Überprüfen Sie den AufrufÜberprüfen Sie bei tools/call erneut die Berechtigung und verweigern Sie mit isError, wenn sie fehlt; nichts wird ausgeführt.
5. Ausführen und protokollierenFühren Sie die Transaktion aus, messen Sie sie, wenn Ihr eigener Agent die Überlegung angestellt hat, und schreiben Sie den Aufruf in das Prüfprotokoll unter dieser Person.

Umgang mit Schreibvorgängen.

Ein Modell, das ein mehrdeutiges Ergebnis erhält, wird erneut aufrufen, und eines, das einen Fehler erhält, wird einen korrigierten Eingabewert versuchen. Entwerfen Sie dafür. Schreibvorgänge, die erstellen, sollten einen Handle zurückgeben und, wo möglich, einen Idempotenzschlüssel oder einen natürlichen Schlüssel akzeptieren, damit eine Wiederholung erkannt wird. Schreibvorgänge, die den Zustand ändern, sollten explizit über den Übergang sein, den sie durchführen, und unmögliche Übergänge mit einem lesbaren Grund ablehnen: eine Zahlung gegen eine stornierte Rechnung zu erfassen ist ein. isError Ergebnis, das dies sagt, nicht ein stilles No-Op und nicht ein Stack-Trace. Lassen Sie niemals einen teilweisen Schreibvorgang zurück; wenn ein mehrstufiges Werkzeug nicht abgeschlossen werden kann, rollen Sie zurück und berichten Sie.

• Bevorzugen Sie Entwürfe und Genehmigungen. Gestalten Sie die Erstellung additiv (ein Entwurf) und geben Sie der Finalisierung ihr eigenes Werkzeug mit eigenen Berechtigungen, sodass der destruktive Schritt der ist, den ein Kunde bestätigt und den eine Rolle kontrolliert.
• Kennzeichnen Sie destruktive Werkzeuge. Setzen destructiveHint bei Stornierungen und Löschungen und dies in der Beschreibung angeben; Claude und ChatGPT verwenden solche Signale, um zu entscheiden, ob sie vor dem Anruf fragen sollen.
• Fragen statt raten. Wenn ein Anruf eine Entscheidung erfordert, die das Tool nicht treffen kann, geben Sie ein Ergebnis zurück, das Eingaben erfordert, mit einer Aufforderung zur Erhebung; der Kunde stellt die Frage an die Person und versucht den Anruf mit der Antwort erneut.
• Begrenzen Sie den Explosionsradius. Begrenzen Sie die Rate pro Verbindung, setzen Sie ein Ausgabenlimit pro Integration, wo Ihr eigener Agent Überlegungen anstellt, und validieren Sie jede Eingabe serverseitig, unabhängig vom Schema, da das Schema eine Empfehlung für das Modell ist, nicht eine Durchsetzung.

Die Oberfläche mit einem echten Kunden testen.

Der MCP-Inspektor wird ausüben tools/list und tools/call und den OAuth-Flow durchlaufen. Der echte Test ist ein Modell. Verbinden Sie Claude als benutzerdefinierten Connector oder ChatGPT im Entwicklermodus, melden Sie sich als Benutzer mit einer engen Rolle an und fragen Sie nach einem routinemäßigen Ergebnis, das drei oder vier Tools benötigt. Beobachten Sie, welche Tools es auswählt und warum; eine falsche Wahl ist fast immer ein Beschreibungsproblem. Melden Sie sich dann als Benutzer ohne eine der Berechtigungen an und bestätigen Sie, dass der Lauf beim richtigen Anruf mit einem Grund stoppt, den das Modell zurückgibt.

So wird der Sois-Workspace-Server aufgebaut und überprüft: Transaktionen als Tools, instruktive Beschreibungen, eine rollenbasierte gefilterte Liste, eine zweite Überprüfung bei jedem Anruf, Entwürfe vor Genehmigungen und ein Protokoll, das eine Person lesen kann. Entwickler, die Apps für den Marktplatz erstellen, veröffentlichen Tools in derselben Liste unter denselben Regeln, sodass eine App von jedem Agenten betrieben werden kann, sobald sie installiert ist. Das Muster ist nicht spezifisch für ein Produkt; jedes ERP, das es übernimmt, wird zu etwas, das ein Agent ausführen kann.

Fragen, die Menschen stellen

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