Jak dodać serwer MCP Supabase do Claude Code

Supabase udostępnia hostowany serwer MCP pod adresem https://mcp.supabase.com/mcp, a Claude Code zaczyna z nim pracować po jednej komendzie. Lokalnie nic się nie instaluje. Poniżej wersja skrócona: komenda, dwa sposoby uwierzytelnienia, trzy parametry w URL, które trzymają całość w ryzach, i reguły uprawnień, których używam. To „połowa o Supabase” z wpisu o trzech serwerach, na których stoi Council; RevenueCat ma osobny tekst.

Dodaj serwer

claude mcp add --scope project --transport http supabase \
  "https://mcp.supabase.com/mcp?project_ref=<your-project-ref>&read_only=true"

--scope project zapisuje wpis do .mcp.json w katalogu głównym repozytorium, więc dostaje go każda sesja w tym repo i każda osoba z zespołu. Tutaj to bezpieczne, bo w URL nie ma żadnego sekretu. Powstały plik wygląda tak:

{
  "mcpServers": {
    "supabase": {
      "type": "http",
      "url": "https://mcp.supabase.com/mcp?project_ref=<your-project-ref>&read_only=true"
    }
  }
}

Project ref to krótki identyfikator z adresu projektu w panelu Supabase: https://supabase.com/dashboard/project/<your-project-ref>.

OAuth albo personal access token

OAuth jest domyślny. Hostowany serwer korzysta z dynamicznej rejestracji klienta, więc nie trzeba zakładać aplikacji OAuth ani przechowywać tokenu. W Claude Code uruchom /mcp, wybierz supabase, kliknij Authenticate: otworzy się przeglądarka, w której logujesz się i wskazujesz organizację z projektem. Dokumentacja Supabase zaleca zrobić to ze zwykłego terminala, a nie z rozszerzenia IDE; u mnie też tak było.

Personal access token przydaje się w CI i w klientach bez obsługi OAuth. Utwórz go na stronie https://supabase.com/dashboard/account/tokens, ogranicz do projektu i przekaż w nagłówku:

claude mcp add --transport http supabase \
  "https://mcp.supabase.com/mcp?project_ref=<your-project-ref>&read_only=true" \
  --header "Authorization: Bearer sbp_..."

W tym wariancie pomiń --scope project: ten zakres zapisuje .mcp.json, który z założenia trafia do commita, a razem z nim trafiłby tam token.

W npm nadal jest pakiet @supabase/mcp-server-supabase do self-hostingu i AI SDK, ale dla Claude Code dokumentacja opisuje serwer hostowany i od niego bym zaczął.

Trzy parametry warte ustawienia

• project_ref ogranicza serwer do jednego projektu i wyłącza narzędzia na poziomie konta (list_projects, create_project, pause_project). Bez niego asystent widzi wszystkie projekty w organizacji. Prowadzę kilka produktów z sąsiednich katalogów, więc to dla mnie różnica między dostępem do jednej bazy a dostępem do wszystkich.
• read_only=true wykonuje każde zapytanie jako użytkownik Postgresa tylko do odczytu. Zapis odbija się od bazy, a nie od promptu.
• features zawęża grupy narzędzi, rozdzielone przecinkami: features=database,docs,debugging wystarcza w większości sesji.

Sprawdź, czy działa

Poproś o coś, co tylko czyta:

Jakie tabele są w bazie i czy na anon_id jest indeks?

Claude Code powinien wywołać list_tables i odpowiedzieć na podstawie żywego schematu. Jeśli odpowiada z pliku migracji, serwer nie jest podłączony: /mcp pokaże dlaczego.

Co potrafi

Grupa	Przykładowe narzędzia	Domyślnie
Database	list_tables, list_migrations, apply_migration, execute_sql	włączona
Debugging	query_logs, get_advisors	włączona
Development	get_project_url, get_publishable_keys, generate_typescript_types	włączona
Edge Functions	list_edge_functions, deploy_edge_function	włączona
Docs	search_docs	włączona
Account	list_projects, create_project, get_cost	wyłączona przy project_ref
Branching	create_branch, merge_branch	eksperymentalna, płatne plany
Storage	list_storage_buckets, update_storage_config	wyłączona

W Council najbardziej opłaciła się grupa Debugging. get_advisors wskazuje tabele bez polityk row-level security, a przez query_logs znalazłem przyczynę awarii webhooka RevenueCat na produkcji: błąd siedział w logu Postgresa, nie w logu aplikacji. Drugi zysk to kontrola dryfu schematu. Pytanie, czy wdrożony schemat nadal zgadza się z plikami migracji, wyłapuje pomyłki, które wcześniej znajdowałem dopiero wtedy, gdy już coś podejrzewałem.

Odczyt na allowliście, zapis niech pyta

Narzędzia MCP przechodzą przez zwykły system uprawnień Claude Code. W .claude/settings.json Council narzędzia do odczytu działają bez pytania:

{
  "permissions": {
    "allow": [
      "mcp__supabase__list_tables",
      "mcp__supabase__list_migrations",
      "mcp__supabase__get_advisors",
      "mcp__supabase__search_docs"
    ]
  }
}

execute_sql i apply_migration nadal pytają, nawet w trybie tylko do odczytu: chcę zobaczyć zapytanie, zanim się wykona.

Nie podłączaj produkcji bez read_only

Serwer działa z Twoimi uprawnieniami dewelopera, więc to narzędzie wewnętrzne, a nie coś, z czym rozmawia użytkownik końcowy. Wynikają z tego dwa nawyki. W pracy interaktywnej łącz się z produkcją tylko wtedy, gdy zadanie tego wymaga, z ustawionymi project_ref i read_only=true, i zostaw ręczne zatwierdzanie wszystkiego, co zapisuje. W zadaniach bez nadzoru zatwierdzaj z góry wyłącznie narzędzia tylko do odczytu, ograniczone do jednego projektu, i niech zgłaszają rekomendacje zamiast wprowadzać zmiany. Powód to prompt injection: tekst, który asystent czyta, czy to zgłoszenie do supportu, czy wiersz w tabeli, może próbować namówić go do wykonania zapytania. Użytkownik Postgresa tylko do odczytu jest zabezpieczeniem na wypadek, gdy prompt zawiedzie.

Zmiany schematu najpierw lądują na gałęzi deweloperskiej albo w osobnym projekcie, a na produkcję trafiają jako migracja, którą przeczytałeś.