asana_board_rollup

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond these flags: fields are resolved live via custom_field_settings, output includes which date field triggered overdue status, rankings are by amount descending, and due_on is always checked. This enriches understanding without contradicting annotations.

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 is long but every clause provides necessary information for a complex composite tool. It front-loads the core purpose with the 'COMPOSITE: roll up ONE board' prefix and uses parenthetical examples sparingly. The structure could be improved by breaking into separate sentences, but there is no redundant filler, making it appropriately concise for the tool's complexity.

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?

With no output schema, the description carries the responsibility of explaining the return shape. It does so by listing the significant output components: section grouping, summed amounts, secondary amount, and overdue tasks with days and field identification. Some ambiguities remain (e.g., exact response format, how pagination is exposed), but for a read-only composite tool with thorough annotations, this is sufficiently complete for an agent to understand what it returns and when to call it.

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 the input schema thoroughly documents each parameter. The description reiterates that fields may be given by GID or exact name, which is already present in the schema for the relevant fields. It does not add substantial new meaning to individual parameters beyond what the schema provides, though it helps tie parameters together conceptually.

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 explicitly states the operation ('roll up ONE board (project)') and details what the output contains: active tasks grouped by section, summed custom amounts, optional secondary amount, and overdue tasks with days and triggering field. This clearly identifies the tool's purpose and differentiates it from sibling tools like asana_portfolio_rollup by the 'ONE board' scoping.

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 usage for single-project rollup but does not explicitly state when to use this tool over a sibling (e.g., asana_portfolio_rollup) or when not to use it. There is no exclusionary guidance or alternative recommendation, so usage context is only implied by the phrase 'ONE board' and the composite nature.

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