MCP-Server

prekonto lässt sich als Werkzeugkasten in einen KI-Assistenten einhängen. Dann laden Sie eine Rechnung im Chat hoch und bekommen den Buchungsvorschlag samt Begründung zurück — ohne Oberfläche, ohne Skript, in Sätzen.

Was MCP ist — kurz und ohne Fachjargon

Ein Sprachmodell kann von sich aus nur reden. Es kennt Ihre Kreditorenliste nicht und kann keine Datei bei uns hochladen. Das Model Context Protocol (MCP) ist die vereinbarte Art, wie ein Programm einem KI-Assistenten Werkzeuge anbietet: eine Liste von Handlungen mit Namen, Beschreibung und Parametern. Der Assistent liest diese Liste und ruft die passende Handlung auf, wenn Sie ihn darum bitten.

Der Vergleich, der in der Buchhaltung trägt: MCP ist für einen KI-Assistenten das, was eine Schnittstelle für eine Software ist — nur dass die Beschreibung in normaler Sprache steht, damit das Modell sie versteht. Sie sagen „lade diese Rechnung hoch“, und der Assistent weiß, dass dafür upload_invoice zuständig ist und dass er vorher die Mandanten-ID braucht.

prekonto einbinden

Der Server spricht Streamable HTTP und ist zustandslos — es gibt nichts zu starten und nichts zu installieren. Zu konfigurieren sind im Kern zwei Dinge: die URL und ein Credential.

Weg 1: OAuth — der bequeme

Clients, die OAuth beherrschen (Claude und ChatGPT gehören dazu), tragen nur die URL ein. Beim ersten Werkzeugaufruf antwortet prekonto mit 401 und nennt im WWW-Authenticate-Header seine Protected-Resource-Metadaten. Daran erkennt der Client, dass er den Anmelde-Ablauf starten kann: Er schickt Sie auf eine prekonto-Seite, dort sehen Sie, welche Rechte die Anwendung erbittet, und stimmen zu oder nicht. Ein Passwort geben Sie dabei nie im Client ein.

Weg 2: API-Key — für alles andere

Clients ohne OAuth-Unterstützung bekommen einen API-Key. Legen Sie ihn im angemeldeten Bereich unter API-Keys an und haken dort genau die Scopes an, die der Assistent haben soll. Der Key beginnt mit pk_live_ und ist nur einmal sichtbar.

// Konfiguration eines MCP-Clients, der HTTP-Header setzen kann
{
  "mcpServers": {
    "prekonto": {
      "type": "http",
      "url": "https://prekonto.de/api/v1/mcp",
      "headers": {
        "Authorization": "Bearer pk_live_…"
      }
    }
  }
}

Die genauen Feldnamen unterscheiden sich je Client — maßgeblich ist die Anleitung Ihres Clients. Die drei Angaben oben sind alles, was von prekonto gebraucht wird.

Wählen Sie die Scopes so knapp, wie es die Aufgabe erlaubt. Ein Assistent, der Belege einliefern und Vorschläge lesen soll, braucht invoices:write und buchungssaetze:read — aber nicht buchungssaetze:write. Ohne diesen Scope kann er nichts freigeben, und die Freigabe bleibt beim Menschen. Das ist der wirksamste Schalter auf dieser Seite.

Die elf Werkzeuge

In der Reihenfolge, in der ein Client sie sinnvoll benutzt. Die Reihenfolge ist nicht Kosmetik: Modelle wählen erfahrungsgemäß eher aus dem Anfang einer Liste, und list_mandanten ist tatsächlich der richtige erste Aufruf. Parameternamen sind snake_case (mandant_id), weil Modelle bei snake_case-Schemas zuverlässiger snake_case liefern.

Jedes Werkzeug antwortet zweifach: mit einem kurzen deutschen Text für das Modell und mit einem Strukturteil für den Client. Der Text ist nicht die JSON-Serialisierung des Strukturteils — ein Modell, das 40 Buchungssätze als JSON bekommt, liest sie nicht. Es braucht die Zusammenfassung und greift für Einzelheiten in den Strukturteil.

