ghl_project_update_task

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

Annotations cover safety hints, and the description adds real context beyond them: the response envelope is `{ "task": { … } }` with no embedded subtasks, the OAuth scope `projects/tasks.write` is required, the endpoint/version header is given, and it warns that current-server `position` has no public reorder endpoint (explaining why position is absent from the schema). It stops short of stating whether omitted fields are preserved on a PATCH.

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 tool-specific block is well structured with a purpose line, endpoint, and scopes. However, six sentences of API-wide preamble (hierarchy, batch-get RBAC filtering, lexorank, recurring-task field names, search sync, delete cascades) are largely irrelevant to a single task update, and they sit ahead of the actual purpose, so the reader must wade through noise before learning what the tool does.

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?

For a PATCH mutation with a very rich schema, no output schema, and annotations present, the description supplies endpoint, auth scope, response shape, and a nested-subtask caveat. The main remaining gap is PATCH semantics — whether unmentioned fields are left untouched or can be cleared — which an agent needs to call this safely.

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% and the schema is unusually detailed (TipTap sanitisation, assignee single-element limit, custom-field key format), so the schema carries the parameter burden. The description only restates the field list at a high level and does not add syntax or constraints beyond what the schema already documents; baseline 3 applies.

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 tool-specific section says plainly it "Updates a task or subtask by id" and enumerates the mutable fields (title, TipTap body, status, dates, assignees, priority, parentTaskId, custom fields). That is a specific verb+resource and implicitly separates it from create/get/delete siblings. Sibling differentiation against ghl_project_update_recurring_task or ghl_project_set_task_home_list is never made explicit, and the opening API preamble dilutes the purpose statement.

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?

Usage is only implied by the name and the field list; there is no statement of when to prefer this over ghl_project_update_recurring_task (for recurring tasks with owners/rruleOptions), ghl_project_set_task_home_list (moving lists), or ghl_project_batch_tasks. The preamble's recurring-task and lexorank remarks hint at boundaries but never route the agent to an alternative.

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