How I Connected Google Search Console to Claude with MCP

What an MCP server is, in plain terms

MCP (Model Context Protocol) is an open protocol that lets an AI assistant call external tools. An MCP server is the go-between: on one side it speaks the assistant’s language, on the other it calls a particular service’s API. For Search Console, that means Claude can pull the queries report, inspect a URL or compare two periods on its own, instead of asking me to export a CSV and paste it into the chat.

The server runs locally, on the same machine as Claude Desktop or Claude Code, and talks to the assistant over standard input and output. No separate hosting required.

Which server I chose, and what I checked before installing

I went with Google Search Console MCP, the Python package gsc-mcp-tools. Three things decided it:

• Coverage. 61 tools: Search Analytics reports, URL inspection, sitemaps, the Indexing API, plus GA4, CrUX data, PageSpeed and audits for structured data, hreflang, headings and internal links.
• Service account support. No browser sign-in needed, which suits a local server that keeps running for weeks.
• A bundled CLI. Every tool is also available as a gsc-cli command. That came in handy while Claude couldn’t see the new server yet.

Before installing, I ran through my usual MCP server checks: is the code open, what is the licence, what are the dependencies and where does the program connect to. MIT licence; outbound traffic goes only to Google APIs, IndexNow and the pages being audited; tokens are kept in local files. Why these checks matter is covered in my post on AI tool security.

Step 1. Authentication: a service account instead of OAuth

The package supports two modes. OAuth is the familiar browser sign-in with your own Google account. A service account is a technical user of a Google Cloud project with a JSON key: no sign-in, and the server doesn’t depend on OAuth token lifetimes. For a local server I picked the latter.

1. Enable the Google Search Console API in a Google Cloud project. For URL submission and GA4 data, also enable the Web Search Indexing API and the Google Analytics Data API.
2. Create a service account and download its JSON key.
3. Grant access in Search Console itself: Settings → Users and permissions → Add user, then enter the service account’s email address.

Step three is the non-obvious one. Google Cloud roles have no effect on Search Console: until the address is added to the property’s users, every call returns 403, however correct the key is. There is no API for this step either — just the form in the UI, filled in by the site owner.

I granted “Full” permission, which is enough for reports and URL inspection. “Owner” is only needed for the Indexing API, so don’t hand it out without a reason.

What saved me some time: I already had a service account, created earlier for Google Analytics. One account can be used across several Google products, with access granted separately in each. I keep the key outside cloud-synced folders — in practice, it is a password to your data.

Step 2. Installation — and the first pothole: out of disk space

I install with pipx so the package gets its own isolated environment:

python -m pipx install gsc-mcp-tools

The install failed with No space left on device. My system drive C: was almost full — about 200 MB free — and pipx creates its environments there by default. The fix is to move pipx’s directories to another drive before installing:

$env:PIPX_HOME = "D:\pipx"
$env:PIPX_BIN_DIR = "D:\pipx\bin"
python -m pipx install gsc-mcp-tools

The environment took about 270 MB. Three programs appeared in the bin folder: gsc-mcp is the server, gsc-mcp-tools is the same server under the package name, and gsc-cli is the command-line client.

Step 3. Registering the server in Claude Code

The key is passed through environment variables. In PowerShell:

$k = "C:\keys\gsc.json"
claude mcp add gsc -s user `
  -e GSC_SKIP_OAUTH=true `
  -e "GSC_SERVICE_ACCOUNT_PATH=$k" `
  -- D:\pipx\bin\gsc-mcp.exe

The -s user flag stores the entry in your user config rather than the project file. That matters to me: my project folder syncs to the cloud, and there is no reason for the key path to live there. For the GA4 tools, add -e GA4_PROPERTY_ID=… to the same command.

claude mcp list

The gsc entry showed “Connected”. Here comes the second gotcha: the tools don’t appear in a session that is already open. The tool list loads when a session starts, so after adding a server you need a fresh one. And “Connected” only means the process starts and answers the handshake — not that Search Console permissions are in place.

Step 4. Testing without Claude — and a bug in the CLI

Rather than wait for a new session, I tried checking access with the package’s own CLI:

gsc-cli list

It crashed before even reaching Google: ValueError: badly formed help string. The traceback showed that the CLI takes the first line of each tool’s docstring and passes it to argparse as help text. One of those docstrings contains a % sign, and a recent argparse (I’m on Python 3.14) validates help strings as soon as subcommands are created, treating the percent sign as the start of a format placeholder.

One change in gsc_mcp/cli.py fixed it — escape the percent sign before passing the text on:

help=help_text.replace("%", "%%")

The MCP server itself was unaffected; only the CLI broke. The patch lives inside the installed package, though, and will vanish on upgrade, so a fix like this belongs with the package author.

One more interface detail: list parameters are passed by repeating the flag, not as a comma-separated string. A comma-separated value doesn’t raise an error — it silently turns into a single “URL”:

gsc-cli batch-url-inspection `
  --site https://example.com/ `
  --urls https://example.com/a `
  --urls https://example.com/b

After the fix, gsc-cli list-properties returned my site with siteFullUser permission. Access confirmed.

What it found on a live website

Junk URLs. Google was still holding on to eight stray addresses: /ru?Itemid=232 and its neighbours, leftovers of long-deleted menu items, plus two legacy URLs like /ru/component/content/article/2-…?catid=14 belonging to two long-unpublished articles from 2019 and 2021. All eight now return 410 Gone.

The legacy URLs taught me something. A redirect rule on the original address simply never fired. It turns out Joomla itself intercepts the old /component/content/article/… format and issues a 301 to an intermediate ?view=article&id=… URL — and only that second address actually returns 404. The rule had to go on that one. Along the way I also found a bug in the Joomla MCP connector: its redirect-creation tool was writing the status code into the wrong field.

URL inspection. For those parameterised URLs the inspection tool returned NEUTRAL with empty fields. That isn’t a failed call: Google simply holds no separate inspection data for them. The package still labels them fetch_error, which is misleading, so look at the fields themselves. For a regular page, the same tool returned “PASS”, the last crawl date and the canonical URL.

Quick wins. The quick_wins tool showed my home page ranking around 8th on average, yet earning one click from 295 impressions over four weeks. The expected CTR at that position is about 3%; the actual one was 0.3%. The next task is obvious: the page title and the snippet description.

What proved useful and what didn’t

• Works out of the box: period comparison, finding queries that lost traffic, quick wins, batch URL inspection, sitemap audits and on-page technical audits. Answers come back in seconds, and Claude picks the right tool for each question on its own.
• Needs preparation: the GA4 tools require the service account to have Google Analytics access, and CrUX data needs a separate API key and enough traffic.
• Comes with caveats: the Indexing API is officially meant only for job posting and livestream pages, with a quota of 200 requests a day. Don’t rely on it for regular pages.
• Always keep in mind: Search Console data lags by two to three days, and a small site simply doesn’t have much of it.

Quick checklist

1. Enable the Google Search Console API in a Google Cloud project.
2. Create a service account, download the JSON key and store it outside cloud-synced folders.
3. Add the account’s email in Search Console with “Full” permission.
4. Install gsc-mcp-tools with pipx; if you are short on space, move PIPX_HOME.
5. Register the server with claude mcp add in the user scope.
6. Check access with gsc-cli list-properties and open a new Claude session.

If you would rather not walk this path yourself, we can connect Google Search Console to an AI assistant for you — on your computer or in your company cloud.

Victor Parhimchik, founder of the IT Deweloper web studio