Google's Analytics MCP server in a team: what it takes, what is missing

Google's own Analytics MCP server is one of the better official MCP servers around: read-only by scope, sensible tools, and maintained by Google. It is also labelled experimental and built for one person on one machine. Here is what it does, and what happens when a whole team wants it.

What the official server does

You run it locally with pipx run analytics-mcp and sign in through the gcloud CLI with Application Default Credentials and the analytics.readonly scope. Because of that scope it cannot change anything in a property, which is the right default. Its tools cover what most questions need: account summaries, property details, linked Google Ads accounts, custom dimensions and metrics, reports through the Data API, funnel reports and the realtime report.

For an analyst who already has gcloud and Python installed, it takes a few minutes and costs nothing. If that describes everyone who will use it, stop reading and install it.

Four things a team runs into

1. It is local only

The server talks stdio to a desktop client. There is no documented remote mode, so it does not exist in claude.ai in the browser, on a phone, or in ChatGPT. You could wrap it in an HTTP transport and deploy it, but then you are also building the OAuth layer that a remote connector needs, which is the subject of a whole article of its own.

2. Every person needs the toolchain

Python, pipx, the gcloud CLI, a Google Cloud project with the Analytics APIs enabled, and an ADC login. For a marketing manager or a managing director who wants to ask "how did the campaign landing pages do last week", that list ends the project before it starts. In practice somebody sets it up once on their own machine and becomes the person everyone asks.

3. One login sees everything that login sees

The server acts as the Google account behind the ADC session. GA4 permissions are per account and property, so a person with Viewer rights on ten properties gets all ten in the chat. That is fine for that person. It stops being fine when the login is shared, or when a colleague should see two of the ten. There is no layer in between that knows who is asking.

4. GA4 data can be personal

Unlike Search Console, GA4 carries user dimensions: city, age bracket, gender, interests. For a large audience they are statistics. For a small one, say the visitors of a B2B pricing page from one city in one week, they are a short step from a single person, and that is data your privacy policy has to cover once it flows into a model. GA4 applies thresholds in some reports, but the MCP server sends whatever the Data API returns.

The ways around it

• Keep it personal. The official server for each analyst who wants it, nobody else. Cheapest, and honest about its scope.
• Deploy it yourself. Wrap it in Streamable HTTP, put an OAuth proxy in front, run it under a service account you add to the properties with Viewer rights. Workable for an engineering team; you own the result. Our proxy comparison covers the options for the OAuth part.
• A reporting tool with an MCP endpoint. Supermetrics, Windsor.ai, Porter Metrics and others sell GA4 alongside many other sources. Strong when you need ten marketing sources in one place; check how each handles per-person access and where it is hosted.
• A gateway in front of GA4. That is Loopthink: one Google sign-in with the read-only scope, the properties you tick, each chat user with their own identity and role, the user dimensions masked until you say otherwise, every call in an audit log.

Official server and Loopthink, side by side

Source for the official server: its README on GitHub, as read on 17 October 2026.

Search Console and Google Ads raise the same questions with different details. They are compared in Search Console MCP servers compared and Google Ads MCP servers compared.

Google Analytics 4 in Claude, step by step →