Google Search Console MCP: що насправді показують чотири SEO MCP-сервери

MCP-сервери для Google Search Console — це спосіб дати агенту читати ваші пошукові дані без попереднього експорту в CSV. Це легка частина. Нелегка — розрізнити самі сервери, бо всі вони представляються однаково, а різниця проявляється лише тоді, коли питаєш, що вони насправді вміють.

Ми запитали. 12 вересня 2026 року ми підключили чотири опубліковані SEO MCP-сервери, надіслали кожному запит tools/list і порахували, що повернулося. Вийшло 42, 21, 4 і 1.

Цей розкид — не рейтинг якості. Це проєктне рішення, і воно змінює те, що агент може робити, скільки він коштує вам у контексті та скільки ваших даних залишає ваш периметр.

Що ми тестували і як

Метод: кожен сервер запускався точно так, як приписує його власна документація, через стандартний ввід-вивід або через HTTP, якщо документація вказувала цей режим. Ми надсилали рукостискання initialize з MCP, потім tools/list і фіксували кількість та назви інструментів. Ключі API ми не використовували ніде, крім випадків, коли сервер відмовлявся стартувати без ключа.

Один сервер — сторонній пакет для Search Console — не завершив рукостискання в нашому 50-секундному вікні, тому його виключили, а не оцінили. Списки інструментів змінюються з кожним релізом, тож ставтеся до цих чисел як до знімка одного ранку, а не як до постійної властивості якогось постачальника.

Чотири конструкції та для чого кожна

Обгортка (21 інструмент). mcp-gsc бере Search Console API і загортає кожен звіт у названий інструмент. Його список читається як посадова інструкція пошукового аналітика: search_analytics, inspect_url, top_movers, quick_wins, cannibalization, content_decay, device_country_breakdown, ctr_anomalies, weekly_seo_report, indexing_coverage. Виграш у тому, що моделі взагалі не треба будувати запит. Ціна в тому, що ви успадковуєте чуже уявлення про те, що має містити звіт, і нічого поза списком попросити не можна.

Дзеркало всієї платформи (42 інструменти). Сервер Ahrefs виставляє продуктову поверхню постачальника кінцева точка за кінцевою точкою: rank-tracker-overview, rank-tracker-competitors-overview, keywords-explorer-matching-terms, keywords-explorer-volume-history, batch-analysis. Це найбагатший список, який ми міряли, і найдорожчий за контекстом, бо кожне визначення інструмента завантажується незалежно від того, стосується воно завдання чи ні. Він же найясніше показує компроміс: широта можливостей в обмін на постійний податок на кожен запит.

Шлюз (4 інструменти). Сервер DataForSEO версії 3 пішов у протилежний бік. Він виставляє docs_index, docs_list_sections, docs_search і один універсальний api_request. Замість того щоб давати ім'я кожній кінцевій точці, він вчить модель знайти документацію, а тоді зробити автентифікований виклик. Чотири інструменти покривають API з сотнями кінцевих точок, і модель платить за конкретність під час виклику, а не під час завантаження. У нашій перевірці HTTP-кінцева точка повернула invalid auth без облікових даних і коректно відповіла з ними. Це і є бажана поведінка.

Сервер з одним інструментом (1 інструмент). seo-mcp-server повертає рівно один інструмент — ai_content_detect. У малому сервері немає нічого поганого, але він має бути чесним щодо того, чим є: демонстрацією або поодинокою перевіркою, а не робочим столом SEO. Якщо ви встановите його, очікуючи тижневий звіт, ви розчаруєтеся так, як інструкція зі встановлення навіть не натякала.

Чотири архетипи. Два з них масштабуються до справжньої звітної роботи, і кожен масштабується у свій бік.

Чому кількість інструментів — неправильний заголовок

Два сервери з однаковим числом можуть поводитися геть по-різному, бо значення має форма межі, а не цифра.

Обгортка вирішує ваші питання заздалегідь. Це справді корисно, коли API під нею незручний, а обгортка кодує справжню експертизу, і список mcp-gsc робить саме це. Вона стає обмеженням тієї ж миті, коли вашого питання немає в списку, і обійти це нічим.

Шлюз майже нічого не вирішує і перекладає роботу на модель. Це гнучкіше й крихкіше. Модель може дістатися будь-чого, а отже, може дістатися неправильної кінцевої точки, неправильно прочитати форму відповіді та витратити три виклики інструментів, щоб з'ясувати, що потрібне поле називається інакше. На простих питаннях обгортка швидша. На нових питаннях відповідає взагалі лише шлюз.

Практичний тест — не «скільки там інструментів», а «чи виставляє сервер саме те, про що я питаю щотижня». У роботі з відстеження позицій це зазвичай пошукова аналітика з розбивкою за датою та пристроєм плюс перевірка URL. І обгортка, і шлюз це покривають. А сервер із 42 інструментами покриває це й ще сорок речей, якими ви сьогодні не скористаєтеся.

Перевірки, які справді важливі до встановлення будь-чого

