Google Keyword Planner podłączony do AI: raport bez lukru
Chciałem, żeby Claude sam widział realne dane Google o słowach kluczowych — liczbę wyszukiwań, konkurencję, prognozę kliknięć — zamiast zgadywać na wyczucie. Poniżej szczery raport z podłączenia: co poszło gładko, a co zajęło więcej czasu niż sama instalacja.
Po co to w ogóle
Google Ads ma Keyword Planner — oficjalne narzędzie doboru słów kluczowych z realnymi liczbami: ile razy miesięcznie szuka się frazy, jaka tam konkurencja, ile może kosztować kliknięcie. Dane są dokładne, bo pochodzą prosto od źródła. Pomysł był prosty: dać asystentowi AI dostęp do tych danych przez protokół MCP (Model Context Protocol), żeby nie przełączać zakładek i nie przepisywać liczb ręcznie.
Wybór implementacji
Oficjalny serwer MCP od Google dla Ads API istnieje, ale w praktyce obsługuje tylko ogólne zapytania do konta — listy klientów, dowolne zapytania GAQL, metadane. O Keyword Planner nie ma tam ani słowa. Trzeba było sprawdzić implementacje open source firm trzecich. Rozrzut spory: od ciężkich serwerów z 30+ narzędziami do zarządzania kampaniami i budżetami po wąskie narzędzia na trzy komendy. Do zadania „daj mi liczby dla słów kluczowych” ciężka wersja byłaby zbędnym ryzykiem — nadmiarowe uprawnienia dla funkcji, które nie są potrzebne. Wybrałem kompaktowy serwer o nazwie google-keyword-planner-mcp — natywny plik wykonywalny bez Pythona i Node.js, trzy narzędzia: generowanie pomysłów na słowa kluczowe, metryki historyczne, prognoza wyświetleń i kliknięć. Otwarty kod, licencja MIT, da się przeczytać w dziesięć minut.
Pierwsza niespodzianka: developer token tylko z konta menedżera
Żeby korzystać z Google Ads API, potrzebny jest tzw. developer token. Logicznie było pójść do już istniejącego konta reklamowego i tam go pobrać — ale sekcja „Centrum API” w Google Ads okazała się dostępna wyłącznie z konta menedżera (MCC), nie ze zwykłego konta reklamowego. Zwykłe konto po prostu nie pokazuje tej sekcji, bez żadnego wyjaśnienia w interfejsie. Trzeba było założyć osobne konto menedżera — bezpłatnie, bez karty, ale to dodatkowy krok, o którym nikt wprost wcześniej nie uprzedza.
Klient OAuth i jednorazowa autoryzacja
Dalej — standardowa ścieżka dla aplikacji desktopowych Google: w Google Cloud tworzy się klienta OAuth typu „Desktop app”, włącza się Google Ads API. Refresh token pobiera się raz prostym skryptem: uruchamia lokalny serwer HTTP na porcie, otwiera stronę autoryzacji w przeglądarce, łapie kod zwrotny i wymienia go na tokeny. Później ponowne logowanie nie jest potrzebne — serwer sam odświeża dostęp.
Drugi niuans: domyślny poziom testowy
Serwer wystartował, protokół ożył, lista narzędzi zwraca się poprawnie — ale realne zapytanie do żywego konta reklamowego zwróciło odmowę: nowy developer token domyślnie działa tylko z kontami testowymi. Żeby dostać dane z prawdziwego konta, trzeba osobno złożyć wniosek o rozszerzony poziom dostępu (Basic/Standard) i poczekać na rozpatrzenie. Technicznie wszystko jest gotowe i działa — ale właśnie ten krok rozciąga się w czasie najbardziej i warto zostawić na niego zapas, a nie liczyć na natychmiastowy efekt.
Podsumowanie
Sama integracja to sprawa paru godzin: pobrać plik, założyć dane uwierzytelniające, raz przejść autoryzację, zarejestrować serwer. Najwięcej czasu zjada nie strona techniczna, a biurokracja po stronie Google — konto menedżera, które nie zakłada się automatycznie, i kolejka do rozszerzonego dostępu. Dalej to już rutynowe narzędzie: AI widzi realny popyt na słowa kluczowe prosto podczas pracy nad tekstem czy kampanią reklamową, bez przełączania kontekstu i bez zgadywania na oko.
Jeśli robisz coś podobnego — zaplanuj osobny czas właśnie na część administracyjną u Google, a nie tylko na samą instalację serwera MCP.




