Google Analytics MCP Server

Official

by googleanalytics

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct aspect of Google Analytics: account summaries, custom dimensions, property details, ads links, annotations, and four distinct report types (standard, conversions, funnel, realtime). There is no overlap in functionality.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern: get_*, list_*, run_*. This makes the tool set predictable and easy to navigate for both agents and humans.
Tool Count5/5
With 9 tools, the set is well-scoped for a Google Analytics server. It covers account info, property configuration, and various reporting needs without being overwhelming or too sparse.
Completeness3/5
The set is read-only for analytics data and lacks CRUD operations for resources like annotations or custom dimensions. While it covers multiple report types, the absence of management tools and dynamic schema discovery (though hints exist) creates notable gaps.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 33 of 35 community issues answered or closed in the last 6 months
- 12 commits in the last 12 weeks
- Last stable release on July 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that information is retrieved, which implies a read operation. However, with no annotations, it fails to disclose potential behavioral traits like authentication requirements, rate limits, or error cases (e.g., empty account list).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource. It contains no unnecessary words or redundancy, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, the description is adequate but minimal. It lacks details about the output structure, potential limitations, or what constitutes 'summaries.' Given the absence of an output schema and annotations, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to elaborate on parameter semantics. It correctly implies that the tool requires no input, which is consistent with a summary retrieval operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Retrieves' and specifies the resource as 'information about the user's Google Analytics accounts and properties.' This clearly communicates the core function and distinguishes it from sibling tools like get_property_details or run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_property_details or list_google_ads_links. There are no exclusions or context cues to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Returns details,' with no mention of read-only nature, auth requirements, or side effects. This is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parameter note, with no wasted words. It is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks details on what 'details' are returned. Given the context of sibling tools, more completeness on output would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by specifying accepted formats for property_id (number or 'properties/' string). Schema coverage is 0%, so this explanation helps agents use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns details about a property,' which gives a clear verb and resource. It does not explicitly differentiate from siblings like 'get_account_summaries' or 'list_property_annotations,' but the tool name provides distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. No exclusions or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses snake_case requirement, independent filter application, pagination details, and complex filter limitations. However, it does not explicitly state that the tool is read-only or discuss quota/rate limits beyond a mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long and contains redundant sections (e.g., the same complex filter notes appear twice). While well-organized with hints, the verbosity harms conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, no output schema), the description covers all parameters, provides examples, explains filter limitations, and offers pagination guidance. Missing return value description and error handling, but overall thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the tool description provides extensive, clear explanations for each parameter, including types, constraints, examples, and links. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a Google Analytics Data API report, with specific verb and resource. However, it does not explicitly distinguish from sibling tools like run_funnel_report or run_realtime_report, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description focuses on parameter details and examples but does not provide selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits disclosed beyond being a read operation. With no annotations, the description fails to mention any side effects, permissions, rate limits, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The main purpose is front-loaded, and the parameter clarification follows efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description explains the parameter format but omits return structure details. Given no output schema, more context on expected response would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds format guidance for property_id (number or 'properties/' prefix), which the schema lacks. This compensates for 0% schema coverage, though only one parameter is detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Returns the property's custom dimensions and metrics.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_account_summaries or run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states what it does without providing context about typical use cases or when to prefer it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes a read operation (returns a list) but does not mention side effects, authentication requirements, rate limits, pagination behavior, or any limitation on the number of links returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence immediately states the purpose, and the second addresses the parameter format. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameter format adequately, but fails to describe the return value structure (e.g., what fields are in each link object) or any pagination/limits. Given no output schema, the description should provide more to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type info (integer or string) for property_id with 0% coverage. The description adds crucial format details: accepted formats are a number or a string 'properties/' followed by a number. This adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Returns a list of links to Google Ads accounts for a property' which specifies the verb (returns), object (list of links), and resource (Google Ads accounts for a property). It distinguishes this tool from siblings like get_account_summaries and run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_account_summaries or other list tools. It does not mention prerequisites, connected Google Ads accounts, or cases where the tool is applicable or inapplicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits beyond returning annotations. Missing details on pagination, permissions, or side effects. The description minimally adds 'returns annotations' without depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is five sentences, front-loaded with core purpose. Could be slightly more concise, but no unnecessary content. Structured with a clear separation between purpose, usage context, and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema provided, but the description does not explain what the returned annotations contain (e.g., fields, pagination). Only states 'returns annotations', leaving the response structure undefined. Insufficient for an agent to fully understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning to the single parameter 'property_id' by specifying accepted formats (number or string with 'properties/' prefix). This compensates for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Returns annotations for a property' and explains what annotations are used for. Differentiates from sibling tools like get_property_details or run_report which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context about when annotations are typically used (recording service releases, marketing campaigns, etc.), implying its use case. Does not explicitly state when not to use or alternatives, but the tool is the only one for annotations, making selection straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses potential exceptions (ValueError, Exception), return structure, and parameter behaviors. It does not mention authentication requirements or rate limits, but it provides substantial behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections for each parameter, examples, and external links. Every section adds value, but could be slightly more concise. It is front-loaded with the purpose and then organizes hints logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 7 parameters, no output schema, and nested objects, the description is highly complete. It covers all parameters with detailed examples, explains return values (funnel_table, funnel_visualization, property_quota), and includes links to external guides. It fully compensates for missing schema descriptions and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds extensive meaning for all 7 parameters with examples, formatting hints, and links. For instance, it explains 'funnel_steps' as lists of dictionaries with required keys, 'date_ranges' with multiple example formats, and 'funnel_breakdown' with JSON structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a Google Analytics Data API funnel report, with specific verb and resource. It distinguishes from sibling tools like 'run_report' and 'run_conversions_report' by focusing on funnel analysis and providing extensive details on funnel-specific parameters such as funnel_steps, funnel_breakdown, and funnel_next_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly distinguishes when to use this tool (funnel reports) versus siblings like 'run_report' (standard reports), but does not explicitly state when not to use it or provide alternatives. It gives clear context and examples for parameter usage, including links to external documentation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the full burden of behavioral disclosure. It meticulously covers parameter formats, constraints (e.g., dimensions must be realtime, no custom metrics), pagination via limit/offset, and complex interactions between dimension and metric filters (including limitations and workarounds). This fully informs the agent of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and code blocks, making it navigable. The one-line summary at the top provides immediate purpose. However, it is verbose, with repeated notes on filter independence appearing twice. Some conciseness could be gained without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, no output schema, no annotations), the description is remarkably complete. It covers all parameter details, provides examples for complex objects, explains limitations, and advises on workarounds for unsupported filter combinations. The agent has sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. It does so thoroughly: each parameter has format info, constraints, and often examples (e.g., dimension_filter, metric_filter, order_bys with 5-7 concrete examples each). It also provides hints for dimensions and metrics, linking to external schemas and custom dimension retrieval. This adds rich semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states 'Runs a Google Analytics Data API realtime report,' specifying the verb, resource, and context. It distinguishes from siblings by focusing on 'realtime' reports, which are separate from the standard 'run_report' tool. The description also references a distinct API endpoint URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool over siblings like 'run_report' or 'run_conversions_report'. It does not mention that realtime reports are for current data with limited lookback, nor does it direct users to other tools for historical data. The usage context is implied but not directly compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses API behavior: dimension and metric filters are applied independently, and explains limitations and workarounds for complex filter combinations. Also mentions quota management.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: purpose sentence, usage guidelines, args, hints with examples. Front-loaded with key info. Slightly verbose but justified by tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, nested objects, no output schema, and no annotations, the description covers all major aspects: allowed values, filter limitations, workarounds, quota advice, and documentation links. Thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates fully with detailed hints for each parameter: allowed dimensions/metrics lists, conversion_spec format, date range examples, filter and order by examples. Adds significant semantic meaning beyond schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a Google Analytics Data API conversions report. It explicitly distinguishes from sibling tool 'run_report' by listing specific use cases like conversions, ad performance, ROAS, and attribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use conditions and names the alternative tool 'run_report'. Includes extensive hints, examples, and workarounds for complex filters, making it clear when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![google-analytics-mcp MCP server](https://glama.ai/mcp/servers/googleanalytics/google-analytics-mcp/badges/card.svg)](https://glama.ai/mcp/servers/googleanalytics/google-analytics-mcp)

Score Badge

Copy to your README.md:

[![google-analytics-mcp MCP server](https://glama.ai/mcp/servers/googleanalytics/google-analytics-mcp/badges/score.svg)](https://glama.ai/mcp/servers/googleanalytics/google-analytics-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/googleanalytics/google-analytics-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server