What the planner gives you, and why it belongs in a chat
Keyword Planner is a standard Google Ads tool: from a few seed phrases it returns related queries, the average monthly search volume for the past year, the level of advertising competition and a bid range per click, plus a forecast of impressions and clicks for a given budget. This is first-party data — the same numbers Google works from.
The data was never the problem; the routine was. To test one idea for a page you open the panel, pick a region and language, type the seeds, filter out the noise and export a table — all for a single answer: is this text worth writing at all. If the assistant already helps with the copy, demand checking may as well live in the same window.
MCP (Model Context Protocol) is the open protocol an assistant uses to call external tools. I unpacked it in the piece on connecting Search Console. Here one sentence is enough: an MCP server is a small go-between program on your machine that answers the assistant on one side and calls Google's API on the other.
Which server I picked
There were three kinds of options. Google's own MCP server for the Ads API is general purpose — account queries, metadata, arbitrary reports; I found no planner tooling in it. Third-party "everything" builds ship thirty-plus tools, campaign, bid and budget management included. And then there are compact utilities with a handful of commands.
I took the compact one, google-keyword-planner-mcp: exactly three tools — keyword ideas, historical metrics, click forecast. A native executable of 28 MB, no Python or Node.js runtime, open source under MIT, readable in an evening.
The reasoning is simple, and it is the through-line of everything I do with AI tooling: the assistant gets precisely the surface the job needs. A server that manages campaigns can spend money, which means one day it will spend money unasked. A server with three read calls can do nothing but hand back numbers. The same principle drives our safe AI agent rollout service.
The big one: developer tokens were retired on 9 September 2026
This is where most of my time went, so it goes first. The old routine: create a Google Ads manager account (MCC), collect a developer token — a 22-character string — from the API Centre, and send it as a header with every request. Almost every guide a search engine offers still describes exactly that.
I followed it to the end: manager account created, token issued, token pasted into the server config. Only then did I reach the documentation, which states plainly that developer tokens were sunset on 9 September 2026. The header is now ignored, and the access level is determined by the Google Cloud project that issued your OAuth credentials. Applications submitted through the API Centre are no longer processed, and the ones still queued were closed by Google with a request to re-apply — this time in the Cloud Console.
The new ladder looks like this:
- Test — granted automatically the moment you enable the Google Ads API in your Cloud project. Test accounts only.
- Explorer — the first level that sees live accounts: 2,880 operations a day. The catch: planner tooling is not available here, as Google classes it among restricted services.
- Basic — 15,000 operations a day, and the level that actually opens Keyword Planner. It requires brand verification for the Cloud project; after that the application is reviewed automatically, in minutes.
- Standard — no daily cap, aimed at large platforms; review takes up to ten working days.
The conclusion I wish I had read first: if the planner is what you need, there is exactly one path — a Google Cloud project, the Ads API enabled, brand verification, and an application for Basic. A manager account is not part of it at all.
Step by step, by hand
- A Google Cloud project. Enabling the Google Ads API puts the project on Test level straight away.
- An OAuth client of the Desktop app type. It yields a client ID and secret pair. For a desktop program that is the normal scenario: Google does not treat such a secret as confidential.
- One-off authorisation. A short script opens a listener on a local port, launches Google's consent screen with the Ads scope, catches the returned code and exchanges it for a refresh token. The two parameters that matter are offline access and forced consent — without them no refresh token is issued.
- The account ID. Ten digits, no dashes — the ad account the data is requested for.
- The server on disk. I downloaded the build for my system and dropped it in its own folder. No runtime to install: it is a single file. Mine went to the D: drive, because the system drive was full.
- Registering it with the assistant. One command, scoped to the user so the server is available in every project rather than a single directory.
claude mcp add keyword-planner \
--scope user \
-e GOOGLE_ADS_CLIENT_ID=... \
-e GOOGLE_ADS_REFRESH_TOKEN=... \
-e GOOGLE_ADS_CUSTOMER_ID=... \
-- D:\mcp\kwp-mcp.exe
The detail that trips everyone up: the client reads the tool list at start-up. A server registered while a session is open stays invisible to it — you need a new chat or an application restart. That is not an installation failure.
Testing the protocol without the assistant
Before hunting for the problem inside the assistant, it pays to confirm the server is alive at all. MCP speaks JSON-RPC over standard input and output, so you can interrogate it by hand: run the executable, push three lines into its input and read what comes back.
initialize — the protocol-version handshake;notifications/initialized — the acknowledgement;tools/list — the tool listing.
If three tools come back, the server and the credentials are fine, and you can move on to a real tools/call. The test saves hours because it splits the problem cleanly into "the server is not answering" and "the client cannot see it".
Where it stalled: a 403 from Google
Protocol alive, tools listed — and the first real request came back refused:
PERMISSION_DENIED
ACTION_NOT_PERMITTED
The Google Cloud project is only
approved for use with test accounts.
The message is honest: the project sits on Test level and will not be handed a live ad account. It has nothing to do with keywords, seeds or regions.
And here is the trap I fell into anyway: after a refusal the instinct is to reword the request — switch language, drop some seeds, try another country. Pointless. The error is about the access level of the whole project, not about a particular call. The only cure is brand verification and a Basic application.
One more note for anyone searching that error text: older API versions return ACTION_NOT_PERMITTED, while the latest one answers with a different code. The same cause wearing two faces is genuinely confusing.
How long it took
The technical part ran to about an hour: download the file, create the OAuth client, obtain a refresh token, register the server, check the protocol. Everything else went to Google's administrative side — first the obsolete manager-account route, then working out the new scheme, then brand verification, which wants a verified domain and a completed consent screen.
If you are planning this for a project, budget a day for paperwork and an hour for installation, not the other way round.
Security: what I would do differently
- Keep secrets out of scripts. Mine sat in a test file while I was debugging, which is a bad habit: they belong in environment variables or a secret store, and the file belongs in the ignore list.
- Fewer tools, smaller surface. Three read functions cannot create a campaign or change a bid. A server that can do those things demands a completely different level of trust.
- A separate Cloud project for the integration. It makes revoking access wholesale trivial without touching anything else.
- Read the code before running it. Twenty-eight megabytes is a compiled binary, but the sources are open: half an hour of reading is cheaper than one incident.
What it gives you day to day
With access open the loop is short: you are writing a page, you ask how many people in Poland search that phrase and which wording is more common, and the numbers arrive in the same window with no exports. The same route covers new service ideas, negative keyword lists and seasonality.
Full disclosure about my own status on the day of publishing: the project is still on Test level and the Basic application is queued. So there are no live-account numbers in this article — only the working scheme and the rakes I stepped on. When access opens, I will come back and add real measurements.
Is it worth repeating
If you write regularly, run ads, or own a website where decisions follow demand — yes. The integration removes context switching, which is the single biggest time sink in that work. If you open the planner once a quarter, the panel by hand is simpler.
And finally: the September reform means most Google Ads API guides are now out of date. Before repeating someone's walkthrough, check the official documentation — its date matters more than a repository's star count.
We can wire Keyword Planner into your AI assistant for you — on your computer or in your cloud, Google access arrangements included.