Читайте обсяг дозволу, а не список функцій. Сервери Search Console успадковують те, що дозволяє ваш OAuth-дозвіл. Дозволу лише на читання, який дає перелічити ресурси й вивантажити пошукову аналітику, достатньо для звітів і моніторингу. Усе, що пропонує змінювати налаштування, надсилати карту сайту чи просити індексацію, пише у ваші ресурси, і це заслуговує на значно вищий поріг, ніж «у цього репозиторію є зірки».

Переконайтеся, що залишає вашу машину. Шлюз, який передає облікові дані API постачальнику, має інший профіль ризику, ніж локальна обгортка, що говорить з Google API вашим власним токеном. Обидва можуть бути гаразд. Але лише один означає, що третя сторона бачить кожне ключове слово, яке ви вивантажуєте.

Проженіть тест порожньої відповіді. Попросіть у сервера діапазон дат без даних — наприклад, ресурс, який ви ще не запустили. Добре зроблений сервер поверне порожній набір результатів. Погано зроблений поверне помилку, а агент, який отримав помилку, часто вигадує правдоподібне пояснення для відсутніх даних. Цей один тест ловить більше проблем, ніж будь-який огляд коду.

Два сервери можуть виставляти той самий звіт і геть різнитися в тому, хто бачить ваші облікові дані.

Перевірте, що стається, коли інструмент зазнає невдачі. Обмеження швидкості реальні: Search Console дозволяє 1 200 запитів за хвилину на ресурс, і хвиля повторних спроб агента вичерпує їх сама. Сервер, який показує обмеження, придатний до роботи. Сервер, який мовчки повертає ніщо, вчить вашого агента, що показів у вас немає, а це гірше за помилку. Те саме обмеження визначає форму будь-якого саморобного трекера позицій, тож бюджет запитів вартий одного рядка у файлі конфігурації.

Підключення до агента

Конфігурація — менша частина. Розміщення визначає, чи отримаєте ви цінність узагалі.

{
  "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>" }
    }
  }
}

Три правила, якими користуємося ми, за спаданням болю, який вони відвертають.

Один сервер на джерело даних. Два сервери, кожен з яких стверджує, що відповідає на питання про позиції, дають дві відповіді, і агент вибере не правильну, а ту, що звучить переконливіше. Віддайте Search Console обгортці, сторонні дані SERP — шлюзу й запишіть, за яким полем хто авторитет.

Тримайте визначення звітності поза сервером. Інструменти дають агенту доступ до даних. Вони не дають йому ваших визначень: які ресурси рахуються, які запити приносять дохід і чи позиція — це середнє за період або знімок за день. Це належить до файлу інструкцій, який агент читає перед тим, як щось викликати, і саме тут проходить межа між корисним підсумком і впевненою помилкою. Процес тижневого звіту — живий приклад визначень, що живуть поза інструментами.

Перевірте перший запуск руками. Витягніть тиждень пошукової аналітики через сервер і порівняйте з тим самим тижнем в інтерфейсі Search Console. Якщо числа не сходяться, у вас проблема з діапазоном дат або атрибуцією, і кожен наступний автоматичний звіт її успадкує.

Погляд Auspia: питання MCP не в тому, який сервер найкращий. А в тому, яку межу ви хочете провести між агентом і своїми даними. Обгортка — це договір, який ви приймаєте заздалегідь. Шлюз — відповідальність, яку ви приймаєте щоразу. Що з цього вбудовується в ширший процес роботи з позиціями, посібник із можливостей агентів розбирає за завданнями. Обидва легітимні, а обпікається та команда, яка зробила вибір, не помітивши, що обирає.

Часті запитання

Чи публікує Google офіційний MCP-сервер для Search Console? Станом на 12 вересня 2026 року ми не знайшли такого в реєстрах пакетів. Сервери Search Console, які ми тестували, — це проєкти спільноти або постачальників поверх офіційного API. Офіційним є шар API, і це саме собою не автоматична вада, але означає, що той сервер — залежність із супроводу, яку обираєте ви.

Скільки MCP-інструментів — це забагато для однієї сесії агента? Фіксованого числа немає. Практична межа — чи витісняє список інструментів ваші інструкції з вікна контексту. Завантажити сервер із 42 інструментами для завдання, якому потрібні два з них, означає платити за сорок визначень у кожному виклику. Завантажуйте вузькі сервери для рутини й широкі для дослідження.

Чи може агент використовувати MCP із Search Console без службового акаунта? Може, якщо сервер реалізував потік OAuth, а ви завершили його один раз локально. Шлях через службовий акаунт легше автоматизувати й важче передати людині, тож команди зазвичай тримають обидва: службовий акаунт для запусків за розкладом і OAuth для нагоди.

Який сервер ви залишили? Обгортку — для тижневих звітів, бо питання відомі. Шлюз залишається встановленим для будь-якої роботи, якій потрібне джерело даних, не покрите обгорткою, а це більшість цікавої роботи і жодна з рутинних.

Автор: Julian Mercer, дослідник інтеграції MCP в Auspia, працював із понад 40 ланцюжками інструментів для агентів. Пише про протоколи агентів, межі інструментів і операційну вартість підключення мовних моделей до живих даних.