Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

GA4 key event audit

ga4_key_event_audit
Read-onlyIdempotent

Which GA4 events are marked as key events (conversions), and do they inflate conversions: more key events than sessions, page_view or other engagement events marked as key, contact clicks (phone, e-mail, WhatsApp) marked as key.

Instructions

Which GA4 events are marked as key events (conversions), and do they inflate conversions: more key events than sessions, page_view or other engagement events marked as key, contact clicks (phone, e-mail, WhatsApp) marked as key. Two Data API runReport calls: events with eventCount and keyEvents, then the property totals of sessions, keyEvents and ecommercePurchases. Returns "key_events" (event_name, event_count, key_events, share_pct, flags), "totals", "key_events_per_session", "findings" ({code, severity, event_name, detail}), the unit and definition of each metric under "metrics" and a "date_range" with "data_complete". Heuristics: check in GA4 Admin > Events > Key events before changing anything. Run it first on a new property, before reading any conversion rate or ROAS.

Input Schema

NameRequiredDescriptionDefault
end_dateNoYYYY-MM-DD, NdaysAgo, yesterday or todayyesterday
client_idNoClient id from clients_list. Required when several clients are registered; empty uses the only client (or the environment variables when there is no client registry)
start_dateNoYYYY-MM-DD, NdaysAgo, yesterday or today28daysAgo
property_idNoNumeric GA4 property id, as listed by ga4_properties; empty uses the configured GA4_PROPERTY_ID (or the client's property)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent safety, and the description adds real value on top: it discloses the two Data API runReport calls (cost/latency signal), the exact output keys including a findings list with severities, and a data_complete flag implying freshness caveats. It stops short of auth or quota details.

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?

Front-loaded with the purpose, then call mechanics, then return shape, then heuristics — a sensible order. The enumerated output keys are dense but justified because no output schema exists; the phrasing is compact with little filler.

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 no output schema, the description carries the return-value burden and does so by naming every top-level key plus the findings structure. Combined with the annotations and a fully documented schema, an agent has enough to call it correctly; only rate-limit/auth expectations are absent.

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%, with date formats, client_id resolution and property_id fallback all documented in the schema. The description adds nothing about parameters — no guidance on date range choice for the audit — so the 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?

Opening sentence names a specific resource and diagnostic angle: which GA4 events are key events and whether they inflate conversions, with concrete red-flag criteria (more key events than sessions, page_view marked as key, contact clicks marked as key). It is clearly a diagnostic audit rather than a plain listing, which implicitly separates it from ga4_key_events, but it never names that sibling explicitly.

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?

"Run it first on a new property, before reading any conversion rate or ROAS" gives an explicit ordering rule, and the Admin > Events > Key events pointer tells the agent what to do with findings. No explicit exclusions or named alternatives are given, which keeps it below a 5.

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