Google Analytics 4 by Get MCP Ads

ga4 run realtime report

ga4_run_realtime_report

Read-onlyIdempotent

Pull live GA4 data with the realtime report tool, querying recent user activity and events using supported dimensions and metrics.

Instructions

Run a read-only GA4 Data API realtime report. Realtime supports only a limited subset of dimensions and metrics.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum number of returned items or rows. The declared bounds and default apply; use pagination for additional results.
`metrics`	No	Realtime metric API names, e.g. activeUsers, eventCount
`orderBys`	No	Native GA4 OrderBy JSON.
`dimensions`	No	Realtime dimension API names, e.g. eventName, city, deviceCategory
`propertyId`	Yes	GA4 property ID (numeric, e.g., 123456789)
`metricFilter`	No	Native realtime-compatible GA4 FilterExpression JSON.
`minuteRanges`	No	Optional named realtime minute ranges; zero is the current minute.
`keepEmptyRows`	No	Keep provider rows whose selected metrics are all zero, where supported.
`dimensionFilter`	No	Native realtime-compatible GA4 FilterExpression JSON.

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.

First observedv2.0.1Sep 23, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds one useful behavioral constraint: realtime supports only a limited subset of dimensions and metrics. Beyond that, it does not describe timeout windows, validation behavior, or quota implications, but the annotation coverage lowers the burden.

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

Conciseness4/5

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

The description is short and front-loaded: the first sentence states the action, and the second adds a relevant limitation. There is minimal waste, though 'read-only' is somewhat redundant with the readOnlyHint annotation. It is concise and scannable, but a bit more actionable guidance would make it stronger.

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?

Given the rich input schema, output schema, and safety annotations, the description is minimally viable but not complete. It lacks explicit information about when realtime reporting is appropriate, how far back the data extends, and how this tool relates to ga4_run_report. The schema fills in parameter details, but the usage context remains thin.

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 parameter descriptions already document propertyId, metrics, dimensions, filters, minuteRanges, and other fields. The description adds general context that realtime dimensions and metrics are limited, but it does not add specific parameter-level meaning. Baseline 3 is appropriate because the schema carries the semantic load.

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 verb and resource: 'Run a read-only GA4 Data API realtime report.' It is clear that this tool executes realtime reports and is not a historical report tool. However, it does not explicitly contrast itself with sibling tools like ga4_run_report or ga4_run_pivot_report beyond the word 'realtime,' so differentiation is present but not fully spelled out.

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 says realtime supports only a limited subset of dimensions and metrics, which is a caution but not a usage guideline. It does not state when to choose this tool over ga4_run_report or when to avoid it, nor does it mention the realtime data timeframe. An agent must infer the intended use from the tool name alone.

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