Loading ToolBench
Model Context Protocol (MCP) server for Google Analytics 4 (GA4) data and schema discovery via NPX. Spawns the Python package through uvx with full stdio passthrough.
The GA4 MCP server has 5 tools with generally sound naming (verb-first convention followed), but exhibits significant gaps in schema documentation and parameter descriptions. Tool descriptions are present but vary in specificity. Critical gaps: (1) Input schemas for several tools are incomplete or inferred rather than directly visible in source code. (2) Parameter descriptions are sparse or generic ('Search keyword' without format guidance). (3) Output schemas are not documented, LLMs cannot anticipate return structure. (4) Error handling is mentioned in descriptions but no concrete recovery guidance is provided in the tool definitions. The 'intent' parameter in get_ga4_data is unusual and poorly documented. The setup_ga4_access tool has an empty input schema, which is a red flag for interactive tools. Overall, the server provides functional tool definitions but lacks the precision and LLM-friendliness expected of production-grade tooling.
Query GA4 Data API with dimensions, metrics, filters, and date ranges. Validates field names against live schema. On invalid names returns why and how to find correct ones.
Get category-addressed troubleshooting guides for setup, IAM, schema, or other issues. Provides detailed fix instructions.
Search the GA4 property schema for dimensions and metrics by keyword. Returns exact valid field names for this property.
Search the GA4 analytical skills library for proven dimension/metric combinations, filters, and interpretation guidance. Fetches from GitHub.
Interactively fix a broken GA4 MCP setup (missing property ID, missing or expired credentials, or missing GA4 access) by asking the user for the needed input through the client, then re-initializing without a restart.
setup_ga4_access has an empty input schema ({}), violating the requirement that every tool parameter schema be documented. This signals incomplete tool registration.
No tool has a documented output schema. LLMs cannot infer what fields are returned by these tools, forcing them to guess downstream data structures and plan fragile chains. Output schemas must document the shape and type of each return field.
Parameter descriptions are sparse and generic. For example, 'dimension_filter' in get_ga4_data is typed as 'object' with description 'Optional dimension filter structure', no details on required fields, nesting, or filter syntax. 'keyword' in search_schema is just 'Search keyword...' with no guidance on case-sensitivity or regex support. This forces LLMs to guess at valid input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 42 | - | v1 |
get_troubleshooting_guide has an example-based topic parameter ('setup', 'iam', 'schema', or other categories') but does not declare topic as an enum. The phrase 'or other categories' signals the list is open-ended or incomplete. Enums prevent LLMs from hallucinating invalid values.
The 'intent' parameter in get_ga4_data is poorly documented ('Plain-English description of what you are trying to learn'). Its relationship to the structured dimensions/metrics/filters is unclear, is it optional? Is it used for validation or result shaping? This parameter seems redundant and causes LLM confusion.
Error handling guidance is mentioned in tool descriptions but not formalized. For example, get_ga4_data says 'On invalid names returns why and how to find correct ones', but no concrete error response structure is documented. Descriptions should state error scenarios and recovery steps clearly.
search_skills tool description mentions fetching from GitHub as operational detail. This is implementation leakage, users should not care where data comes from. Additionally, 'skills' is domain-specific jargon that may not be immediately clear to LLMs unfamiliar with GA4.
Date range parameters (date_range_start, date_range_end) accept both YYYY-MM-DD and relative formats (e.g. '28daysAgo', 'yesterday'), but this flexibility is documented only in descriptions, not enforced in schema. The schema should use a string type with a pattern or format constraint to guide LLM input.