Skip to main content
Glama

GA4 realtime report

ga_run_realtime_report
Read-onlyIdempotent

Run a real-time GA4 report for the last 30 minutes to monitor active users, page views, and events by country, device, screen, or event, with filtering and custom minute windows.

Instructions

Real-time (last 30 minutes) GA4 data. Dimensions: country, city, deviceCategory, unifiedScreenName, eventName, minutesAgo. Metrics: activeUsers, screenPageViews, eventCount, keyEvents. Rows are sorted by the first metric unless orderBy says otherwise.

Input Schema

NameRequiredDescriptionDefault
limitNo
metricsNo
orderByNoSort order. Defaults to first metric descending.
dimensionsNo
propertyIdYesGA4 property ID, e.g. '123456789' (see ga_list_properties).
filterLogicNoHow to join several dimensionFilters.and
minuteRangesNoWindows inside the last 30 minutes; default is the whole 30 minutes.
dimensionFiltersNoDimension filters, e.g. unifiedScreenName CONTAINS '/tours/'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.12.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so safety is covered. The description adds behavioral details beyond annotations, such as default sorting by the first metric unless orderBy overrides, and enumerates supported dimensions and metrics.

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?

Three sentences with no fluff. The main purpose is front-loaded, followed by allowed values and sorting behavior. Every sentence adds value.

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 read-only, idempotent tool with annotations covering safety, the description provides the key dimensions/metrics and default sort. No output schema exists, but the listed fields imply the return shape. The minuteRanges parameter is described in the schema, so nothing critical is missing.

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 63%, leaving some parameters undocumented. The description compensates by listing allowed dimension and metric values, which the schema does not provide as enums. It also reinforces the default sorting behavior mentioned in the orderBy description.

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 clearly states the tool retrieves real-time (last 30 minutes) GA4 data, lists the available dimensions and metrics, and notes default sorting. This distinguishes it from sibling GA tools like ga_run_report (historical) and ga_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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for real-time data via the 'Real-time (last 30 minutes)' qualifier, which contrasts with historical tools. However, it does not explicitly name alternatives or state when not to use it, leaving some inference required.

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