Google MCP Toolbox w Claude Code — BigQuery i dbt z agentem

Każda sesja w Claude nad projektem dbt wygląda podobnie — pierwsze kilkanaście minut na tłumaczenie architektury od zera. Jakie masz datasety, jaka jest struktura modeli, medallion czy monolityczna, które tabele są punktem wejścia. Zanim agent zacznie generować cokolwiek użytecznego, musisz go najpierw wprowadzić w swój kontekst.

Google ma dwa narzędzia, które to zmieniają. Pełnią różne role i ważne jest, żeby nie traktować ich tak samo.

Dwie warstwy — nie jeden produkt

Najczęstszy błąd przy opisywaniu tego ekosystemu: traktowanie MCP Toolbox i Data Agent Kit jako jednego bytu. To dwie osobne rzeczy.

MCP Toolbox for Databases (googleapis/mcp-toolbox, wcześniej genai-toolbox) to oficjalny projekt Google — repozytorium w organizacji googleapis, Apache 2.0, semantic versioning, ok. 16,6k gwiazdek (stan z października 2026). Istnieje od czerwca 2024, v1.0.0 wyszło w kwietniu 2026. To serwer MCP, który uruchamiasz sam (lokalnie albo na własnej infrastrukturze) i który daje agentowi dostęp do BigQuery, Spannera, AlloyDB, Cloud SQL i kilkudziesięciu innych baz. Ryzyko porzucenia: niskie.

Data Agent Kit (dak) to plugin dla Claude Code, Codex CLI i Antigravity CLI — repozytorium gemini-cli-extensions/data-agent-kit-starter-pack, v1.0.0 od końca września 2026. Zawiera 37 skilli (pliki Markdown z instrukcjami dla agenta) i konfigurację serwerów MCP. Ważna zmiana względem wersji z czerwca 2026, którą opisywałem pierwotnie: plugin nie podpina już MCP Toolbox, tylko łączy się ze zdalnymi serwerami MCP, które Google hostuje sam — bigquery.googleapis.com/mcp, dataplex.googleapis.com/mcp, spanner.googleapis.com/mcp i kolejnymi. Google ma historię porzucania projektów — Stadia, Inbox, Google Reader. Warto używać, ale nie budować na tym produkcyjnych workflow z założeniem wiecznego wsparcia.

	MCP Toolbox	Data Agent Kit
Co to jest	Serwer MCP z dostępem do baz GCP	Plugin: skille + zdalne serwery MCP Google
Gdzie działa serwer	U Ciebie (lokalnie albo własny hosting)	U Google (zarządzany endpoint)
Wymaga auth GCP	Tak — ADC	Tak — ADC (konfiguruje go skill `dak-setup`)
Dojrzałość	v1.x, ~16,6k ★, `googleapis`	v1.0, ~200 ★, plugin
Aktualizacja	Homebrew lub nowa binarka	Marketplace pluginów Claude Code

Co daje MCP Toolbox — konkretnie dla BigQuery

Gotowa konfiguracja bigquery (flaga --prebuilt bigquery) eksponuje 9 narzędzi. W codziennej pracy analitycznej wchodzą w grę przede wszystkim:

execute_sql — wykonuje zapytanie SQL
get_table_info — pobiera schemat tabeli: kolumny, typy, metadane
list_dataset_ids / list_table_ids — inwentaryzacja zasobów bez wychodzenia z Claude
search_catalog — szukanie tabel i widoków po słowach kluczowych przez Dataplex Catalog
ask_data_insights — pytania językiem naturalnym (Conversational Analytics API pod spodem)

Efekt praktyczny: Claude w ramach sesji odpytuje BigQuery, widzi aktualny schemat i generuje kod oparty na rzeczywistej strukturze — nie na tym, co mu powiedziałeś pół godziny temu.

Konfiguracja idzie przez zmienne środowiskowe: BIGQUERY_PROJECT, opcjonalnie BIGQUERY_LOCATION, plus ADC. Dwie zmienne ustawiam zawsze, zanim agent dostanie dostęp do danych produkcyjnych: BIGQUERY_READONLY=true (żadnego DML ani DDL) i BIGQUERY_MAXIMUM_BYTES_BILLED — zapytanie, które przeskanowałoby więcej, pada przed wykonaniem i nic nie kosztuje. Agent, który w pętli poprawia zapytanie na tabeli eventów GA4, potrafi spalić budżet szybciej niż człowiek.

