update_task_due_date

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly explains that the operation preserves other task fields, that passing None/empty clears the due date, and that relative date strings must be parsed to ISO beforehand. It does not discuss permissions or side effects beyond the task itself, but it covers the important behavioral specifics.

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 front-loaded with the core purpose, followed by clear usage guidance and parameter details. Every sentence adds meaningful information—examples, constraints, and clearing behavior—without repetition or filler.

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?

The description is complete for this tool's complexity: it covers purpose, when to use, parameter formats, clearing behavior, and what not to do. An output schema exists, so return-value documentation is unnecessary. Nothing needed to invoke the tool correctly is missing.

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 fully compensates. It explains task_id contextually as referring to an existing logged task, and thoroughly documents due_date: ISO format required, natural language must be pre-parsed, and None/empty string clears the date. This is far more than the raw schema provides.

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?

States a specific verb, resource, and scope: 'Change the due date on an existing logged task,' and explicitly lists what it does NOT alter (log_date, status, description, tag, ID). This clearly distinguishes it from sibling tools like update_task_status and update_task_tag.

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?

Provides explicit when-to-use guidance with concrete examples ('due today EOD', 'push #12's due date to Sept 1', 'clear the due date on #7'), and explicitly warns against deleting and re-logging the task. It leaves no ambiguity about when this tool is appropriate.

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