Asana MCP Server

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

Annotations only state readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds critical behavioral detail: the /stories endpoint escapes html_text into literal tags, and literal newline sequences are auto-converted. It also advises when to use the risky format. None of these are derivable from annotations alone, so the description substantially enhances transparency.

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 and front-loaded, opening with the action and purpose before moving to necessary caveats. It contains no filler and every clause earns its place. The two-sentence structure is efficient and highly scannable.

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 three-parameter tool with no output schema, the description is complete. It explains the story terminology, the important text-versus-HTML behavior, and gives clear guidance on parameter usage. Combined with the schema and annotations, an agent has all the information needed to invoke the tool 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 coverage is 100%, so every parameter already has detailed descriptions. The tool-level description mostly restates the schema's warnings about text and html_text, adding the small decision rule 'Pass html_text only if you accept that.' This is a minor increment over the schema, matching the baseline for high schema coverage.

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 uses a specific verb ('Add') and resource ('comment/story to a task'). It distinguishes from sibling tools like asana_add_tag or asana_add_follower by naming the exact object being created. The parenthetical '(story)' makes it clear what kind of entity is added.

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 provides clear usage guidance, strongly recommending plain text and specifying when html_text is acceptable. Although it does not explicitly compare against alternative tools, no obvious alternative comment-creation tool exists in the sibling list. The guidance effectively communicates when this tool and each parameter should be used.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the write nature and safety profile. The description adds no extra behavioral context beyond the dependency direction (e.g., whether existing dependencies are overwritten or appended). Since annotations carry the burden, the lack of additional detail is acceptable but not improved upon.

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?

A single, concise sentence that fully communicates the core action and the dependency direction. Every word is useful, and the parenthetical adds essential clarity without verbosity.

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 simple tool with two required parameters, full schema coverage, and annotations covering idempotency and safety, the description is nearly complete. The only notable gap is the lack of explicit differentiation from the reverse operation asana_add_dependent, which could prevent mis-selection in an agent traversal.

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 100% description coverage for both parameters, so the description does not need to repeat their meaning. The tool description offers no additional semantic nuance beyond what the schema provides, so a baseline score of 3 is appropriate.

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 the action ('Mark a task as depending...') and clarifies the direction of the dependency with the parenthetical 'this task waits on them'. It distinguishes the operation from generic task updates, though it does not explicitly contrast with the sibling asana_add_dependent which may represent the reverse relationship.

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?

No explicit guidance is given on when to use this tool versus alternatives. The parenthetical helps clarify the semantic direction, but there is no mention of when to choose asana_add_dependency over asana_add_dependent or asana_list_dependencies, leaving the agent to infer usage from the name and description alone.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the write/idempotent/non-destructive profile is covered. The description adds the directional semantics ('they wait on this one'), which is useful context, but it does not disclose behaviors such as whether existing dependencies are overwritten or how invalid GIDs in the array are handled.

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 a single, information-dense sentence with a parenthetical that efficiently clarifies the dependency direction. There is no filler or redundant wording, and the key semantic point is front-loaded.

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 simple two-parameter relation operation with no output schema, the description is complete enough for an agent to call it correctly: the purpose and direction are clear, and the annotations cover the safety profile. It falls just short of a 5 because it does not explicitly flag asana_add_dependency as the inverse operation, which would eliminate all ambiguity.

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 both parameters are well-documented in the schema: 'task_gid' is the blocking task GID and 'dependent' is the GID or array of GIDs that depend on this task. The description adds no parameter-level information beyond what the schema already provides, making the baseline score appropriate.

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 uses a specific verb ('Mark') and resource ('tasks'), and the parenthetical '(they wait on this one)' unambiguously defines the dependency direction. This clearly distinguishes it from the sibling tool asana_add_dependency, which presumably performs the inverse operation.

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 provides clear context for the operation by clarifying that the named tasks wait on this task, which implicitly signals when to use this tool. However, it never explicitly mentions the inverse sibling asana_add_dependency or states when to choose one direction over the other, leaving the routing to inference.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the operation is known to be a non-destructive write. The description adds no extra behavioral detail such as permission requirements, impact on existing tasks using the field, duplicate-option handling, or side effects. Since the bar is lowered with annotations, but the description adds almost nothing beyond them, a 2 is warranted.

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?

A single sentence that front-loads the verb and resource, with a parenthetical clarifying the benefit. There is no filler or redundancy; every word 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 simple operation with detailed schema descriptions, the description is mostly sufficient. However, it lacks guidance on ordering behavior (insert_after/insert_before), potential conflicts, and the effect of adding an option to a field already in use. These gaps mean the description is adequate but not 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?

Schema description coverage is 100% for all 5 parameters, and each parameter has a basic description (e.g., 'Option label', 'Option GID to insert after'). The tool description itself does not add further parameter semantics, such as how insert_after and insert_before interact or what happens if both are omitted. With high schema coverage, the baseline of 3 is correct.

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 ('Add') and resource ('an option to an existing enum/multi_enum custom field'), and explains the purpose ('extend a dropdown without recreating the field'). This clearly differentiates it from siblings like asana_create_custom_field (creating a field) and asana_set_custom_fields (setting field values).

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 provides clear context: use this when you need to add an option to an existing enum/multi_enum field. It implicitly excludes recreating the field, but does not explicitly name alternative tools (e.g., asana_create_custom_field) or state when not to use it. The phrase 'existing' and 'without recreating' give solid guidance, so a 4 is appropriate.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the API method and optional positioning/importance behavior, but does not disclose side effects beyond what annotations imply. No contradiction found.

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 core action and pairing context are front-loaded, and every clause serves a purpose.

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 simple attachment operation with strong annotations (idempotent, non-destructive), the description is nearly complete. It doesn't mention return values, but no output schema exists and the success/failure behavior is not critical for such a low-risk call. The pairing context covers the main use case.

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 mentions 'optionally important/positioned' which maps to is_important/insert_before/insert_after but adds no substantive meaning beyond the schema. Baseline 3 is appropriate.

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?

States a specific verb ('Attach'), a resource ('existing custom field'), and a target ('project'), and names the underlying API method. The pairing hint with asana_create_custom_field clearly distinguishes it from sibling tools like asana_remove_field_from_project.

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?

Provides clear context by mentioning it pairs with asana_create_custom_field to build a board, implying when to use this tool in a workflow. It doesn't explicitly exclude alternatives, but the pairing gives enough situational guidance for most agents.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds no additional behavioral context such as whether duplicate followers are ignored, if special permissions are required, or how the API handles multiple follower GIDs. It merely restates the operation without enriching 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?

A single concise sentence: 'Add follower(s) to a task.' Every word earns its place, and the key information is front-loaded. No unnecessary filler or repetition.

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 simple two-parameter mutation with a clear purpose, the description plus the schema and annotations provide sufficient information for an agent to invoke the tool correctly. The lack of an output schema is not an issue here, as return details are not critical for such a straightforward add operation. A minor gap is not explaining behavior when adding existing followers, but the idempotentHint annotation partially covers this.

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% and both parameters (task_gid, followers) are documented in the schema. The description adds minimal semantic value by clarifying 'follower(s)' matches the anyOf string/array type, but it does not expand on GID formats or usage details beyond what the schema already provides.

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 uses a specific verb ('Add') and resource ('follower(s) to a task'), clearly stating what the tool does. It implicitly distinguishes from sibling tools like asana_add_tag or asana_remove_follower by naming 'follower', though it does not explicitly call out alternatives.

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?

No guidance is provided about when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or context in which asana_remove_follower or asana_add_tag might be more appropriate. The usage is only implied from the tool name and description.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety and idempotency profile is covered. The description adds no extra behavioral detail beyond the operation itself, which is acceptable given the annotations, though it does not disclose any side effects like whether existing memberships are affected.

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?

A single sentence that states the action, resource, and gives a concrete example. No wasted words; the purpose is immediately clear.

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 simple operation with only two required parameters fully described by the schema and comprehensive annotations, the description is sufficient to invoke correctly. The lack of an output schema is not a major gap here since the operation is straightforward and no return value needs explanation.

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%, with both 'project_gid' and 'members' already described in the schema. The description does not add meaning beyond what the schema provides, so the baseline 3 applies.

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?

Description uses a specific verb ('Add') with a clear resource ('member(s) to a project'), and the example clarifies intent. It is easily distinguished from sibling tools like asana_add_to_project or asana_add_follower because it explicitly mentions 'project members'.

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 example 'add a teammate to a new board' provides an implied usage context, but there is no explicit guidance on when to use this tool versus alternatives like asana_add_follower or asana_add_to_project. No exclusions or alternative routing are mentioned.

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

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