Co dodają skille — domenowy kontekst bez tłumaczenia

Skille to pliki Markdown, które mówią Claude, jak myśleć o danym temacie i w jakiej kolejności działać. Same nie wykonują kodu. Na starcie sesji Claude widzi tylko ich krótkie opisy, a pełną treść dociąga dopiero wtedy, gdy zadanie pasuje do opisu. Dzięki temu 37 skilli nie zjada kontekstu. Dla analityka pracującego z GCP najistotniejsze są cztery:

gcp-data-pipelines — punkt wejścia dla każdego pytania o pipeline na GCP. Claude najpierw skanuje projekt (szuka dbt_project.yml, workflow_settings.yaml, importów Beam), żeby ustalić, co już masz. Jeśli projekt jest nowy, pokazuje tabelę porównawczą narzędzi — DTS, dbt, Dataflow, Dataform, Spark, Composer — i czeka na Twój wybór. Skill działa jako router: nie decyduje za Ciebie, przekazuje dalej dopiero po Twojej decyzji.

dbt-bigquery — ekspert od pipeline’ów dbt na BigQuery. Wie, jak zbudować model, jaka jest poprawna struktura projektu, jak pisać transformacje inkrementalne, gdzie leżą pułapki SQL (m.in. zamiana IN na EXISTS dla wydajności). Zanim cokolwiek zmieni, kompiluje projekt (dbt compile), żeby zobaczyć istniejący graf modeli.

dataform-bigquery — analogiczny kontekst dla Dataform: składnia SQLX, operacje inkrementalne (append, upsert), walidacja przez dataform compile. Wybór, gdy pracujesz natywnie z GCP i chcesz mieć harmonogram bez zewnętrznego orkiestratora.

gcp-pipeline-orchestration — generuje definicję pipeline’u orkiestracji dla Cloud Composera (zarządzany Apache Airflow): plik YAML z taskami i harmonogramem (dbt run, Spark job, Dataform workflow, SQL w BigQuery) plus deployment.yaml z ustawieniami środowisk dev i prod.

dbt + Composer vs Dataform — różnica, która ma znaczenie

Tu leży praktyczna decyzja architektoniczna, którą warto rozumieć przed konfiguracją.

dbt Core nie ma wbudowanego schedulera. Transformacje piszesz i uruchamiasz ręcznie lub przez własny skrypt, ale jeśli chcesz odpalać pipeline codziennie o 3:00 — potrzebujesz zewnętrznego orkiestratora. Na GCP najpełniejszym wyborem jest Cloud Composer (zarządzany Apache Airflow) i pod niego pisze skill gcp-pipeline-orchestration. Przy jednym projekcie dbt bez zależności od innych systemów wystarczy lżejszy zestaw: Cloud Run Jobs z Cloud Schedulerem. dbt Cloud ma własny scheduler, ale to płatna usługa.

Dataform jest natywnie zintegrowany z BigQuery i ma wbudowane harmonogramowanie z poziomu interfejsu GCP — bez Airflow, bez Composera, bez osobnego klastra do orkiestracji. Płacisz za wykonanie zapytań BQ, nie za dodatkową infrastrukturę. Kompromis: mniejsza elastyczność (tylko BigQuery), ale mniej do zarządzania.

Praktyczna heurystyka:

Masz już dbt i chcesz zachować stack — dodajesz Composer przez skill gcp-pipeline-orchestration
Zaczynasz od zera na GCP i zależy Ci na prostocie — Dataform ze skillem dataform-bigquery
Potrzebujesz orkiestrować heterogeniczny pipeline (dbt + Spark + własny Python) — Composer i tak jest potrzebny niezależnie od wyboru narzędzia transformacji

Jak to wygląda w Claude Code — przykład z dbt i Composerem

