Skip to main content
Glama
Sign In
AdLoop: Google Ads, Reddit Ads & GA4

AdLoop: Google Ads, Reddit Ads & GA4

by kLOsk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Analytics realtime report

run_realtime_report
Read-only

Run a GA4 realtime report to see active users and events, then filter and compare recent minute windows to verify tracking fires correctly after code changes.

Instructions

Run a GA4 realtime report showing current active users and events.

Useful for checking if tracking is firing correctly after code changes: filter on the event that just shipped, or compare the last few minutes with the minutes before. Returns the dimension and metric headers and one row per dimension combination over the realtime window (the last 30 minutes unless minute_ranges says otherwise). When a filter matches nothing, insights[] lists the usual causes.

Google Analytics Data API: https://developers.google.com/analytics/devguides/reporting/data/v1 and Admin API: https://developers.google.com/analytics/devguides/config/admin/v1

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_realtime_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum rows; 0 uses GA4's default.
metricsNoGA4 realtime metric API names, e.g. activeUsers, eventCount, keyEvents. Defaults to ["activeUsers"].
order_byNo[{"field": <requested dimension or metric>, "desc": true}].
dimensionsNoGA4 realtime dimension API names, e.g. unifiedScreenName, eventName, country, deviceCategory, minutesAgo.
property_idNoGA4 property as "properties/123456789" (see get_account_summaries). If empty, uses the default from config.
metric_filterNoSame format as in run_ga4_report.
minute_rangesNoUp to two windows, e.g. [{"start_minutes_ago": 4, "end_minutes_ago": 0, "name": "last_5"}, {"start_minutes_ago": 29, "end_minutes_ago": 5, "name": "before"}]. start_minutes_ago is at most 29 on standard properties (59 on 360). With two windows rows carry a dateRange value with the window's name.
dimension_filterNoSame format as in run_ga4_report, e.g. [{"field": "eventName", "value": "purchase"}].

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.41.4
    • addedInput schema / properties / dimension_filter
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Same format as in run_ga4_report, e.g.\n[{\"field\": \"eventName\", \"value\": \"purchase\"}]."
+}
    • changedInput schema / properties / dimensions / description
      Previous value: -"GA4 realtime dimension API names, e.g. unifiedScreenName,\neventName, country, deviceCategory."New value: +"GA4 realtime dimension API names, e.g. unifiedScreenName,\neventName, country, deviceCategory, minutesAgo."
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 0,
+  "description": "Maximum rows; 0 uses GA4's default.",
+  "type": "integer"
+}
    • addedInput schema / properties / metric_filter
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Same format as in run_ga4_report."
+}
    • changedInput schema / properties / metrics / description
      Previous value: -"GA4 realtime metric API names, e.g. activeUsers, eventCount.\nDefaults to [\"activeUsers\"]."New value: +"GA4 realtime metric API names, e.g. activeUsers, eventCount,\nkeyEvents. Defaults to [\"activeUsers\"]."
    • addedInput schema / properties / minute_ranges
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Up to two windows, e.g. [{\"start_minutes_ago\": 4,\n\"end_minutes_ago\": 0, \"name\": \"last_5\"}, {\"start_minutes_ago\": 29,\n\"end_minutes_ago\": 5, \"name\": \"before\"}]. start_minutes_ago is at\nmost 29 on standard properties (59 on 360). With two windows rows\ncarry a dateRange value with the window's name."
+}
    • addedInput schema / properties / order_by
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "[{\"field\": <requested dimension or metric>, \"desc\": true}]."
+}
  2. Changed3 schema fields changedv0.27.1
    • addedInput schema / properties / dimensions / description
      Added value: +"GA4 realtime dimension API names, e.g. unifiedScreenName,\neventName, country, deviceCategory."
    • addedInput schema / properties / metrics / description
      Added value: +"GA4 realtime metric API names, e.g. activeUsers, eventCount.\nDefaults to [\"activeUsers\"]."
    • addedInput schema / properties / property_id / description
      Added value: +"GA4 property as \"properties/123456789\" (see\nget_account_summaries). If empty, uses the default from config."
  3. Addedv0.13.2
  4. Removedv0.13.0
  5. First observedv0.9.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: the default 30-minute window, the 29/59-minute ceiling on standard vs 360 properties, the row shape (headers plus one row per dimension combination), and the insights[] diagnostics when a filter matches nothing.

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 purpose is front-loaded in one sentence, followed by the usage scenario and then return shape, which is a sensible order. The trailing pair of developer-documentation URLs is marginal filler for an agent but not enough to undermine the structure.

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?

With an output schema present, the description need not specify return fields, yet it still sketches them, and it covers defaults, filters, and the empty-result diagnostic path. The only thin area is that filter format is delegated entirely to "Same format as in run_ga4_report" rather than described inline.

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 explains every parameter, including minute_ranges windows and the 29/59 limit. The description mostly restates what the schema says (window count, dateRange labeling) and adds no syntax or format detail beyond it, so baseline 3 applies.

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 first sentence states a specific verb and resource ("Run a GA4 realtime report showing current active users and events") and pinpoints the realtime window, which distinguishes it from the historical siblings like run_ga4_report. It never names that sibling explicitly, so differentiation relies on the agent inferring from "realtime" and "last 30 minutes".

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?

It gives a concrete trigger scenario — verifying tracking fires after code changes — and a concrete comparison pattern (filter on the just-shipped event, or compare recent minutes against earlier minutes). It does not state when to prefer this over run_ga4_report for historical analysis, so the exclusion side is left implicit.

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

Deploy Server

Other Tools