Annotations already declare the operation is non-read-only, non-destructive, and idempotent, so the description's 'Add a tag' is consistent and does not contradict them. The description adds no extra behavioral context (e.g., duplicate-tag handling, prerequisites), but the annotation coverage keeps this adequate for a simple operation.

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?

A single sentence states the full action with no filler, and it front-loads the operation word and object. This is an appropriately minimal definition for such a simple tool.

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 two-parameter operation with complete schema descriptions and supporting annotations, the description is essentially complete; an agent knows what to call and with which identifiers. The only notable omission is routing among siblings, but that is covered by the usage dimension.

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 has 100% description coverage, and the two parameter names task_gid and tag_gid are self-explanatory alongside their 'GID' descriptions. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.

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 the exact operation (add), resource (tag), and target (task) in a complete verb+object construction. This naturally separates it from asana_remove_tag and asana_add_follower without requiring schema inspection.

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 guidance on when to use this tool instead of a sibling such as asana_remove_tag, asana_add_follower, or asana_set_custom_fields. An agent must infer appropriateness purely from the tool name and the description, with no explicit conditions or exclusions.

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

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

The annotations include idempotentHint=true, readOnlyHint=false, and destructiveHint=false, which already cover the basic safety profile. The description adds no additional behavioral context beyond the annotation-provided hints, such as how the API handles duplicate additions or what the response contains. Since annotations are present and not contradicted, a mid-range score is appropriate.

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 a single, concise sentence that is easy to parse. It is appropriately sized for a simple tool, though it could benefit from a brief note on usage or parameter specifics. No redundant or extraneous information is present.

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 simple add-to-portfolio operation with two required parameters and an existing annotations set, the description is mostly sufficient. However, it lacks explicit guidance on the required parameters (e.g., that both portfolio_gid and item_gid must be provided) and does not clarify what types of items are valid beyond 'project/portfolio item.' Given the sibling list includes asana_add_to_project and asana_remove_from_portfolio, a brief note on when to use this tool would improve completeness.

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 50%: 'item_gid' has a description ('Project or portfolio GID to add'), while 'portfolio_gid' has no description. The description text adds 'project/portfolio item' context but does not compensate for the undocumented 'portfolio_gid' parameter. The meaning of 'portfolio_gid' is inferable from the tool name but not explicitly stated in the description or 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 'Add a project/portfolio item to a portfolio' states a specific verb ('Add') and resources ('project/portfolio item' and 'portfolio'), making the tool's purpose clear. It is distinct from the sibling asana_remove_from_portfolio, which represents the opposite operation. However, it does not explicitly differentiate from other 'add' tools (e.g., asana_add_tag, asana_add_follower) beyond the resource name.

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 the tool is used when a project or portfolio item needs to be added to a portfolio, but it does not state when to use this tool versus alternatives like asana_add_to_project or asana_remove_from_portfolio. There is no explicit when/when-not guidance, though the resource naming ('portfolio') provides some context.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds the option of placing in a section, which is also captured by the section_gid parameter. It does not disclose any additional behavioral traits such as what happens if the task is already in the project, but the idempotent hint suggests safe repetition. No contradiction with 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 short and front-loaded with the core purpose. The second sentence ('Fixes: no MCP tool for addProject + section placement.') is a developer-oriented note that adds historical context but is not essential for invoking the tool. Overall, it is concise with minimal waste.

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 is simple with clear parameters and annotations, but since there is no output schema, the description does not explain what is returned. For a straightforward add-to-project operation, this may be sufficient, but the lack of any mention of return values or error conditions means an agent has to guess the response format.

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?

Input schema descriptions cover 100% of parameters, with clear descriptions for task_gid, project_gid, and section_gid. The description's mention of 'optionally placing it in a specific section' merely restates the section_gid schema description, adding no extra semantic value beyond what the schema already provides.

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?

Description clearly states the action ('Add a task to a project') and the optional section placement, distinguishing it from siblings like asana_remove_from_project or asana_add_tag. The verb 'Add' plus the resource 'project' makes the tool's purpose unambiguous.

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 (when adding a task to a project), but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The 'Fixes: no MCP tool for addProject + section placement' line provides some context but is not a clear usage guideline for an agent.

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

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

The description discloses important behavioral traits beyond the annotations: mandatory confirmation, read path restrictions via ASANA_MCP_FILE_ROOTS, and the 100MB size limit. These are safety-relevant details that the annotations do not provide, making the tool's behavior transparent and predictable.

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 a single, information-dense sentence that front-loads the core purpose and then packs three critical constraints (confirmation, path restriction, size limit) without any wasted words. Every part 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 mutation tool with side effects, the description covers the essential safety and scope constraints. There is no output schema, but return values are not critical for understanding how to invoke the tool. Minor details like error handling or overwrite behavior are absent, but the description is sufficient for correct invocation.

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 all parameters are already documented in the input schema. The description adds a global constraint (Max 100MB) and reinforces the confirmation requirement, but does not add parameter-specific semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 the action 'Attach a local file to an Asana task', using a specific verb and resource. It distinguishes itself from sibling tools that handle tags, followers, or task creation, leaving no ambiguity about what this tool does.

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 provides clear context for when to use the tool (attaching files) and includes critical usage conditions such as requiring confirm:true and path restrictions. It does not explicitly mention alternatives or when not to use it, but the use case is unambiguous.

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

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

The description states 'GET-with-default-fields ONLY' implying a read-only operation, but the annotations set readOnlyHint=false and idempotentHint=false, which contradict that. This creates confusion for an agent about whether the tool performs writes or mutations. The description contradicts 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 consists of two compact sentences and a parenthetical that front-load the essential constraint (GET-with-default-fields ONLY) and the task of routing to alternatives. There is zero wasted verbiage, and the key limitation is placed immediately after the purpose.

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?

Given the simplicity of the tool (only one array parameter, no output schema) the description covers the main limitations and alternatives. It lacks a mention of response formatting or pagination, but since these are not prevalent for batch calls and no output schema exists, the main usage and constraints are well covered. A minor deduction for absence of response details.

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 already describes the 'actions' parameter at 100% coverage, but the description goes beyond that by explaining that only GET with default fields is allowed and that opt_fields/completed_since and PUT data are dropped. This provides critical extra semantic context about how parameters behave in the batch endpoint.

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 the tool executes up to 5 Asana API operations in a single HTTP call, giving a specific verb (execute) and resource (Asana API operations). It additionally distinguishes itself from siblings by noting that filtered reads should use other tools and writes should use dedicated tools, making its purpose unambiguous against the large sibling list.

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?

Explicitly directs the agent on when and when not to use it: 'For filtered reads use asana_search_tasks/asana_list_*; for writes use the dedicated tools.' It also warns about the limiting behavior (options and PUT data are dropped) which defines the proper use case clearly.

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

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

The description adds no behavioral detail beyond 'update.' It does not state whether omitted fields remain unchanged, how html_notes interacts with notes, or whether custom_fields are merged or replaced. Annotations cover only mutation and non-destructiveness, so this missing partial-update semantics is a meaningful gap.

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 two concise, front-loaded sentences with no filler. The first sentence states the core action, and the second efficiently enumerates the field categories.

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?

Important context is missing, including partial-update behavior and what the tool returns (no output schema). It also does not guide the agent toward the right sibling tool or explain trade-offs vs. single-purpose setters, leaving an incomplete picture for a mutation with 9 parameters.

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 all parameters are already documented. The description adds little beyond grouping 'dates' and 'notes,' and the only cross-reference to another tool (custom_fields format) appears in the schema, not the description.

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 clear verb ('update'), a specific resource ('multiple task fields'), and lists the covered field categories, which maps well to the schema. It distinguishes itself from single-field helpers by signaling a combined update, but it does not explicitly differentiate from sibling asana_bulk_update or asana_batch_ops.

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 phrase 'in a single REST call' and 'Combines' weakly implies this should be used when multiple fields need updating together, providing some usage signal. However, no explicit when-to-use or when-not-to-use guidance is given, and alternatives like set_dates or set_custom_fields are not mentioned.

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

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.

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

Annotations already declare this is non-read-only (readOnlyHint: false), non-destructive (destructiveHint: false), and idempotent (idempotentHint: true). The description adds useful context by revealing it loops over section.addTask and returns a per-task summary, which helps set expectations about granular results. It does not cover failure modes or rate limits, but that is acceptable given the annotations already carry the core safety profile.

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?

