Google Analytics MCP Without a Service Account: Three Paths That Work

Forty minutes into the official Google Analytics MCP setup, you're staring at gcloud auth application-default login --scopes ... and wondering why a chat connector needs a cloud project. The README assumes you know. You came here because you don't — or because you do, and you'd still rather not.

The official server does not require a service account. It requires something adjacent and, for most people, equally annoying — Application Default Credentials backed by a Google Cloud project. A service account is one of two ways to provide that. There's a second way through Google Cloud without one, and a third way that skips Google Cloud entirely.

Do you already have a Google Cloud project you understand, or are you about to create your first one just to ask GA4 a question in chat? That answer picks your path.

What the official server actually needs

Google's official Google Analytics MCP server comes straight from the Analytics team, costs nothing, and gets releases — v0.6.0 shipped in May 2026, still marked Experimental. The tool list is short and report-shaped; the full rundown of what it can answer lives in the GA4 MCP server overview.

To run, it needs three things on your machine: Python 3.10+ with pipx, a Google Cloud project with the Analytics Admin API and Analytics Data API enabled, and credentials with the analytics.readonly scope. That last requirement is what sends people searching "without service account." The README offers two auth commands, both starting with gcloud — and no troubleshooting section for either. This page is that section.

Path 1 — OAuth as yourself, no service account

This is the path for a solo operator on a personal laptop: authenticate as yourself, no extra identities. The README gives it one command; the command hides six console steps:

1. Create a project at console.cloud.google.com (or pick an existing one). Copy its project ID.
2. Enable both APIs for that project: Google Analytics Admin API and Google Analytics Data API.
3. Open Google Auth Platform (Google moved the old "OAuth consent screen" menu there) and configure the consent screen. On a Workspace account, pick Audience: Internal — it skips the two traps below. Otherwise pick External, then add your own email under Audience → Test users, or the login in step 5 ends with Error 403: access_denied.
4. Still in Google Auth Platform → Clients → create an OAuth client, type Desktop app. Download the JSON.
5. Run the README's command, pointing at that file:

gcloud auth application-default login \
  --scopes https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform \
  --client-id-file=YOUR_CLIENT_JSON_FILE

6. Note the credentials path it prints (typically ~/.config/gcloud/application_default_credentials.json), then register the server. In Claude Code:

claude mcp add analytics-mcp \
  --scope user \
  -e "GOOGLE_APPLICATION_CREDENTIALS=PATH_TO_CREDENTIALS_JSON" \
  -e "GOOGLE_PROJECT_ID=YOUR_PROJECT_ID" \
  -- pipx run analytics-mcp

In Claude Desktop or Cursor, the same thing as JSON in the MCP config file:

{
  "mcpServers": {
    "analytics-mcp": {
      "command": "pipx",
      "args": ["run", "analytics-mcp"],
      "env": {
        "GOOGLE_APPLICATION_CREDENTIALS": "PATH_TO_CREDENTIALS_JSON",
        "GOOGLE_PROJECT_ID": "YOUR_PROJECT_ID"
      }
    }
  }
}

Restart the client, then run the check: ask for your account summaries. The first answer should list your GA4 properties — if it does, you're done, and the prompts guide is where it starts paying off. That's the whole official path with no service account in it. About five minutes if you've made an OAuth client before; if this console is new to you, the comparison article puts the realistic range at 60–90 minutes, sometimes never.

One trap nobody warns you about: if your consent screen stays in Testing status, Google expires the refresh token after 7 days. The connector that worked on Monday dies the following Monday with invalid_grant: Token has been expired or revoked — an error that points nowhere near the consent screen. Publish the app in Google Auth Platform, or plan on re-running the login weekly. Publishing triggers Google's "unverified app" warning on your next login — Advanced → continue. It's your own app; the warning is for strangers.

Path 2 — when a service account is actually the right call

Service-account impersonation exists for a reason, and it's not to torture marketers:

gcloud auth application-default login \
  --impersonate-service-account=SERVICE_ACCOUNT_EMAIL \
  --scopes=https://www.googleapis.com/auth/analytics.readonly,https://www.googleapis.com/auth/cloud-platform

Use it when the credentials shouldn't belong to a person — a shared team setup, a server that runs reports on a schedule, an agency machine that outlives any one employee's Google login. Personal laptop, personal GA4, personal questions? Skip it. You'd be adding an identity layer you don't need. (If you do use it, your own account also needs the roles/iam.serviceAccountTokenCreator role on that service account, or the impersonation itself gets denied.)

And add the service account's email to the GA4 property itself — Admin → Property access management → Viewer. The grant lives in the GA4 interface, not in Cloud, which is exactly why it gets missed. Without it the server connects fine, then returns 403s or empty account lists, and nothing in the terminal points you to the right place.

The error messages, decoded

Each of these looks cryptic in the terminal and has a one-line fix:

One more pattern — everything connects but the property list comes back empty — is the Path 2 trap above: the identity you authenticated has no access to the GA4 property. Grant it in GA4 Admin, not in Cloud.

Path 3 — no Google Cloud at all

The third option drops the cloud project: auth is a browser OAuth screen, and the Google Cloud console never opens. The real difference between these tools is what you hand over. Stape proxies the live API through its hosted MCP — no copy of your data, but a third party in every request. Two Minute Reports hosts a GA4 server behind its own account. Analytics Edge ships a no-code desktop app that keeps everything local (Windows builds today). The wider landscape sits in the overview.

Community OAuth servers on GitHub — lyonicbeneke/google-analytics-mcp, surendranb/google-analytics-mcp — are the in-between: free, self-hosted, browser OAuth instead of the ADC dance — though a Cloud project with an OAuth client stays mandatory and a third-party repo handles your tokens.

And ConvRadar is one of the hosted ones — full disclosure, this site runs it.

ConvRadar's version of the trade: it ingests your GA4 into its own database nightly, so answers run on data through yesterday — a copy on someone else's server, in exchange for a five-minute setup and a tool list built for diagnosis instead of raw report calls. The official server keeps everything on your machine and queries data current to the minute. The full who-fits-which breakdown is in the comparison article; walkthroughs for the hosted path: Claude, ChatGPT.

If you read those gcloud flags and knew what every one meant — stay official. If you pasted them hoping for the best, the hour you're about to spend on ADC is the actual price tag, and a hosted connector is how you skip paying it.

Pick by who you are, not by which README you found first.