Google Search Console MCP servers: compare access, not tools

There is no official Google Search Console MCP server. Every option is a community project wrapping the same public API, nearly all of them are MIT licensed, and they read the same numbers from the same place. So the tool counts filling every comparison table are close to the least useful thing to choose on.

What actually differs is how much access each one asks for, and whether anything survives after you stop asking. Below is what five of them request, read from their own setup instructions rather than their feature lists, on four axes the roundups leave out.

Disclosure before anything else: we build one of these. QueryScope is the paid hosted option, and for several of the jobs below it is the wrong pick and a free repo is the right one. That is said up front because a vendor writing "best servers" and landing on itself is worth exactly nothing to you.

TL;DR:

• No official Google server exists. Google ships an official, read-only MCP for Analytics and nothing for Search Console, so every option is community-built on the public API.
• The real split is credentials: a service account key file added as a user on your property, versus an OAuth grant you can revoke.
• Several setup guides tell you to grant Full access. Google's own role table says a Restricted user can already read Performance data.
• None of the five documents storing history, so every one of them inherits Search Console's 16-month wall.
• One "free" server needs a Gemini API key, which puts a second vendor and a per-call bill inside a local tool.

Is there an official Google Search Console MCP server?

No. Google publishes an official MCP server for Google Analytics, documented as a server that "lets you connect your Analytics data to an LLM, like Gemini" and "available for read requests only. It can't edit your Google Analytics configuration or settings." [1] That page does not mention Search Console anywhere, and no equivalent Google-built server exists for it.

The practical consequence is that every Google Search Console MCP server you can install is a community project calling the same public Search Console API. That is not a warning. It means the data is identical across all of them, because there is only one source, and it means the differences are entirely in the wrapper: how it authenticates, what it does with the results, and what it leaves behind.

It also sets the honest bar for the read-only question. Google's own answer, in the neighbouring product, is a server that cannot write at all. Hold the community servers to that standard and they separate quickly.

What actually differs between them?

Four things, and tool count is not one of them. A server exposing twenty tools and a server exposing one are both reading the same API, and the twenty-tool one is frequently just a finer slicing of the same call. The axes that change your decision are the credential it wants, the permission that credential costs you, whether any history outlives the API, and whether a third party ends up in the loop.

Here is where five of the commonly recommended servers land, taken from their own READMEs:

server                  credential        install    tools
AminForou/mcp-gsc       OAuth or SA       uvx        20
acamolese/...-mcp       OAuth readonly    uvx/pipx    8
ahonn/mcp-server-gsc    service account   npm/npx     1
surendranb/...-mcp      service account   pip         6
garethcull/...-mcp      SA + Gemini key   Cloud Run   1

All five are MIT licensed. The interesting column is the second one, and no comparison table seems to print it.

Why do the setup guides ask for Full access?

Because the permission you grant is set by the most powerful tool in the bundle, not by the question you want to ask. AminForou's mcp-gsc tells you plainly: "Add the service account email to your GSC property: Search Console → Settings → Users and permissions → Add user → Full access." That server ships twenty tools including add and remove sites, and submit and delete sitemaps, so Full access is not over-reach there. It is genuinely required by what the tool can do.

The question is whether you wanted those tools. If you installed a Search Console MCP to ask which pages are losing clicks, you have just granted a key file the ability to delete your sitemaps, because it came in the same box.

Google's role table makes the gap checkable rather than a matter of taste. A Restricted user has "simple view rights on most data," and Performance data is available at all three permission levels. A Full user is what you need for the actions Restricted cannot take: submit sitemaps, remove URLs, disavow links, verify fixes. [2] So for a server that only reads performance data, Restricted is enough, and the install instruction is the thing asking for more, not the API.

Two of the five make this visible in opposite directions. ahonn/mcp-server-gsc exposes exactly one tool, search_analytics, and its setup still walks you through adding the service account as a property administrator. acamolese/google-search-console-mcp goes the other way and states the boundary as a feature: it "only requests the webmasters.readonly scope from Google, which is read-only by design," and "cannot submit sitemaps, request indexing, or modify any property setting." Same job, same data, and a materially different thing sitting on your property.

What does a service account cost you that OAuth doesn't?