Zakładam: projekt BigQuery my-analytics-prod, dataset raw_events, chcę zbudować model silver z sesjami GA4 i uruchamiać go codziennie automatycznie.

Krok 1: autentykacja do GCP

gcloud auth login
gcloud auth application-default login

Pierwsze polecenie daje dostęp dla komend CLI. Drugie — dla bibliotek i serwerów MCP. Bez ADC żaden serwer BigQuery nie zadziała.

Krok 2: instalacja pluginu

GH=https://github.com/GoogleCloudPlatform
claude plugin marketplace add $GH/data-agent-kit-plugin
claude plugin install dak@dak-marketplace

Krok 3: konfiguracja projektu i regionu

W nowej sesji Claude Code uruchom skill konfiguracyjny:

/dak:dak-setup

Skill po kolei sprawdza gcloud i ADC, pyta o ID projektu (proponuje ten z gcloud config), region i usługi do włączenia, a potem zapisuje konfigurację. Gdy któryś krok się nie uda, zatrzymuje się i mówi, co blokuje. Na koniec wpisz /mcp — serwer dak-bigquery powinien być na liście.

Krok 4: generowanie modelu dbt z aktualnym schematem

Sprawdź schemat tabeli raw_events.ga4_events i napisz
dbt model silver_sessions — jeden wiersz na sesję
(user_pseudo_id + ga_session_id), partycjonowanie po
event_date, inkrementalny z merge na tym kluczu.

Claude przez MCP pobiera aktualny schemat z BigQuery, skill dbt-bigquery pilnuje poprawnej struktury modelu i generuje SQL, schema.yml i wpis w dbt_project.yml. Schemat nie jest wklejony ręcznie — agent go widzi bezpośrednio.

Krok 5: orkiestracja przez Cloud Composer

Stwórz pipeline Composera, który codziennie o 3:00 UTC
odpala dbt run --select silver_sessions i po sukcesie
uruchamia model gold_user_lifetime_value.

Skill gcp-pipeline-orchestration generuje plik pipeline’u i deployment.yaml. Nie wchodzisz do GUI Airflow — agent pisze pliki, a Ty je przeglądasz przed wdrożeniem.

Aktualizacja — z CHANGELOG-iem w ręku

Plugin aktualizujesz przez marketplace pluginów Claude Code (/plugin). Przed aktualizacją przeczytaj CHANGELOG.md w repozytorium: skille zmieniają zachowanie agenta, a zmiana skilla nie wywala żadnego builda — zobaczysz ją dopiero w tym, co agent robi. Między czerwcem a wersją 1.0 plugin wymienił całą warstwę MCP — kto nie czytał changeloga, nie miał jak tego zauważyć.

MCP Toolbox aktualizuje się niezależnie — przez Homebrew lub pobranie nowej binarki. Wydania śledź osobno, bo to stabilniejsza warstwa z własnym cyklem.

Ryzyka

Ryzyko	Ocena
Plugin młody, mała społeczność, konto GitHub poza `googleapis`	Realne. Skille to Markdown — łatwo je przeczytać przed użyciem i sforkować, gdyby projekt zamarł
Zdalne serwery MCP po stronie Google	Zapytania i wyniki idą przez infrastrukturę Google; sprawdź, czy polityka danych firmy na to pozwala
MCP Toolbox — binarka u Ciebie	Niskie — oficjalny projekt `googleapis`, dojrzały cykl wydań
Zmiany zachowania skilli po aktualizacji	Czytaj CHANGELOG przed każdą aktualizacją

MCP Toolbox warto wdrożyć niezależnie od decyzji o pluginie — to oficjalne, stabilne narzędzie, które eliminuje kopiowanie schematów i wyników zapytań między oknem BQ a sesją Claude. Skille traktuję jako przydatny kontekst domenowy, który skraca onboarding agenta do projektu, ale nie jako fundament infrastruktury.

Agent, który sam pisze modele dbt, potrzebuje też zasad, które go zatrzymają, zanim zepsuje dane — rozkładam to w tekście o governance w dbt. Przykład agenta, który czyta dane analityczne i odpowiada zespołowi, opisałem przy bocie GA4 na n8n i Slacku.