create_task

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only repeats the tool's core purpose and gives zero insight into side effects (e.g., whether notify_all triggers notifications, whether check_required_custom_fields validation occurs, whether creating a task with parent creates a subtask by default, or how links_to behaves). For a mutation tool with no annotation coverage, this is severely under-specified.

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?

A single efficient sentence, no waste or redundancy.

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?

High-complexity mutation tool (19 params, no annotations, no output schema) with only 8 words of description. Schema handles parameter definitions, but the description fails to convey return behavior, side effects, or how creation relates to sibling tools like update_task or duplicate_task.

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 74%, meaning most parameters carry their own meaning in the schema (e.g., priority has explicit 1-4 mapping, time_estimate in ms, parent as subtask creator). The description adds nothing beyond the schema, but since coverage is above 80%... actually it's 74%, just under the 80% threshold. The description contributes zero parameter semantics, landing at the baseline-3 for a mostly-covered schema. Some parameters like notify_all, start_date, and due_date_time have no schema description either, and the tool description doesn't help fill those gaps.

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 'Create a new task in a list' clearly states the verb (create) and resource (a task in a list). It distinguishes from siblings like create_list, create_folder, and create_goal, though it doesn't explicitly differentiate from update_task or the many other create_* siblings. It lacks detail about the scope/context beyond 'in a list', which is slightly vague but adequate given the name.

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?

There is no guidance on when to use this tool versus alternatives such as duplicate_task, move_task_to_list, or add_task_dependency. No prerequisites are mentioned (e.g., needing list_id already obtained via get_lists), and no exclusions or when-not-to-use guidance is provided. For a creation tool with 19 parameters, this is a significant gap.

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