Skip to main content
Glama
jabeer4148-ops

google-measurement-mcp

List GA4 key events

ga4_list_key_events
Read-onlyIdempotent

List key events on a GA4 property to view their counting method and deletable status. Use this read-only tool to identify events available for conversion tracking.

Instructions

Lists key events (formerly 'conversions') on a GA4 property, with counting method and whether each is deletable. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows to return. Defaults to 25 to protect the context window. Prefer narrowing the query over raising this.
pageTokenNoOpaque token from a previous response's `nextPageToken`, to fetch the following page. Paging is manual so the caller controls cost.
propertyIdYesNumeric GA4 property ID, with or without the 'properties/' prefix. Call ga4_list_account_summaries to discover it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it discloses the response contents (counting method and deletability) and clarifies terminology (formerly 'conversions'). No contradiction with annotations.

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?

The description is a single, efficient sentence that front-loads the action ('Lists key events') and includes only necessary context. No filler or redundant phrases.

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?

Without an output schema, the description compensates by indicating what fields will be present (counting method, deletable flag). Combined with the 100% parameter documentation and annotations covering safety, it gives an agent enough to call the tool correctly. It does not specify, for example, sorting or total count, but these are not essential for a list operation.

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%, and each parameter already has detailed descriptions (limit default, pageToken purpose, propertyId format). The tool description does not add further parameter-level meaning, so the baseline score of 3 is appropriate.

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 states a specific verb ('Lists'), a precise resource ('key events on a GA4 property'), and includes clarifying details (formerly 'conversions', counting method, deletable flag). This clearly differentiates it from sibling tools like ga4_list_custom_dimensions or ga4_list_account_summaries.

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 gives clear context: it is a read-only listing operation for a GA4 property's key events. Parameter descriptions add practical guidance, such as using ga4_list_account_summaries to find the property ID and preferring to narrow the query over raising the limit. It doesn't explicitly name alternatives or when-not conditions, but the context is sufficient.

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