Skip to main content
Glama
MoonEyes

google-ecommerce-mcp

Plan a GA4 custom dimension

ga4_plan_custom_dimension_create
Read-only

Plan registering a custom dimension on a GA4 property to track event, user, or item parameters before applying changes. Checks required names, scope, and quota limits without writing data.

Instructions

PLAN (nothing is written): register a custom dimension on the client's GA4 property. Warning: parameterName and scope are immutable and the slot counts against the quota (50 event / 25 user / 10 item). Apply with google_apply after the user agreed. No automatic rollback (archiving is not offered).

Input Schema

NameRequiredDescriptionDefault
scopeNoScope (can never be changed later)EVENT
client_idNoClient id from clients_list. Required when several clients are registered; empty uses the only client
descriptionNoOptional description, 150 characters at most
property_idNoNumeric GA4 property id of the client (empty: the configured one)
display_nameYesName shown in GA4 reports
parameter_nameYesEvent or user parameter to register, e.g. payment_type (can never be changed later)
disallow_ads_personalizationNoUSER scope only: exclude it from ads personalization

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it warns that parameterName and scope are immutable, quantifies the quota (50 event / 25 user / 10 item), and discloses that no automatic rollback exists because archiving is not offered. That is exactly the kind of irreversible-consequence context an agent cannot get from readOnlyHint/destructiveHint alone, and it is consistent with readOnlyHint=true since nothing is written.

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?

Four short clauses, front-loaded with the plan-vs-write distinction, then the risk warning, then the apply step. Every sentence carries distinct decision-relevant information with no padding.

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?

For a 7-parameter mutation-planning tool with no output schema, it covers the workflow handoff, irreversibility, and quota limits, and the schema handles client/property selection. It could note how the resulting plan is retrieved (plan_get) or reviewed, but nothing essential is missing.

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 the schema already labels scope and parameter_name as 'can never be changed later', so the description largely restates parameter facts. Its genuinely additive detail (the 50/25/10 quota) is not per-parameter guidance, so the baseline 3 is right.

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?

States a specific verb (plan/register), resource (custom dimension), and target (client's GA4 property), and the 'PLAN (nothing is written)' prefix instantly separates it from apply-style siblings like google_apply and from the read-only ga4_custom_definitions.

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?

Explicitly names the follow-up action and precondition: 'Apply with google_apply after the user agreed.' That is clear workflow routing, though it stops short of stating when *not* to use this tool or what alternative exists if the user declines.

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