google-analytics-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools name a distinct GA4 resource and action, so core reporting/metadata/admin tools are easy to separate. However, several overlapping clusters remain—validate_query vs check_compatibility, the two funnel reporters, and the audience-diagnostics/export trio—which can cause misselection despite helpful descriptions.
Naming Consistency5/5
All 27 tools consistently use a ga4_ prefix with snake_case verb_noun names like list_properties, run_pivot_report, and get_audience_export_diagnostics. The prefix immediately identifies the server domain and the verb establishes intent, so names are highly predictable.
Tool Count3/5
27 tools is on the heavy side; the long line of one-off diagnostics and redundant funnel/report variants makes the set feel larger than necessary. Still, the GA4 surface covered is broad and most tools target a distinct endpoint, so the count is more borderline than clearly overblown.
Completeness4/5
For an intentionally read-only GA4 server, the core lifecycle is covered: discover accounts/properties, run core/realtime/pivot/funnel/batch reports, inspect metadata/custom definitions/events, and diagnose integrations. Minor gaps such as no direct data-stream getter and no account-level aggregation keep it from a perfect 5.
Average 3.7/5 across 27 of 27 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- 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?
There are no annotations, so the description carries the full burden of explaining behavior. It states only that the tool asks for compatibility, but does not describe the response format, how empty metric/dimension arrays are handled, whether the operation is read-only, or how compatibilityFilter affects results.
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 a single front-loaded sentence with no redundant wording. It could be slightly more direct if 'Ask' were replaced with 'Checks', but it is appropriately concise.
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?
For a tool with six parameters, nested filters, no annotations, and no output schema, this description is incomplete. It does not explain what the compatibility response looks like, how filters interact with the check, or what the compatibilityFilter enum values mean. An agent would need to inspect the API documentation to use it reliably.
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 50%, so the description should compensate, but it provides no parameter-specific guidance. The only parameter detail comes from the schema; metrics, dimensions, and compatibilityFilter are left unexplained in the description.
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 identifies the tool as a compatibility check against the official GA4 Data API for proposed Core report dimensions and metrics. It is specific enough to convey the action and resource, though it does not name or distinguish sibling tools such as ga4_validate_query.
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 phrase 'with a proposed Core report selection' implies the tool is used when an agent has candidate dimensions/metrics and needs to verify compatibility before building a report. However, it gives no explicit guidance on when to choose this over alternatives, and no when-not-to-use cases.
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?
With no annotations, the description carries the full behavioral burden. It states 'read-only', which is a genuine safety guarantee, and describes the scope of analysis. However, it does not disclose output format, pagination or limit behavior, or edge cases like missing or incomplete ecommerce events—especially relevant because there is no output 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?
One sentence with no filler, front-loading the read-only nature and core scope. It efficiently packs several meaningful elements—events, revenue metrics, item-level reporting, and date range—into a compact definition. Not verbose, though the phrase 'coverage diagnostics' remains somewhat abstract.
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?
For a diagnostic tool with no annotations and no output schema, the description omits the result shape and does not explain what the diagnostics will look like. It is sufficient to know that an ecommerce diagnostic is being requested, but not enough for the agent to fully anticipate the output or confidently select this tool over closely related diagnostic siblings.
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 schema describes propertyId, startDate, and endDate, but limit and datePreset are undocumented. The description only reinforces the date-range concept and adds no meaning for the undocumented parameters. It does not compensate for the 60% schema description coverage, leaving the agent uncertain about limit behavior and datePreset semantics.
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?
Names the exact resource and scope: 'ecommerce coverage diagnostics' for 'core ecommerce events, revenue metrics, and item-level reporting' over a date range. 'Read-only' also helps the agent understand the nature of the tool. It could more clearly define what 'coverage diagnostics' means, but it is specific enough to distinguish from other GA4 diagnostic tools.
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 ecommerce qualifier and listed coverage areas imply the intended use case, but the description does not explicitly say when to use this tool versus alternatives like audience, BigQuery export, or server-side tagging diagnostics. No named alternatives or exclusions are provided, so the agent must infer routing from sibling names and the description's domain.
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?
With no annotations, the description carries the transparency burden. It helps by disclosing the 'best-effort' nature of the results and that it uses 'metadata-aware Data API reports,' which signals potential incompleteness. However, it does not clarify read-only behavior, auth expectations, or what 'best-effort' means in practice.
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 front-loaded sentence with no filler. The core purpose and output are stated immediately, and every clause contributes meaningful information such as 'metadata-aware' and 'best-effort.'
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 output schema and no annotations, the description gives a reasonable but thin picture: a key-event inventory returning names and counts. It lacks detail on date-range behavior, limit semantics, and the practical implications of 'best-effort,' so it is minimally adequate but not complete.
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-level meaning beyond the schema. Schema coverage is 60% and the description does not explain how date range, datePreset, or limit affect the key-event inventory. The agent must rely entirely on the schema's limited descriptions and defaults.
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 and resource: 'Inventory GA4 key events/conversions' and states the return value ('best-effort event names and counts'). This clearly separates it from generic reporting tools like ga4_run_report, though it does not explicitly name a sibling or contrast itself with ga4_get_event_parameters.
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?
There is no guidance on when to use this tool versus alternative GA4 tools. The phrase 'Inventory GA4 key events/conversions' implies a listing use case, but there are no explicit when-to-use/when-not-to-use instructions or mentions of sibling tools.
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?
With no annotations, the description carries the transparency burden. 'Best-effort' and 'Documents Data API limitations for raw parameters' are genuinely useful behavioral caveats, and the source mix is disclosed. However, it does not state read-only safety, output behavior when no parameters are found, or any API/quota implications.
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 tight sentences: the first states the core result and source, the second states a key limitation. Every word earns its place and the most important qualifier is front-loaded.
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?
For a 6-parameter tool with no output schema and no annotations, this is thin. An agent still does not know the return shape, how eventNames or dates shape the inventory, or which sibling should be preferred in a given scenario. The best-effort caveat is valuable but insufficient.
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 description does not elaborate on any specific parameter's meaning or format. With 4 of 6 parameters already documented in the schema and datePreset/limit semantics reasonably encoded by defaults and enums, the description's lack of parameter detail is acceptable though not compensatory.
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 deliverable ('event parameter inventory') and its data sources ('GA4 metadata plus event reports'), and flags the best-effort nature. It distinguishes the tool's niche among GA4 siblings, though it does not explicitly name or contrast sibling tools.
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?
There is no explicit guidance about when to use this tool versus alternatives like ga4_get_custom_definitions or ga4_run_report. The 'best-effort' caveat implies use for reconnaissance rather than authoritative answers, but no when-to-use or when-not-to-use context is provided.
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, the description must carry the full behavioral burden. The word 'Read' signals non-mutation, but the tool's behavior beyond that—such as what happens when settings is empty, whether all settings are returned by default, authentication requirements, or rate-limit concerns—is undisclosed.
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, front-loaded sentence with no filler. It leads with the primary action and resource, then enumerates the optional settings precisely. Every phrase contributes information.
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 tool is simple with only two parameters, and the description conveys the core output concept ('property details plus selected settings'). However, with no output schema and no annotations, the agent is left without details about the response shape, default behavior when settings is omitted, or any usage caveats. It is minimally viable but has clear 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?
Schema description coverage is only 50%, so the description must compensate for the undocumented settings parameter. It does so by labeling these as 'selected singleton Admin settings' and mapping the enum values to human-readable categories. propertyId is already well described in the schema, and the description adds meaningful context to settings.
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 ('Read') and identifies a clear resource: GA4 property details plus selected singleton Admin settings. The explicit list of setting types (attribution, retention, Google Signals, reporting identity, user-provided-data) sharpens the purpose. It does not explicitly compare to sibling tools, so it stops short of a 5.
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 implies the tool is for reading configuration data but provides no explicit guidance on when to choose it over alternatives like ga4_list_admin_resources or the various diagnostics tools. There are no when-to-use or when-not-to-use conditions, so the agent is left to infer suitability.
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?
With no annotations provided, the description carries the behavioral disclosure burden. It does state that the operation is 'read-only,' which is a meaningful safety signal. However, it does not disclose pagination behavior, rate limits, access/auth assumptions behind 'allowlisted,' or any result-size limitations beyond what the schema implies.
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 a single, front-loaded sentence that opens with the verb, resource, and read-only nature before enumerating supported collections. The enumeration is long but useful, and no words are wasted, though it could arguably have pointed to the enum instead of repeating the list.
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 minimally viable for a list operation: it names the resource, covers the main collection categories, and the schema supplies required parameters. But with no annotations and no output schema, the absence of usage guidance, pagination/limitations, and clarity about 'allowlisted' leaves meaningful gaps for an agent deciding whether this is the right tool.
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 50%, with propertyId and includePersonalIdentifiers already documented in the schema. The description's prose list of collection types loosely mirrors the collection enum, adding mild categorization value, but it does not clarify pageSize usage or add meaning beyond what the enum and parameter defaults already provide.
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 ('List') with a clear resource ('allowlisted GA4 Admin collection') and enumerates the covered resource types, so an agent understands the tool's scope. It broadly distinguishes itself from sibling list/get tools by covering many admin collections at once, though it does not explicitly name or contrast a sibling.
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 implies when to use the tool—when listing one of the enumerated admin collections—but it gives no explicit guidance on when to prefer this generic lister over specialized siblings like ga4_get_custom_definitions or ga4_get_key_events. There are no exclusions, prerequisites, or alternative-selection 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?
The description provides useful behavioral context by labeling the operation 'Read-only' and by noting the fallback to 'observed audienceName report fallback.' With no annotations, however, it does not disclose potential auth requirements, rate limits, or failure shapes, so the behavioral picture is incomplete.
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 a single, efficient sentence that front-loads the read-only nature and the diagnostic scope. It avoids fluff while communicating the key data sources and fallback behavior.
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?
With no output schema and no annotations, the one-sentence description is not enough for a 7-parameter tool. It does not explain what the diagnostics contain, how the three sources relate, or what the consumer should expect in the response, leaving significant gaps for an agent deciding whether the tool fits the task.
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?
Most parameters are already described in the schema, including date handling, propertyId, includeDefinitions, and recurringAudienceListName. The description adds high-level source context that maps to some parameters but does not clarify ambiguous ones like limit or how parameters interact across the data sources.
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 names the resource ('audience diagnostics') and identifies its data sources: Admin API audiences, Data API recurring audience lists, and observed audienceName fallback. It is specific enough to distinguish this from broader GA4 reporting tools, though it does not explicitly contrast it with the sibling audience export diagnostics tool.
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 word 'diagnostics' and the mention of audience sources imply this is for diagnosing audience-related issues, but there is no explicit guidance on when to choose it over siblings like ga4_get_audience_export_diagnostics or ga4_list_audience_exports. Usage context is suggested rather than stated.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the operation is read-only and that OAuth tokens are not exposed, which are important safety traits. However, it does not describe what happens on success/failure, what the response format is, or any side effects beyond verification. The disclosure of read-only and token safety is solid, but other behavioral details are absent.
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, concise sentence that front-loads the key purpose (read-only health check) and then elaborates on what it verifies. There is no redundancy or filler; every word adds value.
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 one optional parameter and no output schema, the description covers the core functionality but lacks important context: the response format (e.g., pass/fail, status details), error handling (e.g., what if credentials are invalid), and guidance on when to use this over specific diagnostics. The absence of output schema makes the return behavior ambiguous, and the lack of usage exclusions leaves the tool partially underspecified.
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 input schema covers 100% of the parameters, and the description adds no additional meaning to the propertyId parameter beyond what the schema already provides. Since the schema adequately documents the parameter, the description provides no incremental value for parameter understanding.
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 is a read-only health check that verifies credentials, accessible properties, and metadata/property access. The verb 'health check' is specific, and the scope is distinct from the sibling diagnostics, though it doesn't explicitly name a differentiating alternative. The mention of not exposing OAuth tokens further clarifies its purpose.
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 the many sibling diagnostic tools (e.g., ga4_get_property_quotas_snapshot, ga4_get_ecommerce_diagnostics). There is no indication of preferred use cases, prerequisites, or conditions where this tool should be avoided. The description leaves the agent to infer when a general health check 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?
With no annotations, the description carries the transparency burden. It usefully discloses auto-pagination, supported metric/dimension counts, and request limits. However, it does not explain what 'intelligent query planning' actually does, how date parameters behave when omitted, or what permission or response-shape expectations exist.
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 three sentences and front-loads the core purpose first. It is compact and avoids unnecessary detail, though the phrase 'intelligent query planning' is somewhat vague and could be replaced with more concrete behavioral information.
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 selecting this tool, and the schema covers most parameters. However, for an 11-parameter tool with no annotations and no output schema, it omits important invocation context such as date range defaults, the interaction between autoPaginate, limit, and offset, and any constraints around propertyId or valid combinations.
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 already 73%, so the schema handles most parameter documentation. The description adds meaningful context beyond the schema by pointing to ga4://metrics and ga4://dimensions resources for valid field keys and by stating the maximum of 9 dimensions and 10 metrics per request, which directly helps the agent populate the metrics and dimensions arrays.
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 a clear action (run a GA4 analytics report) and identifies the resource area (GA4 metrics/dimensions). It also mentions distinctive capabilities like auto-pagination and field limits, but it does not explicitly differentiate this standard report tool from sibling tools like ga4_run_realtime_report or ga4_run_pivot_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 explicit guidance is given for when to use this tool versus its siblings. The description mentions using ga4://metrics and ga4://dimensions resources for available fields, but it does not say when to choose this over ga4_run_realtime_report, ga4_run_pivot_report, ga4_validate_query, or batch report tools.
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?
With no annotations provided, the description carries the full burden and does disclose important traits: the operation is read-only, reports are independent, and they are executed as one batch request. It does not address what happens on partial failure, per-report quota behavior, or how the batch response is ordered, which are meaningful for a batch endpoint.
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 dense, front-loaded sentence with no redundant wording. Every element — count, read-only nature, report type, property scope, and batch mechanism — earns its place.
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?
For a complex nested batch tool with no annotations and no output schema, a one-sentence description is thin. It omits usage routing, response shape/order, and batch failure semantics; only the fairly detailed input schema prevents this from being fully inadequate.
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 50%, and the top-level `reports` parameter has no description in the schema. The tool description adds that there are 1-5 independent GA4 Core reports for the same property, but it does not help an agent understand report object composition, required metrics, or the propertyId format beyond what the schema already states.
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 names a specific action ('Run'), a concrete resource ('GA4 Core reports'), and clear scoping ('1-5', 'same property', 'one official Data API batch request'). This clearly distinguishes it from single-report and pivot-report siblings without requiring the reader to open the schema.
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 count constraint '1-5' and the word 'batch' imply this is for bundling multiple independent reports, which gives useful context. However, it does not explicitly say when to prefer this over ga4_run_report or ga4_batch_run_pivot_reports, nor does it state exclusions.
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 must carry the behavioral disclosure burden. It does disclose a meaningful behavior—falling back to read-only step counts if the endpoint is unavailable—but it omits other useful behavioral details such as authentication requirements, rate limits, or what the response contains. The added value is positive but limited.
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 with no fluf: it leads with the action and endpoint, then adds the two distinguishing capabilities. Every phrase contributes meaning and nothing is wasted.
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?
For a tool with 13 parameters, a nested steps array, no annotations, and no output schema, the description is too thin. It does not explain return values, how to choose visualization types, what open funnel means, how limits behave, or how this compares to the simpler funnel tool. The schema provides some structure, but the overall context is not complete enough for an agent to reliably invoke the tool in the right scenario.
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 46%, and the description does not compensate for the undocumented parameters. It touches breakdownDimension, nextActionDimension, and fallbackToStepCounts via 'optional breakdown/next-action' and 'falling back to read-only step counts', but leaves limit, isOpenFunnel, breakdownLimit, nextActionLimit, visualizationType, and datePreset semantically unexplained 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 starts with a specific verb and resource: 'Run the GA4 Data API v1alpha runFunnelReport endpoint'. It also names differentiators like 'optional breakdown/next-action' and a fallback mode, which separates it from siblings such as ga4_run_report, ga4_run_pivot_report, and ga4_run_funnel_recipe.
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 intended use is implied from the endpoint name and 'advanced funnel report', and the fallback behavior gives some contextual guidance, but it does not explicitly state when to choose this tool over alternatives like ga4_run_report or ga4_run_funnel_recipe. No exclusions or alternative-routing conditions are provided.
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?
With no annotations, the description carries the full burden of disclosing behavior. It explicitly labels the operation 'Read-only' and says it lists metadata-exposed definitions, but it does not describe output shape, pagination, error behavior, or what 'fallback' means in practice.
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?
A single sentence front-loads the core action and resource, then adds the read-only fallback context. There is no filler or duplication of schema 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?
For a one-parameter read-only list tool, the description adequately states the input and what will be returned (custom dimensions and metrics). The main residual gap is explaining the 'fallback' behavior and any limitations of the metadata source.
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 100% and the only parameter, propertyId, already has a clear schema description including a numeric example. The description adds no additional parameter-level meaning, so the baseline of 3 applies.
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 names a specific verb ('List') and a distinct resource ('custom dimensions and custom metrics'), so an agent can distinguish it from generic metadata tooling such as ga4_get_metadata. The phrase 'Read-only fallback for custom definition inventory' is slightly ambiguous, which keeps this from a 5.
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 'Read-only fallback for custom definition inventory' phrase implies a fallback use case, but it does not explicitly state when to use this tool instead of ga4_get_metadata or an admin custom-definition endpoint. No exclusion or alternative is named.
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 exist, so the description carries the burden. It discloses two useful behavioral traits: the operation is read-only and realtime supports only a limited subset of dimensions and metrics. It does not mention auth requirements, quota behavior, or return shape, but the safety profile is at least covered.
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 dense sentences with no filler; the key scope and constraint are front-loaded. Every clause earns its place.
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?
For a 9-parameter tool with no annotations and no output schema, two sentences are thin: an agent still lacks guidance on return shape, data-recency window, and how quota or failure cases behave. The schema carries most parameter semantics, but the description alone is not enough to invoke this tool confidently.
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 78%, and the schema already documents most parameters with realtime-specific names and examples. The description adds a general caution that valid dimensions/metrics are limited, which is useful, but it does not enrich meaning for orderBys, filters, or minuteRanges.
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 specifies the action (run), the resource (read-only GA4 Data API realtime report), and the realtime scope, which distinguishes it from ga4_run_report and other report variants. The note about limited dimensions/metrics further pins down what kind of report this is.
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?
There is no explicit statement of when to pick this tool over ga4_run_report or batch/pivot variants. The limitation sentence implies this tool is only appropriate for realtime-compatible queries, but it does not name alternatives or give exclusion criteria.
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 description explicitly says 'Read-only', which is the key behavioral trait for an agent deciding whether invocation is safe. It also lists what operations will be performed. It does not discuss rate limits, pagination, or error behavior, but for a non-mutating diagnostic tool the disclosed behavior is largely 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 compact, front-loads the critical read-only qualifier, and enumerates the three operations in a single breath. Every clause adds meaningful information, with no redundant restatement of the tool name.
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?
With no output schema, the description still conveys what the caller will get: a list of exports, state counts, and optional row samples. It is somewhat light on details like how an existing export is selected for sampling or what 'state counts' contains, but for a read-only diagnostic of this complexity it is reasonably complete.
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 67%, and the description adds only one parameter-level insight: 'optionally samples rows' maps to includeRowSample. propertyId is already documented in the schema, while pageSize and sampleLimit have constraints but no descriptions in either the schema or the tool description. This matches the baseline for moderate schema coverage.
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 identifies the resource (Audience Export) and the specific operations: listing exports, reporting state counts, and optionally sampling rows. It does not explicitly distinguish itself from closely related sibling tools like ga4_list_audience_exports or ga4_query_audience_export, so it stops short of a 5.
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 word 'diagnostics' implies a troubleshooting/health-check use case, and the read-only framing suggests safe inspection. However, there is no explicit statement of when to use this tool versus overlapping siblings, nor any exclusions or alternative routing 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?
No annotations are provided, so the description carries the full burden. 'Detect' and 'diagnose' credibly communicate a non-mutating, read-only diagnostic operation, which is meaningful behavioral context. But it doesn't disclose what happens when no export link exists, whether BigQuery-side access is required, or what the result shape looks like.
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?
A single front-loaded sentence: the verb and resource come first, followed by a compact enumeration of the diagnosis targets. Every clause carries information, with no filler and no repetition of schema contents.
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 diagnostic tool with two fully documented parameters, the enumerated diagnosis dimensions give an agent a solid picture of scope and behavior. Minor gaps remain: no output schema exists to describe return values, and the no-export-link edge case is unaddressed, but the core selection-and-invocation context is well covered.
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 100% with both parameters already well documented, so the baseline is 3. The description's 'stream coverage' phrase loosely maps to includeDataStreams' comparison role, adding a light semantic link, but it does not materially extend the parameter documentation already present 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 names a specific verb-resource pairing: 'Detect GA4 BigQuery export links and diagnose...' and enumerates the exact diagnosis dimensions (export modes, stream coverage, excluded events, dataset location). The explicit 'BigQuery export' scope clearly separates it from sibling audience-diagnostics tools like ga4_get_audience_export_diagnostics and ga4_get_audience_diagnostics.
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: an agent can infer this is the tool for checking GA4 BigQuery export health and configuration, and the name scope differentiates it from audience-related diagnostics. However, the description never explicitly states when to use it, names no alternatives, and gives no exclusions or preconditions.
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?
With no annotations, the description carries the full burden of behavioral disclosure. 'List' clearly signals a read operation, but the description does not mention pagination behavior, auth requirements, or whether default channel groups are excluded. These are notable gaps for a listing 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?
A single concise sentence that front-loads the verb and resource. Every word earns its place; there is no redundancy or 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 simple one-parameter read-only listing tool, the description is largely complete: it states the action, resource, and property scope. The only missing context is output behavior such as pagination, but the low complexity keeps this from being a major gap.
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 100%, and the propertyId parameter is already described with type and example. The description adds no additional semantic detail about the parameter beyond associating it with a GA4 property.
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 ('List'), names a precise resource ('custom channel groups'), and scopes it to a GA4 property. This clearly distinguishes it from sibling tools like ga4_get_custom_definitions or ga4_get_metadata.
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 intended use is implied by the name and description, but there is no explicit guidance about when to choose this tool over alternatives or when not to use it. No exclusions or sibling comparisons are provided.
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?
With no annotations, the description carries the behavioral burden; it explicitly labels the call as 'read-only' and 'best-effort,' which tells an agent the operation is non-mutating and results may be incomplete. It does not go into error behavior or permissions, but the core side-effect profile is clear.
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 entire description is one compact, front-loaded sentence that wastes no words. Every phrase—'best-effort,' 'read-only,' and the list of data sources—adds meaningful information.
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 read-only diagnostic call, the description provides the essential subject and safety profile. However, with no output schema and no annotations, it leaves a moderate gap around return format, failure modes, and what specific diagnostic checks are performed.
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 input schema already documents all three parameters with 100% coverage, so the description does not need to repeat them. The mention of 'event rules' and 'stream settings' adds light context that maps to includeRules and includeSettings, but the description adds little 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 names a precise verb ('get diagnostics'), a specific resource ('server-side tagging'), and the data sources involved (data streams, Measurement Protocol secrets, event rules, stream settings). This clearly sets it apart from sibling diagnostics tools for ecommerce, audiences, BigQuery export, and the generic health check.
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 tool's purpose implies use when checking server-side tagging configuration, but the description never explicitly states when to choose it over ga4_health_check or the other diagnostics tools. No exclusions or alternative-routing guidance are provided.
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?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states the tool is read-only, auto-paginated, and scoped to authenticated user access, which are key behavioral traits. It stops short of describing response shape or potential limitations, but covers the most important safety and execution 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 a single, well-structured sentence with no filler. Key facts—action, resource, scope, read-only safety, and pagination—are front-loaded and each 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, single-parameter, read-only listing tool, the description plus schema is nearly sufficient to invoke correctly. It discloses authentication, safety, and pagination; the only real gap is the lack of an explicit response shape, which 'list' strongly implies and no output schema exists to confirm.
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 schema has one parameter, pageSize, with zero description coverage, and the description does not mention it directly. 'Auto-paginated' subtly hints at pagination, but the description fails to explain how pageSize affects behavior; it relies entirely on the parameter name and schema constraints.
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?
Uses a specific verb 'List' with the resource 'raw GA4 Analytics Admin accounts', clearly identifying the object and scope. The phrase 'accessible to the authenticated user' sharpens the definition and separates it from sibling tools like ga4_list_properties.
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 the usage context: call this when listing GA4 admin accounts for the current authenticated user. However, it offers no explicit guidance on when to prefer this over related tools such as ga4_list_properties or ga4_list_admin_resources, and it does not state when not to use it.
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?
With no annotations, the description carries the behavioral disclosure burden. It explicitly marks the operation as read-only, reveals that it executes one GA4 report per funnel step, and states that the result is simple step counts rather than a modeled funnel with conversion metrics. This is meaningful behavioral context beyond the schema, though it does not discuss rate limits 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?
A single front-loaded sentence covers safety, tool purpose, execution model, and output shape with no filler. Every phrase contributes information: 'read-only', 'configurable funnel recipe', 'one GA4 report per eventName/pagePath step', and 'simple step counts'.
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 schema supplies parameter detail well, and the description covers the core behavior and output in broad terms. However, there is no output schema and no explicit return structure, and the description does not clarify how step counts relate to each other (e.g., independent counts versus sequential drop-off) beyond the 'one report per step' hint. It is adequate but leaves some contextual 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level detail, but the schema already documents six parameters with types, defaults, enums, required markers, and descriptions for the main fields. At roughly 67% schema description coverage, the structured data carries most of the burden; the description's lack of parameter guidance is acceptable but not ideal.
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 a specific verb ('Run'), a specific resource ('a read-only configurable funnel recipe'), the mechanism ('one GA4 report per eventName/pagePath step'), and the output ('simple step counts'). This distinguishes it from generic reporting tools and even hints at the contrast with the advanced funnel sibling.
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 by the words 'read-only', 'configurable funnel recipe', and 'simple step counts', which suggests this is the simpler alternative to ga4_run_advanced_funnel_report. However, it never explicitly names when to use this tool versus the advanced funnel or standard report tools, and it gives no exclusion criteria.
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?
With no annotations, the description takes on the behavioral disclosure burden and does state that the operation is read-only, that every pivot requires an explicit limit, and that quota state is available. It could be more explicit about the response format, but the key safety and constraint signals are present.
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 dense sentence that front-loads the action and read-only nature, then packs the most important constraints and capabilities without filler. Every phrase contributes.
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 a complex nested schema and no output schema, the description does not state the return shape or explain what 'quota state' means in the response. It is adequate when paired with the schema, but an agent would still be guessing about the output format and about when to choose this over ga4_batch_run_pivot_reports.
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 only 50%, and the description summarizes capabilities (native filters, ordering, quota state, multiple date ranges) that mostly map to existing nested properties with no deeper explanation. It adds the 250,000-pivot-cell ceiling and the explicit-limit rule, but it does not clarify how the dense nested report object should be composed beyond what the schema already requires.
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—'Run a read-only GA4 Data API pivot report'—and calls out distinguishing features (pivots, filters, ordering, quota state, date ranges) that set it apart from sibling report tools like ga4_run_report and ga4_run_realtime_report.
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 clearly implies use when a pivot-style GA4 report is needed, but it provides no explicit when-to-use or when-not-to-use guidance against closely related siblings such as ga4_run_report, ga4_batch_run_pivot_reports, or ga4_run_realtime_report. The boundary is left to inference from the tool name.
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?
With no annotations provided, the description carries the behavioral burden. It clearly signals a non-executing validation operation and details the exact checks performed, including specific limit numbers. It does not describe return or error behavior on invalid combinations, but the core safety and non-mutating nature are conveyed.
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 dense sentences, with the primary purpose front-loaded and concrete rules following immediately. Every word adds value; no filler or repetition.
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 schema is simple and the validation rules are well summarized, but there is no output schema and the description does not explain what the tool returns or how invalid combinations are reported. This leaves a meaningful gap for an agent trying to interpret the result.
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 input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds useful context about limits (9 dimensions, 10 metrics) and compatibility rules, but does not add format-specific detail beyond what the schema provides.
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 identifies the action: validate a metric/dimension combination before execution. It also specifies concrete checks (max limits, ecommerce rules, compatibility), making the tool's purpose specific. However, it does not explicitly distinguish itself from the sibling ga4_check_compatibility, whose name suggests overlapping functionality.
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 phrase 'BEFORE executing' provides a clear usage context: run this tool prior to executing a report query. It does not, however, state exclusions or route to alternatives like ga4_check_compatibility, so it falls short of a fully explicit usage guide.
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?
With no annotations, the description carries the burden of safety disclosure; it explicitly advertises a non-mutating operation ('without creating new exports'). It stops short of describing pagination or response shape, so it is not a full behavioral profile.
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?
One tight, front-loaded sentence with no filler. The key scoping information ('existing', 'without creating new exports') is in the same clause as the main action.
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 list operation, the description plus schema provide enough to invoke it with just propertyId and optional paging/recurring flags. The absence of an output schema and an explicit pointer to query_audience_export leaves minor gaps, but nothing critical for a correct call.
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 documents propertyId and gives constraints for pageSize and includeRecurring, while the description's mention of snapshot and recurring lists modestly clarifies includeRecurring. It does not fully compensate for the low schema coverage, but the remaining parameters are conventional and inferable.
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 names a specific action ('List'), a precise resource ('GA4 Audience Export snapshots and Recurring Audience Lists'), and explicitly scopes it to existing items ('without creating new exports'). This clearly distinguishes it from any create/export sibling and from query-style tools.
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 the right time to use the tool: when you need to enumerate existing GA4 audience export definitions. It also rules out creation, but it does not name alternatives or state when to use ga4_query_audience_export instead, leaving some routing to inference.
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?
With no annotations, the description carries the full behavioral burden. It discloses a key behavior: user/device identifiers are redacted by default and require explicit opt-in. This adds meaningful context beyond the schema, though it does not mention pagination behavior or error conditions.
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 no filler. The primary action is front-loaded, and the important privacy-related opt-in behavior is stated concisely.
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 query tool with a clear parameter schema, the description covers the core purpose and a critical behavioral constraint. Minor gaps remain around response format and pagination semantics, but the essential information to invoke the tool correctly is present.
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 has low description coverage, and the description only adds contextual meaning for includePersonalIdentifiers by explaining the default redaction behavior. It does not elaborate on limit, offset, or audienceExportName, though the parameter names and pattern are reasonably self-explanatory.
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 action ('Query rows') on a specific resource ('existing GA4 Audience Export'), which clearly distinguishes it from sibling tools like listing exports or running diagnostics.
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 fetching row-level data from an audience export, but it does not explicitly state when to choose this tool over alternatives such as ga4_list_audience_exports or ga4_get_audience_export_diagnostics.
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 behavioral burden. It explicitly discloses that the operation is read-only, that reports are independent, that they must share a property, and that they execute as one official Data API batch request. This gives the agent a solid safety and scoping profile, though partial-failure behavior and response ordering are not mentioned.
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?
A single sentence that front-loads the verb, cardinality, read-only nature, resource type, property scope, and batching mechanism. Every phrase carries meaningful information and there is no 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 batch tool with a rich input schema, the description covers the key invocation context: how many reports, read-only safety, same property, and one batch request. It is slightly incomplete around what happens if one report fails and the shape of the batch response, especially given there is no output schema, but the core usage is clear enough for an agent to proceed.
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 documents propertyId and most nested fields such as dateRanges, filters, and cohortSpec. The description adds the cross-report constraint that all reports use the same property and reaffirms the 1–5 limit, but it does not explain how to construct a valid pivot report object or compensate for the undocumented 'reports' parameter beyond what the schema implies.
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 ('Run'), a precise resource ('GA4 pivot reports'), and clear constraints ('1-5', 'same property', 'one official Data API batch request'). This distinguishes it from the singular ga4_run_pivot_report and the non-pivot ga4_batch_run_reports without needing to open the schema.
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 when running multiple independent pivot reports against the same property in a single batch. It communicates the 1–5 cardinality and same-property constraint, but it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.
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 burden. It conveys a read-only retrieval action and the output scope (complete list of dimensions/metrics). It does not detail response structure or auth requirements, but for a simple metadata fetch this is acceptable.
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 states the core function, the second gives a practical use case. No redundant phrases or noise.
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 single-parameter read tool with no output schema, the description covers what it returns, the required scope, and a common use. It doesn't enumerate response fields, but that is not necessary for correct invocation.
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 100%, and propertyId already includes type and an example. The description adds only 'specific GA4 property,' which reinforces but does not meaningfully extend the schema. Baseline 3 applies.
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 (Get) and resource (complete list of dimensions and metrics) scoped to a specific GA4 property. This clearly distinguishes it from sibling tools like ga4_list_accounts or ga4_get_property_configuration.
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: use when you need the full dimension/metric catalog for a property and explicitly notes it's useful for discoverng custom dimensions and metrics. It does not mention alternatives or exclusions, so it doesn't reach a 5.
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 that this is a read-only listing operation and identifies which properties are included (those accessible with current credentials), plus the returned fields. However, it does not mention pagination, rate limits, result ordering, whether archived properties are included, 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 concise sentences with no filler. The first sentence front-loads purpose and scope; the second lists the return fields. Every sentence 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 zero-parameter, read-only listing tool with no output schema, the description is nearly complete: it states what the tool returns and what properties are included. The only minor gap is lack of information about pagination or result limits, but the core invocation is fully specified.
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 baseline is 4 and the description need not explain parameter behavior. There is no parameter information to add beyond the empty schema, and the description appropriately focuses on output and scope instead.
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 action ('List'), a specific resource ('GA4 properties'), and a clear scope ('accessible with the current credentials'). It also enumerates the returned fields, clearly distinguishing this property-listing tool from siblings that list accounts, admin resources, or audience exports.
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 makes the tool's context clear: call it to list all GA4 properties the credentials can access, with the expected return fields listed. It does not explicitly name alternative tools or exclusion criteria, but 'GA4 properties' and 'List all' provide solid guidance for selecting this tool over siblings.
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 carries the full burden. It discloses the non-obvious cost behavior: even though no report runs, one property-quota token is charged to the category with the most remaining quota. This is valuable, specific behavioral context beyond the basic read action.
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 core purpose, followed by a critical caveat. Every sentence earns its place with no fluff or repetition of schema 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?
For a single-parameter read tool, the description is nearly complete: it names the resource, endpoint, side effect, and non-report behavior. It omits details about the response shape, but that is partially forgiven because no output schema exists and the name suggests a snapshot structure.
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 100% and the single parameter already has a clear description ('Numeric GA4 property ID or properties/{id}'). The tool description adds no additional parameter-level detail, so the baseline 3 applies.
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?
States a specific verb ('read'), a precise resource ('current GA4 Data API property quota snapshot'), and the endpoint version. It also explicitly distinguishes itself from running a report, which differentiates it from the many report-oriented sibling tools.
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 use for checking quota state and explicitly says it does not run a report, an important exclusion that prevents misuse. It does not name an alternative tool or enumerate conditions, but the context is clear enough for an agent.
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-server MCP server](https://glama.ai/mcp/servers/getmcpads-com/google-analytics-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/getmcpads-com/google-analytics-mcp-server)

Score Badge

Copy to your README.md:

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

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/getmcpads-com/google-analytics-mcp-server'

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