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

Annotations already declare readOnlyHint=false and idempotentHint=true, so the description does not need to repeat those. It adds valuable behavioral context by specifying the draft status constraint and listing exactly which fields are updatable, which implies other fields are immutatable. This enriches the agent's understanding beyond the annotations without contradicting them.

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 description is two compact sentences with no fluff. The first sentence front-loads the action and the full field list; the second sentence states the condition. Every word earns its place, and the structure makes it easy to scan.

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?

Given there is no output schema and the tool is a focused update operation, the description covers the essential information: what fields can be updated and the precondition. It does not mention error behavior or return values, but that is secondary for an update tool, and the idempotent hint provides some side-effect assurance. Overall, it is complete enough for an agent to call it correctly.

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 must compensate. It lists every updatable parameter (title, successCriteria, instruction, observationPoints[], probingQuestions[], observerMeasurementEnabled, participantRatingEnabled) and clarifies they can be updated 'any of' individually or together, which directly informs how to use the parameters. Though it does not elaborate on each field's meaning, the names are largely self-explanatory, and the listing is sufficient for correct usage.

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 the specific verb 'update', the resource 'task in a draft UT', and enumerates the exact fields it can modify. The added constraint 'Only works on tasks of PREPARING drafts' clearly differentiates it from sibling tools like add_task and delete_task, leaving no ambiguity about what it does.

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 an explicit condition for use: 'Only works on tasks of PREPARING drafts.' This tells the agent when this tool is applicable and implicitly when it is not. It does not name alternative tools for other task states, but the condition is clear enough for an agent to decide.

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