Google Search Console MCP: co tak naprawdę wystawiają cztery serwery MCP do SEO

Serwery MCP Google Search Console to sposób, w jaki agent czyta twoje dane wyszukiwania bez wcześniejszego eksportu CSV. To część łatwa. Trudna to odróżnienie serwerów od siebie, bo wszystkie przedstawiają się tak samo, a różnica wychodzi dopiero wtedy, gdy zapytasz, co naprawdę potrafią.

Więc zapytaliśmy. 12 września 2026 połączyliśmy cztery opublikowane serwery MCP do SEO, wysłaliśmy do każdego żądanie tools/list i policzyliśmy, co wróciło. Wyszło 42, 21, 4 i 1.

Ten rozrzut nie jest rankingiem jakości. To decyzja projektowa i zmienia to, co agent może zrobić, ile kosztuje cię w kontekście i ile twoich danych opuszcza twój obręb.

Co testowaliśmy i jak

Metoda: każdy serwer uruchamialiśmy dokładnie tak, jak nakazuje jego własna dokumentacja — przez standardowe wejście i wyjście albo przez HTTP, gdy dokumentacja wskazywała ten tryb. Wysłaliśmy uścisk dłoni initialize z MCP, potem tools/list, i zapisaliśmy liczbę oraz nazwy narzędzi. Kluczy API użyliśmy wyłącznie tam, gdzie serwer odmawiał startu bez klucza.

Jeden serwer, pakiet Search Console od strony trzeciej, nie dokończył uścisku dłoni w naszym 50-sekundowym oknie, więc został wykluczony, a nie oceniony. Listy narzędzi zmieniają się z każdym wydaniem, więc traktuj te liczby jako zdjęcie pewnego poranka, nie jako trwałą właściwość któregokolwiek dostawcy.

Cztery konstrukcje i do czego służy każda

Otoczka (21 narzędzi). mcp-gsc bierze Search Console API i opakowuje każdy raport w nazwane narzędzie. Jego lista czyta się jak opis stanowiska analityka wyszukiwania: search_analytics, inspect_url, top_movers, quick_wins, cannibalization, content_decay, device_country_breakdown, ctr_anomalies, weekly_seo_report, indexing_coverage. Zysk: model nigdy nie musi budować zapytania. Cena: dziedziczysz cudze zdanie o tym, co raport powinien zawierać, a o nic spoza listy nie da się poprosić.

Zwierciadło całej platformy (42 narzędzia). Serwer Ahrefs wystawia powierzchnię produktu dostawcy punkt końcowy po punkcie końcowym: rank-tracker-overview, rank-tracker-competitors-overview, keywords-explorer-matching-terms, keywords-explorer-volume-history, batch-analysis. To najbogatsza lista, jaką zmierzyliśmy, i zarazem najdroższa w kontekście, bo każda definicja narzędzia ładuje się niezależnie od tego, czy dotyczy zadania. Najwyraźniej też pokazuje kompromis: szerokość możliwości w zamian za stały podatek od każdego promptu.

Brama (4 narzędzia). Serwer DataForSEO w wersji 3 poszedł w przeciwną stronę. Wystawia docs_index, docs_list_sections, docs_search i jedno ogólne narzędzie api_request. Zamiast nazywać każdy punkt końcowy, uczy model znaleźć dokumentację i dopiero potem wykonać uwierzytelnione wywołanie. Cztery narzędzia pokrywają API z setkami punktów końcowych, a model płaci za konkretność przy wywołaniu, nie przy ładowaniu. W naszym sprawdzeniu punkt końcowy HTTP zwrócił invalid auth bez poświadczeń i odpowiedział poprawnie z nimi. To zachowanie pożądane.

Serwer jednego narzędzia (1 narzędzie). seo-mcp-server zwraca dokładnie jedno narzędzie, ai_content_detect. Nie ma nic złego w małym serwerze, ale powinien być szczery co do tego, czym jest: demonstracją albo pojedynczym sprawdzeniem, nie warsztatem SEO. Jeśli zainstalujesz go, oczekując raportu tygodniowego, rozczarujesz się w sposób, o którym instrukcja instalacji nigdy nie wspomniała.

