Skip to main content
Glama
google-data-mcp

google-data-mcp

by seliem-attia

GA4: Change history

ga4_change_history
Read-only

Retrieve who changed what and when on a GA4 property, including UI changes and before/after states, to audit configuration history.

Instructions

Who changed what on the property and when (including in the GA4 UI), incl. state before/after. Times as RFC3339, e.g. '2026-09-01T00:00:00Z'. Further pages via pageToken.

Input Schema

NameRequiredDescriptionDefault
actionsNo
pageSizeNoDefault 25, max. 200
propertyYesGA4 property ID, e.g. '123456789' or 'properties/123456789'
pageTokenNo
actorEmailsNo
resourceTypesNoe.g. ['CUSTOM_DIMENSION','DATA_STREAM','DATA_RETENTION_SETTINGS']
latestChangeTimeNo
earliestChangeTimeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.1

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. Beyond that, the description usefully discloses the return content (who/what/when plus state before/after) and that changes made directly in the GA4 UI are captured, which matters for interpreting audit results. It also notes pagination via pageToken, though it omits the fact that GA4 change history is time-bounded and that pageSize defaults to 25.

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?

Three short sentences, with the core payload description front-loaded, then the time format, then pagination. No filler. The 'incl.'/'incl.' abbreviations and the parenthetical are slightly cryptic but the density is appropriate for an audit tool.

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 an 8-parameter tool with no output schema, the description covers what is returned in prose and the time format, but leaves filter semantics, retention window, and default/max page behaviour unexplained. An agent can call it, but may apply filters incorrectly or misinterpret empty results.

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 38% across 8 parameters, so the description has to compensate and it partly does: it supplies the RFC3339 format with an example for earliestChangeTime/latestChangeTime, which the schema leaves undocumented, and explains pageToken's continuation role. It says nothing about how actions, actorEmails, and resourceTypes filters combine (AND vs OR) or about their allowed values, leaving several undocumented parameters unexplained.

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 specific retrieval scope: who changed what on the GA4 property, when, plus before/after state. That distinguishes it from reporting tools like ga4_run_report and from ga4_list_annotations, though it never names an alternative explicitly. The 'who changed what ... and when' framing identifies the resource (change history) clearly enough to select correctly.

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 when-to-use or when-not guidance, and no mention of sibling tools such as ga4_list_annotations, which an agent could easily confuse with this audit-log tool. Usage is only implied by the phrase 'change history'. The '(including in the GA4 UI)' parenthetical hints at coverage scope but is not framed as a selection criterion.

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