start_experiment

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

With no annotations, the description carries the full burden of behavioral disclosure, but it provides almost none. It merely restates the action (starting an experiment) without mentioning side effects like making the experiment live to users, requiring a draft state, or irreversibility. This is essentially a tautology of the tool name.

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, directly front-loaded sentence with zero fluff. It is concise, though slightly under-specified, which keeps it from a perfect 5.

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 tool that mutates experiment state, the description is incomplete. It does not explain prerequisites (e.g., the experiment must exist and be in draft), what happens on success, or how it relates to create_experiment and stop_experiment. The simple one-parameter schema mitigates the issue, but critical contextual information is missing.

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 input schema fully documents the single required parameter (experimentId) with a clear description. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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 ('Start running') and the resource ('an A/B test experiment'), which distinguishes it from sibling tools like create_experiment and stop_experiment. However, it does not explicitly elaborate on what 'start running' entails (e.g., activation versus scheduling), leaving a slight ambiguity.

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that this should follow create_experiment or precede get_experiment_results, nor does it warn against using it on an already-running experiment. The intended workflow is only weakly implied by the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.