Deactivate a conversion goal by goal ID or event name and return the updated goal. Historical conversion events and reports remain available.
| Name | Required | Description | Default |
|---|---|---|---|
| goalId | No | Goal ID returned by goals_create or goals_list. | |
| eventName | No | Conversion event name to deactivate when goalId is not available. | |
| projectId | No | Optional project ID. Omit only when the API key is project-scoped or the account has a clear default project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that the return value is the updated goal and that historical data remains available, which are important behavioral clarifications beyond the annotation. No contradiction detected.
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 brief, with two sentences that front-load the core action and result, and a second sentence addressing a common concern (historical data preservation). No superfluous information.
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?
The description covers purpose, method, result, and side effect on history. It lacks details on reversibility or permissions, but given the annotations and schema, it is largely sufficient for a deactivation tool.
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?
Input schema coverage is 100%, so baseline is 3. The description mentions 'by goal ID or event name', which aligns with the anyOf constraint but adds minimal extra meaning. The projectId parameter is not described, but its schema description covers it. No significant additional insight.
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 clearly states the action (deactivate a conversion goal), the resource (conversion goal), and the methods (by goal ID or event name). It also specifies that it returns the updated goal, distinguishing it from creation (goals_create) and listing (goals_list). The purpose is unambiguous.
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?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It implies usage when deactivation is needed, but lacks guidance on choosing between goalId and eventName or comparing to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action combination (e.g., domains_add, experiments_create, goals_deactivate, reports_experiment_chart). There is no overlap or ambiguity; even the three report tools serve clearly different purposes (totals, time-series, channel breakdown).
The vast majority of tools follow a resource_action snake_case pattern (domains_add, experiments_list). A couple deviate (billing_portal, usage_summary) but still place the resource first, making the pattern predictable and easy to parse.
With 23 tools covering projects, domains, experiments, goals, reports, billing, health, and usage, the count is well-scoped for a split-testing platform. Each tool addresses a specific need without ballooning into excessive granularity.
The tool surface provides CRUD-like operations for core entities (projects, experiments, goals, domains) and essential report types. Minor gaps exist (no goal update tool, no experiment delete—only archive) but these are reasonable trade-offs for the domain.
