What it does
An open-source, read-only Model Context Protocol (MCP) server that connects Google Search Console data to AI assistants, so questions about search performance get answered in a conversation instead of a report.
The problem
Search Console holds the most reliable data on how a site performs in Google Search, but answering a simple question often means filtering, exporting and joining tables by hand. "Which pages lost clicks last week, and on which queries?" can take twenty minutes.
AI assistants are good at that kind of question, but they can't see Search Console data on their own.
How it works
The Model Context Protocol is an open standard for connecting AI assistants to tools and data sources. This server exposes Search Console as a set of tools the assistant can call, such as querying search analytics for a date range, filtered by page or query.
When you ask a question, the assistant decides which tool to call, the server fetches the data from the Search Console API with your own access (OAuth with your Google account, or a service account for a fixed set of properties), and the assistant answers using the numbers it gets back.
It is read-only by design. It asks Google for the webmasters.readonly scope and refuses to start with a wider one, so no model can change anything in a Search Console account.
The server has nine tools across three Search Console reports. The limit is the API, not the design: the Search Console API has only four resources in total.
- Performance, covered in full:
query_performance,top_queries,top_pages,compare_periods,get_data_freshnessandexport_query. Clicks, impressions, CTR and position, grouped by query, page, country, device, date, hour or search appearance, across web, image, video, news, Google News and Discover, with filters that accept regular expressions. - URL Inspection, covered in full:
inspect_url, for 1 to 10 URLs at a time. - Sitemaps, read only:
list_sitemaps. - Properties:
list_properties.
Some reports can't be reached by any MCP server, because Google publishes no API for them: the aggregate Pages report on index coverage, the Links report, Core Web Vitals and page experience, enhancement and rich result reports in aggregate, crawl stats, manual actions, security issues and removals. Indexing and rich result status are still available one URL at a time through URL Inspection.
In practice it is a Performance report tool with URL Inspection attached. Anyone expecting the whole Search Console interface would be disappointed, so I'd rather say it up front.
A few choices keep the answers honest:
- Caveats travel with the data. Search Console keeps 16 months of history, strips anonymised queries (so query rows never add up to the property total) and has incomplete data for the last 2 to 3 days. Every performance response repeats the relevant caveat, so the assistant doesn't present partial data as complete.
- Small pages, big exports. Calls return up to 1,000 rows, below the API maximum, so counts stay honest and the conversation doesn't fill up. Larger pulls, up to 500,000 rows, go to a CSV file through
export_query. - Quota guard. Google allows 2,000 URL inspections per property per day. The server counts locally and stops at 1,900 with a clear message, instead of failing halfway through a batch.
- Clear failures. An error comes back with a stable reason and a sentence naming the fix, and
gsc-mcp-server doctorchecks the whole setup.
On privacy: the server protects the credential, not the data. Every row a tool returns goes to whichever model provider the assistant uses. An optional filter drops queries that contain an email address or a long run of digits, and a property allowlist refuses every property not on it.
It runs with uv straight from GitHub, no clone needed, and is released under the MIT licence.