Creates a custom metric in GA4 for a numeric event parameter, enabling tracking of values like lead value.
Register a custom metric (a numeric event parameter, e.g. a lead value).
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | No | ||
| description | No | ||
| property_id | No | ||
| display_name | Yes | ||
| parameter_name | Yes | ||
| measurement_unit | No | STANDARD |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description must carry the full behavioral burden. It only states 'Register a custom metric' and leaves out the fact that creation likely requires confirmation (confirm parameter), where property_id is resolved, and whether the call can overwrite or is idempotent. For a state-changing tool this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence without filler. Every word earns its place: the verb, the resource, and the distinguishing trait are all present, and there is no restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter creation tool with no annotations, the description is far from complete. It doesn't mention the confirmation flag, default property_id source, measurement_unit enum semantics, or naming rules for parameter_name. Even though an output schema exists, an agent would still have to guess at critical invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the tool description does not compensate: it says nothing about parameter_name, display_name, measurement_unit, confirm, description, or property_id behavior. The only added semantic is that the metric is a numeric event parameter, which loosely clarifies parameter_name but leaves the rest to name guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Register') and resource ('custom metric'), then disambiguates the resource with 'a numeric event parameter, e.g. a lead value'. That parenthetical is precisely what separates a custom metric from the sibling ga4_create_custom_dimension, so an agent can pick correctly without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no mention of alternatives beyond the implied GA4 domain. The 'lead value' example suggests a use case but does not give enough context to choose this over a custom dimension or a conversion event conceptually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.