A Google Search Console MCP server is how an agent reads your search data without you exporting a CSV first. That much is easy. What is not easy is telling one server from another, because they all describe themselves the same way and the differences only show up when you ask them what they can actually do.
So we asked. On September 12, 2026 we connected four published SEO MCP servers, sent each one a tools/list request, and counted what came back. The results were 42, 21, 4, and 1.
That spread is not a quality ranking. It is a design decision, and it changes what the agent can do, what it costs you in context, and how much of your data leaves the building.
What we tested, and how
Method: each server was launched exactly as its own documentation instructs, over standard input and output or over HTTP where that was the documented mode. We sent an MCP initialize handshake, then tools/list, and recorded the tool count and names. No API key was used unless the server refused to start without one.
Server | Version | Tools returned | Auth required to list tools |
|---|---|---|---|
Ahrefs MCP | 0.0.11 | 42 | No |
mcp-gsc | 0.3.2 | 21 | No |
DataForSEO MCP | 3.1.1 | 4 | Yes, over HTTP |
seo-mcp-server | 3.0.5 | 1 | No |
One server, a third-party Search Console package, never completed the handshake inside our 50 second window and is excluded rather than scored. Tool inventories change with every release, so treat the counts as a snapshot of one morning, not as a permanent property of any vendor.
The four designs, and what each one is for
The wrapper (21 tools). mcp-gsc takes the Search Console API and wraps individual reports as named tools. Its inventory reads like a search analyst's job description: search_analytics, inspect_url, top_movers, quick_wins, cannibalization, content_decay, device_country_breakdown, ctr_anomalies, weekly_seo_report, indexing_coverage. The advantage is that the model never has to construct a query. The cost is that you inherit someone else's idea of what a report should contain, and you cannot ask for anything outside the list.
The full platform mirror (42 tools). The Ahrefs server exposes the vendor's product surface, endpoint by endpoint: rank-tracker-overview, rank-tracker-competitors-overview, keywords-explorer-matching-terms, keywords-explorer-volume-history, batch-analysis. This is the most capable inventory we measured and the most expensive in context, because every tool definition is loaded whether or not it is relevant to the task. It is also the clearest illustration of the trade: breadth of capability against a permanent tax on every prompt.
The gateway (4 tools). DataForSEO's v3 server went the other way. It exposes docs_index, docs_list_sections, docs_search, and one generic api_request. Instead of naming every endpoint, it teaches the model to find the documentation and then make an authenticated call. Four tools cover an API with hundreds of endpoints, and the model pays for the specificity at call time instead of at load time. In our probe the HTTP endpoint returned invalid auth without credentials and answered normally with them, which is the behaviour you want.
The single-tool server (1 tool). seo-mcp-server returns exactly one tool, ai_content_detect. There is nothing wrong with a small server, but be honest about what it is: a demo or a single check, not an SEO workbench. If you install it expecting weekly reporting, you will be disappointed in a way the install instructions never mentioned.
Four archetypes. Two of them scale to a real reporting workflow, and they scale in different directions.
Why the tool count is the wrong headline
Two servers with the same count can behave completely differently, because what matters is the shape of the boundary, not the number.
A wrapper decides your questions in advance. That is genuinely useful when the underlying API is fiddly and the wrapper encodes real expertise, which the mcp-gsc inventory does. It becomes a limit the first time your question is not on the list, and you cannot page around it.
A gateway decides almost nothing and pushes the work to the model. That is more flexible and more fragile. The model can reach anything, which also means it can reach the wrong endpoint, misread a response shape, and spend three tool calls discovering that the field it wanted is called something else. On a simple question, the wrapper is faster. On a novel one, the gateway is the only one that answers at all.
The practical test is not "how many tools" but "does the server expose the thing I ask about every week". For a rank-tracking workflow that is usually search analytics with a date and device split, plus URL inspection. Both the wrapper and the gateway cover that. The 42 tool server covers it and forty other things you will not use today.
The checks that matter before you install anything
Read the permission scope, not the feature list. A Search Console server inherits whatever the OAuth grant allows. A read-only grant that can list properties and pull search analytics is enough for reporting and monitoring. Anything that offers to change settings, submit sitemaps, or request indexing is writing to your property, and that deserves a much higher bar than "the repo has stars".
Verify what leaves your machine. A gateway that forwards your API credentials to a vendor is a different risk profile from a local wrapper that talks to Google's API directly with your own token. Both can be fine. Only one of them means a third party sees every keyword you pull.
Run the empty-response test. Ask the server for a date range with no data, such as a property you have not launched. A well-built server returns an empty result set. A poorly built one returns an error, and an agent that receives an error will often invent a plausible explanation for the missing data. This single test catches more problems than any code review.
Two servers can expose the same report and still differ in who sees your credentials.
Check what happens when a tool fails. Rate limits are real: Search Console allows 1,200 queries per minute per site, and a burst of agent retries can burn that on its own. A server that surfaces the limit is usable. A server that silently returns nothing teaches your agent that you have no impressions, which is worse than an error. The same limit shapes any self-built rank tracker, which is why the request budget deserves a line in the config file.
Wiring it into an agent
The configuration is the small part. The placement is what decides whether you get value.
{
"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>" }
}
}
}Three rules we use, in order of how much pain they prevent.
One server per data source. Two servers that both claim to answer ranking questions will produce two answers, and the agent will pick the one that sounds better rather than the one that is correct. Give Search Console to the wrapper, third-party SERP data to the gateway, and write down which is authoritative for which field.
Keep the reporting definition outside the server. The tool gives the agent access to data. It does not give the agent your definitions: which properties count, which queries are money queries, whether the position is a mean over the range or a daily snapshot. Those belong in an instruction file the agent reads before it calls anything, and they are the difference between a useful summary and a confident wrong one. The weekly report workflow is a working example of definitions living outside the tool.
Verify the first run by hand. Pull one week of search analytics through the server and compare it with the same week in the Search Console interface. If the numbers do not match, you have a date-range or attribution problem, and every automated report after that point inherits it.
Auspia view: the MCP question is not which server is best. It is which boundary you want between your agent and your data. A wrapper is a contract you accept in advance. A gateway is a responsibility you accept every run. For where either fits into a wider ranking workflow, the agent capability guide maps the tasks. Both are legitimate, and the teams that get burned are the ones that picked one without noticing they had picked.
FAQ
Does Google publish an official MCP server for Search Console? Not one that we could find in the package registries on September 12, 2026. The Search Console servers we tested are community or vendor projects that sit on top of the official API. That is not automatically a problem, because the API is the part that is official, but it does mean the server is a maintenance dependency you are choosing.
How many MCP tools is too many for one agent session? There is no fixed number. The practical limit is whether the tool list crowds out your instructions in the context window. If a 42-tool server is loaded for a task that needs two of them, you are paying for forty definitions on every call. Load the narrow server for routine work and the broad one for exploration.
Can an agent use MCP with Search Console without a service account? Yes, if the server implements the OAuth flow and you complete it once locally. The service account route is easier to automate and harder to hand to a person, so teams usually run both: a service account for scheduled runs and OAuth for ad hoc work.
Which server did you keep? The wrapper, for the weekly report, because the questions are known. The gateway stays installed for anything that needs a data source the wrapper does not cover, which is most of the interesting work and none of the routine work.
Author: Julian Mercer, MCP Integration Researcher Across 40+ Agent Toolchains at Auspia. Julian writes about agent protocols, tool boundaries, and the operational cost of connecting language models to live data.
