Das LLM hat keinen Zugriff auf eure Systeme. Es lebt in seiner eigenen Welt, kann brillant formulieren, aber nicht auf eure Daten zugreifen, geschweige denn Aktionen in euren Tools auslösen.
Genau dieses Problem löst MCP, das Model Context Protocol.
MCP ist ein offener Standard (entwickelt von Anthropic, den Machern von Claude), der definiert, wie ein LLM mit externen Systemen kommuniziert. Es ist quasi das USB-Kabel der AI-Welt:
MCP definiert drei Konzepte:
Tools: Aktionen, die das LLM ausführen kann
"Suche Kontakte in Bexio", "Erstelle eine Rechnung", "Zeige offene Angebote"
Resources: Daten, die das LLM lesen kann
Kundenlisten, Produktkataloge, Rechnungsdetails
Prompts: Vorgefertigte Anweisungen für wiederkehrende Aufgaben
"Erstelle ein Angebot" → löst einen definierten Workflow aus
Das LLM entscheidet selbst, welche Tools es braucht, ruft sie in der richtigen Reihenfolge auf und formuliert aus den Ergebnissen eine Antwort. Im Prinzip wird das LLM zum intelligenten Vermittler zwischen Mensch und System.
Bexio ist die Buchhaltungs- und Business-Software, die wir intern bei ongoing nutzen. Kontakte, Rechnungen, Angebote: alles läuft darüber. Das Ziel: einen MCP-Server bauen, der es uns erlaubt, per natürlicher Sprache mit Bexio zu arbeiten.
Bereich
| Beispiel-Aktionen
|
|---|---|
| Kontakte | Kunden suchen, Kontaktdetails abrufen, nach Firma filtern |
| Rechnungen | Alle offenen Rechnungen anzeigen, Rechnungsdetails abrufen, nach Fälligkeit filtern |
| Angebote | Angebote für einen Kunden erstellen, Positionen hinzufügen, Status abfragen |
Ein paar Beispiele aus dem Alltag:
Klingt magisch. War es aber nicht, zumindest nicht am Anfang.
Wir haben den MCP-Server mit dem Symfony AI Bundle gebaut.
Warum wir das Bundle gewählt haben:
Das Bundle abstrahiert die MCP-Spezifikation in Symfony-Services. Statt JSON-RPC-Nachrichten manuell zu bauen und Tool-Definitionen als JSON-Schema zu schreiben, definiert ihr Tools als PHP-Klassen mit Attributen:
Das Bundle übernimmt:
Tool-Discovery und -Registration beim MCP-Client
Serialisierung/Deserialisierung der MCP-Nachrichten
Input-Validierung basierend auf den Typ-Definitionen
Transport-Layer (stdio, HTTP, SSE)
Für Symfony-Entwickler fühlt sich das an wie jeder andere Service: keine neue Sprache, kein neues Framework, keine neue Denkweise.
Und hier wird es spannend. Denn der MCP-Server war in zwei Tagen gebaut. Die Tools funktionierten, die API-Anbindung lief. Technisch alles sauber.
Aber das Ergebnis war unbrauchbar.
Nicht weil die Technik nicht funktionierte, sondern weil das LLM nicht wusste, wie Bexio richtig zu bedienen ist. Ein LLM mit Tools ist wie ein intelligenter Praktikant mit Systemzugang: Er kann die Knöpfe drücken, aber er kennt die Geschäftsprozesse nicht.
Einzelne Tools geben dem LLM Fähigkeiten. Aber ohne Workflows und Instruktionen fehlt das Wissen, diese Fähigkeiten sinnvoll zu kombinieren.
Konkrete Probleme, die wir hatten:
Steuersätze: Das LLM hat Positionen mit dem falschen Steuersatz erstellt, weil es nicht wusste, dass in der Schweiz 8.1% Standard ist und Lebensmittel 2.6% haben. Es hat einfach irgendetwas genommen oder den Default belassen.
Mengeneinheiten: Immer "Stück", auch wenn "Stunden" oder "Pauschal" richtig gewesen wäre. Das LLM kannte die verfügbaren Einheiten nicht.
Formatierung: Keine Subpositionen, keine optionalen Positionen, keine Gruppierung. Das LLM wusste nicht, dass Bexio diese Features überhaupt hat. Es hat einfach eine flache Liste von Positionen erstellt, wie jemand, der Bexio zum ersten Mal öffnet.
Reihenfolge: Das LLM hat versucht, direkt ein Angebot zu erstellen, ohne zuerst den Kunden zu suchen. Oder es hat den falschen Kunden genommen, weil es nicht nachgefragt hat.
Das Erstellen einer Offerte war unser härtester Testfall, und das beste Beispiel dafür, warum MCP mehr braucht als Tools.
1) User: "Erstelle ein Angebot für Müller AG für ein Kundenportal mit Bexio-Anbindung"
User: "Erstelle ein Angebot für Müller AG für ein Kundenportal mit Bexio-Anbindung"
Was passierte:
Wir haben dem MCP-Server Prompts hinzugefügt, vorgefertigte Instruktionen, die dem LLM den Geschäftsprozess erklären:
Aus unbrauchbar wurde verlässlich. Dasselbe LLM, dieselben Tools, aber mit Workflow-Instruktionen erstellt es Angebote, die fast 1:1 so aussehen, wie wir sie manuell erstellen würden. Mit dem richtigen Steuersatz, sinnvollen Mengeneinheiten, strukturierten Subpositionen und optionalen Extras.
MCP-Tools sind die Hände. Workflow-Instruktionen sind das Gehirn.
Wer einen MCP-Server baut und nur Tools definiert, wird enttäuscht sein. Das LLM braucht Geschäftskontext, und zwar nicht als vage Beschreibung, sondern als klare, schrittweise Anleitung. Je spezifischer die Instruktionen, desto besser das Ergebnis.
Das klingt aufwändig, aber es ist genau die Arbeit, die sich lohnt: Einmal sauber definieren, wie ein Prozess ablaufen soll, und das LLM befolgt ihn jedes Mal.
MCP ist noch jung (die Spezifikation wurde Ende 2024 veröffentlicht), aber die Implikationen sind weitreichend:
Interne Tools per Sprache bedienen. Nicht als Spielerei, sondern für echte Produktivität. Unsere Bexio-Anbindung spart uns konkret Zeit bei Angebotserstellung und Rechnungsübersicht.
Bestehende Systeme AI-fähig machen, ohne sie umzubauen. Bexio selbst hat keine AI-Features. Über MCP haben wir sie trotzdem.
Prototypen in Tagen statt Monaten. Ein MCP-Server für eine REST-API ist in 1–3 Tagen gebaut. Die Workflow-Instruktionen brauchen länger, aber das ist Prozess-Arbeit, nicht Programmierung.
Security ist nicht optional. Ein MCP-Server gibt einem LLM Zugriff auf echte Systeme. Rechte-Management, Validierung und Audit-Logs sind Pflicht, nicht Kür.
Das LLM ist nicht deterministisch. Dieselbe Frage kann zu leicht unterschiedlichen Tool-Aufrufen führen. Für kritische Prozesse (Rechnungen erstellen, Zahlungen auslösen) braucht es Bestätigungsschritte.
Workflow-Design ist die eigentliche Arbeit. Der technische MCP-Server ist einfach. Die Frage "wie soll der Prozess ablaufen und welche Regeln gelten?" ist die harte Arbeit, und sie braucht jemanden, der sowohl das System als auch das Geschäft versteht.
Unternehmen, die bestehende Business-Software nutzen (ERP, CRM, Buchhaltung) und diese per AI zugänglich machen wollen
Teams, die interne Tools haben und einen natürlichsprachlichen Zugang dazu bauen wollen
CTOs, die AI-Integration evaluieren, ohne ihre bestehende Architektur umzubauen
MCP löst ein echtes Problem: Es bringt LLMs von "kann reden" zu "kann handeln." Und es tut das mit einem offenen Standard statt proprietären Integrationen.
Aber der technische Standard ist der einfache Teil. Was wir bei unserem Bexio-Projekt gelernt haben:
MCP ist kein Zukunftsthema. Es ist ein Jetzt-Thema, für jeden, der bestehende Systeme intelligenter machen will.
"Wenn ihr eure Business-Software AI-fähig machen wollt, oder einfach wissen wollt, ob MCP für euren Fall Sinn ergibt, meldet euch."
Im nächsten Schritt fragen wir dich noch nach deiner E-Mail Adresse.
Senden
Wir schaffen technisch hochstehende digitale Lösungen auf Basis von tiefem User-Verständnis – damit du in der digitalen Welt erfolgreich bist.
