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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. It adds the 'explicitly scoped' and 'bounded experiment' framing, plus the fact that comparable trial evidence is returned. It does not elaborate on compute behavior or result shape, but it does not contradict the annotations.

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?

Two compact sentences with zero filler. The main action and return value are front-loaded, and the prerequisite dependency is stated immediately afterward.

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?

This is a complex 24-parameter tool with no output schema, yet the description provides only one sentence of operational context. It leaves important semantics around sweep strategy, constraints, objective selection, walk-forward behavior, and return format entirely implicit. The protocolId prerequisite helps, but it is not enough for reliable invocation.

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?

With 24 parameters and only 25% schema description coverage, the description carries a heavy burden that it does not meet. The only parameter it mentions is protocolId, which the schema already describes. It offers no guidance on parameterOverrides, objectiveMetric, constraints, evaluationMode, walk-forward settings, or strategy.

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?

States a clear action ('Run an explicitly scoped parameter sweep') and a concrete output ('comparable trial evidence'). It also links to the prerequisite protocol tool, distinguishing it from define_experiment_protocol. It does not fully differentiate from execution-like siblings such as walk_forward_candidate, but the scoping qualifier provides reasonable separation.

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?

Explicitly names the required precondition: protocolId returned by define_experiment_protocol. This gives clear when-to-use context and points to the correct upstream tool. It does not mention alternatives or when-not-to-use scenarios, but the stated prerequisite is meaningful guidance.

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