I Open-Sourced a Google Search Console MCP Server — After Cutting the Tools That Were Fake
A shipped MCP server is the real credential. This one got smaller and more honest on the way to being published.
By Andrew Pyle
I build and run MCP servers as part of a control plane that operates a portfolio of live sites. None of that was public, so I picked one server, cleaned it up, and open-sourced it. The interesting part was not the code that shipped. It was the code I deleted on the way out the door.
01
Why publish one at all
"MCP certification" is a phrase people search for, but there is no official one. In practice, the credential for the Model Context Protocol is a working server someone can read, install, and run. So instead of writing more about MCP, I published a real server: a Google Search Console MCP server that gives an AI assistant live search-analytics, URL-inspection, and sitemap tools.
I wrote more about the two meanings of "MCP certification" — the retired Microsoft one and the new Anthropic protocol — in a separate guide.
02
The catch: two-thirds of the tools were fake
The server started with about 31 tools. That looked impressive until I read the source. Roughly 20 of them were labelled SIMULATED in their own descriptions. Each one validated its inputs, logged a message, and returned a canned response with a quiet flag: "simulated": true, "No actual API call was made."
These were the tools that made the server look special: upload a disavow file, set hreflang, change the crawl rate, remove a URL, add or remove a property. In a demo they all "worked." In reality they did nothing.
The reason is simple once you check: Google exposes no public API for most of those operations. There is no endpoint to upload a disavow file, configure hreflang, or set a crawl rate. The crawl-errors API was retired in 2019. The tools were stubs standing in for endpoints that do not exist.
03
Shipping by subtraction
A tool that claims to remove a URL from Google but silently does nothing is worse than no tool at all. An assistant would call it, report success, and the user would trust a change that never happened. Publishing that under my name would trade a small honest tool for a convincing lie.
So I deleted every simulated tool, plus the dead crawl-errors call. Ten tools survived — the ones that make a real request to the Search Console or Web Search Indexing API:
- Search analytics: query clicks, impressions, CTR, and position by query, page, country, or device.
- Top queries and top pages over a lookback window.
- URL inspection: index status, coverage, canonical, and rich-result state for a URL.
- Sitemaps: list, and a real submit.
- Indexing: notify Google of a new or updated URL.
The README says plainly which operations are missing and why, so nobody expects the fake ones. Smaller, but every tool does what it says.
04
The point
The honest scope is the whole story. "Proof of MCP skill" is not a certificate; it is a server you can run — and the judgment to cut the parts that only look like they work. The code is on GitHub under an MIT licence if you want to read it or use it.
Related
writing
A thumbnail for every site, without a person taking screenshots
When you run a network of sites, you want a little preview of each one — a visual index of the whole thing. Doing that by hand is a chore that's always out of date. Doing it automatically is a small pipeline with a surprising number of ways to go wrong.
writing
A deploy that rolls itself back
The scariest moment in running your own infrastructure is the config reload that takes the site down and leaves you staring at a terminal. So I stopped trusting myself to catch it, and made the deploy check its own work — and undo itself when the check fails.
writing
Let the edge do the scaling so the origin can stay small
A network of sites sounds like it needs a big, muscular backend. It doesn't. Put a cache in front, keep the origin one small, well-understood thing, and let the edge absorb the traffic you were about to over-engineer for.
writing
One Django app, one FastAPI edge, and where I draw the seam
I keep reaching for the same two-framework shape: Django for everything that owns the data, FastAPI for everything the outside world reads fast. The interesting decision isn't which framework — it's exactly where the line between them goes.
writing
One engine, many domains
How I stopped building websites and started building the machine that builds them — the multi-tenant pattern behind a sports network, a 50-state platform, and a family of atlases.