- Home
- Case studies
- Search Console and Keyword Planner data, available directly in a conversation
Search Console and Keyword Planner data, available directly in a conversation
An agency with more than twenty clients stopped exporting files from Google dashboards. Two MCP servers provide direct access to SEO and keyword data in chat.
4 min read
- Client
- Marketing agency
- Industry
- Marketing / SEO / PPC / Analytics
- Scope
- Analytics and data
- Delivery time
- 12 days
Who the client was and what was getting in the way
A marketing agency managing more than twenty accounts across SEO and paid campaigns. Every client had a separate property in Google Search Console and a separate ad account. The routine was: open the dashboard, set a date range, export search-query data, then repeat for pages, then countries, and finally combine everything in a spreadsheet. Twenty times over. The team spent five to ten hours a week on this, and all that remained was another spreadsheet.
The second issue was the cost of tools. Subscriptions to popular SEO suites for a five-person team can run from eight hundred to six thousand zlotys a month. Most frustratingly, despite those prices, none of them show actual Search Console data. They show their own estimates, while clients ask for the real figures from their property.
Keyword Planner was available only through the Google Ads interface, so every keyword study meant entering terms by hand and copying search volumes and costs into a spreadsheet. Finally, the agency kept hitting the same wall whenever it considered building its own client dashboard: the data was locked inside Googleβs interfaces and could not be connected elsewhere.
What we built
We built two MCP servers β a layer that lets an AI assistant retrieve data itself instead of waiting for someone to export it. Both were built in Node.js and TypeScript, with OAuth 2.0 authorization. Access to ad data also requires a developer token and a manager account linking the clients.
The first server connects to Search Console. It provides search analytics β queries, impressions, click-through rate, and average position β with filters for date range, dimension, and row count. It also provides a list of sitemaps with their status and errors, plus URL inspection: whether a page is indexed, when it was last crawled, and how it appears on mobile devices. We built in error handling and query-limit management so nothing breaks halfway through a report across twenty domains.
The second server connects to Keyword Planner. It returns keyword ideas with monthly search volume, competition level, and average cost per click; provides historical data by month; and lets users filter the list by minimum and maximum search volume and by competition.
We connected both servers to Claude Code. An analyst can simply ask for what they need: show the top ten queries for this domain from the last month, check search volume for this keyword, or compare click-through rates on desktop and mobile. The answer comes back in a table. We could also build scripts on the same layer to collect data for all clients at once and assemble reports.
How it works today
The work took twelve days across four stages: setting up access and designing the architecture; building the Search Console server; building the Keyword Planner server; and, finally, connecting everything to Claude Code, documenting it, and training the team.
Analysts no longer log into dashboards to get data. They ask in chat and receive an answer based on current figures straight from the source. Portfolio-wide reports now run once instead of requiring twenty copy-and-paste sessions. The data is no longer locked in Googleβs interfaces, so it can be connected to the agencyβs own dashboards.
The outcome
Two MCP servers were built: one for Search Console and one for Keyword Planner. Access to SEO data is direct and current, with no intermediary estimating the numbers. Keyword research β search volume, cost per click, and competition β happens automatically. The solution has no recurring fee, unlike the SEO suites whose subscription costs prompted the project in the first place.
What we would do differently
The biggest time sink was not building the servers but completing Googleβs formalities: the consent screen, credentials, and application for a developer token for ad data. These are things you have to wait for, and we started arranging them only when we needed them. For the next project using Google interfaces, we will submit applications on day one, alongside architecture design.
We also underestimated query limits. They are invisible with one domain, but across twenty they can break a report halfway through. We added queuing and retries during development; they should have been part of the design from the start.
Related projects
E-commerce conversion tracking: from 35% event coverage to nearly complete
A beauty e-commerce store was showing Meta only one third of its purchases. We fixed server-side measurement while respecting consent and raised coverage to nearly complete.
An agent that reviews Google Ads every day and suggests changes for approval
Daily account analysis with B2B context instead of generic tips. The agent only reads and makes suggestions; a person approves every change.