1. What the server is
Google publishes an MCP server for Google Analytics, in the googleanalytics/google-analytics-mcp repository, that lets an AI assistant query a GA4 property directly instead of you exporting numbers and pasting them into a chat. The repository labels it experimental. According to the setup notes it needs Python 3.10 or later, pipx, and a Google Cloud project with both the Analytics Admin API and the Analytics Data API enabled, and it authenticates through Application Default Credentials with the analytics.readonly scope. Google's overview page states it is for read requests only and cannot edit your configuration or settings.
2. What an agent can ask it
The tools it exposes cover account and property details, links to Google Ads accounts, standard and funnel reports, custom dimensions and metrics, and real-time reports. In practice that means an agent can answer "which landing pages grew last month" or "where do people drop out of this funnel" without you opening GA4. It is the same Data API behind the Explorations covered in the event analysis workflow, with a conversational front end.
3. What read-only protects, and what it does not
Read-only is a real safety property. An agent that cannot change settings cannot break your tagging, delete a data stream, or alter a conversion definition, and that makes it a much easier thing to approve than a tool that can write. It does nothing about the quality of the answer. The agent can still pick the wrong metric, misread a date range, or report a number that comes from a thresholded or sampled report without saying so. That is the same lesson as reading Data Studio's reasoning panel and checking a Conversational Analytics answer: access control and correctness are separate problems.
4. Set it up with the least access that works
The scope is read-only, but the credential's own access decides which properties the agent can see, so give it the narrowest one that does the job. I run my own reporting pipeline with a Viewer-level credential for exactly this reason, and I would do the same here: a dedicated identity with access to the one property you intend, not your personal account with access to everything. Keep the credential out of any repository and out of shared chat logs, and revoke it when the experiment is over.
5. Make the agent show its request
Ask it to state the exact report it ran: the dimensions, metrics, date range, and filters. Then reproduce one number in the GA4 interface before you rely on the rest. If the two disagree, the request is where to look first. My take: this is useful for fast exploration and for drafting questions worth investigating properly, and I would not let its output go into a stakeholder readout without that reproduction step. A fair limitation: the project is experimental, so tool names and behavior may change, and I have described it from the documentation rather than from months of production use.
Who is responsible for what
Giving an agent access to analytics data is a governance decision as much as a technical one:
- Analytics owns the verification step and decides which questions an agent may answer unreviewed.
- Engineering and security own credential creation, scoping, and revocation.
- Privacy and legal confirm the agent does not pull anything into a tool the data should not leave, as covered in the privacy-first analytics blueprint.
- Leadership asks where a number came from before it is repeated.