Cztery archetypy. Dwa z nich skalują się do prawdziwej pracy raportowej i każde skaluje się w innym kierunku.

Dlaczego liczba narzędzi to zły nagłówek

Dwa serwery o tej samej liczbie mogą zachowywać się zupełnie różnie, bo liczy się kształt granicy, nie cyfra.

Otoczka rozstrzyga twoje pytania z góry. To naprawdę przydatne, gdy API pod spodem jest niewygodne, a otoczka koduje prawdziwe doświadczenie — lista mcp-gsc robi dokładnie to. Staje się ograniczeniem w pierwszej chwili, gdy twojego pytania nie ma na liście, i nie ma jak tego obejść.

Brama prawie nic nie rozstrzyga i spycha pracę na model. Jest elastyczniejsza i bardziej krucha. Model może sięgnąć po cokolwiek, czyli może sięgnąć po niewłaściwy punkt końcowy, źle odczytać kształt odpowiedzi i zużyć trzy wywołania narzędzi, żeby odkryć, że pole, którego chciał, nazywa się inaczej. Przy prostych pytaniach otoczka jest szybsza. Przy nowych pytaniach odpowiada wyłącznie brama.

Praktyczny test to nie „ile jest narzędzi", lecz „czy serwer wystawia to coś, o co pytam co tydzień". W pracy nad śledzeniem pozycji to zwykle analityka wyszukiwania z podziałem na datę i urządzenie plus sprawdzanie adresu URL. Otoczka i brama to pokrywają. Serwer z 42 narzędziami pokrywa to i pokrywa przy tym czterdzieści innych rzeczy, których dziś nie użyjesz.

Sprawdzenia, które naprawdę mają znaczenie przed instalacją

Czytaj zakres uprawnień, nie listę funkcji. Serwery Search Console dziedziczą to, na co pozwala twoje nadanie OAuth. Nadanie tylko do odczytu, które potrafi wylistować usługi i pobrać analitykę wyszukiwania, wystarczy do raportowania i monitoringu. Cokolwiek proponuje zmianę ustawień, wysłanie mapy witryny albo zgłoszenie do indeksowania, pisze do twoich usług, a to zasługuje na znacznie wyższy próg niż „to repozytorium ma gwiazdki".

Sprawdź, co opuszcza twoją maszynę. Brama przekazująca poświadczenia API dostawcy ma inny profil ryzyka niż lokalna otoczka, która rozmawia z API Google twoim własnym tokenem. Oba mogą być w porządku. Ale tylko jedno oznacza, że strona trzecia widzi każde słowo kluczowe, które pobierasz.

Uruchom test pustej odpowiedzi. Poproś serwer o zakres dat bez danych, na przykład usługę, której jeszcze nie uruchomiłeś. Dobrze zrobiony serwer zwraca pusty zbiór wyników. Źle zrobiony zwraca błąd, a agent, który dostaje błąd, często wymyśla wiarygodne wyjaśnienie brakujących danych. Ten jeden test wyłapuje więcej problemów niż jakikolwiek przegląd kodu.

Dwa serwery mogą wystawiać dokładnie ten sam raport i całkowicie różnić się tym, kto widzi twoje poświadczenia.

Sprawdź, co się dzieje, gdy narzędzie zawiedzie. Limity tempa są realne: Search Console pozwala na 1200 zapytań na minutę na usługę, a fala ponowień agenta wyczerpuje je sama. Serwer, który pokazuje limit, da się używać. Serwer, który po cichu zwraca nic, uczy twojego agenta, że nie masz wyświetleń, a to gorsze od błędu. Ten sam limit kształtuje każdy samodzielnie zbudowany tracker pozycji, więc budżet żądań zasługuje na jedną linię w pliku konfiguracyjnym.

Podłączenie do agenta

Konfiguracja to ta mniejsza część. To umiejscowienie decyduje, czy wyciągniesz z tego wartość.

