Skip to content
Wróć do bloga
Poradnik5 min czytania

Supabase, Vercel i RevenueCat wewnątrz Claude Code: setup MCP, na którym powstał Council

Jak podłączyłem Supabase, Vercel i RevenueCat do Claude Code przez MCP podczas budowy Council — dokładny setup każdej usługi i trzy przepustki gościnne.

Claude CodeMCPSupabaseVercelRevenueCat
Supabase, Vercel, RevenueCat, MCP i Claude Code połączone z aplikacją mobilną Council

Kiedy opisywałem, jak zbudowany jest Council, skupiłem się na architekturze: jeden backend na Next.js + Supabase, aplikacja webowa, aplikacja Expo, dwóch dostawców płatności sprowadzonych do jednej tabeli subskrypcji. Nie opowiedziałem jednak, jak to powstawało dzień po dniu — a szczera odpowiedź brzmi: zaskakująco duża część pracy w ogóle nie działa się w edytorze. Działa się w dashboardach: edytorze SQL Supabase, stronie deploymentów Vercela, katalogu produktów RevenueCat.

MCP (Model Context Protocol) to rzecz, która złożyła te dashboardy prosto do mojego terminala. To otwarty standard pozwalający usługom wystawiać swoje API asystentowi AI, a Claude Code obsługuje go natywnie. Gdy Supabase, Vercel i RevenueCat zostały podłączone, „sprawdź schemat“, „zajrzyj do logów deployu“ i „utwórz produkty na iOS“ przestały być przełączaniem kart i stały się zdaniami. Ten wpis to setup wszystkich trzech, dokładnie taki, jakiego używa Council.

Supabase: baza danych jako rozmówca

Supabase udostępnia hostowany serwer MCP, więc nie ma czego instalować. Wpis ląduje w .mcp.json projektu (plik jest w repozytorium, więc każda sesja dostaje go automatycznie):

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

Pierwsze użycie uruchamia logowanie OAuth w przeglądarce — i to cały setup. Dwa szczegóły znaczą więcej, niż się wydaje:

  • Ogranicz zakres przez project_ref. Bez niego MCP widzi każdy projekt w twojej organizacji Supabase. Z nim Claude może dotykać wyłącznie bazy tego projektu. Jeśli pracujesz nad kilkoma produktami w sąsiednich folderach (ja tak), to różnica między „asystentem z dostępem do jednej bazy“ a „asystentem z dostępem do wszystkich“.
  • Dodaj narzędzia read-only do allowlisty. W .claude/settings.json Council pozwala na list_tables i list_migrations bez pytania, a wszystko, co zapisuje, wciąż pyta. Więcej o tym niżej.

Jak to wygląda w praktyce: budując funkcję sesji, mogłem zapytać „jak teraz wygląda tabela sessions i czy jest indeks na anon_id?“ — i dostać odpowiedź z żywej bazy, a nie z potencjalnie nieaktualnego pliku migracji. Sprawdzanie schematu, szybkie zapytania odczytujące, grzebanie w logach po nieudanym webhooku, security advisors wyłapujące brakujące polityki RLS — wszystko bez wychodzenia z rozmowy, w której powstaje kod. Claude Code porównujący plik migracji z faktycznie wdrożonym schematem i łapiący rozjazd to rzecz, która kiedyś wymagała ode mnie wystarczającej podejrzliwości, żeby w ogóle to sprawdzić.

Vercel: deploye i zmienne środowiskowe bez dodatkowej karty

Vercel również utrzymuje hostowany endpoint MCP. Rejestruje się go jedną komendą:

claude mcp add --transport http vercel https://mcp.vercel.com

Podobnie jak Supabase, uwierzytelnia się przez OAuth przy pierwszym użyciu. Vercel wydaje dodatkowo oficjalny plugin do Claude Code, który na MCP nakłada skille — /vercel:deploy, /vercel:env, /vercel:status — więc typowe scenariusze to jedna komenda slash zamiast akapitu instrukcji.

Produkcyjny deploy Council to skrypt w repozytorium (npm run deploy:web), ale to wszystko wokół deployu jest miejscem, gdzie integracja się spłaca: sprawdzenie, czemu padł preview build, i przeczytanie jego logów; porównanie zmiennych środowiskowych między lokalnym .env.local a tym, co faktycznie stoi na produkcji; upewnienie się, że deployment podchwycił nową zmienną, zanim spędzi się dwadzieścia minut na debugowaniu „czemu ten klucz jest undefined“. Rozjazd środowisk między lokalną maszyną a produkcją to jedna z tych klas błędów, które są trywialne, gdy się spojrzy, i doprowadzają do szału, gdy się nie spojrzy — a teraz spojrzenie kosztuje jedno zdanie.

