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

Annotations already mark the tool as destructive and read-write, but the description adds nothing about what the operation does to existing draft rounds—whether it overwrites them, appends to them, or depends on accepted_rounds as constraints. The description does not contradict the annotations, but it also does not disclose the side effects that the destructiveHint warns about.

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?

One short sentence, front-loaded with the verb and object, with no filler or repetition. It is as concise as a description can be while conveying the core purpose.

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 generative tool with a nested accepted_rounds array, an instructions field, a source_stage pointer, a destructive annotation, and no output schema, yet the description is a single seven-word sentence. It leaves the agent without guidance on required inputs, output shape, side effects, or how this step fits into the overall draft workflow.

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 needed to compensate by explaining the non-obvious parameters, but it only mentions 'confirmed skills.' It never clarifies what accepted_rounds represents, why instructions is needed, what version means, or how source_stage should be set. Property names and structure do some work, but the burden is on the description and it is not met.

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 a specific operation ('Generate draft interview-plan rounds') and identifies its source ('confirmed skills'), which separates it from the other generate_* siblings such as generate_skills, generate_competencies, and generate_outcomes. It does not explicitly contrast with add_rounds or update_rounds, but the verb and draft scope are clear enough.

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 phrase 'from confirmed skills' implies the tool should be used after skills are confirmed, but it never states that prerequisite directly, nor does it mention alternatives like add_rounds or update_rounds. An agent must infer the correct workflow placement rather than being told when this generator is the right choice.

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