MCP Google Analytics Server

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Each tool targets a distinct resource or action: specific send_* tools cover different standard event types (signup, purchase, login, etc.), while run_* tools clearly differentiate report types (standard, realtime, pivot, funnel, batch). get_*, list_*, and validate_* have unique purposes with no overlap.
Naming Consistency5/5
All tool names follow a strict ga_verb_noun pattern in snake_case. Verbs are consistently used: get for single items, list for collections, run for reports, send for events, and validate for checking. The naming is predictable and uniform.
Tool Count4/5
At 18 tools, this is slightly above the ideal 3-15 range but each tool has a clearly defined role. The breadth is justified by the server's dual purpose of event sending and report analysis, though the many send_* event-specific tools could be seen as redundant with ga_send_event.
Completeness5/5
The server covers the full analytics workflow: discovering accounts/properties/streams, sending both custom and standard events, validating events, running various report types (standard, realtime, pivot, funnel, batch), and retrieving metadata. No obvious dead ends or missing core operations for its stated purpose.
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description corroborates with 'Get details'. The description adds the 'configured' qualifier, implying a specific pre-set property, but does not disclose additional behavioral traits such as return format, auth requirements, or side effects. Given the annotation covers the read-only nature, this is adequate but not rich.
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 of eight words, immediately front-loaded with the action and resource. Every word contributes to the meaning, with no filler or redundancy. This is exemplary 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?
For a zero-parameter, read-only getter, the description sufficiently conveys the tool's purpose and scope. No output schema exists, but the description does not need to detail return values for such a simple tool. Sibling tools are not addressed, but the low complexity means the description is essentially 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 input schema has zero parameters, and schema description coverage is 100% (vacuously). No parameter documentation is needed. The description adds no param-specific meaning, but with 0 params, a baseline score of 4 is appropriate.
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 a specific verb ('Get') and resource ('details about the configured GA4 property'), clearly indicating the tool retrieves information about a specific property. However, it does not explicitly contrast with sibling tools like ga_list_properties or ga_get_metadata, so it lacks explicit sibling differentiation.
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 ga_list_properties (for listing properties) or ga_get_metadata (for metadata). No context, prerequisites, or exclusions are mentioned, leaving the agent without clear decision-making support.
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?
The annotations already declare readOnlyHint=true, so the tool is known to be safe. The description adds a token consumption warning and default limit context, which is useful operational behavior. However, it does not describe response format, pagination behavior, or error conditions, leaving gaps beyond what annotations provide.
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 concise and front-loaded. The token warning is important operational guidance, and the common dimensions/metrics list is compact and immediately useful. Every line contributes value without unnecessary filler.
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?
With 8 parameters and no output schema, the description could do more to explain what the response contains or when to use this over sibling report tools. It does address token usage and provides common field examples, but lacks explicit return-value semantics and usage exclusions. Overall, it is adequate but incomplete for a complex reporting tool.
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 provides 100% parameter coverage with descriptions, so the baseline is 3. The description adds value by listing common dimension and metric names (e.g., date, city, activeUsers, sessions) that help agents construct valid parameter values beyond the schema's generic examples.
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 the tool runs a custom Google Analytics report with dimensions and metrics. However, it does not explicitly differentiate from sibling tools like ga_run_realtime_report, ga_run_pivot_report, or ga_run_funnel_report, so it is clear but not fully distinguishing.
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 implies usage for custom reports by listing common dimensions and metrics, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or preferances among the sibling report tools. Token optimization advice is present but not tied to specific alternative selection.
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?
The annotation readOnlyHint=false already indicates this is a mutation, and the description does not add significant behavioral context beyond that. It doesn't mention return values, side effects, or requirements. With no output schema, the description carries full burden but only restates the purpose.
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 concise sentences. The first sentence states the action, and the second adds useful context about the event type. No wasted words.
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 send-event tool with no output schema, the description is adequately clear about the purpose but lacks details on expected behavior, return values, or prerequisites. Sibling tools like ga_send_event could be confused without explicit differentiation. Given the schema covers most parameters, this is acceptable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 75% of parameters with descriptions, and the description adds minimal meaning by referencing 'authentication method,' which aligns with the 'method' parameter. It doesn't clarify relationships between parameters or the optional client_id, so it provides only marginal value beyond 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 the tool's function ('Send a login event to Google Analytics') and specifies the event type, distinguishing it from siblings like ga_send_signup or ga_send_purchase. It uses a specific verb and resource.
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?
It provides clear context by stating it is the 'standard event for tracking user logins,' which tells when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks explicit exclusion guidance.
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?
The description says this is an ecommerce tracking event, which aligns with the annotations (readOnlyHint=false, since it sends data). It adds some context by clarifying the event is for tracking, but does not disclose additional behavioral traits such as delivery semantics, idempotency, or how the event maps to Analytics.
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 short, front-loaded sentences convey the core purpose and use case without any filler. Every phrase earns its place.
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?
For a simple event-sending tool with a detailed input schema, the description captures the essential context. It lacks mention of response behavior or caveats about the openWorldHint annotation, but these are minor for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific explanations. The input schema covers descriptions for currency, value, items, and user_properties, but leaves client_id and user_id undocumented. With 67% schema coverage, the description should compensate for the missing parameter semantics but does not.
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 opens with a specific verb and resource: 'Send an add to cart event to Google Analytics.' It clearly identifies the tool's purpose and differentiates it from sibling ecommerce events like ga_send_purchase and ga_send_begin_checkout.
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 second sentence, 'Ecommerce event for tracking when items are added to shopping cart,' clearly states the trigger condition for using this tool. It does not explicitly exclude alternatives, but gives enough context for when this event is appropriate.
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?
The description adds the behavioral detail 'Automatically uses page_view event name', which is not in annotations. It also aligns with readOnlyHint=false as a write operation, but does not disclose other side effects such as property prerequisites or error behavior.
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, with the primary action front-loaded and no fluff. Every word contributes to understanding the tool's purpose and behavior.
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 is adequate for a simple pageview event sender, covering the core action and the automatic event name. However, it omits any mention of return values or required property configuration, which would be useful given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all 6 parameters, achieving 100% coverage. The tool description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.
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 'Send a page view event to Google Analytics' and 'Standard event for tracking page/screen views', which both identifies the action and differentiates it from sibling tools like ga_send_purchase or ga_send_signup.
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?
It gives clear context that this is the standard tool for page/screen views, which is useful for selecting it among the sibling send tools. However, it does not explicitly state exclusions or name alternative tools for non-pageview events.
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?
Annotations already declare readOnlyHint=false, indicating a write operation. The description adds no further behavioral context such as authentication needs, rate limits, or side effects. It does not contradict annotations, but it also does not go beyond them.
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 short sentences, front-loaded with the primary action. Every word contributes to clarifying the tool's purpose and usage. No redundant or extraneous 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?
For a simple tracking event, the description is adequate, but it omits details like whether user_id is required (it is not, but this is not clarified) and gives no explanation of client_id. There is no output schema, so return value is unmentioned. The minimalism is acceptable but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with method, user_id, and user_properties described. The description itself does not explain any parameters. The missing client_id description remains unaddressed, but the schema provides enough for most parameters. Baseline 3 is appropriate given partial schema coverage.
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 uses a specific verb ('Send') and resource ('a sign-up event to Google Analytics'), clearly distinguishing it from siblings like ga_send_login and ga_send_purchase. It states exactly what the tool does without ambiguity.
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 states that this is the 'Standard event for tracking new user registrations,' which clearly implies when to use it. While it does not explicitly name alternatives or exclusions, the context is sufficient for an agent to choose it over other event-sending tools.
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?
The annotation readOnlyHint=true already establishes the tool is read-only. The description adds valuable behavioral context about potential huge output size and token optimization, warning about limits. This goes beyond the annotation by flagging performance implications, which is helpful for an AI agent to make safe and efficient calls.
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: one main sentence plus a focused warning. It front-loads the core purpose and adds a single high-value caution about token usage. Every sentence earns its place, with no fluff or repetition of schema details.
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?
This is a moderately complex tool with 4 parameters, no output schema, and sparse schema descriptions. The description covers purpose and a key performance warning, but does not explain the pivots/dimensions relationship, expected return shape, or how to structure date ranges beyond what the schema provides. It is minimally viable but leaves significant gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description does little to clarify the parameters. It mentions 'row and column dimensions' but does not explain that 'pivots' and 'dimensions' are distinct structures, nor does it describe how metrics or dateRanges behave. The token-optimization note mentions 'Limit dimensions' but offers no concrete parameter syntax or usage examples, leaving the agent under-informed about the main input fields.
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 a specific action: 'Run a pivot table report with row and column dimensions.' This distinguishes it from sibling tools like ga_run_report (standard reports) and ga_run_funnel_report by emphasizing the pivot/crosstab nature. The verb 'Run' and resource 'pivot table report' are specific and unambiguous.
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 provides clear usage context: 'Recommended for analysis, not raw data extraction' and advises limiting dimensions/date ranges due to token consumption. This implicitly tells the agent when to use this tool (analysis) and when not to (raw extraction), though it does not explicitly name an alternative tool. The guidance is practical and actionable.
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?
Annotations already indicate readOnlyHint=false and openWorldHint=true, signaling side effects. The description adds that it's an ecommerce event but discloses no additional behavioral traits like auth requirements or rate limits. It does not contradict annotations.
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, front-loaded with the primary purpose, no fluff. Every word contributes to understanding the tool's function.
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?
For an event-sending tool with nested objects and no output schema, the description adequately covers the main purpose. It doesn't explain return values, but none are expected for a send operation. It could mention prerequisites like needing a GA property context, but that may be handled at a different level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71%, which is moderate. The description itself adds no parameter-specific meaning beyond what the schema provides (e.g., 'Total value of cart', 'Items in checkout'). It neither compensates for the undocumented user_id/client_id nor adds extra semantics.
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 states a specific verb and resource: 'Send a begin checkout event to Google Analytics.' It clearly distinguishes this tool from siblings like ga_send_purchase and ga_send_add_to_cart by naming the exact event type.
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?
It provides clear context: 'Ecommerce event for tracking when users start the checkout process.' This implies when to use it, though it does not explicitly mention alternatives or exclusions. The context is sufficient given the sibling tool names.
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?
Annotations already indicate a write operation via readOnlyHint=false. The description adds that it sends data externally to Google Analytics, which is useful but largely redundant with the tool name and sibling context. No additional behavioral caveats like auth needs, deduplication, or rate limits are disclosed.
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 concise sentences, front-loaded with the primary action. Every word adds value, and it does not restate schema information.
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?
The tool has 11 parameters and nested objects, but the schema is rich with descriptions. The description clearly defines the event purpose and when it should fire, which is sufficient for a competent agent given the sibling tools and schema context. It could mention duplicate protection or user identification but is not lacking enough to drop below 4.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 82%, so the schema already documents most parameters. The description only generically mentions 'transaction details and items' without adding specifics about required fields or nested item structure, so it doesn't compensate for the remaining undocumented parameters.
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 sends an ecommerce purchase event to Google Analytics, specifically for tracking completed purchases. This distinguishes it from sibling tools like ga_send_event, ga_send_begin_checkout, and ga_send_add_to_cart.
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?
It provides clear context that this is for completed purchases with transaction details and items, implying use at purchase completion. It doesn't explicitly name alternative tools for other funnel stages, but the 'completed purchases' wording offers sufficient guidance.
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?
The readOnlyHint annotation already signals a safe read operation. The description adds valuable context by explaining it uses GA4's debug endpoint, does not record the event, and returns validation messages and errors. This goes beyond the annotation and helps the agent understand side effects and return behavior, though it doesn't cover all details like rate limits or authentication.
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, front-loaded with the primary purpose, and each sentence adds distinct value. There is no redundant information or filler, making it extremely concise and well-structured.
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 nested objects and four parameters, the description gives a high-level purpose and return behavior, but lacks context on prerequisites (e.g., having a GA4 property configured), parameter usage, and edge cases. It is adequate for a simple validation tool but leaves gaps for an agent unfamiliar with GA4 specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%), and the description does not compensate by explaining parameters like user_id, client_id, or the structure of events beyond what the schema provides. The description only mentions 'an event' generically, leaving several parameters undocumented in both the schema and description, making it hard to invoke correctly.
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 the tool validates an event before sending it to Google Analytics, using a specific verb ('validate') and resource ('event'). It also distinguishes itself from sibling send tools by explicitly noting it does not record the event, making its purpose unambiguous.
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 gives clear context: use this before sending an event, to check for errors. It implies the tool is for pre-send validation, which differentiates it from send tools, but it does not explicitly name alternatives or state when not to use it. The guidance is useful but not exhaustive.
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?
Annotations already provide readOnlyHint=true, so safety is covered. The description adds meaningful behavioral context: each step matches an event, eventName defaults to the step name, and filterExpression overrides eventName. This goes beyond the schema and annotations, though it doesn't discuss topics like auth or rate limits.
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 three concise sentences, front-loaded with the purpose, and every sentence provides necessary detail. No redundant or filler content.
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 nested schema and no output schema, the description covers the trickiest part (event matching logic) well. However, it omits any mention of funnelBreakdown or funnelVisualizationType, though these are optional and already described in the schema.
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 coverage is about 50%, and the description compensates by clarifying key parameter semantics: 'set eventName per step (defaults to the step name)' and 'pass a full filterExpression instead' (overrides eventName). This adds real value beyond the schema descriptions.
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 'Run a funnel analysis report to track user progression through steps', with a specific verb and resource. It distinguishes itself from sibling report tools (ga_run_report, ga_run_pivot_report) by focusing on funnel analysis.
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?
Usage context is implied through the term 'funnel analysis report' but there is no explicit comparison to alternative report tools or exclusions. The description does not say when to use this instead of ga_run_report or ga_run_pivot_report.
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?
Annotations already signal mutation (readOnlyHint=false) and external side effects (openWorldHint=true). The description adds valuable behavioral details: asynchronous processing and reporting delay ('appear in reports within minutes'). It does not disclose failure modes or rate limits, but given annotation coverage, this is sufficient.
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 three short, focused sentences. The first sentence states the core purpose, the second provides usage context, and the third lists common event examples. Every sentence earns its place with no redundant filler.
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?
For a tool with 4 parameters, nested objects, and no output schema, the description covers key context: purpose, usage, async behavior, and typical event names. Missing explicit return-value expectations (e.g., 2xx acknowledgment) and any caveats about data limits, but the description is largely complete for a fire-and-forget event sender.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like events, user_id, client_id, and user_properties. The description adds a few example event names (`click`, `form_submit`, `video_play`), but these are illustrative rather than enriching parameter semantics beyond the schema. Baseline 3 is appropriate.
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 opens with a specific verb and resource: 'Send a custom event to Google Analytics via Measurement Protocol.' This clearly distinguishes it from sibling tools that handle specific event types (e.g., ga_send_purchase, ga_send_signup) by emphasizing 'custom' and 'any GA4 event.'
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 gives clear usage context: 'Use this for tracking custom user actions, conversions, or any GA4 event.' It implies this is the generic fallback compared to specialized siblings, though it doesn't explicitly say 'use dedicated tools when available.' This is strong guidance but lacks an explicit 'when not to use' exclusion.
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?
The readOnlyHint annotation already declares this is a safe read operation, lowering the bar for the description. The description adds the scoping detail 'accessible to the service account' but does not disclose additional behavioral traits such as pagination or return format, which is acceptable given the tool's simplicity.
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 short sentences, each adding value. The main action is front-loaded, and the usage guidance is concise without redundancy.
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?
For a simple list tool with no parameters and no output schema, the description provides complete context: what it does, its scope, and how it fits into the larger workflow. No additional information is needed.
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?
With zero parameters, the schema already fully covers parameter semantics. The instruction states a baseline of 4 for 0-param tools, and the description adds no unnecessary parameter details.
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 the tool lists all Google Analytics accounts accessible to the service account. This specific verb+resource combination distinguishes it from sibling tools like ga_list_properties, which list properties rather than accounts.
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 explicitly states when to use this tool: 'Use this to find account IDs for listing properties.' This gives clear context for its role in the workflow, though it does not name alternatives or exclusion criteria.
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?
Annotations already declare readOnlyHint=true, and the description's 'List' action is consistent. The description adds the context of being for the configured GA4 property, but does not disclose additional behaviors like whether results are paginated or what fields are returned. With annotations covering the safety profile, this is adequate but not rich.
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: two sentences with no filler. It front-loads the core purpose first and then adds the key use case. Every word earns its place.
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?
For a simple parameterless tool with a read-only hint, the description is complete. It explains what the tool does and why to use it. No output schema exists, but the description does not need to detail return values for such a straightforward listing operation.
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 tool has zero parameters, so the schema covers everything by definition. The description does not need to add parameter meaning, and the baseline of 4 is appropriate for parameterless tools.
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 the tool lists data streams for the configured GA4 property, using a specific verb and resource. It distinguishes itself from sibling tools like ga_list_properties and ga_list_accounts by focusing on data streams specifically.
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?
It provides a clear use case: 'find measurement IDs for Measurement Protocol.' This implies when to use it, though it does not explicitly mention alternatives or when not to use it. Still, the context is clear and helpful.
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?
The readOnlyHint annotation already establishes the read-only nature. The description adds valuable behavioral context: the time window (last 30 minutes) and the default result limit, which helps the agent anticipate response size. It does not disclose rate limits or authentication prerequisites, but the annotation covers safety and the added context is sufficient for a read-only tool.
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 concise and front-loaded: the first line states the purpose. The token optimization warning and common dimensions/metrics are tightly packed into a few lines, with no filler. Every sentence earns its place, and the use of a warning emoji draws attention to an important cost-saving measure.
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 provides enough information for a simple report tool: purpose, time window, common parameters, and size control. However, there is no output schema, and the description does not explicitly describe the response format (e.g., rows of dimension/metric values). While an agent can infer the return structure, the lack of explicit return-type guidance leaves a gap.
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?
With 100% schema description coverage, the baseline is 3. The description adds value by listing common dimensions (city, country, deviceCategory, unifiedScreenName) and metrics (activeUsers, screenPageViews, conversions), which are not present in the schema and greatly aid the agent in constructing valid parameter values.
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 the tool's function with a specific verb ('Get') and resource ('real-time Google Analytics data'), and narrows the scope to 'last 30 minutes,' distinguishing it from historical report tools like ga_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool (for recent real-time data) and includes a token optimization tip about using 'limit' to control result size. It doesn't explicitly name alternative tools for historical data, but the 'last 30 minutes' scoping provides contrast with ga_run_report and similar siblings.
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?
The readOnlyHint annotation already indicates a safe read operation. The description adds valuable behavioral context beyond the annotation by warning of potential large data returns and giving limits to mitigate token usage. This is a specific and useful disclosure about performance characteristics, enhancing the agent's understanding of the tool's behavior.
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 exceptionally concise: two sentences plus a warning. The first sentence states the core purpose, and the second provides critical usage constraints. Every word earns its place, with no redundancy or filler. It is front-loaded with the main action and immediately follows with important warnings.
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?
For a simple tool with one parameter and no output schema, the description covers the necessary aspects: what it does, the format of the requests, and constraints on batching. It does not explicitly describe the return format, but given the lack of an output schema and the tool's simplicity, this is not a significant gap. The warning about large data partially covers the return expectations.
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 covers the parameter 'requests' with a description referencing ga_run_report, giving a baseline of 3. The description adds further semantics by specifying a practical limit of 2-5 reports and advising small limits for each report, which is valuable guidance beyond the schema. This enriches the parameter meaning and helps the agent construct appropriate requests.
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 the tool's function with a specific verb and resource: 'Run multiple reports in a single request.' This distinguishes it from sibling tools like ga_run_report, which runs a single report, and ga_run_batch_reports, though the name already implies batching. The warning about token optimization further clarifies the purpose as a batching mechanism for efficiency.
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 provides clear context for when to use this tool: 'Run multiple reports in a single request' and includes a practical constraint: 'Limit to 2-5 reports per batch.' It references the format of ga_run_report, implying it is a batch variant, but does not explicitly state when not to use it or name alternatives. The guidance is useful but could be more explicit about replacing multiple ga_run_report calls.
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?
readOnlyHint already indicates a safe read operation, and the description adds the non-obvious behavior of aggregating properties across all accounts when no accountId is given. It does not describe return format or pagination, but annotations reduce the burden.
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 short, focused sentences convey the purpose and the key filtering behavior. The main action is front-loaded and every sentence earns its place with no redundant detail.
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?
For a simple read-only list operation with one optional parameter and a readOnly annotation, the description sufficiently explains the core behavior and account-scoping logic. No output schema exists, but 'list' clearly implies a list of properties as the return value.
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 already fully documents accountId with an example, giving a 100% coverage baseline of 3. The description adds meaningful context by stating the consequence of omitting the parameter, which is behavior not captured in 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 opens with 'List Google Analytics properties', using a specific verb and resource that distinguishes it from sibling tools like ga_list_accounts and ga_list_data_streams. The optional account ID filter adds scoping detail.
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?
It clearly explains when to use the optional accountId and what happens without it (aggregates across all accessible accounts). However, it does not explicitly mention when not to use this tool or name alternatives, so it stops short of full 5.
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?
Annotations already declare readOnlyHint=true, so the description carries a lower burden. It adds a crucial behavioral disclosure: 'Response can be large (~500+ items). Use sparingly and cache results when possible.' This alerts the agent to response size and performance cost, beyond what the annotation provides.
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: the first states the purpose precisely, the second gives a necessary caution about response size. Every sentence earns its place; no redundancy or fluff.
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?
For a zero-parameter metadata retrieval tool with no output schema, the description fully covers its scope and a key behavioral caveat. An agent can correctly decide to invoke it and understand the response implications. No gaps.
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 tool has zero parameters, so description need not explain parameter semantics. Per the rubric, 0 params yields a baseline of 4.
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?
Description clearly states the tool retrieves dimensions and metrics metadata for a GA4 property. The verb 'Get' and resource 'dimensions and metrics metadata' are specific, and it is distinct from sibling tools like ga_run_report which query data rather than metadata.
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 implies the tool is used to discover available metadata before running reports. The warning 'Use sparingly and cache results when possible' provides clear operational context on when to call. However, it does not explicitly mention alternatives or when-not-to-use.
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:

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

Score Badge

Copy to your README.md:

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

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/leonardosepulvedat/mcp-google-analytics'

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