Dateien nehmen upload_invoice und upload_stammdaten auf zwei Wegen an: datei_base64 (bevorzugt) oder datei_url. Beides gibt es, weil MCP-Clients hier unterschiedlich zuverlässig sind — manche reichen eine angehängte Datei sauber durch, andere haben nur eine URL. Der URL-Weg lädt nur von öffentlich erreichbaren https-Adressen und folgt keinen Weiterleitungen.

Bei DATEV-KRexport-Dateien lohnt es, den dateiname mitzugeben (KRExport_KRED_…, KRExport_KTO_…): Er liefert Mandantennummer und Wirtschaftsjahresbeginn und ist der Rückfall, falls die Kopfzeile nicht wiedererkannt wird. Nötig ist er nicht — die Art wird zuerst aus der Kopfzeile gelesen, eine umbenannte KRexport-CSV läuft deshalb genauso ohne Sprachmodell durch.

So sieht das in der Praxis aus

Ein Beispieldialog. Was der Assistent im Hintergrund aufruft, steht in eckigen Klammern.

Drei Dinge daran sind kein Zufall. Der Assistent fragt nach der Kontenliste, statt eine Kontonummer zu erfinden — die Server-Instruktionen sagen ihm ausdrücklich, dass nur Konten aus list_gegenkonten gültig sind, und der Server würde ein erfundenes Konto ohnehin abweisen. Er fragt vor dem Bestätigen. Und er erklärt, warum der Satz im Review liegt, weil die Begründung als Prüfergebnis am Buchungssatz hängt und nicht erfunden werden muss.

Grenzen: was kein Werkzeug kann

Die Werkzeugliste ist bewusst kürzer als die REST-API. Was ein Modell versehentlich tun kann, wird es irgendwann versehentlich tun — deshalb gibt es diese Handlungen im MCP-Kanal gar nicht:

• Kein Werkzeug löscht etwas. Nicht eine Rechnung, nicht einen Buchungssatz, nicht ein Stammdatenkonto. Auch ein Stammdaten-Upload löscht nichts: Er legt an und aktualisiert, nicht mehr gelieferte Konten bleiben stehen.
• Kein Werkzeug legt einen Mandanten an. Beraternummer, Mandantennummer, Wirtschaftsjahr und Sachkontenlänge sind Angaben des Steuerberaters; sie werden in der Oberfläche erfasst.
• Kein Werkzeug verwaltet Webhooks. Ein Modell soll keine Zustelladressen einrichten können. Abos laufen über die REST-API.
• Kein Werkzeug legt einen Kreditor an. Wer auf ein Konto korrigiert, zu dem es keinen Kreditor gibt, bekommt einen Fehler — die Kreditorenliste gehört dem Mandanten.
• Kein Werkzeug ändert Betrag oder Belegdatum. Beide stehen so auf der Rechnung. Ein Versuch wird abgewiesen, nicht stillschweigend verworfen.

Und die Regel, die über allem steht: Ein Kontierungsvorschlag, den ein Sprachmodell gebildet hat, geht immer einmal durch den Review — unabhängig davon, welchen Weg der Beleg genommen hat. Ein Modell kann diese Schwelle nicht anheben, weil sie nicht in seiner Antwort steht, sondern in deterministischen Prüfungen danach. Die Einzelheiten stehen in der Dokumentation zu Confidence und Ampel.

Technische Einzelheiten

Kein SSE-Strom, und das ist eine Entscheidung: Es gibt keine server-initiierten Nachrichten — keine Fortschrittsmeldungen, keine Sampling-Rückfragen. Ein Strom, über den nur eine Nachricht geht, wäre bloß eine Verbindung, die offen bleibt. Fragt ein Client eine unbekannte Protokollversion an, antwortet der Server mit seiner neuesten; der Client entscheidet dann, ob er damit arbeiten kann.

Ein GET auf den Endpunkt antwortet 405 mit Allow. Absichtlich kein 404: Den würde ein Client als „falscher Pfad“ deuten und die Verbindung ganz aufgeben, statt zu erkennen, dass dieser Server zustandslos ist.

Der Pfad steht auch im OpenAPI-Dokument unter /api/v1/openapi.json — damit die Beschreibung der Schnittstelle vollständig ist, nicht damit ein generierter REST-Client ihn benutzt.