Three sentences, each earning its place: outcome, return value, and use-case. The first sentence front-loads the core action and scale. No fluff, though the phrase 'Throughput multiplier for triaging a board column' is a bit informal it still conveys intent efficiently.

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 2-parameter, no-output-schema tool, the description covers the core action, the response format, and one practical use case. It does not address partial failures or edge cases, but these are relatively minor for bulk operations given the annotations cover idempotency and safety. Enough for a competent 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% (both task_gids and section_gid are documented in the schema itself). The description does not add extra syntax or format details beyond the schema, so the parameter semantics score defaults to the baseline of 3. No compensation required.

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 uses a specific verb ('Move') and resource ('MANY tasks into one section') and distinguishes itself from the single-move tool by explicitly stating it does bulk work in a single call. This makes the purpose unambiguous even among siblings like asana_move_section.

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 provides a clear usage context ('Throughput multiplier for triaging a board column'), indicating it is for bulk/triaging operations. It does not explicitly list when not to use it or mention alternatives, but the emphasis on 'MANY' and 'single call' implicitly routes agents to this tool for bulk moves rather than single-task moves.

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

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

Explicitly discloses the internal looping behavior (Loops PUT per task), failure handling (continues past individual failures), and return format (per-task summary). This goes significantly beyond annotations that only declare readOnly=false, idempotent=true, and destructive=false, providing essential execution semantics.

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, front-loading the defining characteristic ('SAME field changes') and packing in behavior, error handling, and output summary. Every word 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?

The description covers the core calling pattern, failure behavior, and return summary, which is strong for a tool with no output schema. Missing only minor details like batch size limits or rate-limit implications, but overall an agent can invoke and interpret results 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% and the description merely lists the same parameter categories ('assignee, dates, completed, notes/html_notes, custom_fields') without adding meaning beyond what the schema already documents. It does not elaborate on the custom_fields structure or edge cases, so baseline 3 applies.

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 ('Apply') and resource ('MANY tasks') with the key 'SAME field changes' qualifier, distinguishing it from per-task update tools. It lists the exact fields it can update, leaving no ambiguity about scope.

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 bulk use via 'MANY tasks in one call' but does not explicitly say when to prefer this over alternatives like asana_batch_update or asana_set_dates. No when-not-to-use guidance is provided, though the 'SAME field changes' constraint is a clear condition.

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

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

Annotations already indicate the mutation is non-read-only, idempotent, and non-destructive. The description adds the toggle behavior and default value, but does not disclose side effects such as completion timestamps, notifications, or the response shape. It does not contradict 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 a single, front-loaded sentence with no filler. It communicates the core operation and the key parameter variance in minimal space.

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 simple two-parameter toggle operation with strong annotation coverage, the description is sufficient for correct invocation. It lacks explicit alternative routing and some post-condition detail, but those are minor given the schema and idempotent/non-destructive annotations.

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 coverage is 100%, so the schema already documents both parameters and their meanings. The description repeats the completed:false behavior but does not add meaningful semantic detail beyond what the schema provides.

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 uses a specific verb-resource pairing ('Mark a task complete') and clearly covers both directions: complete by default and incomplete via completed:false. This is unambiguous and distinguishes the tool's purpose from sibling tools that read or update other task properties.

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 implicitly indicates this tool is for changing task completion state, and the completed parameter explains the two modes. However, it does not explicitly say when to prefer this over alternatives like batch_update or bulk_update, nor does it mention any preconditions or 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.

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is covered. The description adds the 'design the board schema' contextual note but does not disclose side effects or prerequisites beyond the schema. No contradiction with 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?

Two compact sentences deliver the essential purpose, subtype constraint, and enum_option guidance with no filler. The key information is front-loaded and every word contributes.

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?

Given a 6-parameter tool with full schema coverage and no output schema, the description covers the core usage and special cases effectively. It could mention return behavior or error conditions, but for a create operation the essential details are present.

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 baseline is 3. The description adds a concise reminder of the resource_subtype enum and the enum_options structure, which slightly reinforces the schema but doesn't provide extra semantic depth beyond what the schema already defines.

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 uses a specific verb 'Create' with a clear resource 'workspace custom field' and adds 'design the board schema' to signal its intent. It distinguishes itself from sibling tools like get_custom_field or add_enum_option by specifying creation and subtype guidance.

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 gives concrete guidance for enum/multi_enum subtypes (pass enum_options), which helps with conditional usage. However, it does not explicitly state when to use this vs. alternatives like add_enum_option or update_project, leaving some ambiguity for the agent.

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

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

Annotations already indicate non-read-only, non-destructive, and open-world behavior, so the description bears a lower burden. However, it adds no extra behavioral context such as required permissions, side effects, or response format. The description neither contradicts nor meaningfully supplements the annotations, so a mid-range score is appropriate.

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 a single, concise sentence that front-loads the core verb and resource. The parenthetical adds contextual value without unnecessary verbosity, earning a strong score for efficiency.

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?

Given the tool creates a portfolio, the description does not address return values, required fields beyond the schema, or any additional context like workspace specificity. The parenthetical purpose hint is helpful but insufficient for a complete understanding; the missing parameter explanations and lack of usage guidance leave notable gaps.

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 0%, and the description provides no explanation of what the 'name', 'color', or 'workspace' parameters mean or how they should be formatted. The description entirely fails to compensate for the lack of schema documentation, leaving the agent without any guidance on parameter usage.

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 the action ('Create a portfolio') and adds a parenthetical explaining its purpose ('group projects for North-Star-style tracking'). It distinguishes itself enough from sibling tools like asana_create_project by naming the 'portfolio' resource, though it does not explicitly contrast with related portfolio tools.

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?

No guidance is given about when to use this tool versus alternatives. The description only explains what the tool does, not the scenarios or prerequisites for creating a portfolio, nor does it mention sibling tools like asana_add_to_portfolio or asana_create_project.

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

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

Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds the behavioral nuance about team/workspace default handling. It does not disclose other behaviors like return value or permission requirements, but given annotation coverage, a 3 is appropriate.

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 core action is front-loaded, and the key conditional (team GID requirement) is stated immediately after. Every word 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 create operation with 7 parameters, the description covers the critical context (team requirement and workspace default). It does not mention return values, but given that no output schema exists and the operation is straightforward, the description is still sufficiently complete for an agent to invoke 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?

The schema provides 100% description coverage for all 7 parameters, so the description itself does not need to add parameter-level detail. The baseline of 3 applies because the schema does the heavy lifting.

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 and resource: 'Create a project.' It clearly distinguishes this from sibling tools like asana_update_project or asana_delete_project. The additional context about team GID requirements further clarifies the scope.

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 gives explicit usage guidance for when a team GID is required (org workspace) versus when the workspace default is used. It does not explicitly name alternatives, but the condition is clearly stated for the primary decision point.

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

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

Annotations already cover the basic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds no behavioral context beyond that, such as side effects (e.g., notifications, story creation), authentication needs, or rate limits.

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 extremely concise: one sentence plus a succinct parameter note. It front-loads the action and avoids any filler, earning a high score for efficiency.

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 tool with 6 parameters and no output schema, the description is too sparse. It lacks usage context, behavioral nuance, and any explanation of expected outcomes or return values, leaving significant gaps for an agent.

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 baseline for parameter semantics is 3. However, the description states 'text required', which directly contradicts the input schema's required fields (only project_gid and status_type are required). This misleading information reduces the score.

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 ('Post') and resource ('status update to a project'), clearly indicating the action. It does not explicitly differentiate from sibling tools like 'asana_update_project' or 'asana_list_project_statuses', but the purpose is unambiguous on its own.

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 provides no guidance on when to use this tool versus alternatives, nor any exclusions or conditions. It simply states what the tool does, leaving the agent to infer the appropriate context.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-non-destructive nature is known. The description adds no behavioral context beyond restating the creation action, such as permissions, side effects, or response behavior. No contradiction exists, but no extra transparency is provided.

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 one tight sentence that states the core action and the optional positioning feature. There is no wasted wording, and the essential information is front-loaded.

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 simple creation tool with 4 parameters all documented in the schema, the description is adequate but not complete. It omits details like behavior when both insert_before and insert_after are set, and since there is no output schema, it does not mention return values. These are minor gaps but prevent a higher score.

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 every parameter is described in the schema. The description mentions insert_before/insert_after by name but adds no new semantic detail beyond what the schema already provides; baseline 3 is appropriate.

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 uses a specific verb ('Create') and a clear resource ('a new section in a project'), with optional positioning detail. This unambiguously distinguishes it from siblings like update_section, delete_section, and move_section.

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 the tool is for creating new sections, but does not explicitly state when not to use it or mention alternatives. For example, it does not indicate that moving an existing section should use move_section, so usage guidance is only implicit.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds no additional behavioral context, such as potential side effects, permission requirements, or return behavior. It neither contradicts nor enriches the annotation information.

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?

A single, clear sentence with no filler words. It is appropriately brief for a simple operation, though it skips any usage guidance that could be additively included without bloating the text.

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 7 parameters fully documented in the schema and annotations covering the safety profile, the core calling contract is present. However, the description omits any context about typical workflows, relationship to parent tasks, or differences from creating a standalone task, which would help an agent reason about when to choose this tool.

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%, with each parameter having a clear description. The tool description itself adds no parameter-level detail, so the schema carries the full burden. Baseline of 3 is appropriate since the schema is fully self-explanatory.

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 uses a specific verb ('Create') with a clear resource ('a subtask') and scope ('under a parent task'). This unambiguously differentiates it from sibling tools like asana_create_task or asana_create_section.

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?

No guidance is provided about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description leaves it to the agent to infer that this is for subtask creation only, with no mention of when parent task creation would be more appropriate.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write nature is covered. The description adds context like "workspace inferred" and "dates auto-wrapped," but these largely echo the schema descriptions rather than revealing new behavioral traits beyond what structured fields already provide. No contradiction with annotations exists.

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?

Three sentences with no filler: the first states the action, the second clarifies the key projects-vs-default decision, and the third lists supported fields. Information is front-loaded and 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?

The description covers the essential usage decision (projects vs default workspace) and lists supported parameters, which is adequate for a create operation. However, since there is no output schema, it does not mention what the tool returns (e.g., the created task object), and it omits any error/edge-case context. Given the 11-parameter richness, a bit more detail would improve completeness.

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 already has an explanatory description. The description mentions supported features (assignee, notes, dates, etc.) but adds no new semantic information beyond what the input schema already provides. The baseline of 3 applies since the schema does the heavy lifting.

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 "Create a general task" with a specific verb and resource, distinguishing it from siblings like asana_create_subtask and asana_create_project. It also clarifies the key scoping decision between providing projects or using the workspace default, leaving no ambiguity about what the tool does.

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 provides clear context on how to choose between specifying projects (workspace inferred) or letting the task land in the workspace default. However, it does not explicitly mention when not to use this tool or point to alternative tools like asana_create_subtask, so it stops short of full when/when-not guidance.

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

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

Annotations already mark this as destructive and read-only. The description adds valuable behavioral context by disclosing the confirmation requirement and the no-op behavior when confirm is false, which is beyond what annotations convey. It does not contradict 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 exceptionally concise, using a single imperative sentence plus a short note. It front-loads the destructive warning and delivers all critical information without any filler or redundant phrasing.

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 destructive operation, the description covers the essential gate and no-op fallback, and the annotations provide the safety profile. It does not mention return values or side effects beyond deletion, but for a simple project delete with confirm-gating, this is nearly 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?

With 0% schema description coverage, the description must compensate for parameter documentation. It briefly explains the confirm parameter via the gate condition, but does not describe project_gid at all. Since project_gid is self-explanatory from the tool name, the partial coverage is adequate but not thorough.

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 'permanently delete a project', which is a clear verb+resource combination. It differentiates from siblings by emphasizing the destructive, permanent nature, making it distinct from update or create operations.

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 provides a critical usage condition: 'Requires confirm:true (C13 gate)' and explains that it becomes a no-op otherwise. However, it does not mention when to avoid this tool or suggest alternative tools, leaving the usage context partially implied rather than explicit.

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

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

Annotations include destructiveHint=true and idempotentHint=true, and the description reinforces these by saying 'DESTRUCTIVE' and adding the key behavioral detail that Asana requires the section be empty or it moves its tasks out. It also discloses the confirm:true gate.

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?

Single compact sentence with the destructive warning front-loaded and all necessary info packed in without 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?

Covers destructive behavior, precondition about empty section, and required confirm flag. It does not mention return value or error cases, but with no output schema and simple params, the essential call context is present.

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 has 0% description coverage, so the description must compensate. It mentions confirm:true explicitly, but does not explain section_gid format or behavior. It adds some meaning but leaves a gap for the main required parameter.

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 verb ('delete') and resource ('a section'), and the parenthetical about empty/moves tasks out adds precision that distinguishes it from update/reorder siblings.

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?

It implicitly conveys a destructive operation and signals when to use it (when deleting a section) but doesn't explicitly name alternatives or exclusion conditions. The confirm gate adds a usage prerequisite.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds valuable nuance beyond annotations: the specific confirmation gate, the no-op behavior without confirm, and the permanence of the deletion. No contradiction with 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?

Two sentences with zero wasted content. The destructive warning is front-loaded, the confirmation requirement is explicit, and the consequence of a false confirm is stated.

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 simple delete with two fully-schema'd parameters and annotations covering destructive/idempotent behavior, the description provides all needed operational detail: the confirmation gate, the no-op consequence, and permanence. Nothing essential is missing.

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 coverage is 100%, so both parameters are already well described in the schema. The description adds semantic clarity for the 'confirm' parameter (that it gates the operation and produces a no-op report), but this is marginal beyond an already excellent 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?

Description states a specific verb ('delete') and resource ('task'), clearly naming it as a permanent (trash) deletion. It is unambiguous and distinguishes itself from mutation tools like asana_update_project and asana_set_dates.

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?

Description provides explicit context on when it takes effect: 'Requires confirm:true (C13 gate)' and when it does not ('Without confirm it is a no-op'). It does not name alternative deletion tools (e.g., asana_delete_project), but the action is specific enough that selection is unambiguous.

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

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

Annotations already mark this as not read-only, not idempotent, and not destructive, so the description's main contribution is clarifying the operation returns an async job. This is critical for the caller to know the result is not immediate and provides useful behavior beyond annotation defaults.

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 unnecessary text. The core action is front-loaded, and the additional sentence explains the include parameter and async return, giving high information density without redundancy.

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?

Although the description covers the basic action and return type, it leaves gaps: it does not explain how to interact with the async job (e.g., polling via asana_get_job), and the phrase 'clone a board with its structure' is ambiguous about whether tasks are included or only empty structure. With no output schema, these missing details reduce self-sufficiency.

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 already has a documented meaning. The description only adds detail for the 'include' parameter with an example list of allowed fields and clarifies it can be an array or comma string, which is a modest enhancement beyond 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 clearly specifies the action ('Duplicate') and the resource ('existing project'), with a parenthetical clarifying it means cloning a board and its structure. This distinguishes it from siblings like create_project, update_project, and duplicate_task.

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 the use case (copying an existing project) but does not explicitly state when to choose this tool over alternatives, nor list any exclusions or preconditions. Usage is inferred from the action rather than guided.

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

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

The description discloses that the tool 'Returns an async job', a behavioral trait not captured by the annotations (readOnlyHint=false, destructiveHint=false). It also clarifies the role of the 'include' parameter. This adds meaningful context beyond the structured 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 and front-loaded. It consists of a clear purpose statement, a brief elaboration of the 'include' parameter, and a note about the async return. Each sentence contributes useful information with no fluff.

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 description provides the essential information for calling the tool: the action, the key parameter, and the async return behavior. It could mention how to track the async job (e.g., via asana_get_job), but this is inferable from the sibling list. Annotations cover safety and schema covers parameters, so the overall package is nearly 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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds an example for 'include' and clarifies its format, but this largely reinforces schema info rather than providing substantial new meaning. Baseline 3 is appropriate since the schema does the heavy lifting.

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 the operation as 'Duplicate a task' and adds 'template instantiation' for context, making the verb and resource explicit. However, it doesn't explicitly differentiate from related siblings like asana_instantiate_task_template or asana_create_task, so it stops short of full sibling distinction.

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 purpose 'Duplicate a task' implies when to use it, but there is no explicit guidance on when not to use it or which alternative to choose (e.g., asana_create_task for new tasks, asana_instantiate_task_template for template-based creation). Usage context is implied rather than articulated.

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

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

Beyond the readOnlyHint annotation, the description adds critical behavior: multi-homed tasks are NOT duplicates, and deleting one removes the task from every board. It also announces the return structure. This goes well beyond the annotations and prevents a common destructive mistake.

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 dense but efficiently engineered: the core purpose and the key non-intuitive warning (multi-homed vs duplicate) come first. It's a single structured run-on sentence with clear punctuation, packing in purpose, scope options, output contract, and a safety warning without any empty 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 a read-only, no-output-schema tool with 5 optional parameters, the description covers the dedup logic, the scan scopes, and the returned object shapes. It lacks details on pagination (max_pages) and completion filter, but those are present in the schema with descriptions. Nothing needed for correct invocation is missing.

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 already covers 80% of parameters. The description adds cross-board semantics for 'projects' and clarifies that 'project', 'section', and 'projects' are alternative scan scopes. It does not explain 'max_pages' or 'include_completed' beyond the schema, but those have descriptions and the description intentionally focuses on the selection logic.

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 exactly what the tool does: it finds TRUE duplicate tasks and distinguishes them from multi-homed (shared) tasks. It names the verb, the resource (tasks), and the specific dedup logic, which clearly differentiates it from sibling tools like asana_duplicate_task and asana_delete_task.

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?

It gives concrete scope guidance: scan one project/section or pass multiple projects for cross-board dedup. It also tells the agent to 'reason before you delete', implying the primary use case is pre-deletion analysis. However, it does not explicitly name alternative tools or state when NOT to use this tool, relying on implication rather than direct comparison.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds specific behavioral detail about the response: it returns type, precision, and the fully populated enum_options list (name+GID). This goes beyond the annotations without contradicting them and gives the agent a clear expectation of the returned payload structure. It does not, however, disclose pagination or error behavior, but for a fetch-one-via-GID operation this is largely harmless given the annotation coverage.

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 a single, dense sentence with no redundant words. It front-loads the primary action and identifier, then concisely enumerates the useful response components. Every word contributes to the agent's understanding, with no filler or repetition.

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?

Given that the tool is a simple fetch of a single resource by its ID, and there is no output schema to rely on, the description covers the essential invocation material: what the tool does, what key parameter to supply (GID), and what the response will include. It does not mention any error scenarios or whether custom_field_gid is a path parameter or query parameter, but the annotation/openWorldHint and the simplicity of the operation make this adequate. The only missing piece is detailed context for the opt_fields parameter, which is already handled by the schema description. Overall, it is sufficient for an agent to call this tool 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?

The schema documents only opt_fields (50% coverage) with a detailed explanation, while custom_field_gid lacks any description. The description says 'by GID' but adds no additional semantic value about custom_field_gid (e.g., it's a required string identifier) or how opt_fields interacts with the default returned fields. The schema already explains opt_fields well, so the description contributes essentially nothing to parameter meaning. Since the unannotated custom_field_gid parameter is the primary one, this is a notable gap.

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 the precise action (favorite 'fetch' vs 'get'), the target resource (custom field), the identifier (by GID), and explicitly lists the returned data components (type, precision, full enum_options name+GID list). This clearly differentiates it from sibling listing tools like asana_list_workspace_custom_fields and provides an agent with a complete purpose statement.

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 (fetch a specific custom field when you have its GID) but does not explicitly state when to use this tool over alternatives, nor does it mention any conditions or exclusions. It is only through the name and the sibling list that one can infer it is for individual field retrieval, not mass retrieval or manipulation. This is sufficient for a simple read operation but below the explicit bar for when/alternatives guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that data is 'live' and lists the GID types returned, which is useful behavioral context about the output, though it doesn't disclose other traits like pagination behavior or rate limits. This is adequate given the annotation coverage.

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 zero filler. The first sentence states the action and output; the second provides the usage rationale. Every word earns its place, and the key information is front-loaded.

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 simple read-only fetcher with a well-described schema, the description communicates the purpose, output content, and a motivating use case. It omits details like response shape or edge cases, but the schema covers parameters and annotations cover safety, making it sufficiently complete for invocation.

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 100% description coverage—each parameter (limit, max_pages, opt_fields, project_gid) is described. The description itself adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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 uses the specific verb 'Fetch' with the resource 'a project's custom field settings' and specifies the returned content: live field GIDs, types, and enum option GIDs. This clearly distinguishes it from sibling tools like asana_get_custom_field (single field) and asana_list_workspace_custom_fields (workspace-level).

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 explicitly advises using this tool to 'derive field/option GIDs live instead of trusting hand-coded maps that drift', giving a clear use case and rationale. It does not name sibling alternatives or list when not to use it, but the context is strong enough for an agent to choose this tool for live project-specific data.

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

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

Annotations already provide readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context about the polling lifecycle and returned statuses. However, it does not mention potential errors, timeouts, or how long to wait between polls, which would strengthen transparency.

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 waste. The purpose, source context, and return values are all front-loaded. Every word contributes to understanding.

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 simple polling tool with no output schema, the description covers the essential return structure (status and new GID) and usage context. It lacks details on retry behavior or error handling, but given the tool's simplicity and annotations, it is sufficiently complete for correct invocation.

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 provides 100% coverage for both parameters (job_gid and opt_fields) with descriptions. The description only mentions the role of job_gid implicitly. Since the schema covers full parameter meaning, a baseline of 3 is appropriate, and the description does not add significant extra semantic value beyond 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?

Description clearly states the tool polls an async job by GID, specifies the originating tools (duplicate_task/duplicate_project/instantiate_*), and lists the returned status values and result GIDs. It is distinct from sibling tools which perform actions like creating or deleting, not polling.

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 it (after initiating async operations) and provides context through the GID source. It does not explicitly state when not to use it or name alternatives, but the polling purpose is clear enough for an agent to select it for this scenario.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds context beyond the annotations by revealing the optional behavior of include_items (that it also returns member projects/portfolios when true). It does not add deeper details like error handling or edge cases, but it does not contradict any annotation.

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 a single, compact sentence containing the essential verb, resource, and a key optional behavior. It is front-loaded and directly actionable, with no filler or repeated structural details. The phrase 'Fetch one portfolio' immediately sets the domain, and the include_items note provides added value without bloating the text.

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?

Given the tool is a simple read-only fetch operation with three parameters (all schema-documented) and no output schema, the description covers the primary action and the most relevant optional flag. The user does not need extra detail on return format since no output schema is provided, but the description its still sufficient for an agent to invoke correctly. The lack of explicit error handling or alternative hints is minor.

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 has 100% description coverage for all parameters: portfolio_gid, include_items, and opt_fields each already have descriptive text. The main description restates include_items's effect but does not add novel semantics beyond that. Per the rubric, a baseline of 3 is appropriate given schema coverage is high (>80%). The description does not prevent misunderstanding.

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 and resource ('Fetch one portfolio'), making the core purpose clear. It is distinguishable from siblings like asana_list_portfolios (which lists) and asana_get_project (different resource type), although it does not name these alternatives explicitly. The mention of include_items for pulling member projects/portfolios adds specificity.

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 (when you need a single portfolio by GID) and provides guidance on the include_items parameter to optionally get nested items. However, it does not explicitly state when to prefer this over list_portfolios or other get-style tools, nor does it offer exclusion criteria. The context is clear enough for an agent to infer, but formal alternatives are not mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that the response merges custom_field_settings and sections, which is useful behavioral context. It does not discuss pagination, errors, or permission requirements, but those are less critical for a read-only fetch.

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?

Single sentence with zero waste; it front-loads the main purpose and then specifies the key additions. Every word 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?

Given the read-only annotations and the clear statement of what is returned (project plus custom_field_settings and sections), the description is nearly complete. Minor missing context about output structure or error behavior is not critical for this simple fetch tool with no output schema.

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%: project_gid is described as 'Project GID' and opt_fields has a detailed description. The tool description adds no further parameter meaning, so baseline 3 applies since the schema does the heavy lifting.

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?

Description clearly states the verb ('Fetch'), resource ('one project'), and specific inclusions (custom_field_settings with field GIDs + enum option GIDs, plus sections), and notes they are merged into one response. This distinguishes it from sibling tools like asana_list_projects, asana_get_custom_field_settings, and asana_list_sections.

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 this tool is for fetching a single project with its related settings and sections in one call, but it does not explicitly state when to choose this tool over alternatives (e.g., when you only need sections, use asana_list_sections). No explicit exclusions or alternative routing is provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the default rich field set and opt_fields override behavior, but does not discuss edge cases like missing tasks or response format. This is acceptable given 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?

Two concise sentences deliver the essential information with no filler. The core action and the key customizability are front-loaded, making it easy to scan.

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 single-task fetch operation with annotations covering read-only and idempotent behavior, the description is sufficient. It lists the notable returned fields and explains opt_fields usage. A minor gap is the lack of explicit mention of the response shape, but the field list mitigates this.

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%, with both task_gid and opt_fields clearly documented with examples. The description restates that opt_fields can override defaults but adds no semantics beyond what the schema already provides, so a baseline 3 is appropriate.

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 ('Fetch') and resource ('one task') and enumerates the rich fields returned (assignee, projects, section memberships, custom fields, notes, subtask count). This clearly distinguishes the tool from list/search variants and leaves no ambiguity about what it does.

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 the tool is for fetching a single task and mentions how to adjust opt_fields, but it does not explicitly contrast with alternatives like list_tasks or search_tasks. The usage context is understood but exclusionary guidance is absent.

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

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

Annotations already state readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds minimal behavioral context beyond returning fields. It does not contradict annotations. The description clarifies the default 'me' resolution and the output fields. With annotations providing safety profile, the bar is met but not exceeded.

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 short sentences, no filler. The key info—what is fetched and default behavior—is front-loaded. Every word 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?

Given the simple tool, no output schema, and clear annotations, the description covers the essential usage. It could mention that opt_fields overrides the default fields, but that is also in the schema, and the description's coverage is sufficient for correct invocation.

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 coverage is 100% and both parameters are described. The description does not add extra semantics beyond what the schema provides. The default 'me' is already noted in the schema description. Baseline 3 applies.

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 it fetches one user by GID with a default 'me' and returns name, email, and GID. It does not explicitly contrast with sibling asana_list_users, but the specific resource (single user vs list) is evident. The verb 'Fetch' and resource 'one user' are specific enough.

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 by indicating how to specify the user (GID or 'me') and mentions the default. It does not explicitly state when to prefer this over asana_list_users or when not to use it. However, the default 'me' and single-user scope signal the use case of retrieving a specific or current user.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond noting the returned metadata fields; it doesn't discuss default workspace auto-detection or opt_fields behavior, but nothing contradicts 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 a single, focused sentence that names the resource and core output fields without any filler or redundancy. It is concise and front-loaded with the essential scoping information.

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 simple read-only metadata fetch with no output schema, the description covers the primary intent and return fields. Missing return format details are minor given the tool's simplicity and the annotations covering safety and idempotency.

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%: both workspace and opt_fields are documented in the schema with clear descriptions. The tool description adds no further parameter explanation, so it relies on the schema, which is sufficient.

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 uses the specific verb 'Fetch' and identifies the resource as workspace metadata, listing the exact fields returned (name, is_organization, email_domains). This clearly distinguishes it from sibling tools like get_project or get_portfolio.

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 a straightforward read operation for workspace details but provides no explicit when-to-use guidance or alternatives. It's adequate for a simple fetch tool, but lacks exclusion criteria or comparison to related tools.

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

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

The description adds a key behavioral detail beyond the annotations: the operation returns an async job whose new_project field holds the created project, signaling that results may not be immediate. Since annotations already establish non-read-only, non-idempotent, non-destructive behavior, this extra disclosure about async execution is valuable.

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 deliver action, context, and return shape with no redundant wording. The parenthetical 'repeatable board setup' earns its place by clarifying the template concept, and the return behavior sentence is essential.

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?

Despite lacking an output schema, the description tells the agent what will be returned (async job with new_project), which is enough to know how to retrieve the result. It does not cover asynchronous polling or error handling, but for a four-parameter tool with well-documented inputs, this is reasonable.

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 every parameter is already documented. The description does not elaborate on parameter relationships or business rules, sticking to the baseline where the schema carries the semantic load.

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 uses a specific verb and resource: 'Create a new project from a project template,' which clearly distinguishes it from blank project creation and task template instantiation. However, it does not explicitly name or contrast sibling tools like asana_create_project or asana_instantiate_task_template, leaving some differentiation to inference.

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 provides no guidance on when to prefer this tool over alternatives or when not to use it. It neither names sibling tools nor states conditions such as 'use for repeatable setups' as a routing rule, so the agent receives no usage context beyond the action itself.

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

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

The description goes beyond annotations by disclosing the asynchronous behavior: 'Returns an async job whose new_task holds the created task.' This is a critical behavioral trait not captured by readOnlyHint, destructiveHint, or idempotentHint, and it tells the agent what response shape to expect despite the absence of an output schema.

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 a single, tightly packed sentence that front-loads the action, adds a useful parenthetical about the use case, and ends with the return behavior. Every word earns its place with no redundancy.

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 simple two-parameter tool with no output schema, the description covers action, purpose, and return value adequately. It also differentiates the tool from siblings and notes the async mechanics, providing everything an agent needs to invoke 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% because both parameters have descriptions in the input schema ('Name for the new task' and 'Task template GID'). The description itself adds no additional parameter-level context, so the baseline of 3 applies.

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 the tool creates a new task from a task template, using the specific verb 'Create' and identifying the resource. It distinguishes itself from sibling tools like asana_create_task (which creates from scratch) and asana_instantiate_project_template (which creates a project) by explicitly mentioning 'task template' and 'repeatable intake/ops task'.

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 repeatable intake/ops tasks where a task template exists, but it does not explicitly state when to use this tool versus alternatives like asana_create_task or how to obtain a template GID. There is no direct 'instead of' or 'use when' guidance, so the context is clear but exclusions are absent.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety traits are covered. The description adds value by stating the output includes 'download/permanent URLs and sizes', which provides behavioral context about the return payload.

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 a single sentence, front-loads the subject and scope, and includes a valuable output detail. Every word is necessary and there is no redundancy.

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 is simple (list attachments for a task), no output schema exists, but the description covers core behavior and output. Pagination are parameters handle pagination details. No missing information that an agent needs to invoke 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% per context signals, so all parameters are already documented. The description does not supplement any parameter semantics; it only restates the tool's purpose. The baseline is 3, which is appropriate.

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 the verb 'List' refers to 'a task's attachments' and includes specific output details (URLs and sizes). This is differentiable from sibling tools like list_subtasks or list_stories, which target different resources.

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 provides no explicit when-to-use or exclusion criteria. The tool name and description imply its purpose, but there is no guidance on when to choose it over alternatives or mention of prerequisites beyond task_gid.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the behavioral nuance that both directions (dependents and dependencies) are returned simultaneously, which is useful but not extensive; no pagination or format details are disclosed.

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?

A single well-structured sentence that front-loads the primary action ('Return'), specifies both outputs, and includes clear parenthetical definitions. Every word contributes, with no redundancy.

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 simple read-only tool with one parameter and full annotation coverage, the description sufficiently conveys the core functionality. It lacks explicit output format details, but given no output schema and the straightforward nature of the listing, the information is adequate for correct invocation.

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 already documents task_gid as 'Task GID' with 100% coverage. The description does not add parameter-specific meaning beyond indicating the task context. With a single fully documented parameter, the description has little room to add value.

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?

Description clearly states the tool returns both dependencies and dependents, with parenthetical explanations defining each direction. It distinguishes itself from sibling tools like asana_add_dependency and asana_add_dependent by focusing on listing rather than modifying.

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 phrase 'in one call' implies a combined retrieval use case, and the description clearly defines what the tool returns. However, it does not explicitly state when to use it instead of alternatives or provide exclusions, though no direct alternative exists among siblings for listing both directions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe read. The description adds the behavioral detail that results are 'Paginated' and that the default owner is 'me'—useful context not in annotations. However, it does not disclose any other behavioral nuances like rate limits, response shape, or how pagination tokens work. Given the annotation safety coverage, a score of 3 is appropriate.

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 exceptionally concise: one core action clause, one default-value note, and one pagination qualifier. No filler words, no redundant prose. The most important information ('list portfolios owned by a user') is front-loaded, making it trivially easy to parse. Every sentence contributes unique value.

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?

Given the moderate complexity (five optional parameters, all documented in schema) and annotations that establish read-only/idempotent behavior, the description is almost complete. It explains the primary scoping and pagination. Without an output schema, a more explicit note about the return format (e.g., an array of portfolio objects) would elevate completeness, but for a straightforward list resource in a well-known domain, the current description suffices. Not a full 5 because the exact response structure is unaddressed.

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 description coverage is 100%, so all five parameters are already documented, including defaults (owner defaults to 'me', max_pages default 20, etc.). The description repeats the default owner but adds no new meaning beyond the schema. Since the schema fully carries the parameter semantics, a baseline score of 3 is justified.

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?

Description starts with action 'List' followed by the resource 'portfolios' and limits scope to a user's ownership within a workspace. It clearly distinguishes this from sibling list tools (e.g., asana_list_projects, asana_list_tasks) by naming portfolios specifically. The title and description align, adding clarity.

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 tells what the tool does (list portfolios owned by a user in the workspace) but provides no explicit guidance on when to use this tool versus alternatives like asana_get_portfolio for a single portfolio or asana_create_portfolio for creation. It also omits prerequisites or context such as 'workspace' / 'owner' resolution. No exclusions or alternative conditions are given, so the agent is left to infer usage.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral details beyond annotations by noting the archived filter default behavior and pagination, which helps the agent understand the tool's output and the effect of include_archived without overstepping.

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 three short sentences with no fluff. The main action is front-loaded, followed by a key default behavior and a pagination note, all necessary information without repetition.

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 read-only list tool with comprehensive schema descriptions and readOnly annotations, the description covers essential operational context: workspace/team scope, archived filtering, and pagination. No output schema exists, so return value details are not required. Minor gaps like how pagination is controlled (cursor vs page) are already explained via the limit/max_pages parameter descriptions.

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 parameters are already fully documented. The description adds minor reinforcement by mapping 'workspace (or a team)' to workspace/team parameters and mentioning pagination relates to limit/max_pages, but does not introduce new semantic depth.

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 the verb 'List' and the resource 'projects', and scopes it to 'the workspace (or a team)'. This provides a precise purpose and distinguishes it from other list tools like list_tasks or list_teams by naming the resource explicitly.

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 it: for listing projects at workspace or team scope, and indicates a key filter behavior (archived excluded by default, can be included). It doesn't explicitly name alternative tools, but the scope is clear enough for an agent to select this over get_project or list_sections.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds a note on pagination and the field set returned, which is useful, but does not cover error conditions, rate limits, or any side effects. The bar is lowered because annotations cover the core safety, so this is adequate but not copious.

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 two short sentences: first the core purpose and the fields, then a note on pagination. Every word serves a purpose, and the main action is front-loaded. There is no filler or redundancy.

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 is a simple list, and the description gives the returned fields and that pagination is present. Without an output schema, the description omits how the response is packaged (e.g., whether items are embedded or a token is returned) and how the pagination actually ends. However, for a basic list operation with no complex parameters, this is minimally sufficient; it could be improved by stating the default field subset and the meaning of the pagination token.

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 all four parameters (limit, max_pages, opt_fields, project_gid) have meaningful descriptions in the schema itself. The tool description does not add any value on top of the schema—it only repeats the domain of status updates. Since the schema already documents the parameters adequately, a baseline 3 is appropriate.

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 the action (List), the resource (project's status updates), and the specific fields returned (status_type, title, text, author). It distinguishes itself from creating status updates (asana_create_project_status) and from listing other resources like tasks or sections, even without explicitly naming them. The verb+object structure is precise and unambiguous.

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?

No guidance is provided on when to use this tool versus others. There is no mention of alternatives, exclusions, prerequisites (e.g., project GID required), or surrounding conditions like whether this is read-only. Agents receive no hint about when to prefer this tool over list_stories or list_tasks.

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

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

The annotations already mark this as readOnlyHint: true, destructiveHint: false, and idempotentHint: true, so the description correctly aligns with those by describing a read operation. Beyond the annotations, the description adds valuable behavioral context: the returned field set (name + GID) and the fact that results are ordered 'in board order'. This goes beyond what the annotation flags communicate, hence the high-4 score; however, it does not mention pagination or a default limit, which would make it fully transparent.

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 a single, tightly written sentence that immediately names the action and the resource. It front-loads the primary intent ('List the sections') and appends the read elements returned (name + GID) and the ordering (board order). Every segment carries meaning; there is no fluff or repetition of what the title already exprtes.

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 is a simple list operation with only two parameters, and the description covers the primary output property (name + GID) and ordering information, which compensates for the lack of an output schema. However, given no output schema exists, it could be slightly more explicit about the shape of the return (e.g., multiple section objects) or whether it requires authentication on the project. But with the annotations already covering the read-only and idempotent safety profile, the description is adequate and almost complete, missing only minor details.

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%, meaning both parameters (project_gid and opt_fields) have schema-level descriptions, including a detailed explanation of opt_fields and the fact that project_gid is the project's GID. Since the description adds no parameter-specific facts beyond the schema, it is sufficient at the baseline level. The description gives high-level context about what the tool does but leaves parameter meaning to the schema, which is a fair balance for a list tool with only two parameters.

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 clear verb and resource: 'List the sections of a project', making it obvious the tool retrieves sections that belong to a specific project by GID. It calls out the output shape (name + GID) and ordering ('board order'), which sets it apart from sibling tools such as asana_create_section, asana_update_section, or asana_delete_section that mutate section data. An agent can easily differentiate this read operation from its non-read siblings without inspecting any schemas.

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 establishes usage context (listing sections of a project) but offers no explicit guidance on when *not* to use this tool or how to choose it over alternative tools. The title 'List sections' and the verb 'List' somewhat implies it is for read-only retrieval, but it does not name sibling alternatives or specify conditions that would justify using a different function. This is an implied guideline at best, not an explicit one, so it sits at the mid-range.

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

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

Beyond annotations that already mark this as read-only and idempotent, the description adds meaningful behavioral context: stories are composed of comments and activity log, the text field stores comment bodies, and the result is paginated. These details help an agent predict the shape and behavior of the response. There is no contradiction with 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 three short sentences, each adding a distinct piece of information without redundancy. The main purpose is front-loaded, followed by a useful semantic clarification and a reminder of pagination. It is compact yet demonstrates respect for the reader's time.

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 read-only list operation, the description, combined with the full parameter schema and safe annotations, provides enough information to invoke the tool correctly. It explains the resource type and content, and signals pagination handling. There is no output schema, so a bit more detail on returned story fields beyond 'text' could be useful, but this does not prevent correct invocation or comprehension of the core behavior.

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 already provides 100% coverage of all four parameters, so the baseline is a 3. The description adds minimal parameter-specific information beyond the schema; 'Paginated' mirrors the limit/max_pages descriptions. It does not explain how opt_fields interacts with the 'text' field, though that would have been a helpful addition. Overall, the description does not need to compensate, as the schema is sufficient.

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 action and resource: 'List a task's stories' and further clarifies what stories are ('comments + activity log'). This distinguishes it from other sibling tools, as no other tool in the list targets stories. It is unambiguous and immediately tells an agent what the operation does.

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 this tool – whenever a task's stories or comments are needed – but it does not explicitly mention alternatives or situations where another tool should be used instead. With siblings like asana_get_task and asana_list_tasks present, a brief note on when to select this tool over those would improve guidance. No exclusion criteria are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds 'Paginated' and 'rich fields' which are not fully captured by the schema, providing some behavioral context beyond annotations, though not deeply detailed.

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 a single, efficient sentence with no wasted words. It front-loads the core action and includes a useful behavioral note about pagination, though it omits usage guidance, which slightly reduces the completeness.

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 simple read-only list operation with a thorough schema and annotations, the description covers the basics. However, it lacks any mention of when to choose this over other listing tools and doesn't clarify what 'rich fields' entails or how pagination behaves, leaving some gaps for an agent.

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 parameters are already well-documented. The description adds little beyond stating 'rich fields' which loosely maps to opt_fields, but it does not compensate for anything missing; baseline 3 is appropriate.

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 'List a task's subtasks' with a specific verb and resource, and distinguishes it from sibling tools like asana_list_tasks or asana_get_task. The 'rich fields' detail adds specificity about the output depth.

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?

No guidance on when to use this tool versus alternatives like asana_list_tasks or asana_get_task. The description doesn't mention exclusions or prerequisites, leaving the agent to infer appropriate usage from the tool name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds pagination behavior ('Paginated') and hints at a rich default opt_fields behavior through the parameter schema, but does not detail what the returned objects contain beyond name and GID.

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 short and front-loaded with the core purpose ('List tags in the workspace'), followed by the return format and pagination note. It is efficient and covers the essential information without 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?

Given the annotations, the rich parameter descriptions, and the simple nature of a tag-list operation, the description covers what an agent needs to invoke it correctly. The pagination note and return format hint are sufficient for this low-complexity tool.

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 has a meaningful description. The description itself doesn't add parameter detail, but the baseline 3 is appropriate because the schema already carries the semantic load.

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 and resource: 'List tags in the workspace' and notes the return format as name → GID. This distinguishes it from tag-mutating siblings like asana_add_tag and asana_remove_tag, though it doesn't explicitly name which siblings it differs from.

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 a read-only listing action with pagination, which contextually separates it from mutation tools. However, it does not explicitly state when to prefer this tool over alternatives like asana_list_workspace_custom_fields or asana_typeahead for similar listing needs.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about pagination ('Paginated') and the workspace default for assignee queries, which goes beyond annotations. However, it omits details like maximum page size or what happens if no anchor is provided, which would enrich transparency.

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?

Three concise sentences with zero filler. The core action is front-loaded, followed by the key constraint, then a useful default-behavior note. 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 9 parameters, 100% schema coverage, and full safety annotations, the description covers the critical aspects: anchor exclusivity, pagination, and assignee workspace default. It does not explicitly state what happens when no anchor is provided or when multiple anchors are given, which could be ambiguous, but the schema and annotations fill most gaps.

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 baseline is 3. The description adds semantic value by clarifying that exactly one anchor must be used and that assignee falls back to the workspace default, which supplements the individual parameter descriptions. It does not provide deep syntax or format details beyond the schema, as the schema already does 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 states a specific verb ('List') and resource ('tasks'), and enumerates the four filtering anchors (project, section, tag, assignee). It clearly distinguishes from sibling tools like asana_get_task (single task) or asana_search_tasks (search-based) by emphasizing the anchor-based listing.

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 provides clear selection guidance: provide exactly one anchor among the four options. This implies when to use the tool (when you know a project/section/tag/assignee) and prevents misuse by enforcing mutual exclusivity. It does not explicitly name alternative tools or exclusion conditions, but the anchor constraint is a strong usage guideline.

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

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.

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds the valuable behavioral trait 'Paginated' and the authorization-scoping detail that results are limited to teams the token owner belongs to, which goes beyond the schema and 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?

A single descriptive sentence that states the action, resource, scope, and pagination behavior with no filler or redundancy. Every word contributes to understanding the tool.

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 simple paginated list operation, the description combined with the complete parameter schema and the safety annotations is sufficient. There is no output schema, but the tool's purpose and behavior are clear without needing a detailed return-value breakdown.

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 all four parameters are already fully documented in the input schema. The description does not add semantic meaning to the parameters beyond what the schema provides, matching the baseline score for high schema coverage.

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 uses a specific verb and resource: it says 'List teams', identifies scope ('the token owner belongs to'), and specifies the location ('in the workspace/organization'). This clearly separates it from sibling list tools like asana_list_projects or asana_list_users.

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 use whenever team membership information is needed and clarifies that it only covers teams the token owner belongs to, but it does not name alternative tools or state explicit when-to-use/when-not-to-use conditions. The usage context is clear enough for a simple list operation.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds 'Paginated', which is a real behavioral trait, but this is also inferable from the limit/max_pages parameters. There is no mention of default workspace behavior or edge cases, so the description provides only modest value 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 remarkably concise and front-loaded, delivering the core purpose in the first phrase and then adding a useful resolution note and pagination flag. There is no redundant or filler content, and every word contributes meaning.

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 simple list tool with no output schema, the description provides enough key detail: it identifies the resource (workspace members) and the intended outcome (name-to-GID mapping), and mentions pagination. Still, it does not specify the exact shape of returned items (e.g., containing 'gid' and 'name') or clarify the behavior when no workspace is provided, leaving some reliance on the parameter descriptions.

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?

All four parameters have descriptions in the input schema, giving 100% schema coverage. The description itself says nothing about individual parameters or how they affect the list. Because the schema handles parameter documentation, the baseline score of 3 applies.

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 the specific operation: 'List workspace members', and adds a parenthetical about 'name → GID resolution', which clarifies the main use case. It clearly targets the list aspect and distinguishes from a single-user retrieval tool, though it does not explicitly name any sibling or contrast with 'get' tools.

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 the tool should be used when you need to map user names to GIDs, and its plural nature suggests bulk listing. However, it gives no explicit guidance about when to choose an alternative like asana_get_user for a single user, nor any exclusions. Usage context is therefore only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds value by explicitly noting 'Paginated' and the 'ALL' scope, which explains that the tool returns the full set across pages. This is useful 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 one tight sentence with a parenthetical purpose, followed by a single-word sentence 'Paginated.' It is front-loaded with the action and resource, every phrase serves a purpose, and no words are wasted.

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?

Given that annotations cover the safety profile and the schema covers parameters, the description is complete enough for the core call. It includes pagination behavior and the use case. A minor gap is that it does not clarify how workspace is chosen when no workspace parameter is provided, but this may be inherited from context.

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 already documents limit, max_pages, and opt_fields with descriptions (75% coverage). The description adds no parameter-specific meaning, and the workspace parameter has no schema description nor any clarification from the description. Baseline is 3 given partial coverage; the missing workspace context keeps it at a 3.

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 precise verb and resource: 'List ALL custom fields defined in the workspace'. The parenthetical 'design discovery — find a field GID to attach to a board' clarifies the intended use. It inherently differentiates from singular get_custom_field or per-project get_custom_field_settings.

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?

No guidance is given about when to use this tool versus alternatives. It only names a use case (design discovery) but does not mention when not to use it or which sibling would be more appropriate (e.g., get_custom_field for a single field, get_custom_field_settings for project settings).

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

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

The description adds notable behavioral context beyond the read-only/idempotent annotations: it states the tool is built on the search API and caps at 100 by due date, defines blocked tasks, and notes it returns only incomplete tasks with a summary count. This helps the agent understand edge cases and interpretation.

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 dense and front-loaded with 'COMPOSITE: one-call daily brief', followed by behavior, usage, and a key limitation. Each clause contributes useful information, though the long parentheticals make it slightly harder to parse quickly.

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?

Because there is no output schema, the description should clarify what the tool returns; it mentions buckets and a summary count but does not specify whether the response is structured task objects with GIDs or a human-readable brief. The 100-task cap is disclosed, but return format ambiguity remains.

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 baseline is 3. The description restates the user default and horizon_days behavior but adds no new parameter-level semantics; workspace is only indirectly referenced. Examples like 'user=<gid>' reinforce the schema rather than extend it.

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 identifies the tool as a composite one-call daily brief that buckets incomplete tasks into overdue, due_today, upcoming, and blocked. This differentiates it from sibling tools like asana_search_tasks or asana_list_tasks by emphasizing its aggregated, bucketed nature.

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 phrase 'one-call daily brief' implies use for a quick morning overview, and the user scoping instructions are clear, but there is no explicit comparison to alternatives or guidance on when not to use it. The 100-task cap hints at a limitation but does not direct the agent to a more exhaustive sibling.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the key safety traits. The description adds no behavioral context beyond the action itself—no mention of side effects, permissions, or consequences. It does not contradict annotations, but it also does not add the kind of useful behavioral detail (e.g., impact on tasks, required scopes) that would elevate this score.

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 extremely concise: a single functional sentence followed by a brief contextual note about why the tool exists. It is front-loaded with the action and contains no redundant filler. The second sentence adds a small amount of context about the tool's necessity, slightly reducing perfection but remaining efficient.

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 simple two-parameter operation with full schema coverage and annotations indicating safety (non-destructive, idempotent), the description is largely sufficient. It clearly states what the tool does and the parameters are well-documented. It lacks explicit usage guidance and output details, but no output schema exists and the operation is straightforward, so this is not a major gap.

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%, with both 'task_gid' and 'section_gid' each having a clear description ('Task GID to move' and 'Target section GID'). The description does not add extra parameter semantics beyond the schema, so the baseline 3 applies.

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 action ('Move a task to a different section within its project'), clearly identifying the resource (task) and the target (section). It distinguishes itself from siblings like asana_reorder_section (reordering sections) and asana_bulk_move_section (bulk operations), leaving no ambiguity about what this tool does.

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 does not provide any guidance on when to use this tool versus alternatives. It mentions 'Fixes: no MCP tool for section moves,' which hints at its purpose but does not give explicit when-to-use or when-not-to-use conditions, nor does it reference sibling tools that might be better suited in certain scenarios.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds crucial behavioral context: the token-owner restriction, the 403 failure mode, and pagination behavior. This goes beyond what annotations provide and helps the agent predict outcomes accurately.

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 dense with essential information in a compact form: the purpose, the critical limitation, the alternative tools, and the pagination behavior. Every sentence contributes meaning with no redundancy or 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 a read-only list tool, the description covers the necessary context: what it lists, who can call it, failure mode, pagination, and alternatives. All parameters are well-documented in the schema, and no output schema is needed for a list endpoint. Nothing critical is missing.

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 baseline is 3. The description adds value by clarifying the semantics of the 'user' parameter ('default me = token owner') and warning that passing another user fails with 403, which is not evident from the schema alone.

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 the action: 'List the TOKEN OWNER's My Tasks', identifying the specific resource and its scope. It also distinguishes this from other task-listing tools by emphasizing the personal PAT limitation, so an agent can tell it apart from asana_search_tasks or asana_list_tasks.

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?

It explicitly says when to use this tool (only for token owner's My Tasks) and exactly when not to, providing alternatives: 'For other users use asana_search_tasks or asana_list_tasks with assignee=<gid>'. It also warns about the 403 error, leaving no ambiguity.

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