asana_list_task_templates

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

The description only adds the fact that results are paged. Given annotations already declare readonlyHint, openWorldHint, idempotentHint, and destructiveHint=false, the baseline safety profile is covered. The description does not clarify how pagination behaves (e.g., whether limit applies to opt_fields), nor does it note whether the default opt_fields are expanded or that max_pages exist. It adds minimal extra behavioral context beyond the 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 compact, a single sentence that names the verb, resource, and the pagination behavior. It is not padded with filler or irrelevant detail. It is slightly terse, but it conveys the essential fact in under 12 words, making it easy to parse. A score of 5 would require the addition of a sibling alternative for clarity.

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?

The tool has no output schema, and the description does not describe the shape of the returned objects or how opt_fields affects them. Pagination is the only behavior explained, and that is implicit in the paginated parameters. Overall the description is usable, but for a list tool with four parameters and no output format, it leaves distinct gaps around maximum pages behavior and default field selection.

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 schema fully documents all four parameters (100% coverage), so the description naturally does not re-summarize parameter syntax. The description does mention 'Paginated', which ties to the limit and max_pages parameters but does not explain how max_pages interacts with limit or whether opt_fields overrides the default. Thus it provides only marginal semantic value over the schema.

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 states a specific verb ('List') and resource ('a project's task templates'), explicitly calling out 'repeatable task blueprints' which greatly clarifies the kind of resource. It also notes 'Paginated', distinguishing it from other listing tools. Slightly below a 5 because it does not explicitly distinguish itself from sibling tools that operate on projects/templates, though the resource class is clear.

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 conveys when to use the tool implicitly: the user asks for task templates for a project. It does not mention when not to use it, nor does it name alternatives such as asana_list_tasks or asana_get_project. It also lacks any prerequisites or expected usage scenario. The basic purpose is clear, but there is no routing guidance.

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