Datenbank-Tool

Das Datenbank-Tool gibt Deinen Assistenten direkten SQL-Zugriff auf eine Datenbank — für Auswertungen, Reporting und Fragen an echte Daten statt an eine Wissensbasis.

Überblick

Das Tool bringt drei Methoden mit:

• query_database_readonly — lesende Abfragen (SELECT, SHOW, DESCRIBE, EXPLAIN, WITH) in einer erzwungen read-only Session. Das ist der Normalfall für Analysen.
• execute_sql — vollständige SQL-Ausführung inklusive INSERT, UPDATE, DELETE und DDL. Funktioniert nur, wenn X-Allow-Write auf true steht (Standard: false).
• get_database_schema — Tabellen und Spalten inspizieren, bevor eine Abfrage geschrieben wird.

Unterstützte Datenbanken

Andere Systeme — etwa SQLite — sind nicht angebunden.

Einrichtung

Das Datenbank-Tool ist ein eingebautes Werkzeug. Im Assistenten-Editor aktivierst Du es in der Werkzeuge-Sektion und hinterlegst dort seine Konfiguration.

Format der Datenbank-URL

Benutzername und Passwort gehören in diese URL, es gibt kein separates Feld dafür. X-Database-URL hat immer die Form schema://benutzer:passwort@host:port/datenbank, zum Beispiel:

postgresql://mgpt_reader:PASSWORT@db.example.com:5432/meine_db
mssql://mgpt_reader:PASSWORT@db.example.com:1433/meine_db

• Schema: postgres:// oder postgresql://, mysql:// oder mssql:// (bei Microsoft SQL Server ist auch sqlserver:// möglich). Daraus erkennt MeinGPT den Client, sofern Du X-Database-Client nicht setzt.
• Port: Bei Microsoft SQL Server ist 1433 der Standard, wenn Du keinen Port angibst.
• Sonderzeichen: Enthalten Benutzername, Passwort oder Datenbankname Sonderzeichen, müssen sie URL-kodiert (Prozent-kodiert) sein, zum Beispiel @ → %40, : → %3A, / → %2F, # → %23, ? → %3F und % → %25. MeinGPT dekodiert sie vor dem Verbindungsaufbau.
• Nur diese Bestandteile zählen bei Microsoft SQL Server: Host, Port, Benutzer, Passwort und Datenbank aus der URL. Zusätzliche URL-Parameter (etwa ?encrypt=false) werden ignoriert.

Ohne X-Database-URL bricht jeder Aufruf mit „Missing database URL" ab. Über den Verbindungstest im Editor lässt sich die Konfiguration prüfen, bevor der Assistent produktiv geht.

Für Kolleg*innen freigeben

Die Konfiguration – Verbindungsstring und Header – hängt an Deinem Nutzerkonto im jeweiligen Workspace, nicht am Assistenten.

• Innerhalb des Assistenten, den Du erstellt hast: Auch wenn Du den Assistenten über das Teilen-Symbol mit Kolleg*innen teilst, übernehmen sie Deine Datenbankverbindung nicht automatisch. Sie sehen im Assistenten einen "Verbinden"-Button und müssen dort einmalig denselben Verbindungsstring selbst hinterlegen.
• In einem eigenen Assistenten oder direkt im Chat: Du selbst kannst Deine eine konfigurierte Verbindung beliebig oft wiederverwenden – in jedem weiteren Assistenten und auch direkt im Chat über die Konnektor-Auswahl, ohne sie neu einzutragen. Für Kolleginnen gilt das nicht: Jede Person braucht einen eigenen Konnektor-Eintrag. Richte dafür nach Möglichkeit einen eigenen Datenbankbenutzer pro Person mit denselben eingeschränkten Rechten ein (siehe „Zugriff richtig einschränken“ unten); so lässt sich der Zugriff einzelner Kolleginnen gezielt entziehen. Geht das nicht, teilen sich alle denselben Login - ein Passwortwechsel entzieht dann allen gleichzeitig den Zugriff.

