Skip to main content
Glama
konkomaji

Google Marketing MCP

by konkomaji

ga4_create_audience

Create a simple event-based GA4 audience with an event name filter and membership duration. Use the GA4 UI for complex multi-step funnels to avoid errors.

Instructions

Create a simple event-based audience (e.g. 'viewed a property page, no generate_lead'). For anything beyond a single event condition, build it in the GA4 UI -- the filterClauses shape for sequences and multi-step funnels is deep enough that hand-building the request body here would be more error-prone than the UI's audience builder.

Args: membership_duration_days: how long a user stays in the audience once they qualify, 1-540. RLSA on Search needs 1,000+ members before it can serve. event_name_filter: if set, membership = fired this event at least once. Leave unset and build the audience by hand in the UI for anything more complex. confirm: must be true to actually create.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNo
descriptionYes
property_idNo
display_nameYes
event_name_filterNo
membership_duration_daysNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the confirm guard, membership_duration_days range and RLSA threshold, and the exact membership semantics of event_name_filter. It could say more about side effects or failure modes, but the output schema covers return shape and the core behavioral safety is well communicated.

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 description is front-loaded with a one-sentence purpose, followed by scope limits and a compact Args block. The filterClauses rationale is useful but slightly wordy; still, every sentence contributes to either correct usage or safe invocation.

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?

The description covers the essential behavioral and usage context for a flat 6-parameter create tool, and the output schema means return values do not need to be described. The main gap is property_id's role and fallback behavior, but the clear arg names and strong usage guidance make the description largely complete.

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 0%, so the description must compensate. It adds real meaning for membership_duration_days, event_name_filter, and confirm, but it does not explain property_id at all and leaves display_name/description to name-based inference. This partial compensation keeps it adequate but not complete.

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?

Description states a specific action ('Create a simple event-based audience') with an example condition, making the tool's purpose immediately clear. It also differentiates itself from the GA4 UI by explicitly limiting scope to single-event conditions, so an agent can tell it apart from list/read siblings and from a manual UI workflow.

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?

The description explicitly tells the agent when to use this tool versus when to avoid it: anything beyond a single event condition should be built in the GA4 UI. It repeats this guidance in the event_name_filter arg and warns about the filterClauses shape being error-prone, giving strong routing context.

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