get_task

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

No annotations are provided, so the description carries the behavioral burden alone. For a read-only fetch the safety profile is largely self-evident from 'get', and the description usefully discloses the payload shape and the task-vs-project branching. It does not state permission requirements, pagination, or behavior for a missing id, leaving some gaps.

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?

One compact sentence with the core purpose front-loaded and the task/project branching handled parenthetically. Every clause carries information; nothing is padding.

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?

An output schema exists, so the description need not document return values, and the sole parameter is fully documented in the schema. The description supplies the task-vs-project dual behavior, which is the main ambiguity for this tool. Only the absence of routing guidance versus sibling list/search tools keeps it from being fully complete.

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?

A single parameter with 100% schema description coverage sets the baseline at 3. The description reinforces the schema by clarifying that the id may refer to either a task or a project, which affects the response shape, but adds no format or validation detail beyond that.

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 names a specific verb (get) and resource (task/project) and enumerates what 'full details' contains (note, subtasks, dates, tracking), which is far more informative than a bare restatement. It partially distinguishes itself from siblings like list_children by noting that a project returns 'its open children'. It stops short of explicitly contrasting with search_tasks or get_structure, so it lands at 4 rather than 5.

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 explicit when-to-use guidance and no alternatives named. With siblings such as list_children, get_structure, and search_tasks in the same namespace, the agent must infer that get_task is the single-item detail fetch rather than a list/search tool. Usage is only implied, not stated.

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