update_list

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. 'Update' implies mutation, but there's no mention of whether partial updates are supported, whether omitting fields resets them, what happens to unspecified fields, permission requirements, or side effects on related entities like tasks or members. For a mutation tool with zero annotation coverage, this is a significant gap.

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 a single terse sentence with no waste, which is efficient. However, at 4 words it verges on under-specification rather than true conciseness — it saves words but fails to convey necessary information.

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?

With 8 parameters, no annotations, no output schema, only 25% schema coverage, and 6 undocumented parameters, this description is severely incomplete. For a mutation tool of this complexity, the description should explain what fields do, the meaning of unset_status and due_date_time, behavior when fields are omitted, and interaction with due_date vs due_date_time. Despite sibling richness, the description provides no guidance on selection.

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 only 25%, so the description must compensate. The description ('Update an existing list') adds zero parameter semantics. Notably, the schema itself lacks descriptions for 6 of 8 parameters (name, content, due_date, priority, unset_status, due_date_time have no descriptions), and the tool description doesn't clarify what these mean. The 'unset_status' and 'priority' semantics are especially unclear.

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 verb 'Update' with the resource 'list', which is clear enough. However, it doesn't differentiate from siblings like update_task, update_folder, or update_space — all mutation tools on different resources. The description is minimal and generic, relying on the tool name for differentiation.

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?

No guidance is provided on when to use this tool versus alternatives. There's no mention of which list types this applies to (folder lists vs folderless lists), or which fields are updatable in which contexts. The sibling set includes many list-related tools, but there's no exclusion or alternative naming.

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