List schedule tasks

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description correctly spends its words on domain semantics: Gantt ordering, the kind taxonomy including summary groups whose dates follow subtasks, inclusive end_date, and the shape of depends_on with link type and lag. It does not mention permissions, pagination, or result size limits, which keeps it short of a 5.

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?

Purpose and return contents are front-loaded in the first sentence, with field-level clarifications following in compact form. Every sentence carries information, though the mix of result-shape notes and the update cross-reference in one running paragraph makes it slightly denser than ideal.

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, so the description must explain return values, and it does so well: ordering, kind values, inclusive end_date, and dependency structure. Only secondary operational details such as pagination or whether large schedules are truncated are absent.

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?

There is exactly one parameter and schema coverage is 100%, with the schema itself saying 'project_id from list_projects.' The description adds no further meaning about that parameter (the task_id it mentions is an output field, not an input), so the baseline of 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?

States a specific verb and resource ('Gantt schedule tasks of a project') plus the fields returned (dates, duration, dependencies, assignees, percent complete). It also implicitly distinguishes itself from the mutating sibling by naming update_schedule_task for the write path, so an agent can tell read from write without opening a schema.

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?

Gives concrete follow-up routing ('Use task_id with update_schedule_task') and an interpretation rule ('An empty list means the project has no schedule yet'). It never states an explicit exclusion or an alternative listing tool, but there is no obvious competing sibling for schedule reads, so the guidance is clear rather than exhaustive.

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