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

Annotations declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true. The description adds meaningful behavioral context: it resets evidence review, cannot approve/promote, and requires review scope for change requests. This goes beyond the annotations and helps the agent understand side effects. It doesn't contradict annotations. The only gap is not explaining what 'resets evidence review' means in terms of data loss, but the description is still strong.

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?

Three sentences, zero fluff. The first sentence states the core action, the second states critical exclusions, the third states a prerequisite. Every sentence earns its place and the most important information is front-loaded.

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 mutation tool with no output schema, the description covers the key behavioral constraints: what it does, what it doesn't do, and a prerequisite. The nested answer object's semantics are mostly in the schema. It could mention what the response looks like or what 'resets evidence review' implies, but given the annotations and schema richness, this is nearly complete.

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 50%, with projectId and idempotencyKey having descriptions. The description itself doesn't add parameter-level detail beyond what the schema provides. The nested 'answer' object has enums and defaults in the schema, so the schema carries most of the semantic weight. The description's mention of 'draft answer or request changes' maps to the status/reviewStatus enums, but doesn't explain the relationship explicitly. Baseline 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 states a specific action ('Save a draft answer or request changes') and clearly distinguishes what the tool cannot do ('cannot approve an answer or promote it to the answer library'). This is clear and differentiates from sibling tools like helvabase_apply_library_promotion or helvabase_confirm_review. However, it doesn't explicitly name a sibling alternative, so it loses a point for not being fully explicit about which sibling to use instead.

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 gives clear context: this tool is for saving drafts or requesting changes, and it explicitly states when NOT to use it (cannot approve or promote). It also notes that 'Requesting changes requires review scope,' which is a useful prerequisite. It doesn't name a specific alternative tool, but the exclusions are strong enough to guide an agent toward the right choice.

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