Geschäftskonto per KI steuern: Ein MCP-Server für Kontist

Tobias Endres

Tobias Endres

— 4 min read
Geschäftskonto per KI steuern: Ein MCP-Server für Kontist

Wie wir einen MCP-Server gebaut haben, der über Kontists GraphQL-API auf ein deutsches Geschäftskonto zugreift – und was dabei schiefging.

Ausgangslage

Deutsche Banken und Entwickler haben traditionell kein besonders gutes Verhältnis. Wer programmatisch auf sein Konto zugreifen will, steht meist vor einer Wand: keine öffentlichen APIs, keine Dokumentation, und wenn doch, dann hinter Enterprise-Verträgen und monatelangen Onboarding-Prozessen.

Bei Geschäftskonten ist es noch schlimmer. Commerzbank, Postbank, Sparkasse – alle bieten Privatkundenlösungen, die irgendetwas in Richtung Open Banking andeuten, aber für Unternehmenskonten ist die Lage dünn. PSD2 hat zwar APIs erzwungen, aber die sind auf Kontoinformationen und Zahlungsinitiierung beschränkt, oft schlecht dokumentiert und in der Praxis mühsam zu nutzen.

Kontist ist eine der wenigen Ausnahmen. Sie richten sich explizit an Freelancer und kleine Unternehmen und stellen eine öffentliche GraphQL-API bereit – keine Warteliste, keine Enterprise-Anfrage, einfach nutzen. Über diese API lassen sich Transaktionen abfragen, Überweisungen anlegen und Karten verwalten. Für den deutschen Markt ist das ungewöhnlich genug, dass es erwähnenswert ist.

Die Idee: Konto per KI-Agent ansprechen

Wir arbeiten bei Corentic mit KI-Agenten für Routineaufgaben – hauptsächlich über OpenCode. Irgendwann kam die Frage auf: Warum fragen wir unseren Kontostand nicht einfach den Agenten? Warum muss man sich für jede simple Abfrage ins Bankportal einloggen?

Das klingt nach einer Kleinigkeit, aber wenn man regelmäßig prüfen will, ob eine Zahlung eingegangen ist, wie die Liquidität gerade aussieht, oder was in einem bestimmten Monat ausgegeben wurde – summiert sich das. Jeder manuelle Schritt ist Kontext-Wechsel, und Kontext-Wechsel kostet Zeit.

Die Lösung: ein MCP-Server (Model Context Protocol), der Kontists API als Tool-Sammlung für KI-Assistenten verfügbar macht.

Aufbau und Funktionsweise

Das Prinzip ist einfach:

OpenCode → MCP-Server → Kontist GraphQL API → Konto

Der Server läuft lokal auf dem eigenen Rechner, liest OAuth-Tokens aus ~/.config/kontist/tokens.json und stellt dem Agenten diese Tools bereit:

  1. get_balance – Kontostand und verfügbares Guthaben
  2. get_account – IBAN und Kontodetails
  3. list_transactions – Die letzten 50 Transaktionen
  4. list_transfers – Nach Typ gefiltert (z. B. SEPA_TRANSFER)
  5. create_transfer – Überweisung anlegen (gibt eine confirmationId zurück)
  6. confirm_transfer – Bestätigung per TAN
  7. list_cards – Alle verknüpften Karten

Technisches

  • Gebaut mit @modelcontextprotocol/server
  • Nutzt das kontist npm-Paket (v0.52.15)
  • OAuth 2.0 mit Refresh-Token-Unterstützung
  • StdIO-Transport für lokale Ausführung

Ein Tool sieht im Code ungefähr so aus:

const client = new Client({
  clientId: tokens.clientId,
  clientSecret: tokens.clientSecret,
  scopes: ['accounts', 'transactions', 'transfers', ...]
});

server.registerTool('get_balance', {
  title: 'get_balance',
  description: 'Aktuellen Kontostand abrufen'
}, async () => {
  const result = await client.graphQL.rawQuery(`{
    viewer { mainAccount { balance availableBalance } }
  }`);
  return { content: [{ type: 'text', text: JSON.stringify(result) }] };
});

Einrichtung

cd kontist-mcp
npm run auth  # Öffnet OAuth im Browser
# ... autorisieren ...
node server.mjs  # Startet den MCP-Server

Was damit im Alltag geht

Wenn das Konto per API erreichbar ist, verschwinden eine ganze Reihe kleiner Reibungspunkte. Ein paar konkrete Beispiele:

Zahlungseingang prüfen
„Hat Firma X schon überwiesen?" – Der Agent sucht in den letzten Transaktionen nach IBAN oder Firmenname und antwortet direkt. Kein Portal-Login, kein manuelles Scrollen durch die Transaktionsliste.

