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

The destructiveHint=true / readOnlyHint=false annotations flag this as a mutation, and the description adds what actually changes ('nothing changes' on conflict), how the optimistic-concurrency guard works (mismatched IDs yield a 409 with P-062 vs P-063 depending on whether anything is live), and the read-before-write protocol. It also gives a concrete external constraint (P-058) that would otherwise be invisible.

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 two paragraphs are front-loaded: the mutation and the pre-read requirement come first, and the error-code detail follows. Every sentence carries operational content, though the P-058/P-062/P-063 parentheticals read densely and could be trimmed slightly without losing meaning.

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 4-parameter destructive tool with no output schema, the description covers everything an agent needs: how to derive the concurrency tokens, what makes the operation legal, what the failure modes mean, and how to recover. The annotations plus the description together leave no significant behavioral gap.

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 coverage is already 100%, but the description still adds real meaning: it says which fields of a prior lexq_groups_get call map to expectedCurrentVersionId and expectedCurrentDeploymentId and why they exist (staleness detection). The required memo parameter is never explained in the description, so the schema carries that one alone.

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 first sentence states a specific verb and resource ('roll the group back to the version that was live before the current one') and pins the target scope, so an agent can tell it apart from lexq_deploy_undeploy, lexq_deploy_publish, or lexq_versions_* siblings that also change what is live. That scope statement by itself resolves which sibling to use.

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 states an explicit prerequisite workflow ('call lexq_groups_get first'), which fields gate the call (canRollback), when it must not be attempted (previous version must be ACTIVE and not past its effective end), and what to do on failure ('read the group again and check with the user before retrying'). That is when-to-use, when-not-to-use, and the alternative path all in one.

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