SEO GSC Wizard MCP

GA4 realtime events

get_ga4_realtime_events

Read-only

Use this when the user wants to confirm that an event just fired, such as a test booking or purchase, or asks which events GA4 is receiving right now. Reads GA4 Realtime for the property linked to the site: eventName, eventCount and keyEvents for the last 30 minutes, sorted by eventCount, highest first (ties by eventName, A to Z). Events appear seconds after GA4 receives them. Pass eventName (e.g. purchase) to check one event. Not for conversions older than 30 minutes, revenue, pages or traffic sources: use get_ga4_key_events. These are unprocessed counts for the whole GA4 property, because Realtime cannot be narrowed to a hostname. When the property is linked to several sites on different hosts, sharedWithSites lists the others, and an account the site was shared with is refused. An empty result does not by itself mean tracking is broken. Returns notConfigured when Google Analytics is not connected or no GA4 property is linked.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "siteUrl": "<siteUrl>"
    },
    "name": "get_ga4_realtime_events"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of events to return.
`siteUrl`	Yes
`eventName`	No	Only count this event (e.g. purchase). Omit to list every event received.

Output Schema

Name	Required	Description
`asOf`	No
`hint`	No
`events`	No
`reason`	No
`thenBy`	No
`account`	No
`listKey`	No	Name of the top-level field that holds the rows sortedBy describes.
`siteUrl`	No
`nextStep`	No
`ordering`	No
`sortedBy`	No
`eventName`	No
`siteScope`	No
`sortOrder`	No
`thenOrder`	No
`truncated`	No
`dataSource`	No
`propertyId`	No
`emptyBecause`	No
`methodLimits`	No
`notConfigured`	No
`windowMinutes`	No
`reauthRequired`	No
`matchedRowCount`	No
`sharedWithSites`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only establish readOnly/openWorld/destructive=false, and the description goes well beyond them: 30-minute window, sort order with tie-breaking, seconds-level ingestion latency, property-wide unprocessed counts that cannot be narrowed to a hostname, sharedWithSites behavior, refusal of shared accounts, the caveat that an empty result does not prove tracking is broken, and the notConfigured condition. That is exactly the behavioral context annotations cannot carry.

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 when-to-use condition and the sibling exclusion are front-loaded, and the dense middle sentences each carry operational detail. It is on the long side and the sharedWithSites/refused-account sentence is harder to parse than the rest, but no sentence is filler.

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

Completeness5/5

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

An output schema exists, so return-shape explanation is unnecessary, and the description still covers the edge cases an agent must anticipate — timing lag, property-wide scope, empty results, and the notConfigured error. Nothing material is missing for a three-parameter read-only query.

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 67%, with limit and eventName documented in the schema. The description adds non-obvious meaning the schema lacks: siteUrl selects the linked GA4 property rather than filtering by host, and eventName acts as a single-event filter with an example (purchase). It does not discuss the limit parameter or the outcome of exceeding available events, which keeps it below a 5.

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 opens with a concrete verb and resource — reading GA4 Realtime for the property linked to a site — and enumerates the exact fields returned (eventName, eventCount, keyEvents) over the last 30 minutes. It also explicitly distinguishes itself from get_ga4_key_events, so an agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

It gives a precise trigger ('when the user wants to confirm that an event just fired, such as a test booking or purchase') plus the negative case ('Not for conversions older than 30 minutes, revenue, pages or traffic sources') and names the sibling to use instead. The eventName parameter is also framed as the way to check a single event.

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

All SEO GSC Wizard MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?