list_task_references

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

Since annotations are absent, the description does the full work of telling the agent this is a read operation, and it does say 'Read-only.' It also clarifies that the tool surfaces URLs and reference notes, not entire tasks. Missing behavior includes how unknown task or project IDs are handled, whether returned links are resolved or raw, and what exactly the response structure looks like—no output schema backs it up.

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 gets the job done in one sentence. 'Read-only' is front-loaded, the exact target location ('## References' section) is included, and it has no filler.

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 the simplicity of this tool—two string IDs, no nested objects, no output schema—the description is nearly complete. It tells the agent what the tool reads, what is visible, and that it has no side effects. The remaining gap is that the parameter semantics are not explained anywhere, which is relevant, but the overall calling context is straightforward.

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?

The input schema has no description for either projectId or taskId, and the tool description adds nothing about them. 'Read-only' and 'a task's References section' only hints at taskId; projectId is never even loosely explained. Because schema coverage is 0%, the description should compensate for this gap and does not.

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 clearly states a specific verb ('lists') and a precise resource: a task's 'References' section. It also distinguishes the tool from mutation siblings by identifying it as 'Read-only' and describing the exact data returned (external URLs and reference notes). It does not explicitly separate itself from get_task or context_for_task, which might overlap for an agent, so it's not a perfect 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?

The description implies when to use the tool: when an agent needs the references attached to a task. The 'Read-only' label helps avoid using it for mutation. However, it does not mention alternatives such as add_task_reference, remove_task_reference, or get_task, nor does it state conditions for when not to use it.

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