Supabase MCP einrichten: Projekt und Leserechte begrenzen

Noch unsicher beim Zugangsweg? Der Datenbank-Assistent erstellt einen Prüfplan; der Datenbankvergleich ordnet Datei, Rolle und Projekt ein.

Für den ersten Supabase-MCP-Test sollte feststehen, welches Projekt angesprochen werden darf und welche Daten Sie lesen möchten. Wählen Sie ein Entwicklungsprojekt mit einer kleinen Testtabelle statt einer offenen Frage über sämtliche Datenbanken. Dieser Leitfaden trennt drei Einstellungen, die unterschiedliche Aufgaben erfüllen: die Projektauswahl, den Lesemodus und die angebotenen Werkzeuggruppen. Erst ein anschließender Abruf zeigt, ob die gewünschte Tabelle tatsächlich erreichbar ist.

Den gehosteten Endpunkt eingrenzen

Supabase dokumentiert https://mcp.supabase.com/mcp als gehosteten Endpunkt. Der Parameter project_ref begrenzt den Zugriff auf ein Projekt, read_only=true lässt Datenbankabfragen als lesenden Postgres-Nutzer laufen und features wählt Werkzeuggruppen aus. Diese Einstellungen ergänzen sich. Eine eingeschränkte Werkzeugauswahl ist nicht dasselbe wie eine eingeschränkte Projektwahl.

Ein Beispiel für die Vorbereitung lautet https://mcp.supabase.com/mcp?project_ref=IHRE_PROJEKTREFERENZ&read_only=true&features=database. Ersetzen Sie den Platzhalter durch die Referenz Ihres Testprojekts und übernehmen Sie die URL in das zum Client passende Feld. Nutzen Sie die Clientübersicht für das Format und prüfen Sie anschließend die tatsächlich angezeigte Konfiguration. Die normale gehostete Einrichtung führt durch eine Anmeldung; ein Datenbankpasswort gehört nicht in diese URL.

Die drei Grenzen getrennt kontrollieren

Notieren Sie die Projektadresse und den erwarteten Tabellennamen vor dem Test. Eine erfolgreiche Abfrage gegen ein anderes Projekt wäre technisch erfolgreich und fachlich trotzdem falsch. Prüfen Sie neben dem Namen deshalb auch eine vorbereitete Testzeile. Wählen Sie wenige Spalten und eine kleine Ergebnismenge. Ein vollständiger Export hilft bei dieser Frage nicht weiter und macht die Kontrolle unnötig schwer.

Mit einer kleinen Tabelle beginnen

1. Legen Sie im vorgesehenen Entwicklungsprojekt eine unkritische Testressource fest. Notieren Sie Schema, Tabelle und erwartete Werte.

2. Tragen Sie die eingegrenzte Server-URL ein und schließen Sie die Anmeldung ab. Prüfen Sie die Projektzuordnung und Werkzeugliste.

3. Lassen Sie zuerst die Tabellenstruktur prüfen und lesen Sie dann nur die vorbereiteten Werte. Vergleichen Sie das Ergebnis direkt mit dem Dashboard.

4. Halten Sie Umfang und Ergebnis fest. Nach einem Projektwechsel oder geänderten Werkzeuggruppen wiederholen Sie genau diesen Test, bevor Sie den Ablauf erweitern.

Verbindungsfehler von Datenbankfragen unterscheiden

Wenn die Anmeldung scheitert, beginnen Sie bei der MCP-Fehlersuche. Wenn Tabellen fehlen, prüfen Sie Projekt und Schema, bevor Sie die Verbindung neu anlegen. Die PostgreSQL-Anleitung vertieft die Planung eines begrenzten Datenbanktests. Über die Supabase-Registersuche finden Sie weitere Einträge; prüfen Sie deren Quelle, bevor Sie Einstellungen des offiziellen Dienstes auf ein anderes Projekt übertragen.

Reicht die Projektreferenz als Leseschutz?

Nein. Projektauswahl und Lesemodus sind getrennte Einstellungen. Prüfen Sie beide vor dem Test.

Ist read_only eine Zusage über alle Datenflüsse?

Nein. Der dokumentierte Parameter betrifft Datenbankabfragen. Prüfen Sie zusätzlich Werkzeuggruppen und den konkreten Vorgang.

Belegt ein Tabellenname den richtigen Datenbestand?

Nicht allein. Vergleichen Sie die Projektreferenz und eine bekannte Testzeile, da Namen in mehreren Projekten vorkommen können.

Soll ich nach einem Fehler sofort Schreibrechte freigeben?

Nein. Prüfen Sie erst Projekt, Schema, Anmeldung und fehlgeschlagenen Vorgang. Ein Lesetest benötigt keinen vorsorglichen Schreibversuch.

Herstellerdokumentation abgerufen am 1. Oktober 2026. Die Testabläufe sind redaktionelle Vorschläge.

1. Supabase MCP Server
   Abrufbefehl anzeigen

   curl -s https://supabase.com/docs/guides/ai-tools/mcp

Alle Beiträge