Anders als bei OAuth-Konnektoren wie SharePoint oder Google Workspace (siehe Verbindungsmodell), die sich einmal autorisieren lassen und danach überall nutzbar sind, gibt es für das Datenbank-Tool aktuell keine Möglichkeit, eine Verbindung einmalig für die ganze Organisation einzurichten.

Mehrere Datenbanken anbinden

Das Datenbank-Tool kennt pro Person und Workspace genau eine Datenbankverbindung. Diese eine Verbindung gilt in all Deinen Assistenten und im Chat; ein zweiter Eintrag mit einer anderen Datenbank lässt sich nicht anlegen. Für mehrere Datenbanken gibt es zwei Wege:

• Eigener MCP-Server pro Datenbank: Betreibe für jede Datenbank einen MCP-Server, der SQL-Zugriff anbietet, und lege jeden als eigenen Konnektor an (siehe Custom MCP Server). Jeder Eintrag hat eigene Zugangsdaten und lässt sich getrennt aktivieren. Der Server muss per HTTPS aus dem Internet erreichbar sein; hinter einer Firewall musst Du die MeinGPT-IP-Adressen freischalten (siehe IP-Freischaltung). Die Einstellung „Erlaubte Aktionen der Konnektoren“ gilt nur für die in MeinGPT eingebauten Konnektoren, nicht für eigene MCP-Server. Schreibzugriffe begrenzt Du deshalb im MCP-Server selbst oder mit einem Datenbankbenutzer, der nur lesen darf.
• Datenbank über einen Outpost freigeben: Liegt die Datenbank im eigenen Netz, kannst Du sie als Dienst über einen Outpost freigeben. Jede freigegebene Datenbank erscheint als eigener Konnektor „via Outpost“ (siehe Dienste: Datenbank, MCP-Server, HTTP-API). Das setzt die Dienste-Vorschau für Deinen Workspace voraus.

Fehlerbehebung bei Verbindungsproblemen

Der Verbindungstest baut eine direkte TCP-Verbindung zur Zieldatenbank auf — ohne Proxy oder Zwischenschicht. Die häufigsten Ursachen für „Verbindung fehlgeschlagen", wenn die Zugangsdaten korrekt sind:

• Nur die IP-Adresse freigeschaltet, aber kein Port-Forwarding. Eine Firewall-Regel für die MeinGPT-IPs (siehe IP-Freischaltung) reicht allein nicht — der Zielport muss zusätzlich per NAT/Port-Forwarding von außen erreichbar sein. Prüfe das mit einem Verbindungstest von außerhalb Deines Netzwerks auf genau Host und Port.
• MSSQL mit benanntem Server-Instance statt fester Portnummer. Ein benannter SQL-Server-Instance-Name (SERVER\INSTANZ) löst den tatsächlichen Port dynamisch über den SQL Server Browser Service auf UDP 1434 auf. Ist UDP 1434 nicht erreichbar oder der Browser-Dienst deaktiviert, schlägt die Auflösung fehl — verwende stattdessen die feste TCP-Portnummer der Instanz direkt in der Verbindungs-URL.
• Datenbankbenutzer ohne Remote-Login-Recht. Der Benutzer aus X-Database-URL braucht explizite Berechtigung für Verbindungen von außerhalb localhost (bei MSSQL z. B. eine Server-Login- statt reine Datenbank-Berechtigung).
• TLS bei MSSQL lässt sich nicht abschalten, wird aber nicht erzwungen. MeinGPT fordert bei Microsoft SQL Server eine verschlüsselte Verbindung an (encrypt: true) und akzeptiert dabei jedes Server-Zertifikat, auch selbstsignierte. Meldet der Server, dass er keine Verschlüsselung unterstützt, kann die Verbindung unverschlüsselt zustande kommen. Ein Zertifikatsproblem ist daher keine Ursache für einen fehlgeschlagenen Test.
• TLS bei PostgreSQL ist nicht voreingestellt. MeinGPT schaltet TLS nicht von sich aus ein. Hänge ?sslmode=require an die X-Database-URL an, um die Verbindung zu verschlüsseln. Dabei wird das Serverzertifikat vollständig geprüft (Zertifikatskette und Hostname); der Server braucht also ein Zertifikat einer öffentlich vertrauten Zertifizierungsstelle. Mit ?sslmode=no-verify wird verschlüsselt, ohne die Identität des Servers zu prüfen.
• Reverse Proxies vor der Datenbank. Ein HTTP(S)-Reverse-Proxy kann kein rohes Datenbankprotokoll (PostgreSQL-, MySQL- oder TDS-Wire-Protocol) durchreichen. Zwischen MeinGPT und der Datenbank darf nur eine reine TCP-Weiterleitung liegen, kein Layer-7-Proxy.

