MCP-Server für Ihre Datenbank: sichere Read-only-Analysen in natürlicher Sprache

In den meisten Unternehmen gibt es ein oder zwei Personen, die Fragen aus der Datenbank beantworten können. Alle anderen warten. Ein Vertriebsleiter möchte den Umsatz des letzten Quartals nach Region sehen. Eine Operations-Leiterin möchte verspätete Bestellungen nach Lager wissen. Jede Anfrage landet in einer Warteschlange, und einfache Fragen dauern Tage.

Der Preis dafür sind langsamere Entscheidungen und die stille Gewohnheit, zu raten. Die Leute hören auf zu fragen, weil die Antwort zu spät kommt, um noch etwas zu bewirken. Gleichzeitig verbringt der Analyst seine Woche mit kleinen Abfragen statt mit der tiefergehenden Arbeit, für die er eingestellt wurde.

Was das leistet

MCP (Model Context Protocol) ist ein offener Standard, den Anthropic eingeführt hat. Er ermöglicht es KI-Assistenten wie Claude und anderen kompatiblen Clients, sich über kleine Programme, sogenannte MCP-Server, mit Tools und Daten zu verbinden. Die Unterstützung unterscheidet sich je nach KI-Client, prüfen Sie daher vor der Planung eines Rollouts die aktuelle Dokumentation des jeweiligen Clients.

Mit einem Datenbank-MCP-Server kann eine Führungskraft eine Frage in natürlicher Sprache stellen. Die Antwort kommt aus Postgres, MySQL, SQL Server oder einer ähnlichen Datenbank. Der Assistent wählt ein Tool, der Server führt eine sichere Abfrage aus, und das Ergebnis kommt zusammen mit der Abfrage zur Kontrolle zurück. Typische Fragen sind:

• „Wie hoch war der Umsatz nach Region im letzten Quartal, verglichen mit dem Quartal davor?“
• „Bei welchen Produkten gab es diesen Monat mehr Retouren als üblich?“
• „Wie viele Bestellungen wurden letzte Woche aus jedem Lager verspätet versendet?“

Das entscheidende Wort ist sicher. Mit dem unten beschriebenen Aufbau bleibt der Assistent read-only, hat keinen Zugriff auf personenbezogene Daten und kann die Produktionsumgebung nicht ausbremsen.

Vordefinierte Tools oder freies SQL

Es gibt zwei Wege, einem Assistenten Zugriff auf Ihre Daten zu geben. Jeder passt zu einer anderen Zielgruppe.

Vordefinierte Tools

Jedes Tool führt eine feste, geprüfte Abfrage mit wenigen Parametern aus, etwa einem Zeitraum und einer Region. Die Antworten kommen schnell und sind konsistent. Das Modell kann keinen fehlerhaften Join schreiben, weil es überhaupt kein SQL schreibt. Das passt für Führungskräfte und die meisten Mitarbeitenden.

Abgesichertes freies SQL

Das Modell schreibt eine Abfrage, und der Server prüft sie vor der Ausführung. Es muss sich um ein einzelnes SELECT auf freigegebene Views handeln, ergänzt um ein Zeilenlimit. So lassen sich auch unerwartete Fragen beantworten, die Antworten müssen aber genauer geprüft werden. Das passt für Analysten, die die Abfrage lesen und Fehler erkennen können.

Die meisten Teams beginnen mit vordefinierten Tools für die wichtigsten Fragen. Abgesichertes SQL ergänzen sie später für eine kleine Gruppe, wenn Bedarf besteht.

So funktioniert es, Schritt für Schritt

1. Read-Replica nutzen. Abfragen laufen gegen eine Kopie der Datenbank, nicht gegen die primäre Instanz. Eine aufwendige Abfrage kann Ihre Kunden nicht beeinträchtigen.
2. Kuratierte Views anlegen. Wir erstellen Views mit verständlichen Namen wie sales_by_region_monthly, statt rohe Tabellen offenzulegen. Views verbergen Joins und interne Spalten.
3. Personenbezogene Daten weglassen. Standardmäßig schließen die Views Namen, E-Mail-Adressen, Telefonnummern und ähnliche Felder aus. Die meisten geschäftlichen Fragen lassen sich ohnehin mit aggregierten Werten beantworten.
4. Nutzer ohne Schreibrechte anlegen. Der Server verbindet sich mit einem Datenbanknutzer, der nur aus den kuratierten Views lesen darf.
5. Zwei Arten von Tools anbieten. Vordefinierte Tools beantworten häufige Fragen mit festen Abfragen. Ein abgesichertes SQL-Tool akzeptiert, falls gewünscht, nur einzelne SELECT-Anweisungen auf freigegebene Views.
6. Limits durchsetzen. Jede Abfrage hat ein Zeilenlimit und ein Timeout. Ergebnisse werden zusammengefasst, bevor sie an den Assistenten zurückgehen.
7. Jede Abfrage protokollieren. Wir erfassen den Nutzer, die Frage, das ausgeführte SQL, die Laufzeit und die Zeilenanzahl.
8. Mit bekannten Antworten testen. Vor dem Rollout prüfen wir den Assistenten anhand von Fragen, deren richtige Antwort bereits bekannt ist.

Eingesetzte Tools

