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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with 'WITHOUT creating it'. It adds useful workflow context about the returned draft fields and its role as an intermediate step, going slightly 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 sentences, front-loads the main action, and every clause earns its place. It states the transformation, the non-mutation constraint, and the downstream use in one compact, scannable block.

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?

There is no output schema, but the description compensates by enumerating the draft fields (title, instruction, scheduleKind, schedule, timezone, config) and explaining the workflow connection to neuron_create_task. It is sufficiently complete for a drafting tool with annotations covering the side-effect profile.

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 100%, with clear parameter descriptions for botId, prompt, and timezone. The description adds context by linking prompt to the output spec and mentioning timezone in the output field list, but it does not materially extend the schema's parameter documentation. 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 uses a specific verb ('Turn... into') and names the exact resource ('structured task spec') and output fields. It explicitly distinguishes from the sibling neuron_create_task by stating the draft is NOT created, so there is no confusion with nearby create/update/run task tools.

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 clearly states when to use the tool: to produce a draft before creating a real task, and explicitly directs the agent to use the returned draft as input to neuron_create_task after edits. This provides concrete workflow guidance and implicitly excludes using this tool for final creation or updates.

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