Google Search Console MCP Server: Self-Host or Hosted?

Choosing a Google Search Console MCP server comes down to three trade-offs the feature tables skip: what the setup actually costs you (less than most tutorials imply), whether the server hands your coding agent raw rows or a ranked answer, and whether your history survives past Google's 16-month wall. Tool count is the least useful number to compare.

This post walks the real decision: the two ways to authenticate a self-hosted server and the one gotcha that breaks them, the difference between a server with twenty tools and one that tells you what to fix, and why "keeps your history" is a promise no feature list can show you.

TL;DR:

• A GSC MCP server connects your coding agent (Claude Code, Cursor, and the rest) to your Search Console data. The open-source ones are free and good. The trade-off is everything you run and maintain yourself.
• You do not need Google to "verify" your app to read your own Search Console. That scope is non-sensitive, and Google's own policy says non-sensitive-only apps are not required to verify. The real friction is a 7-day token expiry in "Testing" mode, or holding a service-account key.
• More tools is not more useful. A server that hands your agent 25,000 rows still needs your agent to know what to do with them. Analysis-first means the server ranks what to fix.
• Search Console forgets everything past 16 months, and a live-read server forgets with it. Keeping history means snapshotting it forward, which someone has to run.

What is a Google Search Console MCP server?

A Google Search Console MCP server is a small program that connects your coding agent to your Search Console account over the Model Context Protocol, so you can ask about clicks, queries, and indexing in your editor instead of a browser tab. Several are free and open source on GitHub. The rest are hosted services you connect to.

The real fork is not which one has more features. It is who runs it. A self-hosted server is a repo you clone, authenticate, and keep alive on your own machine or a box you own. A hosted server is a URL you add to your editor, where someone else handles the running. One popular open-source option, AminForou's mcp-gsc, ships around twenty tools across analytics, URL inspection, and sitemaps, and it is genuinely useful. Whether it is the right choice depends on the three questions below, not on that number.

Do you need Google to verify your app?

No. Reading your own Search Console uses a non-sensitive OAuth scope, and Google's own policy is explicit: "If your app utilizes only non-sensitive scopes, it is not mandatory for your app to complete the app verification process." The verification gauntlet you may have read about applies to sensitive and restricted scopes like Gmail and Drive, not to read-only Search Console.

So the setup is smaller than the tutorials make it sound. What is real is a different gotcha, and it only hits the OAuth path. If you self-host with a personal Google account and leave the app in "Testing" status, Google expires the refresh token every seven days. Its docs say a Testing-status project "is issued a refresh token expiring in 7 days, unless the only OAuth scopes requested are a subset of name, email address, and user profile." Search Console is not in that subset, so your server stops working weekly until you sign in again.

There are two honest ways around it:

• Publish the app to "Production." Because the scope is non-sensitive, you can do this without the security review that sensitive scopes trigger. The token stops expiring on the 7-day clock.
• Use a service account instead. You create a service account, download its JSON key, and add its email address to your Search Console property as a user. No consent screen, no browser sign-in, no 7-day expiry. The trade is that you are now holding a long-lived private key, which is a secret you have to store carefully and remember to remove when you are done.

Neither is hard. Both are one-time chores. The point is that "you need Google to verify you" is not the real cost of self-hosting, and anyone who tells you it is has not set one up.

Self-host or hosted: which should you actually run?

Self-host if you want to own the stack and do not mind running a process, storing a key or re-authorizing, and applying updates yourself. Go hosted if you would rather skip all of that and get the analysis instead of the raw API. Neither is wrong. They are different amounts of you.

Here is the honest split, once the verification myth is out of the way:

• Self-hosted (the open-source servers). Free, private, and yours. You clone the repo, do the service-account or OAuth setup once, host the process somewhere it stays running, and pull updates when the maintainer ships them. Your agent gets the Search Console API wrapped as tools: real data, in raw form, for you to direct.
• Hosted. One line in your editor, no key to manage, updates arrive on their own, and the running is someone else's problem. What you are paying for is not access to your data, which is free either way. It is the two things below: the analysis on top of the data, and the history underneath it.

This is where QueryScope sits: the hosted, read-your-own-data option for people who would rather ask a question than run a server. If owning the stack matters more to you than saving the setup, a self-hosted server is the better call, and that is a real answer, not a concession.

Does a server with more tools do more for you?

Not necessarily. A server can expose twenty tools and still hand your agent 25,000 rows to sort out. The number that matters is not how many endpoints it wraps, but whether it turns those rows into a ranked answer: which page to fix first, and why. Wrapping the API is the easy 80%. Knowing what to do with the result is the part that pays.

There is a subtlety here that a raw wrapper passes straight through to you. Search Console's query table always under-reports, because Google drops rare queries from it for privacy while still counting them in your totals. A server that just surfaces the API hands your agent that under-count with no warning, and the totals never reconcile. The honest read is to take volume from the page level and treat the query list as intent, not as a count. A server that knows the difference does that for you. A server that is a thin wrapper leaves your agent to trip over it.

More tools also means more surface for your agent to wander. Twenty endpoints is twenty things it can call and twenty ways to spend a turn pulling data instead of deciding something. The useful server is the one that has already decided what is worth looking at.

Will the server keep your history?

Only if it stores your data forward. Search Console keeps a rolling 16-month window and then deletes, with no backfill and no export of the gap once it is gone. A server that reads live shows you only what Google still has. Anything older is already deleted before your agent ever asks.

Keeping history is not a feature you can spot in a tool list, because it is a behavior over time, not an endpoint. It means snapshotting your data every day and storing it somewhere past the 16-month wall, which is a storage-and-schedule job that someone has to own. A self-hosted server can do this, but only if you build and run the storage yourself. A live-read server, self-hosted or hosted, cannot, because it holds nothing between calls.

This is the quiet one. You do not notice it on day one, when everything you want is inside the window. You notice it eighteen months in, when you go to compare this quarter to the same quarter last year and the data is simply not there. If you plan to still be reading this site's numbers in two years, ask any server you are considering the one question a feature table cannot answer: what does it remember?

So which Google Search Console MCP server should you pick?

Pick on the three axes, not the tool count. If you want to own the stack, do the one-time setup, and work with raw data, a self-hosted open-source server is the right call and costs you nothing. If you want the analysis, the kept history, and a one-line install, a hosted server is what you are actually paying for. The tool count settles none of that.

Whatever you choose, hold it to an honest boundary. A Search Console MCP server reads your search data: clicks, queries, position, indexing. It stops at the click. It cannot tell you what converted, and it cannot see the competing results page, so treat any tool that promises revenue or ranking certainty with suspicion. QueryScope reads your own Search Console from your editor, ranks what to fix, and keeps your history, and it says plainly where its view ends. If a metric in any of this is unfamiliar, the Search Console glossary defines each one with the caveat that makes it misleading.

Sources

• Google Cloud Platform Console Help, OAuth App Verification ("Apps that request access to scopes categorized as sensitive or restricted must complete Google's OAuth app verification"; "If your app utilizes only non-sensitive scopes, it is not mandatory for your app to complete the app verification process").
• Google for Developers, Using OAuth 2.0 to Access Google APIs (a project with a publishing status of "Testing" "is issued a refresh token expiring in 7 days, unless the only OAuth scopes requested are a subset of name, email address, and user profile").
• AminForou, mcp-gsc (open-source Google Search Console MCP server; supports OAuth and service-account authentication; around twenty tools across analytics, URL inspection, and sitemaps).