A file and a revocation story. A service account is a JSON key downloaded from Google Cloud and left on disk, then added as a user on your Search Console property. surendranb's server has you grant "the service account email full permissions"; ahonn's has you add it as a property administrator. The credential is not tied to a person, does not expire the way a grant does, and anyone who copies that file has whatever access the account was given.

An OAuth grant behaves differently in the way that matters when something goes wrong. It is attached to your Google account, it is scoped at the point of consent, and you can revoke it from your account's permissions page without touching the property's user list or rotating a key. That is the shape our own connection uses, and it is also what acamolese's free server uses, so this axis genuinely does not separate paid from free.

Neither is wrong. A service account is the right answer for unattended automation and shared team access, which is exactly what those projects say it is for. It is the wrong default for one person reading their own data from their own laptop, which is most people installing one of these. Choosing between a self-hosted and a hosted server turns on the same trade-off one level up.

Does any of them keep your history?

None of the five documents storing anything. Every one of them is a live reader: you ask, it calls the API, it hands back what Google currently holds. Nothing in any of those READMEs describes a database, a snapshot, or a retention policy.

That matters more than any feature on the list, because Search Console keeps 16 months and then deletes the oldest day every day, with no backfill and no archive. A stateless server inherits that wall exactly. Whatever it could not see today, it will never be able to see, and the month that rolls off next week is gone from every one of these tools simultaneously.

This is the one axis where a hosted service can offer something a local script cannot, and it is also the axis where most people genuinely do not care yet. If you are answering questions about the last few months, statelessness costs you nothing at all. If you want to compare this quarter against the same quarter two years ago, no server on this list can do it, and neither can any of them start doing it retroactively, because Google never had the data to give back.

Is anything else in the loop?

In one case, yes. garethcull/search-console-mcp requires three environment variables to run: a shared secret, a base64-encoded service account key, and a GEMINI_API_KEY, described as an "API key for Gemini (used to translate natural language to GSC query JSON)." It deploys to Google Cloud Run or your own infrastructure.

That is a defensible design and it is worth knowing before you install it, because it changes the cost and privacy shape of a tool that reads as free and local. There is a second vendor in the path, your query text reaches it, and there is a per-call bill attached to a server you self-host. Every other option on this list does its translation inside the MCP client you already pay for, which is the same reason running Search Console analysis from your IDE costs nothing extra in tokens: the model you are already running does the reasoning.

So which one should you pick?

Match it to the job, and start from the free ones, because for most jobs they are the answer.

• You want to read your own data from your own machine. Take an OAuth, read-only server. acamolese's is the cleanest statement of that shape, and it says out loud what it cannot do.
• You want the widest tool surface and you accept a Full-access service account. AminForou's twenty tools cover property management, URL inspection and sitemaps, and the permission it asks for is honestly required by that range.
• You want one call and nothing else. ahonn's single search_analytics tool is the smallest thing that works. Consider adding the service account as a Restricted user rather than an administrator and seeing whether anything breaks.
• You are running this for a team or unattended. A service account and a self-hosted deployment is the design intent, which is where garethcull's Cloud Run shape and surendranb's aggregation fit.
• You need history past the 16-month wall, across several sites, without maintaining any of it. That is the case none of the free ones cover, and it is the one QueryScope is built for. If that is not your problem, do not buy it.

The honest summary is that these servers are much more alike than the comparison tables suggest, because they are all reading one API that has one set of numbers in it. Pick on the access you are comfortable granting, then on whether you need anything to outlive the window. If you want to see what the read actually feels like before choosing, Search Console in your terminal is the same job from the hosted side, and the MCP setup itself is one command either way.

Sources

• Server details are quoted from each project's own README, read on 2026-08-11: AminForou/mcp-gsc, acamolese/google-search-console-mcp, ahonn/mcp-server-gsc, surendranb/google-search-console-mcp, garethcull/search-console-mcp. Licenses, credential methods and tool counts are as those pages state them; projects change, so check the repo before installing.
• [1] Google for Developers, Google Analytics MCP server (official Analytics server, read requests only, cannot edit configuration; no Search Console equivalent documented).
• [2] Google Search Console Help, Managing users and permissions (Owner, Full user and Restricted user definitions; Performance data available at all three levels; submit sitemaps, remove URLs and disavow require Full).