Google Webtools MCP

google-webtools-mcp

An MCP server that gives an AI agent direct access to Google Search Console and Google Analytics 4 — property management, search performance analysis, indexing checks, GA4 reporting, and site verification.

For AI agents

If an agent is driving this server, point it at [SKILL.md](SKILL.md) first (Russian). It covers the working order — property discovery, verification, sitemaps, indexing checks, the regular audit path — how to read a URL Inspection result, what Search Console does *not* expose, which calls burn quota, and which tools write to live configuration.

What it does

The server exposes 39 tools built on five Google APIs:

Beyond raw API access, tool responses are post-processed by a local analysis layer: position-based CTR benchmarks, trend detection, query intent classification, opportunity scoring, and a recommendation engine. Most tools return a readable Summary and Data block rather than bare JSON, plus Recommendations and Limitations sections when there is something worth saying.

Infrastructure: an in-memory TTL+LRU cache (search analytics 15 min when the range ends within the last 2 days and 1 h once it is older, sitemaps 15 min, site lists 30 min, URL inspections 1 h), a rate limiter (20 req/s, burst 30), and two transports — stdio (default) and stateless Streamable HTTP.

Tools

Search Console properties (4)

Sitemaps (4)

Search performance (6)

Opportunities (5)

Indexing (3)

Query analysis (3)

Reports (2)

GA4 administration (7)

GA4 reporting (3)

Site verification (2)

Setup

1. Get Google credentials

Enable these APIs in your Google Cloud project: Search Console API, Google Analytics Admin API, Google Analytics Data API, and Site Verification API.

The server requests these OAuth scopes:

https://www.googleapis.com/auth/webmasters

https://www.googleapis.com/auth/analytics.readonly https://www.googleapis.com/auth/analytics.edit https://www.googleapis.com/auth/siteverification.verify_only

Option A — Service account (best for servers and automation):

1. Google Cloud Console → IAM & Admin → Service Accounts → create one.
2. Add a key → Create new key → JSON → download it.
3. In Search Console → Settings → Users and permissions → add the service account's email address.
4. In GA4 → Admin → Property access management → add the same email.

Option B — OAuth 2.0 (best for personal, local use):

1. Google Cloud Console → APIs & Services → Credentials → Create credentials → OAuth client ID → Desktop app.
2. Download the client secrets JSON.
3. On first run, the server prints an authorization URL to stderr and starts a temporary local callback listener. Open the URL, consent, done.
4. The token is stored at ~/.google-webtools-mcp/token.json and refreshed automatically, so you authorize only once.

2. Environment variables

Authentication methods are tried in this order, and the first one that yields usable credentials wins. A method that fails is recorded and the next one is tried: if GOOGLE_APPLICATION_CREDENTIALS points at a missing or malformed file, the server does not stop there — with OAuth configured (and a saved token) it starts under the OAuth account instead. Check the [auth] Authenticated via … line on stderr to see which identity was actually used.

1. Service account — GOOGLE_APPLICATION_CREDENTIALS, then GOOGLE_SERVICE_ACCOUNT_KEY, then ./credentials.json if its type is service_account.
2. Application Default Credentials (gcloud auth application-default login) — skipped if GOOGLE_APPLICATION_CREDENTIALS is set.
3. OAuth via GSC_OAUTH_CLIENT_SECRETS_FILE.
4. ./credentials.json in the working directory, if it looks like OAuth client secrets (has an installed or web key).

If none succeed, the server prints a setup guide to stderr and starts anyway, so a host or a directory can still list its tools without keys. Every tool call then looks for credentials again and, until one method works, returns the same error with the setup hint instead of calling Google. Fixing the key file needs no restart.

3. Install

docker run -i --rm \

-v /absolute/path/to/service-account.json:/creds/sa.json:ro \ -e GOOGLE_APPLICATION_CREDENTIALS=/creds/sa.json \ ghcr.io/stufently/google-webtools-mcp:1.2.2

Replace /absolute/path/to/service-account.json with the key file from step 1 (Docker needs an absolute path), then paste the command. Docker pulls the image on the first run (amd64 and arm64), so nothing else needs installing. It should print Server running on stdio to stderr and wait for a client (Ctrl+C to quit). Every client block below runs this same docker run; the key file is mounted read-only and never written into the client config.

The image covers the service account. OAuth does not work in a container on the first run (see Docker); for OAuth, build from source.

Verified clients and platforms

Only what has actually been run is listed as verified. Everything else in Connecting it is a documented config that nobody has checked end to end.