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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds substantive behavior: the cancel action discards pending tasks (explaining *what* is destroyed), and the mandatory optimistic version signals a concurrency check that can reject the call. It stops short of describing what happens on a version conflict or what the response contains.

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, front-loaded with the available actions and ending with the precondition; there is no filler. It is arguably too terse for a destructive three-parameter mutation, but nothing written is wasted.

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 destructive, all-parameters-required mutation with zero schema descriptions and no output schema, the definition leaves key gaps: the identity of the id parameter, the effect of pause vs. cancel on in-flight work, and conflict/error behavior. The safety profile is covered by annotations and the actions are enumerated, but parameter semantics remain substantially unexplained.

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?

Schema description coverage is 0%, so the description carries the burden, and it partially compensates: 'version optimiste' gives meaning to the otherwise opaque version integer, and the three listed operations map onto the action enum. The required id parameter is never explained — an agent cannot tell from the description whether it is a workflow id, a run id, or something else.

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 names three concrete operations (activate, pause new entries, pause-and-cancel pending tasks), which is far more specific than restating the title. However, it never names the resource being mutated ('workflow' appears only in the tool name), and it does not distinguish itself from closely related siblings like set_collection_state or set_task_state.

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?

Usage is implied by the enumerated state transitions, and 'Version optimiste obligatoire' gives a real precondition the agent must satisfy before calling. There is no explicit when-to-use/when-not-to-use guidance and no named alternative for related state changes.

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