TL;DR
The Google Analytics MCP server is Google’s own official, open-source tool that connects live GA4 data to an AI model like Claude or Gemini through the Model Context Protocol (MCP), an open standard for letting AI assistants call outside tools directly. Instead of opening GA4 and clicking through reports, you ask a question in plain English and the model pulls the real numbers and answers it.
It’s free, read-only, and runs locally on your own machine or server. Setup means enabling two Google Cloud APIs, generating read-only credentials, and pointing an MCP-compatible client, Claude Code, Gemini CLI, or a self-hosted remote connector for Claude.ai, at the server.
On privacy: GA4 is already required to exclude personally identifiable information like names and emails, so the MCP server can’t hand over data that was never collected to begin with. Anthropic’s policy separately excludes MCP and other connector content from the data used to train Claude. What flows through stays inside your conversation.
What Is the Google Analytics MCP Server, and Why Use It?
Model Context Protocol, or MCP, is an open standard Anthropic introduced for connecting AI models to outside tools and data sources through one shared interface. Instead of every company building a custom, one-off integration for every AI assistant it wants to support, MCP gives them a single protocol to build against once. Any MCP-compatible client, Claude, Gemini, Cursor, whichever, can then plug into that same server without a separate integration for each one.
The Google Analytics MCP server is Google’s own implementation of that standard for GA4. It’s open-source under the Apache 2.0 license, built and maintained by the Google Analytics team, and it wraps the GA4 Admin API and Data API into a set of tools an AI model can call directly. Point Claude or Gemini at it, and instead of opening GA4, clicking into a report, and exporting a CSV, you just ask: “What were my top landing pages last month?” or “How did organic traffic trend against paid over the last quarter?” The model calls the tool, pulls the real numbers from your property, and answers in plain English.
Why use it instead of just opening GA4 like normal? Because most of what agencies and in-house marketers actually do with analytics data isn’t browsing a dashboard. It’s translating that data into a decision, a slide, or a client email. GA4’s interface is built for exploring metrics, not for answering “why did conversions drop on the 14th” in one step. An MCP connection collapses that gap. You still get real GA4 data, not a guess, but the model does the digging, the cross-referencing, and the first draft of the explanation.
How It Actually Works
Under the hood, the server exposes seven tools, grouped into three jobs.
The Tools It Exposes
Account and property info. get_account_summaries lists which GA4 accounts and properties you have access to, get_property_details pulls the specifics of one property, and list_google_ads_links shows which Google Ads accounts are linked to it.
Core reporting. run_report is the workhorse. It runs a standard GA4 report with whatever dimensions and metrics you ask for. run_funnel_report builds a funnel report on the fly, and get_custom_dimensions_and_metrics surfaces any custom tracking you’ve set up, so the model knows what’s available before it tries to query it.
Realtime. run_realtime_report checks who’s on the site right now, genuinely useful during a launch or a campaign push when you want a pulse check without switching tabs.
That’s the whole toolset. No tool creates, edits, or deletes anything in your GA4 configuration.
What It Can’t Do
Google’s own repo labels it plainly: Experimental, and read-only. It can’t touch your GA4 settings, can’t create audiences, can’t change your data retention window. If a prompt asks the model to “fix” something in your Analytics setup through the MCP connection, it simply can’t — the scope it authenticates with, analytics.readonly, doesn’t allow write access at all.
It also runs locally by default, on your own machine or your own server, not as a hosted service Google operates for you. That matters for the setup section further down. A local, read-only, open-source tool is about as conservative a design as Google could have shipped this with.
Why Marketers and Agencies Are Adopting It
Most new GA4 tooling doesn’t catch on this fast. This has, and the reason isn’t really about the AI part. It’s about what it replaces.
Nobody outside a data analyst role reliably remembers that “engaged sessions” and “engagement rate” are two different fields, or which report has “landing page” and which has “page path.” You just describe what you want instead. And most client-reporting time was never really about pulling numbers, it was about turning numbers into a sentence someone would actually read. A connected model can draft that sentence straight from live data instead of from a screenshot pasted into a doc three days ago.
It’s faster for the exploratory stuff too. “Why did traffic dip on the 14th” used to mean opening three reports and cross-referencing them by hand. Now it’s one prompt, and the model chains a report, then a comparison, then a segment breakdown, without you doing the chaining yourself.
And it costs nothing extra to try. Because it’s Google’s own open-source release, there’s no separate subscription, and it isn’t locked to one AI provider. It behaves the same whether the client on the other end is Claude, Gemini, or something else entirely.
At an agency, all of that shows up in small moments. Catching the question a client is about to ask before the call even starts. Turning a mid-month check-in into an actual conversation instead of a screen share of a dashboard nobody else in the room can read.
Is Your Client Data Safe? How Privacy Actually Works
This is usually the first question anyone asks, right after the initial “okay, that’s neat” reaction wears off. It deserves a real answer, not a wave-off. Two separate systems are involved here — GA4 and Claude — and each one answers it differently.
What GA4 Itself Already Keeps Out
Before any MCP server enters the picture, GA4 is already supposed to be free of anything that identifies a specific person. Google’s terms explicitly prohibit sending personally identifiable information — names, email addresses, phone numbers, exact home addresses — to Analytics in the first place, and a compliant implementation shouldn’t have that data sitting in the property at all. What GA4 actually stores is aggregate and pseudonymous: session counts, event names, page paths, device categories, city-level location, channel groupings. So when the MCP server runs a report, it isn’t retrieving a list of who visited your site. GA4 was never holding that list to begin with.
What Happens to That Data Inside Claude
On the Claude side, the relevant fact is Anthropic’s own policy on connector data: content pulled in through connectors, MCP servers included, whether local or remote, is specifically excluded from the data Anthropic uses to train its models. It only becomes part of that pool if someone manually copies it into the chat as pasted text, which isn’t how a tool call works. The numbers a report returns get used to answer the question in that conversation. Nothing more.
Standard conversation-retention rules still apply on top of that. How long a chat is stored depends on your plan and your training-data preference in settings, and that’s worth checking directly in Anthropic’s current privacy documentation rather than taking any blog post’s word for it, since it’s the kind of policy that gets updated. But the specific worry people usually raise, whether an AI model is going to learn from a client’s private traffic numbers, has a clear answer for connector data: no. That’s excluded by design.
Put those two together and the practical picture is this: the data source — GA4 — is already stripped of who your visitors are, and the pipe carrying it to Claude doesn’t feed it back into model training. What you’re left with is Claude seeing the same aggregate metrics you’d see in the GA4 UI, just queried in plain English instead of clicked through by hand.
How to Get Started With the Google Analytics MCP Server
The full step-by-step lives in Google’s GitHub repo, google-analytics-mcp under the googleanalytics org, but here’s the shape of it.
Connecting It to Claude Code
This is one of the two paths Google documents explicitly. Install pipx, enable the Google Analytics Admin API and Data API in a Google Cloud project, set up Application Default Credentials scoped to analytics.readonly, then run one command:
claude mcp add analytics-mcp --scope user -e "GOOGLE_APPLICATION_CREDENTIALS=..." -e "GOOGLE_PROJECT_ID=..." -- pipx run analytics-mcp
Claude Code picks it up as a local MCP server the next time you start a session.
Connecting It to Claude.ai or Claude Desktop
Here’s the part worth knowing before you try it: the official server runs locally over stdio. It’s designed to run on your own machine, not to be reached over the internet. Claude.ai’s custom connectors, under Settings > Connectors, expect a remote MCP server with a public URL, so pointing claude.ai directly at the GitHub repo as written won’t work out of the box. Claude Desktop can run it locally through its own MCP config file the same way Claude Code does. If you specifically want it inside the claude.ai web interface, you’d need to deploy the server somewhere reachable over the internet first, a small cloud instance or a serverless platform, then add that URL as a custom connector.
Connecting It to Gemini
Google’s own instructions default to this path: install Gemini CLI or Gemini Code Assist, add the server to ~/.gemini/settings.json with the same credentials, then type /mcp inside Gemini to confirm it shows up in the list.
Whichever client you use, the credential and API-enablement steps are identical. The client is just the thing asking the questions. The server and the GA4 property underneath it don’t change.
Google Analytics MCP vs. the GA4 Interface vs. BI Dashboards
None of this replaces GA4 or your existing dashboards. It sits alongside them, and it’s worth being clear-eyed about where each one actually wins.
The GA4 interface is still the right place for deep, structured exploration, building a report you’ll reuse weekly, or configuring the property itself: events, conversions, audiences. MCP can’t touch configuration at all, so that job isn’t going anywhere. A BI dashboard, Looker Studio or a client-facing report, is still the right place for a fixed set of metrics someone checks on a schedule. It’s built to be glanced at, not conversed with.
Where the MCP connection actually wins is the questions that don’t have a pre-built report sitting there already. The ad hoc “wait, why did this happen” moment. The client call where someone asks something you didn’t prep a slide for. The first-pass analysis before you decide what’s actually worth building a permanent dashboard around.
What You Can Actually Ask It
A few real prompts that work well once it’s connected:
- “What were my top five landing pages by sessions last month, and how does that compare to the month before?”
- “Were most of my users over the last 90 days logged in or anonymous?”
- “Build me a funnel from homepage view to signup for the last 30 days.”
- “What’s happening on the site right now?” (this one hits the realtime tool)
- “What custom dimensions am I already tracking on this property?”
The model can chain several of these together in one exchange too. Ask a broad question and it will often run more than one report to answer it properly instead of making you ask each piece separately.
Limitations Worth Knowing
A few things worth setting expectations on before you rely on this daily:
- It’s labeled Experimental by Google. The tool set and behavior can still change between releases, so don’t wire anything mission-critical to it without a fallback.
- It’s read-only, so it won’t fix anything, tag anything, or update your GA4 configuration. You still need someone, or something else, to act on what it finds.
- It only sees what the GA4 Data and Admin APIs expose. If something isn’t tracked as an event or a dimension in your property, asking the model about it won’t conjure it into existence. Garbage in, garbage out still applies here like anywhere else.
- Running it locally means whoever’s machine it’s on needs their own valid Google Cloud credentials with access to the property. That’s a small setup tax on every new team member who wants to use it directly, part of why a lot of teams end up centralizing it on one shared server instead of everyone running their own copy.
Final Thoughts
The Google Analytics MCP server isn’t a new analytics platform, and it doesn’t try to be. It’s a narrower, more useful idea: let a model that’s already good at reading and writing sit directly on top of the data you already have, instead of forcing a person to be the translation layer between a dashboard and a decision every single time.
That’s a small architectural change with an outsized effect on how fast a team moves from “I wonder why” to an actual answer. Set it up once, point it at a real property, and the honest test is simple: does asking beat clicking? For most of the questions that come up in a normal week, it does.
The best analytics tool is the one that answers the question you actually asked.