• MCP-SDKs für Python oder TypeScript.
• Python mit FastAPI und Standard-Datenbanktreiber für Postgres, MySQL und SQL Server.
• Ein SQL-Parser, der prüft, dass abgesicherte Abfragen einzelne, rein lesende Anweisungen auf erlaubte Views sind.
• Ihre bestehende Datenbank und deren native Read-Replica- oder Replikationsfunktionen.
• Strukturiertes Logging in Ihre bestehende Log-Plattform, damit Abfragen durchsuchbar und auditierbar sind.

Funktionen von Datenbanken und KI-Clients ändern sich. Prüfen Sie die aktuelle Dokumentation Ihres Datenbankanbieters und Ihres Clients zu Replikation, Berechtigungen und MCP-Unterstützung.

Was Sie für den Start brauchen

• Einen Datenbankadministrator, der eine Read-Replica, Views und einen eingeschränkten Nutzer anlegen kann.
• Rund zwanzig echte Fragen, die heute gestellt werden, mit bekannten Antworten zum Testen.
• Ein kurzes Datenverzeichnis, auch informell, das erklärt, was die wichtigsten Tabellen und Spalten bedeuten.
• Eine Entscheidung, welche Daten sensibel sind und in keinem View auftauchen dürfen.
• Einen abgestimmten KI-Client, der MCP für Ihre Nutzer unterstützt.

Typischer Umfang und Zeitrahmen

Als Schätzung: Eine erste Read-only-Version dauert typischerweise ein bis drei Wochen. Das umfasst eine Handvoll kuratierter Views und vordefinierter Tools. Die Spanne hängt davon ab, wie aufgeräumt Ihr Schema ist und ob bereits eine Read-Replica existiert. Unübersichtliche Schemas dauern länger, weil die Views die Bereinigung übernehmen. Ein abgesichertes Tool für freies SQL folgt bei Bedarf meist, sobald sich die kuratierten Views als zuverlässig erwiesen haben.

Risiken und wie wir damit umgehen

Überzeugend klingende falsche Antworten

Ein Assistent kann eine Spalte falsch interpretieren und eine plausible, aber falsche Zahl liefern. Kuratierte Views mit klaren Namen verringern dieses Risiko. Der Assistent zeigt die ausgeführte Abfrage an, und wir testen vor dem Start gegen bekannte Antworten.

Offenlegung personenbezogener oder sensibler Daten

Der eingeschränkte Datenbanknutzer kann nur freigegebene Views lesen. Personenbezogene Felder werden bereits auf View-Ebene ausgeschlossen, sodass kein Prompt sie erreichen kann.

Langsame oder teure Abfragen

Die Replica, Zeilenlimits und Timeouts schützen die Produktionsumgebung. Wir beobachten das Abfrageprotokoll auf Muster, die einen neuen View oder einen Index erfordern.

Prompt Injection und SQL Injection

In der Datenbank gespeicherter Text kann Anweisungen enthalten, die sich an den Assistenten richten. Der Server führt nur validierte, rein lesende Anweisungen aus, und Tool-Ausgaben werden als Daten behandelt. Die vollständige Liste finden Sie in unserer Sicherheits-Checkliste für MCP-Server.

Wann Sie das nicht bauen sollten

Wenn Ihr BI-Tool bereits eine Funktion für natürlichsprachliche Abfragen bietet, die Ihre Fragen und Berechtigungen abdeckt, nutzen Sie diese. Wenn jeden Montag dieselben fünf Kennzahlen gebraucht werden, ist ein geplanter Bericht günstiger und berechenbarer. Unser Leitfaden zu automatisierten KPI-Berichten in Slack und Telegram beschreibt diesen Weg. Und wenn Ihre Daten erst gründlich bereinigt werden müssen, bevor ihnen jemand vertrauen kann, erledigen Sie das zuerst. Ein Assistent macht schlechte Daten leichter zugänglich, aber nicht richtiger.

Wenn Ihre Fragen eher in Dokumenten als in Tabellen stecken, ist ein Retrieval-System die bessere Wahl. Lesen Sie dazu einen internen Wissensassistenten für Slack und Teams. Wenn Sie zusätzlich Antworten aus APIs und älteren Geschäftssystemen brauchen, lesen Sie MCP für interne APIs und ERP-Systeme.

Wie UnlockLive Sie unterstützt

UnlockLive IT ist eine Softwareagentur mit Hauptsitz in Toronto und eigenem Entwicklungsteam. Wir bauen diese Integrationen für Unternehmen in den USA, Kanada, Großbritannien und Australien. Unser Service MCP-Server-Entwicklung umfasst Scoping, Bedrohungsmodell, Umsetzung, Deployment und laufende Wartung. Da Datenbankzugriffe sensibel sind, kann unser Cybersecurity-Team Berechtigungen, Logging und Bedrohungsmodell vor dem Rollout prüfen.

Wenn Sie eine zweite Meinung zu Umfang oder Risiken möchten, buchen Sie ein kostenloses 30-minütiges Gespräch. Bringen Sie ein oder zwei Fragen mit, die Ihr Team jede Woche stellt, und wir sagen Ihnen ehrlich, ob ein MCP-Server das richtige Werkzeug ist.