MCP

Supabase in der IDE nur lesend abfragen, unter drei Sicherheitsstufen

Für Leute, die in Cursor und ähnlichen IDEs Supabase nur lesend abfragen wollen. Der Autor pflegt dieses Repository nicht mehr; Schreiben muss die drei Sicherheitsstufen akzeptieren.

Official source · Query MCP

Install

pipx install supabase-mcp-server

Für wen

Diese Anleitung gilt für Leute, die dieses Community Query MCP noch nutzen und in der IDE SQL sicher ausführen oder die Supabase Management API aufrufen wollen. Der offizielle Hauptweg: supabase-mcp-server mit pipx installieren und per stdio an Cursor, Windsurf oder Cline anbinden. Der Autor hat erklärt, dass er nicht mehr aktiv pflegt, und zeigt auf das offizielle Nachfolge-Repository. Wer eine langfristige Option will, sieht zuerst das Nachfolgeprojekt; dieses Repository nicht als einzigen Einstieg behandeln.

Nachfolge-Repository:

https://github.com/supabase-community/supabase-mcp

Es passt zu Leuten, die SQL zuerst im read-only-Modus ausführen. Die Belege sagen, read-only / read-write sei steuerbar, zur Laufzeit gebe es risk level assessment, und SQL werde in safe, write, destructive gestuft. Destructive-Anweisungen als Einstieg eignen sich nicht. Ungenannte Tool-Funktionsnamen nicht als bewiesene Schnittstellen behandeln.

Ersten Versuch in 3 Minuten

Die offiziell empfohlene Installation steht unten. Voraussetzung: diese Maschine kann pipx ausführen. Konfigurationsort ist ein MCP-Client mit stdio. uv pip install nicht gleichzeitig als weitere bevorzugte Installation behandeln.

pipx install supabase-mcp-server

Diese Repository-Seite:

https://github.com/alexander-zuev/supabase-mcp-server

Erster Versuch: die offizielle Nur-Lesen-SQL-Fähigkeit. Ausführungsmodus auf read-only, eine Abfrage ohne Datenänderung. Erfolgssignal: Abfrageergebnisse kommen zurück, kein Block durch die Sicherheitsrichtlinie. Nur-Lesen verbindet trotzdem dein Supabase/Postgres; nicht als ohne Netz und ohne Datenbankzugriff lesen. Der Server selbst nutzt asyncpg und hängt nicht mehr von lokalen PostgreSQL-Entwicklungsbibliotheken ab; PostgreSQL brauchst du nur noch, wenn du eine local Supabase instance betreibst.

Anwendungsfälle

Fall 1: Nur-Lesen-Datenabfrage. Das entspricht Control read-only ... SQL query execution. Die Belege schreiben weder Tool-Funktionsnamen noch Beispiel-SQL; nichts erfinden. Bei Erfolg siehst du Ergebnisse, oft mit Risikoeinstufung.

Fall 2: Schema ändern oder Management API / Auth Admin SDK aufrufen. Das entspricht manage schema changes, call the Supabase Management API, use Auth Admin SDK. Das ist Schreiben: vor dem Aufruf im write-Modus sein und in der Dreistufen-Sicherheit sehen, ob es safe, write oder destructive markiert ist. Erfolgssignal: die Änderung wird von den Sicherheitskontrollen angenommen. Ohne offiziellen Rückweg nicht als leicht rücksetzbar beschreiben.

Grenzen

Der Autor pflegt nicht mehr aktiv. Nur-Lesen/Lesen-Schreiben und die drei Sicherheitsstufen sind eingebaute Kontrollen, kein Nullrisiko. Die Belege geben weder ein konkretes Tool-Register noch Geheimnis-Variablennamen noch Deinstallationsschritte. Die uv-Installation ist nur ein weiterer Paketmanager-Befehl in der Doku; nicht neben den pipx-Hauptweg stellen.