Google has an official MCP server for Google Ads and one for Analytics. For Search Console it has none, at least none we could find in October 2026. So the community filled the gap, and a few hosted services followed. They differ less in what they can read than in what they can write, and in where the search terms end up.
What a Search Console MCP server can touch
The Search Console API is small. It reads search analytics (clicks, impressions, CTR and position by query, page, country, device and date), lists sitemaps and properties, and inspects URLs. It also writes: it can submit and delete sitemaps, and add and remove properties. Read-only access is a scope of its own, webmasters.readonly, so a server that only wants to report can ask Google for exactly that and nothing more.
That is the first thing to check in any option: which scope does the consent screen ask for? A server that requests the full scope can delete a sitemap even if it ships no delete tool today. A tool added in the next release, or a prompt that convinces a model to call a generic request tool, would find the permission already granted.
The second thing is the QUERY dimension. Search terms are what people typed into Google. Most are harmless, some contain names, addresses or order numbers, and all of them go into the model's context the moment a tool returns them.
The options
- AminForou/mcp-gsc, the most popular community server. Around twenty tools, batch URL inspection included. Signs in with a desktop OAuth client in your browser or with a service account you add to each property. It ships sitemap and property writes; the destructive ones sit behind
GSC_ALLOW_DESTRUCTIVE, but there is no general read-only mode. Runs over stdio, with SSE and Docker optional and no authentication documented for the remote endpoint. - ahonn/mcp-server-gsc. One tool, search analytics, read only. Service account JSON only. Small, simple, local.
- mcpsearchconsole.com, a hosted server. Google OAuth with the read-only scope, sitemap writes as a separate opt-in. A free tier with fifteen pulls a day, Solo €4.99 and Team €29.99 a month. The operator and the hosting region are not named on the site.
- Composio. Nine tools including Add Site, Delete Site and Submit Sitemap. A developer platform, priced by calls.
- AnythingMCP. Eleven tools, four of them writes: submit and delete sitemaps, add and remove sites. You bring your own Google OAuth client, and access runs through the one Google account that authorized it.
- Porter Metrics, a reporting tool with an MCP URL you add as a custom connector. Free for three properties and thirty days of history.
- Loopthink, our product. Read-only scope at sign-in, a performance and a sitemaps tool per property, the QUERY dimension off until you switch it on, roles and an audit log per person.
The comparison
| mcp-gsc | mcp-server-gsc | mcpsearchconsole | Composio | AnythingMCP | Loopthink | |
|---|---|---|---|---|---|---|
| Runs where | Your machine | Your machine | Hosted, region not stated | Hosted | Frankfurt or self-hosted | Germany |
| Google sign-in | OAuth client or service account | Service account | Google OAuth | Managed or own OAuth app | Own OAuth client, one account | One Google sign-in, no client of your own |
| Read-only scope | No | Depends on the key's property role | Yes, writes opt-in | No | No | Yes |
| Sitemap or property writes | Yes, deletes behind a flag | No | Opt-in | Yes | Yes, four tools | No |
| Search terms to the model | Always | Always | Always | Always | Response mapping can drop fields | Off until you enable them |
| Per-person identity and audit | No | No | Not described | Logs, built for developers | Roles and audit log | Yes, roles and audit per person |
Sources: the READMEs and product pages linked above, as read on 17 October 2026.
Why "read-only" belongs at the consent screen
A flag like GSC_ALLOW_DESTRUCTIVE=false is a promise from the server's code. A read-only scope is a promise from Google. The first holds as long as nobody changes the config, upgrades into a version with a different default, or finds a tool that was not covered. The second holds no matter what the server does, because the token itself cannot write. If the people using the connector only need reports, there is no reason to hand the server more than the read-only scope, and the options that ask for it make that decision once, for everybody.
Who sees the search terms
Search Console already filters anonymized queries out of its reports, but what is left still comes from real people. A query like a customer's name plus "invoice", or a street address plus a product, is the kind of row nobody notices in a dashboard and everybody notices in a chat transcript that gets pasted into a ticket. Most options send every query to the model by default, because the tool returns what the API returns. Loopthink keeps the QUERY dimension off until somebody with the right role switches it on, and the role decides who gets it afterwards: an SEO lead sees the terms, the content team sees pages and clicks.
Which one fits
- One SEO, one laptop, and you want every tool: mcp-gsc. Keep the destructive flag off.
- Only the performance numbers, as simply as possible: mcp-server-gsc with a service account that has restricted access on the property.
- A cheap hosted connector for yourself: mcpsearchconsole.com does the read-only scope right; check where it is hosted before you connect client properties.
- A team, client properties, or anyone who will ask "who looked at that": a layer with roles and an audit log, which is what we built.
Running Google Ads too? The same questions, with write access on top, are in Google Ads MCP servers compared.