Google Analytics MCP: What the Official Server Does

Google maintains an official GA4 MCP server, analytics-mcp, published at github.com/googleanalytics/google-analytics-mcp and installable with pipx run analytics-mcp. It exposes seven tools. All seven are read-only. There is no write path, no relationship management, no workflow trigger, and no change-history access.

It is the narrowest official MCP server across the three Google surfaces we run in production — and the only one that has never produced a single friction issue in nearly two months of daily agent use. Those two facts are the same fact.

The seven tools

Tool	What it does
run_report	Custom GA4 report with arbitrary dimensions, metrics and filters
run_realtime_report	Active users and events in the last 30 minutes
run_funnel_report	Multi-step funnel analysis
get_account_summaries	Every GA4 account and property the credential can reach
get_property_details	Metadata for one property
get_custom_dimensions_and_metrics	Custom schema registered on a property
list_google_ads_links	Google Ads accounts linked to the property

Three reporting tools, four discovery tools. That is the whole surface.

The scorecard

Each cell scored 0–4, where 0 means not addressable at that layer and 4 means an agent succeeds on the first call from the tool description alone.

Layer	Read	Write	Relationship	Workflow	Audit / History
UI	4	3	3	3	3
API	4	3	3	2	2
MCP	3	0	0	0	0

UI and API rows are assessed against Google's published product and API surface. The MCP row is scored from production use.

The four zeros are not defects. GA4's Admin API can create custom dimensions, define audiences and manage access bindings; the MCP server deliberately exposes none of it. For an analytics surface that is a defensible call — the overwhelming majority of what an agent wants from GA4 is a number, and a read-only server cannot corrupt a property's configuration at 3am.

The read score of 3 rather than 4 comes down to one thing.

The property ID problem

Property ID is a parameter on every tool call, not an environment variable and not a server default. The agent has to already know it.

This is the Uncontextualized failure mode: the tool descriptions are accurate and the parameter schemas are correct, but the tool assumes the agent arrives already holding a piece of deployment-specific state. An agent that does not know the property ID has two options — call get_account_summaries first and spend a round trip discovering it, or guess and fail.

The fix is not a code change. It is putting the property ID in the organisation profile the agent reads at session start, so the number is context rather than a discovery task. Ours lives in that profile precisely so no agent ever spends a call finding it again.

That pattern generalises: when a tool needs a constant that is stable per deployment, the constant belongs in the agent's context, not in a discovery round trip. Every session that rediscovers it pays the same tax.

Authentication: one credential, two integrations

analytics-mcp authenticates through Application Default Credentials — a file path in GOOGLE_APPLICATION_CREDENTIALS. Two paths work:

• Service account. Create one in Google Cloud, add its email to GA4 Admin → Property Access Management with the Viewer role, download the JSON key. This is the documented path and the right one for a server deployment.
• Authorized-user JSON. The {client_id, client_secret, refresh_token, type: "authorized_user"} shape produced by a one-time OAuth flow.

We run the second, because it lets one credential serve both GA4 and Search Console. That decision has a sharp edge worth knowing about: analytics-mcp requests the analytics.readonly scope on every token refresh, and Google's token endpoint rejects any scope outside the original grant. If you re-mint that credential later for another Google service, the new grant must remain a superset of analytics.readonly or GA4 breaks silently at the next refresh. We hit exactly that failure from the other direction while adding Search Console, and it cost a debugging cycle. The details are in the Search Console post.

One credential across two integrations is efficient. It also couples them, and the coupling is invisible until a refresh fails.

Why the alternatives lost

For completeness, since the GA4 MCP landscape is thin:

• mcp-server-google-analytics (ruchernchong) — archived October 2025. An orphaned server caps its own coverage score regardless of tool count, because unmaintained coverage is coverage on borrowed time.
• Stape's hosted option via npx mcp-remote — your analytics data transits a third party, and the browser OAuth flow does not survive a headless container. Both are disqualifying for a server deployment; the first should be disqualifying for anyone.

The official server being both first-party and the best available option is unusual in the MCP ecosystem right now. Search Console, by contrast, has no official server at all.

The verdict: zero issues is not the same as high value

We have run analytics-mcp in production since 8 June 2026. Across that window our agents filed zero friction issues against it. For comparison, over a comparable period the same fleet filed 14 against Google Workspace tooling and 27 against our CRM integration.

That number deserves a careful reading. It does not mean GA4 is the best-integrated surface we run. It means the server does one narrow thing and does it correctly. There is no write path to get wrong, no relationship model to misunderstand, and no workflow trigger to fire by accident. A tool with a small surface has a small failure surface.

The harder question is what we actually got from it — and here we owe an honest answer.

We chose not to join GA4 to Search Console

When we built our weekly SEO triage tool, joining GA4 traffic to Search Console impressions was the obvious design. We measured first. Over the trailing 28 days to 30 July 2026 the site drew 19 organic clicks across 25 pages. Per-page session counts sat in the low single digits.

Correlating those numbers would have produced confident-looking output with no information in it. So GA4 was cut from v1 entirely, with a documented threshold for revisiting: roughly 30 clicks per page per month, the point where CTR-to-conversion comparison stops being noise.

The integration works. We use it for realtime checks and ad-hoc reporting. We deliberately do not use it for the thing it seemed most obviously built for, because at our current volume that use would manufacture confidence rather than insight.

Would we deploy it? Yes, without reservation — it is first-party, read-only, cheap to run, and it has never once misled an agent. Just size the value against your own traffic before assuming an analytics MCP will tell you something you did not already know. A read-only server that returns accurate numbers is still only as useful as the numbers.

Related

• Google Search Console MCP: 5 Setup Errors — the same credential, no official server, considerably more friction
• Google Workspace MCP: Official vs Community Server — the third Google surface we run
• Gmail MCP Search Returns IDs, Not Senders — what an unshaped response costs an agent
• Claude Code MCP Scopes: Local, Project, User + a 4th Layer — where MCP server configuration lives on disk