PostgreSQL MCP: Zuerst das Tabellenschema ansehen, dann eine schreibgeschützte Abfrage ausführen

Für wen

Für alle, die ein Modell PostgreSQL-Tabellenstrukturen ansehen und schreibgeschütztes SQL ausführen lassen wollen. Die Evidenz sagt: Dieses MCP bietet schreibgeschützten Zugriff auf PostgreSQL, um das schema zu prüfen und schreibgeschützte Abfragen auszuführen.

Du musst eine verbindbare postgresql:// URL liefern und akzeptieren, dass das Modell Tabellenstrukturen und Abfrageergebnisse sieht. Eine schreibgeschützte Transaktion ist kein „Nullrisiko“: Sie verbindet weiter, liest weiter Daten, und die URL kann Benutzername und Passwort tragen.

Die Evidenz listet keine Clients. Die offizielle Seite liegt im Baum servers-archived; die Evidenz nennt den Wartungsstatus nicht extra. Nimm nicht an, dass dies noch die aktuelle Hauptempfehlung ist.

Erster Versuch in 3 Minuten

Nimm den NPX-Hauptpfad; Docker ist nicht die Hauptinstallation. In der MCP-Konfiguration des Clients verwende:

"command": "npx",
"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://localhost/mydb"
]

Ersetze die letzte URL durch eine Datenbank, auf die du schreibgeschützt zugreifen darfst. Benutzername und Passwort dürfen laut Evidenz als postgresql://user:password@host:port/db-name stehen. Klebe kein produktives Schreibkonto und kein vollständiges Passwort in das Gespräch.

Voraussetzungen: Auf dem Rechner ist npx; die Datenbank erlaubt Verbindungen von diesem Prozess; beim ersten Mal nur das schema prüfen oder eine Abfrage, die keine Daten ändert.

Konfiguration: command / args des Client-MCP-Servers. Das dritte Argument ist die Verbindungszeichenfolge.

Risikoarmer erster Aufruf: zuerst die Ressource postgres://<host>/<table>/schema lesen, um Spaltennamen und Typen einer Tabelle zu sehen; oder das Tool query mit einem sql-String aufrufen — die Evidenz garantiert Ausführung in einer READ ONLY-Transaktion. Nicht INSERT/UPDATE/DELETE nutzen, um „Schreibschutz zu prüfen“.

Erfolgssignal: Nach der Verbindung listet der Client Tabellen-schema-Ressourcen, oder query liefert ein schreibgeschütztes Ergebnis. Schlägt die Verbindung fehl, zuerst die URL ändern (lokale DB, Port, Datenbankname); nicht auf Docker wechseln und raten. Zu Docker ergänzt die Evidenz nur: Unter macOS, wenn der Dienst auf dem Host läuft, host.docker.internal verwenden.

Anwendungsfälle

Fall 1: Klären, welche Spalten eine Tabelle hat. postgres://<host>/<table>/schema lesen. Die Evidenz sagt: Das ist ein aus Datenbankmetadaten automatisch entdecktes JSON schema mit Spaltennamen und Datentypen. Es gibt keine API zur Tabellennamen-Enumeration; <host> und <table> nach der tatsächlichen Verbindung ersetzen. Nicht sichtbare Tabellen nicht erfinden.

Fall 2: Eine schreibgeschützte Abfrage auf einer bereits bestätigten Tabelle ausführen. query aufrufen; der einzige Parameter ist sql. Die Evidenz garantiert Ausführung in einer READ ONLY-Transaktion; Paginierung, Timeouts und den ausführbaren SQL-Dialektumfang beschreibt sie nicht. Bestätigt ist nur: Dieses SQL geht als schreibgeschützte Abfrage in die verbundene Datenbank. Nicht annehmen, temporäre Tabellen zu schreiben oder zustandsändernde Funktionen aufzurufen.

Grenzen

Das ist schreibgeschützter Zugriff, keine rückgängig machbare Schreiboperation: Die Evidenz gibt kein undo. Die Verbindungszeichenfolge kann ein Passwort enthalten — das ist Credential- und Datenebenen-Exposition. Das einzige Tool ist query. Docker und NPX sind verschiedene Pfade; Hauptpfad bleibt NPX. Die Evidenz schreibt weder Connection-Pooling noch SSL noch die Durchsetzung einer schreibgeschützten Rolle, und sie behauptet nicht, dass eine READ ONLY-Transaktion jede Nebenwirkung blockiert (manche SQL-Funktionen können weiter externe Effekte haben, die Seite führt das nicht aus). Die Seite liegt in einem archivierten Repository-Baum; die Evidenz liefert kein Ersatzpaket und keine Migrationsanleitung.