
MCP Google Search Console
io.github.crunchtoolsPublished by GitHub account crunchtoolsv0.1.0Updated Nov 3, 2026
Secure MCP server for Google Search Console analytics, sitemaps, and URL inspection
Overview
Local MCP server that lets an assistant query Google Search Console search analytics, manage sitemaps, inspect URL indexing and manage site properties.
- What you can do
- Query search analytics data such as clicks, impressions, CTR and position
- List, get, add and delete Search Console site properties
- List, get, submit and delete sitemaps
- Inspect the indexing status of a specific URL
- When to use it
- Useful when you want an assistant to pull Search Console performance numbers, check why a page is or is not indexed, or keep sitemaps and verified properties in order without opening the Google console by hand.
- Requirements
- Runs as a local Python process (uvx or pip) or a container. Needs a Google Cloud OAuth client with the Search Console API enabled and the webmasters scope, plus credentials supplied as GSC_CLIENT_ID, GSC_CLIENT_SECRET and either a browser OAuth flow or GSC_REFRESH_TOKEN; optional GSC_CREDENTIALS_DIR and GSC_OAUTH_REDIRECT_URI. Network access to Google APIs.
Installation
In SourceWeft
- Open MCP Google Search Console in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
mcp-google-search-console-crunchtools
Secure MCP server for Google Search Console. Query search analytics (clicks, impressions, CTR, position), manage sitemaps, inspect URL indexing status, and manage site properties.
[CI] [PyPI] [License: AGPL v3]
Installation
uvx (recommended, zero-install)
pip
Container (Podman/Docker)
OAuth Setup
This server supports two authentication methods: browser-based OAuth (recommended) and environment variable (fallback).
Option A: Browser-Based OAuth (Recommended)
Browser-based OAuth handles token exchange automatically. When credentials expire, visit the /auth URL and click through Google's consent screen — no manual code exchange needed.
Step 1: Create a Google Cloud OAuth App
- Go to Google Cloud Console
- Create a new project (or select an existing one)
- Navigate to APIs & Services > Library
- Search for Google Search Console API and click Enable
- Navigate to APIs & Services > Credentials
- Click + CREATE CREDENTIALS > OAuth client ID
- If prompted, configure the OAuth consent screen first:
- User type: External (or Internal if using Google Workspace)
- App name: anything (e.g., "MCP Search Console")
- Scopes: add
https://www.googleapis.com/auth/webmasters - Test users: add your Google account email
- Back on Create OAuth client ID:
- Application type: Web application
- Name: anything (e.g., "MCP Search Console")
- Authorized redirect URIs: add your server's callback URL (e.g.,
https://mcp-gsc.example.com/oauth2callback)
- Click Create — copy the Client ID and Client Secret
Step 2: Configure and Start
Create an env file:
Start the server with a persistent volume for credentials:
Step 3: Authenticate
Visit https://mcp-gsc.example.com/auth in your browser. You'll be redirected to Google's consent screen. Grant access and the server will save credentials automatically.
When tokens expire, any tool call will return the /auth URL. Click it to re-authenticate — no container restart needed.
Option B: Environment Variable (Fallback)
If you prefer static credentials or can't expose a callback URL, set GSC_REFRESH_TOKEN in your env file. See the manual OAuth flow below.
Manual OAuth flow
- Open the URL in your browser, sign in, and click Allow
- Copy the
code=value from the redirect URL - Exchange the code:
- Copy the
refresh_tokenfrom the response and addGSC_REFRESH_TOKEN=...to your env file.
How it works at runtime
The server checks for credentials in this order:
- File-based credentials from
GSC_CREDENTIALS_DIR/credentials.json(written by the browser-based flow) - Environment variable
GSC_REFRESH_TOKEN(fallback)
On each API call, the server exchanges the refresh token for a short-lived access token (~1 hour), cached in memory and refreshed automatically. Updated tokens are persisted to the credentials file for reuse across container restarts.
Available Tools (10)
Security
- OAuth2 credentials stored as
SecretStr(never logged) - File-based credentials written with
0o600permissions (atomic writes) - Automatic token scrubbing from error messages
- Pydantic input validation with
extra="forbid" - No filesystem access, shell execution, or code evaluation
- TLS certificate validation (httpx default)
- Request timeouts and response size limits
- Built on Hummingbird container images
See SECURITY.md for the full security design document.
Development
License
Source: README.md at commit dde91a8
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts