Connect GA4 + Search Console to Claude via MCP

Connecting GA4 and Search Console to Claude via MCP turns the two most important organic-data surfaces you own into tools an AI analyst can query directly — no CSV exports, no copy-pasting screenshots of the Performance report. The wiring itself is a claude mcp add plus service-account JSON exercise. The part most guides skip is the part that matters: scoping the access so the agent can read everything it needs and change nothing.

The landscape has a genuine asymmetry that shapes every decision in this build. Google publishes and maintains an official, open-source GA4 MCP server — Apache-2.0 licensed, versioned releases, its own page on the Google Analytics developer docs. Search Console has no official equivalent as of this writing; every GSC MCP server we found is community-built. You’ll trust one server because Google signed it, and the other because you read its code and capped its permissions.

This guide covers the full build in order: the architecture (local stdio processes, credentials that never leave your machine), the GA4 server setup with its property-level access grant, the community GSC server choice and its user invite, Claude Code’s three config scopes, the least-privilege guardrail checklist, and the quota ceilings an exploratory agent can burn through faster than you’d expect.

Start with what Google actually ships. The official GA4 MCP server lives at github.com/googleanalytics/google-analytics-mcp under an Apache-2.0 license, described on its own Google developer docs page as a local MCP server that interacts with the Google Analytics Admin API and Data API. As of July 8, 2026 it sits at 2.6k GitHub stars with its latest release, v0.6.0, dated May 21, 2026 and 66 commits on main — actively maintained, not a hackathon artifact. It exposes seven tools: get_account_summaries, get_property_details, list_google_ads_links, run_report, run_funnel_report, get_custom_dimensions_and_metrics, and run_realtime_report.

Search Console is the opposite story. There is no official Google-maintained GSC MCP server as of this research pass — every implementation we found is third-party. The most-starred is AminForou/mcp-gsc at 1.1k stars (v0.3.2, April 2026), MIT licensed, supporting both OAuth browser login and service-account auth, with roughly 20 tools spanning property management, search analytics, URL inspection, and sitemap management. If you want the broader server landscape before committing, our 25-server MCP roundup covers GA4 as one row among many — this post exists because the two servers a working analyst-agent actually needs deserve a dedicated end-to-end build, not a table row.

That asymmetry is not a footnote — it is the risk model. The GA4 server inherits Google’s maintenance cadence and a documented, deliberate read-only design. A community GSC server inherits whatever its maintainer decided, which is why the scoping and permission steps in Section 04 do more security work than the server choice itself.

Both servers in this build run as local stdio processes — Claude Code spawns them on your machine via pipx run or uvx and talks to them over standard input/output. That is a materially different trust model from remote HTTP/SSE connectors (the Notion or Asana pattern), where Anthropic’s cloud calls a vendor-hosted endpoint directly. Here, the service-account JSON key and any cached OAuth tokens live on the machine running Claude Code and nowhere else. For agency work on client data, that locality is a feature: the credential story stays inside your existing laptop-security posture instead of adding a new hosted intermediary.

It also means these servers are a Claude Code build, not a claude.ai custom-connector build. Claude’s remote-MCP infrastructure expects a publicly reachable HTTPS endpoint — neither of these servers offers one, and for this use case you don’t want one.

Worth knowing for context: Google announced official MCP support for a first wave of Google services — Maps, BigQuery, Compute Engine, GKE — on December 11, 2025, with an explicitly governance-first framing. GA4 and Search Console were not on that list, but the posture Google describes is the right one to copy even for community servers:

Prerequisites: Python 3.10+ and a GA4 property you administer. (If the property itself isn’t set up cleanly yet, start with our GA4 complete setup guide first — an MCP server pointed at a misconfigured property just automates confusion.) The server installs and runs via pipx run analytics-mcp, and authenticates through Application Default Credentials (ADC), scoped to analytics.readonly. You have two ADC paths:

• OAuth desktop flow — gcloud auth application-default login. Your own Google identity, quickest for a solo setup.
• Service account — a dedicated non-human identity with a downloadable JSON key (or impersonation, if you prefer keyless). The right answer for client work and anything a team shares.

Here is the step everyone misses: creating a service account and downloading its JSON key does not grant it any GA4 access. The service-account email must be separately added to the target property — in GA4, under Admin → Property Access Management — before a single API call succeeds. Grant it access to the one property this agent needs, and nothing organization-wide.

Then register the server with Claude Code:

# Google's server, run via pipx (Python 3.10+)
claude mcp add --transport stdio --scope local \
  --env GOOGLE_APPLICATION_CREDENTIALS="$HOME/keys/ga4-readonly.json" \
  analytics -- pipx run analytics-mcp

The -- separator matters: everything before it configures Claude Code (transport, scope, env vars); everything after it is the command that actually launches the server, passed through untouched — that split is straight from Anthropic’s MCP documentation. Once added, ask Claude to list your GA4 account summaries; if the tool call returns your property, auth and grant are both working.

That read-only design is server-side and deliberate — it is Google’s own guardrail, not one you have to configure. Your job on the GA4 side is only to keep the identity’s footprint small: one property, read-level access, a key file that lives outside any repo.

With no official server, your first decision is which community implementation to trust. We anchor this build on AminForou/mcp-gsc — the most-starred option we found (1.1k stars, v0.3.2, April 2026), MIT licensed, with both OAuth and service-account auth and ~20 tools covering search analytics, URL inspection, and sitemap management. Its README notes a separate hosted version adds GA4 tools, but the open-source repo itself is GSC-only — which is fine, because the official Google server already covers GA4. Its recommended install path uses uv/uvx (Astral’s Python packager) — the same one-command, no-manual-venv pattern the official GA4 server gets from pipx run. Alternatives exist — this is one of the eight community repos we catalogued — but whichever you pick, read the code before you feed it a credential. It is a community project, not a Google product.

The Search Console API supports two OAuth scopes: webmasters (read/write) and webmasters.readonly (read-only). Use the read-only scope — and as a bonus, Google reclassified it as non-sensitive in 2024, so it doesn’t trigger the per-scope app-verification process the write scope can involve.

The grant step mirrors GA4 but lives in a different place: the service-account email must be manually invited as a user on the target property, via Search Console Settings → Users and permissions. Permission levels matter here:

• Full — sufficient for reading performance data. This is what an analyst-agent needs.
• Owner — required only for actions like sitemap submission. An analyst-agent should never hold it.
• Restricted — narrower view rights; workable if your use case is purely aggregate reporting.

Register it with Claude Code using the same claude mcp add … -- … pattern as the GA4 server, launching whatever run command the repo’s README specifies via uvx, with your credential path passed through --env. The smoke test: ask Claude to list the properties the service account can see. One property in the response means the invite worked and the blast radius is right.

Claude Code stores MCP server configs at three scopes, and the choice is a security decision, not a convenience one. Local (the default) is private to you in the current project, written to ~/.claude.json. Project writes to .mcp.json in the repo root — version-controlled and shared with teammates. User is private to you across all projects. When the same server name exists at multiple scopes, precedence runs Local > Project > User.

Project scope is where teams get nervous — a checked-in config that grants credentialed tool access sounds like a supply-chain problem. Anthropic’s guardrail: project-scoped servers require explicit per-user approval before Claude Code will connect to them. claude mcp list shows them as pending approval until each user approves interactively. And .mcp.json supports environment-variable expansion, so you commit the server definition without committing anyone’s key path:

// .mcp.json — committed; each teammate sets GA4_SA_KEY_PATH locally
{
  "mcpServers": {
    "analytics": {
      "command": "pipx",
      "args": ["run", "analytics-mcp"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "${GA4_SA_KEY_PATH}"
      }
    }
  }
}