Was das Tool selbst begrenzt — und was nicht

Das Tool erzwingt genau zwei Dinge:

• Read-only-Trennung: query_database_readonly weist alles ab, was nicht mit SELECT, SHOW, DESCRIBE, EXPLAIN, PRAGMA oder WITH beginnt, und setzt die Session read-only.
• Grenzen gegen Ausreißer: ein Statement-Timeout von 30 Sekunden und die Zeilenobergrenze aus X-Max-Rows.

Zugriff richtig einschränken

Die Berechtigungen liegen beim Datenbankbenutzer, mit dem Du Dich verbindest. Drei Bausteine reichen für die meisten Fälle:

1. Ein eigener Benutzer, der nur lesen darf

CREATE USER mgpt_reader WITH PASSWORD 'ein-starkes-passwort';
GRANT CONNECT ON DATABASE meine_db TO mgpt_reader;
GRANT USAGE ON SCHEMA public TO mgpt_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mgpt_reader;

2. Views statt Rohtabellen, wo Spalten sensibel sind

CREATE VIEW kunden_sicht AS
SELECT id, name, email, land
FROM kunden;
-- ausgeschlossen: steuernummer, bankverbindung, …

3. Row Level Security, wenn Zeilen je Mandant getrennt bleiben müssen

Damit gilt die Einschränkung unabhängig davon, welche Abfrage der Assistent formuliert.

Beispiele

„Was waren letztes Quartal unsere zehn umsatzstärksten Produkte?"

SELECT p.product_name,
       SUM(s.quantity * s.unit_price) AS revenue,
       COUNT(DISTINCT s.order_id) AS order_count
FROM sales s
JOIN products p ON s.product_id = p.id
WHERE s.order_date >= '2026-01-01'
  AND s.order_date < '2026-04-01'
GROUP BY p.product_name
ORDER BY revenue DESC
LIMIT 10;

„Prüf die Bestelltabelle auf Datenqualitätsprobleme."

SELECT COUNT(*) AS total_rows,
       COUNT(*) FILTER (WHERE customer_id IS NULL) AS null_customers,
       COUNT(*) FILTER (WHERE order_date IS NULL) AS null_dates,
       COUNT(*) FILTER (WHERE total_amount < 0) AS negative_amounts
FROM orders;

Der Assistent formuliert die Abfrage, führt sie aus und erklärt das Ergebnis. Bei unbekannten Strukturen sieht er sich vorher mit get_database_schema das Schema an.

Empfehlungen für den Betrieb

• Read-only als Standard. X-Allow-Write nur dort einschalten, wo ein Assistent wirklich schreiben soll — und dann mit einem Datenbankbenutzer, der nur die dafür nötigen Rechte hat.
• Indizes für die häufigen Muster. Das 30-Sekunden-Timeout trifft sonst zuerst die interessanten Abfragen.
• Vorberechnete Views für wiederkehrende Auswertungen, statt jedes Mal über die Rohdaten zu aggregieren.
• X-Max-Rows bewusst setzen, wenn Tabellen groß sind: der Standard von 5000 Zeilen ist eine Obergrenze, kein Richtwert.

Weiterlesen

• Werkzeuge und Connectors im Überblick
• Datenbanken anbinden
• Trust Center