{
  "mcpServers": {
    "gsc": {
      "command": "npx",
      "args": ["-y", "mcp-gsc"],
      "env": { "GSC_CREDENTIALS": "/path/to/service-account.json" }
    },
    "dataforseo": {
      "url": "http://localhost:3000/mcp",
      "headers": { "Authorization": "Basic <base64 login:password>" }
    }
  }
}

Trzy zasady, których używamy, uszeregowane według ilości oszczędzanego bólu.

Jeden serwer na źródło danych. Dwa serwery, z których każdy twierdzi, że odpowiada na pytania o pozycje, dają dwie odpowiedzi, a agent wybierze tę, która brzmi wiarygodniej, nie tę poprawną. Daj Search Console otoczce, dane SERP strony trzeciej bramie, i zapisz, które pole jest u kogo miarodajne.

Trzymaj definicję raportowania poza serwerem. Narzędzia dają agentowi dostęp do danych. Nie dają mu twoich definicji: które usługi się liczą, które zapytania napędzają przychód i czy pozycja to średnia z okresu, czy zrzut dzienny. To należy do pliku instrukcji, który agent czyta, zanim cokolwiek wywoła, i to jest różnica między użytecznym podsumowaniem a pewnym siebie błędem. Przepływ raportu tygodniowego to żywy przykład definicji żyjących poza narzędziami.

Sprawdź pierwsze uruchomienie ręcznie. Pobierz tydzień analityki wyszukiwania przez serwer i porównaj z tym samym tygodniem w interfejsie Search Console. Jeśli liczby się nie zgadzają, masz problem z zakresem dat albo atrybucją, a każdy późniejszy raport automatyczny go dziedziczy.

Stanowisko Auspia: pytanie MCP nie brzmi „który serwer jest najlepszy". Brzmi „jaką granicę chcesz poprowadzić między swoim agentem a swoimi danymi". Otoczka to umowa, którą przyjmujesz z góry. Brama to odpowiedzialność, którą przyjmujesz przy każdym uruchomieniu. Która z nich wpasowuje się w szerszy przepływ pracy z pozycjami, przewodnik po możliwościach agentów porządkuje według zadania. Obie są zasadne, a parzy się zespół, który wybrał, nie zauważając, że wybiera.

Częste pytania

Czy Google publikuje oficjalny serwer MCP dla Search Console? Na 12 września 2026 nie znaleźliśmy takiego w rejestrach pakietów. Testowane przez nas serwery Search Console to projekty społeczności albo dostawców oparte na oficjalnym API. Oficjalna jest warstwa API, co samo w sobie nie jest automatyczną wadą, ale oznacza, że ten serwer to zależność utrzymaniowa, którą wybierasz sam.

Ile narzędzi MCP to za dużo na jedną sesję agenta? Nie ma stałej liczby. Praktyczna granica to to, czy lista narzędzi wypycha twoje instrukcje poza okno kontekstu. Załadowanie serwera z 42 narzędziami do zadania, które potrzebuje dwóch z nich, oznacza płacenie za czterdzieści definicji przy każdym wywołaniu. Ładuj wąskie serwery do rutyny, a szerokie do rozpoznania.

Czy agent może używać MCP z Search Console bez konta usługi? Może, jeśli serwer zaimplementował przepływ OAuth i raz go ukończysz lokalnie. Ścieżka konta usługi jest łatwiejsza do automatyzacji i trudniejsza do przekazania człowiekowi, więc zespoły zwykle trzymają obie: konto usługi do uruchomień zaplanowanych i OAuth do pracy dorywczej.

Przy którym serwerze zostaliście? Przy otoczce, do raportu tygodniowego, bo pytania są znane. Brama zostaje zainstalowana do każdej pracy wymagającej źródła danych, którego otoczka nie pokrywa, a to większość ciekawej pracy i żadna z rutyn.

Autor: Julian Mercer, badacz integracji MCP w Auspia, pracował z ponad 40 łańcuchami narzędzi dla agentów. Pisze o protokołach agentów, granicach narzędzi i koszcie operacyjnym łączenia modeli językowych z żywymi danymi.