If a referenced variable has no default and isn’t set, Claude Code fails to parse the config — it fails closed rather than silently connecting with a blank credential. (If you’re weighing whether this belongs in MCP at all versus a Skill, see Claude Skills vs. MCP for marketing automation — live API access to credentialed data surfaces is squarely MCP territory.)

Most MCP-plus-Google-Analytics coverage stops at “connected.” The real guardrail work is the pair of grants: one GA4 property, not organization-wide access; one verified GSC site with Full — not Owner — permission. The table below is the setup checklist we use, with the exact scope strings and the quota ceilings to design around. Sources: Google’s developer docs and each server’s GitHub repo, retrieved July 8, 2026.

Most GA4/GSC MCP writeups never mention quotas. That is a mistake for agentic use specifically, because an exploratory agent making multi-turn queries behaves nothing like a dashboard refreshing once an hour. The GA4 Data API meters usage in tokens, not requests — each call’s cost varies with row count, dimension and metric count, filter complexity, date-range length, and data cardinality. A standard property gets 200,000 Core tokens per day and 40,000 per hour, with the same figures applying separately to the Realtime and Funnel categories; Analytics 360 properties get ten times both. The ceiling that bites agents first, though, is smaller: 14,000 tokens per project per property per hour on a standard property, plus a 10-concurrent-request cap.

Two practical mitigations. First, add "returnPropertyQuota": true to report requests during development — the response tells you exactly how many tokens each query consumed, which turns quota design from guesswork into measurement. Second, put aggregation instructions in the agent’s prompt or project memory: ask for totals and top-N breakdowns, not row-level dumps. (Google’s docs have also listed a separate, simpler general ceiling — on the order of tens of thousands of requests per project per day plus a per-IP queries-per-second cap, as documented at the time of writing — but the token buckets above are the binding constraint to design against.)

On the Search Console side the arithmetic is about rows. searchanalytics.query caps at 25,000 rows per request and 50,000 rows per day per site per search type (web, image, and video count separately) — so an agent pulling a full year of query-level data must paginate, and a two-day pull may be the honest answer for very large sites. Project-level quotas are generous (40,000 QPM, 30,000,000 queries per day, 1,200 QPM per site per user), but a separate “load” quota — a short-term ten-minute bucket plus a one-day bucket — can trigger quota-exceeded errors independently, especially on page and query-string groupings over long date ranges. Teach the agent to narrow date windows and dimensions when it hits one, rather than retrying the same heavy query.

With both servers connected, the first working session writes itself: ask Claude for last month’s organic sessions by landing page from GA4, the top rising queries from Search Console over the same window, and a joined narrative — which pages are earning impressions they don’t convert, which queries rank on page two with real click volume. That cross-surface join is the thing neither Google UI gives you in one place, and it is where an analyst-agent starts paying for its setup time in the first hour. For what a full rollout looks like past the first session — adoption, prompt patterns, the failure modes — our own agency MCP rollout case study is the honest after-picture, and predictive GA4 reporting once the data’s flowing is the natural next build.

The trend worth reading here is the asymmetry itself. Google maintaining an official GA4 MCP server — with versioned releases and a deliberate read-only boundary — while Search Console remains community-only tells you where Google currently believes agent-mediated access is safe: reporting data first, configuration surfaces not at all. The December 2025 announcement wave (Maps, BigQuery, Compute Engine, GKE) points the same direction, and its IAM-and-audit-logging framing suggests that when official servers do expand, they are likely to arrive governance-first rather than capability-first. We’d expect the GSC gap to close eventually — but building on a community server with capped permissions today is not wasted work, because the grants, scopes, and quota discipline transfer unchanged to whatever official server may follow.

If you’d rather hand this whole build — and the reporting layer on top of it — to a team that has already made the mistakes, our analytics services cover exactly this stack, and agentic SEO engagements are where the GSC half of this wiring earns its keep week over week.