Ausgaben nachvollziehen
„Wie viel haben wir dieses Quartal für AWS ausgegeben?" – Der Agent filtert die Buchungen nach Händlernamen und summiert. Das funktioniert für beliebige Kategorien: Software-Abos, Subunternehmer, Reisekosten.

Liquidität im Blick behalten
Für schnelle Entscheidungen – kommt eine Ausgabe noch diesen Monat rein oder nicht – reicht oft ein einziger Blick auf den Kontostand. Der Agent liefert ihn sofort.

Überweisungen ausführen
Das ist der interessantere Teil: Eine Überweisung wird über den Agenten angelegt, eine confirmationId kommt zurück, und der zweite Faktor – die TAN-Bestätigung – erfolgt auf dem Handy. Der Agent übernimmt die Erstellung, die Genehmigung bleibt beim Menschen. Das ist kein Sicherheitsproblem, sondern sinnvolle Aufgabenteilung.

Regelmäßige Zusammenfassungen
Ein Agent, der wöchentlich die letzten Transaktionen abruft und eine kurze Zusammenfassung schreibt – eingegangene Zahlungen, größere Ausgaben, aktueller Stand – lässt sich mit wenigen Zeilen konfigurieren.

Was beim Bauen aufgefallen ist

Der Weg war nicht gerade, und ein paar Dinge sind erwähnenswert, falls jemand ähnliches baut.

Token-Ablauf ohne Auto-Refresh
Kontists OAuth-Tokens laufen nach einer Stunde ab. Eine eingebaute Refresh-Logik gibt es im SDK nicht – zumindest nicht in der Version, die wir genutzt haben. Das bedeutete: Jeder Server-Neustart erforderte eine neue Browser-Authentifizierung. Für den Dauerbetrieb ist das mühsam, für gelegentliche Nutzung geht es.

SDK-Grenzen kennen
Das kontist-Paket deckt nicht alles ab, was die API theoretisch hergibt. Manche Methoden, die man erwarten würde, fehlen einfach. Und GraphQL-Queries, die direkt gegen die API funktionierten, ließen sich nicht immer 1:1 über das SDK abfeuern. Wir haben relativ früh aufgehört, dagegen anzukämpfen, und sind bei dem geblieben, was explizit dokumentiert und stabil war.

API-Änderungen ohne Ankündigung
Queries, die einen Monat funktionierten, brachen nach einem Kontist-Update zusammen. Das ist bei öffentlichen APIs ohne strenge Versionierung kein ungewöhnliches Problem, aber man sollte es einkalkulieren, wenn man so einen Server produktiv betreiben will.

Der Moment, in dem es ernst wurde
Als der Transfer-Flow das erste Mal durchlief – Überweisung anlegen, confirmationId erhalten, TAN-Bestätigung, Geld bewegt – war das der Punkt, an dem das Projekt aufgehört hat, ein Experiment zu sein. Es ist ein kleiner Moment, aber er ändert die Perspektive darauf, was mit diesen Tools möglich ist.

Kontext: Warum das in Deutschland relevant ist

Es lohnt sich, kurz innezuhalten und zu erklären, warum ein simpler API-Zugang zum Geschäftskonto überhaupt erwähnenswert ist.

In anderen Märkten – UK, Niederlande, Skandinavien – gibt es ausgereifte Open-Banking-Infrastrukturen. Entwickler können auf Kontodaten zugreifen, Zahlungen initiieren und Finanz-Apps bauen, ohne besondere Hürden. In Deutschland ist das Bild ein anderes. PSD2 hat zwar eine gesetzliche Grundlage geschaffen, aber die Umsetzung ist lückenhaft: Die APIs sind oft fehlerhaft dokumentiert, auf bestimmte Anwendungsfälle beschränkt, und für Geschäftskonten gilt vieles davon ohnehin nicht.

Kontist ist in diesem Umfeld eine Ausnahme – nicht weil ihre API besonders ausgereift wäre, sondern weil sie überhaupt existiert und öffentlich zugänglich ist. Das macht dieses Projekt weniger zu einer technischen Glanzleistung als zu einem Symptom: Es zeigt, was möglich wäre, wenn mehr Banken ähnliche Schnittstellen anbieten würden.

Wer wir sind und warum wir das gebaut haben

Wir sind Corentic, ein kleines Team, das sein eigenes Unternehmen von Anfang an mit so viel Automatisierung wie möglich aufbaut. Nicht aus Prinzip, sondern weil manuelle Prozesse fehleranfällig und zeitintensiv sind – und weil wir lieber an den eigentlichen Aufgaben arbeiten als an Verwaltungsroutinen.

Dieses Projekt passt in dieses Bild: Es war kein geplantes Produkt, sondern eine Antwort auf eine konkrete Frage. Was als technisches Experiment begann, ist zu einem funktionierenden Teil unseres Finanz-Workflows geworden – unspektakulär, aber nützlich.

Der Code ist offen auf github.com/corentic/kontist-mcp.