google-analytics-mcp-server

Overview Schema Source Related Servers Discussions Admin

ga4 check compatibility

ga4_check_compatibility

Read-onlyIdempotent

Checks whether proposed GA4 Core report dimensions and metrics are compatible via the official Data API, preventing invalid report configurations.

Instructions

Ask the official GA4 Data API which dimensions and metrics are compatible with a proposed Core report selection.

Input Schema

TableJSON Schema

Name	Required	Description
`metrics`	No	Native or documented calculated metric names to request. Check compatibility with the selected dimensions.
`dimensions`	No	Native reporting dimensions. Validate compatibility with the selected metrics.
`propertyId`	Yes	Numeric GA4 property ID or properties/{id}.
`metricFilter`	No	Native GA4 FilterExpression JSON.
`dimensionFilter`	No	Native GA4 FilterExpression JSON.
`compatibilityFilter`	No	Limit compatibility results to the requested GA4 compatibility category.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Original tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv2.0.0Sep 30, 2026

addedInput schema / properties / compatibilityFilter / description

Added value: +"Limit compatibility results to the requested GA4 compatibility category."

addedInput schema / properties / dimensions / description

Added value: +"Native reporting dimensions. Validate compatibility with the selected metrics."

addedInput schema / properties / metrics / description

Added value: +"Native or documented calculated metric names to request. Check compatibility with the selected dimensions."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "result": {
+      "anyOf": [
+        {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        },
+        {
+          "items": {},
+          "type": "array"
+        },
+        {
+          "type": "string"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "boolean"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Original tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query."
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object"
+}

First observedv1.0.0Aug 29, 2026

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and this description does not contradict them. The description adds that the check targets the official GA4 Data API, but it does not reveal additional behavioral details such as rate-limit implications or the nature of the compatibility response beyond what the output schema and annotations would provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence that states the tool's purpose with no filler or repetition of schema fields. It is front-loaded with the core behavior and outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the strong annotations, complete parameter schema, and the existence of an output schema, the description is largely complete for the tool's complexity. It could be slightly richer by naming the related validation sibling, but nothing essential for calling it is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all six parameters, including dimensions, metrics, propertyId, filters, and compatibilityFilter. The description adds no extra semantic meaning beyond what the parameter descriptions already provide, placing this at the baseline score.

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 ('ask the official GA4 Data API') plus a precise outcome: checking which dimensions and metrics are compatible for a proposed Core report selection. It clearly differentiates this from siblings like ga4_run_report or ga4_validate_query by focusing on compatibility, not execution or validation.

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: use this tool to check whether dimensions and metrics are compatible before running a report. However, it never explicitly states when to prefer this over the closely related ga4_validate_query or other GA4 report validation tools, so usage guidance is adequate but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.