RevenueCat: cały katalog zakupów w formie rozmowy

To zaskoczyło mnie najbardziej. RevenueCat ma zarówno hostowany serwer MCP, jak i oficjalny plugin do Claude Code (plugin to przyjemniejsza droga — zawiera skille do typowych zadań, jak integracja paywalla czy testy w sandboksie). Hostowany serwer uwierzytelnia się sekretnym kluczem API v2 ograniczonym do projektu:

claude mcp add --transport http revenuecat https://mcp.revenuecat.ai/mcp \
  --header "Authorization: Bearer sk_..."

Każdy, kto konfigurował zakupy w aplikacji, zna ten taniec: products, entitlements, offerings, packages — każdy tworzony we właściwej kolejności, każdy odwołujący się do pozostałych, wszystko rozsiane po ekranach dashboardu. Z podłączonym MCP katalog mobilnych subskrypcji Council powstał jako dialog — „utwórz entitlement pro, podepnij produkt miesięczny i roczny, umieść je w domyślnym offeringu“ — a Claude Code wykonywał ekwiwalent klikania przez API i odczytywał stan z powrotem, żeby go zweryfikować. Potrafi też sprawdzić status produktów w sklepach i wyciągnąć metryki przychodów, co zamienia „jak konwertują triale“ w pytanie, a nie sesję raportowania.

Dla Council łączy się to szczególnie dobrze z architekturą z poprzedniego wpisu: webhooki RevenueCat zapisują do tej samej tabeli subscriptions w Supabase, do której pisze Stripe. To znaczy, że jeden asystent, podłączony do obu końców, może prześledzić zakup od zdarzenia RevenueCat aż do wiersza, który otwiera paywall. Debugowanie przez granice dwóch SaaS-ów w jednej rozmowie szczerze przypomina oszukiwanie.

Higiena uprawnień: odczyt za darmo, zapis pyta

Część, którą polecam skopiować każdemu: narzędzia MCP przechodzą przez ten sam system uprawnień, co wszystko inne w Claude Code, i warto poświęcić pięć minut na jego ukształtowanie. .claude/settings.json w Council wpisuje nieszkodliwe narzędzia read-only na allowlistę, żeby nie przerywały pracy:

{
  "permissions": {
    "allow": [
      "mcp__supabase__list_tables",
      "mcp__supabase__list_migrations",
      "mcp__plugin_RevenueCat_RevenueCat__list-projects",
      "mcp__plugin_RevenueCat_RevenueCat__list-products",
      "mcp__plugin_RevenueCat_RevenueCat__get-product-store-state"
    ]
  }
}

Wszystko, co zmienia stan — SQL zapisujący, tworzenie produktów, deploye — nadal prosi o potwierdzenie. Ten podział sprawia, że cały setup jest komfortowy: asystent może swobodnie patrzeć na produkcję, a dotykać jej tylko z moim palcem na przycisku.

Miejsce, w którym chwalę narzędzie, bo na to zasłużyło

Wypróbowałem wiele narzędzi AI do programowania i Claude Code jest tym, które przestało być odczuwalne jako narzędzie. Po części to zasługa modelu, ale w większym stopniu — właśnie tej historii integracji: przychodzi tam, gdzie mieszka twój stack. Serwery MCP powyżej, system uprawnień, który czyni je bezpiecznymi, skille pakujące procesy w komendy, pluginy od samych vendorów — to wszystko składa się jak dobra infrastruktura, nie jak demo. Council to produkt z dwóch aplikacji, z prawdziwym backendem, prawdziwymi płatnościami i prawdziwymi wydaniami w sklepach, zbudowany w pojedynkę — i nie sądzę, żeby „w pojedynkę“ było prawdą bez niego. To najbliższa rzecz, jaką miałem, do kolegi z zespołu, który przeczytał wszystkie dashboardy, pamięta każdy schemat i nigdy nie męczy go pytanie „czekaj, czemu tej zmiennej środowiskowej brakuje?“.

Trzy przepustki gościnne, jeśli się wahasz

Jeśli odkładasz wypróbowanie Claude Code — mam trzy przepustki gościnne do rozdania, kto pierwszy, ten lepszy:

Odbierz przepustkę gościnną →

Podłącz go do swoich odpowiedników Supabase/Vercel/RevenueCat i daj mu prawdziwe zadanie, nie zabawkowe. Właśnie wtedy wszystko zaskakuje. A jeśli budujesz coś w rodzaju Council — aplikacja webowa, aplikacja mobilna, jeden backend, prawdziwe subskrypcje — odezwij się: dowożenie takich produktów od zera do produkcji to to, czym się zajmuję.