Skip to main content
Glama

Ads experiment end

ads.experiment.end
Destructive

End a running experiment by providing the customer ID and experiment name, with optional confirmation, to stop the test and prevent further changes.

Instructions

End a running experiment.

Input Schema

NameRequiredDescriptionDefault
confirmNo
experimentYes
customer_idYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.10.0

TDQS

C2.2/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety bar is lowered, but the description still adds nothing beyond them. It does not say whether ending stops serving immediately, whether results/metrics are preserved, or whether the action can be undone, which matters for a destructive, non-idempotent call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The single sentence is efficient and front-loaded with the verb, containing no filler. But its brevity crosses into under-specification, since nothing occupies the space where essential behavior and parameter context should be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained, but for a destructive, non-idempotent lifecycle operation with three undocumented parameters, one sentence is inadequate. The agent lacks the confirmation semantics and the consequences of ending an experiment before invoking it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across three parameters. The description never mentions customer_id, experiment, or especially the optional 'confirm' parameter, whose purpose and expected value are completely undocumented and unexplained anywhere the agent can see.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('End') and resource ('a running experiment'), and 'running' narrows the target to an active experiment. However, it does not differentiate this from the closely related siblings ads.experiment.schedule and ads.experiment.promote, which also act on experiments, so an agent gets no help distinguishing lifecycle operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage signal is the implied precondition that the experiment must be running. There is no instruction on when to end versus promote or schedule an experiment, no note on checking status first, and no mention of prerequisites or exclusions anywhere in the description.

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