Навошта гэта наогул трэба
У Google Ads ёсць Keyword Planner — афіцыйны інструмент падбору ключавых слоў з рэальнымі лічбамі: колькі разоў у месяц шукаюць фразу, якая там канкурэнцыя, колькі можа каштаваць клік. Дадзеныя дакладныя, бо яны прама з першакрыніцы. Ідэя была простая: даць ІІ-асістэнту доступ да гэтых дадзеных праз пратакол MCP (Model Context Protocol), каб не пераключацца паміж укладкамі і не капіраваць лічбы рукамі.
Выбар рэалізацыі
Афіцыйны MCP-сервер ад Google для Ads API існуе, але на практыцы ўмее толькі агульныя запыты да акаунта — спісы кліентаў, адвольныя GAQL-запыты, метаданыя. Пра Keyword Planner там няма ні слова. Прыйшлося глядзець староннія open-source рэалізацыі. Разбег вялікі: ад цяжкіх сервераў на 30+ інструментаў з кіраваннем кампаніямі і бюджэтамі да вузкіх утыліт на тры каманды. Для задачы «проста дай лічбы па ключавых словах» цяжкі варыянт быў бы залішнім рызыкай — лішнія правы дзеля функцыянальнасці, якая не патрэбна. Спыніўся на кампактным серверы пад назвай google-keyword-planner-mcp — натыўны выканальны файл без Python і Node.js, тры інструменты: генерацыя ідэй па ключавых словах, гістарычныя метрыкі, прагноз паказаў і клікаў. Адкрыты код, MIT-ліцэнзія, можна прачытаць цалкам за дзесяць хвілін.
Першая нечаканасць: developer token без кіраўнічага акаунта не выдаецца
Каб карыстацца Google Ads API, патрэбны так званы developer token. Лагічна было пайсці ў ужо існуючы рэкламны акаунт і атрымаць яго там — але раздзел «Цэнтр API» у Google Ads апынуўся даступны толькі з кіраўнічага акаунта (MCC), а не са звычайнага рэкламнага. Звычайны акаунт гэты раздзел проста не паказвае, без тлумачэнняў у інтэрфейсе. Прыйшлося завесці асобны кіраўнічы акаунт — бясплатна, без прывязкі карты, але гэта асобны крок, пра які нідзе загадзя явна не папярэджваюць.
OAuth-кліент і аднаразовая аўтарызацыя
Далей — стандартны шлях для настольных прыкладанняў Google: у Google Cloud ствараецца OAuth-кліент тыпу «Desktop app», уключаецца Google Ads API. Токен абнаўлення (refresh token) атрымліваецца адзін раз простым скрыптам: ён падымае лакальны HTTP-сервер на порце, адкрывае старонку аўтарызацыі ў браўзеры, ловіць код вяртання і мяняе яго на токены. Пасля гэтага паўторны ўваход не патрэбны — сервер абнаўляе доступ сам.
Другі нюанс: тэставы ўзровень доступу па змаўчанні
Сервер запусціўся, пратакол ажыў, спіс інструментаў аддаецца карэктна — а вось рэальны запыт да жывога рэкламнага акаунта вярнуў адмову: новы developer token па змаўчанні працуе толькі з тэставымі акаунтамі. Каб атрымаць дадзеныя па сапраўдным акаунце, трэба асобна падаваць заяўку на пашыраны ўзровень доступу (Basic/Standard) і чакаць разгляду. Тэхнічна ўсё гатова і працуе — але менавіта гэты крок расцягваецца ў часе мацней за ўсё, і на яго варта закладаць запас, а не разлічваць на імгненны вынік.
Што ў выніку
Сама інтэграцыя — справа пары гадзін: спампаваць бінарнік, завесці ўліковыя дадзеныя, адзін раз прайсці аўтарызацыю, зарэгістраваць сервер. Асноўны час з'ядае не тэхнічныя крокі, а бюракратыя на баку Google — кіраўнічы акаунт, які не ствараецца аўтаматычна, і чарга на пашыраны доступ. Далей гэта ўжо рутынны інструмент: ІІ бачыць рэальны попыт па ключавых словах прама падчас працы над тэкстам ці рэкламнай кампаніяй, без пераключэння кантэксту і без здагадак на вока.
Калі вы робіце нешта падобнае — закладвайце асобны час менавіта на адміністрацыйную частку ў Google, а не толькі на саму ўстаноўку MCP-сервера.
