Google Search Console MCP Server

An MCP server that gives Claude and other AI agents real control over Google Search Console — list your properties, check whether a URL is indexed, find the pages Google left out, run URL inspection in bulk, submit sitemaps, request indexing, and pull search analytics, all from a conversation.

Built for SEO practitioners tired of checking index status and submitting sitemaps by hand, one property at a time, and for the AI agents that can do it for them.

shahidali.co/tools/gsc-mcp is the project page: the same install lines, the tool list, and what the quota rules actually are, written for people who have not opened this repo.

Add it to your agent

Claude Code, in one command:

claude mcp add gsc -- uvx gsc-indexer-mcp

Anything else that speaks MCP, by hand — this is the whole config:

{
  "mcpServers": {
    "gsc": { "command": "uvx", "args": ["gsc-indexer-mcp"] }
  }
}

uvx fetches and runs the published package with nothing installed first, which is why every button above is a one-liner. A .mcp.json with exactly that content sits in this repo, so cloning it is also enough.

No API key goes in any of these. Sign-in happens once, in your browser, when you first call gsc_setup() — see The OAuth client is handled for you.

Project status

Beta. The whole surface is wired up, and it has now met a real Google account — on one operating system, driven by one person.

0.1.0 drops the pre-release suffix so that pip install finds it without --pre. That is a decision about reach, not a claim of maturity: this project needs bug reports from people who are not its author, and a package pip refuses to install by default does not get them. Read the Known issues in CHANGELOG.md before pointing it at a property you care about — in particular, a transient rate-limit from Google currently ends the whole batch. Bug reports are the point; please file them.

Fifteen tools are registered on the server and covered by a wire-level smoke test that connects a real MCP client session and confirms every tool answers with a description. Storage, quota accounting, OAuth, and config are the foundation underneath them. Sign-in has been walked for real, on Windows against a live Google account — see docs/manual-smoke.md, which is also where the defects that run found are recorded. Submission has since driven a real browser and had Google confirm real Request Indexing calls, in Chrome and in Brave, against live properties. That is one platform and one operator, and every automated assertion about it is still made against a fake; see Known gaps for what that does and does not buy you.

Released versions and what changed in them are in CHANGELOG.md. Watch or star the repo if you want to know when the milestones above are verified on a platform other than Windows.

Tools

Shipped and registered on the MCP server today:

Why quota accounting is the hard part

Most tools in this space get Google's limits wrong, then get throttled and blame detection. Both limits that matter are per property, not per account:

Properties are independent, so eight properties means eight independent budgets. This server tracks slots individually rather than counting a daily total, so it knows the exact minute the next slot opens — and it deliberately over-counts rather than under-counts when a race is possible, because a short wait is cheaper than a hard Quota Exceeded.

Finding what is not indexed

gsc_find_unindexed collects candidate URLs — from the property's registered sitemaps, from URLs already in the local store, or both — inspects the ones whose last inspection has gone stale, and reports each unindexed URL with a reason. limit caps how many URLs are inspected, not how many come back: an inspection spends budget, and a cap that only trimmed the output would pay full price for an answer it discarded. Which URLs a capped run reaches follows the store's own URL ordering (alphabetical), not staleness, so a capped run is a sample rather than a worst-first sweep.

gsc_audit answers the same question from the store alone — no HTTP inspection, no budget spent. It is point-in-time: it reports what the last inspection found, and carries as_at and a stale count so you can tell how old that picture is. There are deliberately no movement numbers.

Reason codes

There are ten of them. submitting_helps on each row is the one to act on before calling gsc_request_indexing: