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

Annotations already cover readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds important behavioral details beyond that: the 200-task cap, the suggestion to filter if truncated, and the inclusion of archived tasks for sprint-scoped queries. These are not in the annotations and give the agent critical expectations about output volume and scope.

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?

Two sentences with no filler. The purpose is front-loaded, the cap and archived behavior are stated in the second sentence, and the alternative tool is mentioned last. Every sentence earns its place.

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 list tool with five optional parameters and no output schema, the description covers the core behaviors: return scope, cap, archived inclusion, and the alternative. It doesn't mention pagination or sorting, but those are likely not essential given the tool's simplicity and the annotation coverage. The description gives enough for an agent to call it correctly.

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%, so each parameter is already documented. The description adds a practical hint that columnId and sprintId should be used to avoid truncation, but doesn't redefine the parameters themselves. This meets the baseline for well-covered schemas.

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 opens with a specific use case ('tasks scoped to a specific column or sprint') and then clarifies the unfiltered behavior ('returns every task on the board'). It explicitly names the sibling tool it is not ('Prefer get_board_state'), making the purpose unmistakable.

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 explicit when-to-use ('when the user wants tasks scoped to a specific column or sprint') and when-not-to ('Prefer get_board_state when the user wants a general overview'). Also warns about truncation and tells the agent to filter by columnId/sprintId, guiding parameter selection.

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