Asana MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct resource+action pairs, and the singular/plural get patterns (e.g., asana_get_project vs asana_get_projects) help. However, with 86 tools there is mild risk of confusing similar operations like asana_add_task_dependencies vs asana_add_task_dependents, and the many list-by-entity variants (project/section/tag) require careful reading.
Naming Consistency4/5
The asana_verb_noun pattern is consistently applied, with verbs like get, create, update, delete, add, remove, search. Minor deviations include mixing 'get' and 'list' for collections (asana_get_users_for_workspace vs asana_list_workspaces) and the presence of asana_typeahead alongside search tools, but overall the naming is predictable.
Tool Count1/5
86 tools is far beyond the typical well-scoped MCP server range. Even for a large API like Asana, this is excessive and will overwhelm agents, increasing selection latency and the chance of choosing the wrong tool despite clear descriptions.
Completeness5/5
The tool surface covers nearly every major Asana entity (workspaces, teams, users, projects, tasks, subtasks, sections, portfolios, goals, tags, custom fields, attachments, time tracking, stories) with CRUD operations where applicable. Advanced analysis tools (history, flow metrics, velocity, comparable tasks) add depth. No critical dead ends are evident.
Average 4.3/5 across 86 of 86 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate this is a mutating, non-idempotent operation (readOnlyHint=false, idempotentHint=false). The description adds only the return behavior (returns the created portfolio object with gid and name) and domain context, but does not disclose additional side effects, permissions, or workspace requirement details beyond what the schema provides. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences: the first front-loads the core purpose, the second gives useful domain context, and the third states the return value. Every sentence earns its place with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with full schema coverage and one required parameter, the description is largely complete. It explains what the tool does, what portfolios are for, and what is returned. It does not explicitly mention the workspace fallback or permission requirements, but those are partially covered by schema and annotations, so the description is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond the schema for parameters, only mentioning the response contains gid and name, which is optional return information rather than parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource ('Create a new portfolio in a workspace') and distinguishes it from sibling portfolio tools like get_portfolio, update_portfolio, and delete_portfolio by using the specific verb 'create'. The context about grouping projects adds further clarification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for creating a portfolio, but it does not explicitly state when to use it over alternatives or provide exclusions. There is no mention of update/delete as alternatives or any conditions under which this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, and idempotent behavior. The description adds value by disclosing the return shape (array of project objects with specific fields), which is not obvious from annotations. However, it does not mention pagination behavior or the potential need for multiple calls despite the schema exposing limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place. The primary action is front-loaded, the return format is stated, and a related tool is cross-referenced. No wasted words or redundant repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and good annotations. The description provides a clear return type and fields, which is essential given no output schema. However, the phrase 'List all projects' could overpromise given the limit/offset pagination parameters, though the schema compensates. Overall, sufficient for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description is not required to explain parameters. The only marginal addition is the mention of specific fields (gid, name, color, archived) which partially overlaps with opt_fields, but it doesn't clarify parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all projects in a portfolio') and the resource (portfolio items). It distinguishes itself from sibling tools like asana_get_portfolio (which likely gets portfolio details) and asana_search_projects (searching across workspaces). The return format is also specified, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions asana_add_portfolio_item for adding projects, which is a complementary action rather than an alternative for listing. No exclusions, prerequisites, or context on when this tool is preferred over other listing/search tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 description need not repeat these. It adds useful behavioral context by stating that only supplied fields are changed and that the updated portfolio object is returned. No contradictions with annotations exist, but it does not disclose potential side effects beyond the update itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action. Every phrase adds value: what can be updated, the partial-update guidance, and the return value. No wasted words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and well-covered by annotations and schema. The description specifies the return value, partial-update behavior, and the accepted fields. No output schema exists, but the return value is described. Permissions or error cases are not mentioned, but the combination of annotations and description provides sufficient context for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description adds a marginal nuance ('Only supply the fields to change') that reinforces optionality, but it does not provide additional semantics beyond what the schema already offers. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a portfolio's name, color, or public visibility, with a specific verb and resource. This distinguishes it from sibling update tools (e.g., update_project, update_task) by explicitly naming the portfolio as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Only supply the fields to change' provides a clear usage guideline for partial updates. However, it does not explicitly mention when to use this tool versus other update tools, nor does it state any exclusions or alternatives, leaving some ambiguity for an agent selecting among many sibling update functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a non-read-only, non-idempotent write operation. The description adds that it returns the created task object and suggests using memberships for section placement, which is useful context. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, first gives purpose, second gives guidance and return. No fluff, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema is rich, the description does not clarify whether project_id is still required when supplying memberships (since project_id is listed as required). It also doesn't discuss potential errors or edge cases, but covers the main purpose and return. Given the complexity, a bit more guidance on parameter interplay would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions. The description emphasizes a preference for memberships over project_id, but this is already stated in the schema's project_id description, so it adds minimal new semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Create') and resource ('a new task'). It also mentions the return value, distinguishing it from other creation tools like create_subtask or create_project based on the object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implied usage context: use this whenever you need to create a task. It provides a parameter-level preference (memberships over project_id) but does not explicitly contrast with create_subtask or other sibling tools, so there is no when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, and the description adds that it returns a success message and can control placement. This provides some behavioral context beyond the annotations, but it does not disclose details like what happens if the project is already in the portfolio, despite idempotentHint=true. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the primary action. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with full schema coverage and annotations, the description adequately covers the operation. It mentions the return value and placement options. It could be more complete by noting that the operation is idempotent, but this is already in the annotations, so the description does not need to repeat it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 with clear meanings. The description briefly mentions insert_before/insert_after but adds no new semantic detail beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('a project to a portfolio'), clearly distinguishing it from sibling tools like asana_remove_portfolio_item and asana_get_portfolio_items. It also mentions optional placement control, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool adds a project to a portfolio, and the optional insert_before/insert_after parameters indicate placement customization. While it does not explicitly name alternatives, the sibling list makes the intended use obvious, and there are no misleading exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral details beyond the annotations: it states the return value (empty object on success) and recommends a post-verification method (asana_get_task with opt_fields=`dependencies`). It does not contradict the idempotentTrue and destructiveFalse annotations, though it could also mention idempotency behavior if relevant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence explains the action, the second gives return value and verification. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 the essential aspects: purpose, behavior, return value, and verification. It does not explain edge cases like overwriting existing dependencies, but the idempotentHint annotation reduces the need for that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of both parameters with detailed descriptions (task_id as GID, dependencies as array of GIDs). The tool description does not add parameter-specific meaning beyond that, so the schema carries the burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Mark' and the resource 'tasks as dependencies of a given task', with a clarifying parenthetical that defines the dependency direction (cannot start until dependency tasks complete). This distinguishes it from the sibling tool asana_add_task_dependents, which handles the opposite relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by explaining the dependency relationship, but it does not explicitly mention when to use this tool versus alternatives like asana_add_task_dependents. It gives clear context but no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive behavior (destructiveHint=false). The description adds useful context that enum options are added separately and that the created object is returned, but it does not disclose other behaviors like permissions or irreversibility of type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no fluff. The first sentence states main purpose and types, the second handles enum options, and the third states the return value, all efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter creation tool with no output schema, the description covers the core action, supported types, return value, and the enum option follow-up. It does not list all parameters but relies on the schema, and it omits workspace default behavior, which is already in the schema. This is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter documented. The description adds a meaningful note about enum option workflow but otherwise repeats type values already present in the schema, so it does not significantly enrich parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with "Create a new custom field in a workspace," using a specific verb and resource. It distinguishes from sibling tools like asana_update_custom_field and asana_create_enum_option by explicitly focusing on creation and referring to the separate option-adding step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance for enum/multi_enum fields, directing users to asana_create_enum_option for adding options. However, it does not state when to use this tool versus other custom field tools like update or delete, though that is largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds that the tool returns the created section object with gid and name, which is useful, and explains the visual manifestation of sections. However, it does not go beyond that to discuss authentication, rate limits, or error cases. The added value over annotations is modest, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by clarifying context and placement guidance. Every sentence earns its place with no redundant filler, making it concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 5 parameters and no output schema, the description covers the main points: what it does, what sections look like, and the return value. It omits explicit notes on mutual exclusivity of insert_before/insert_after, but that is already in the schema. Given the annotations and schema richness, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions (e.g., name, project_gid, insert_after/before with mutual exclusivity). The description's mention of insert_before/insert_after for placement adds some conceptual guidance, but it largely mirrors what the schema already says. With full schema coverage, the baseline of 3 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new section in a project'), identifies the resource (a section within a project), and distinguishes this from sibling tools like asana_update_section or asana_delete_section. It also adds helpful context about what sections are (column headers in board view, group headers in list view), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to control section placement using insert_before or insert_after, which guides the agent on when to use these parameters. However, it does not explicitly mention alternative tools or when not to use this tool, so it lacks explicit exclusions. Still, the placement guidance is a solid usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that this is a write operation (creates) and clarifies the parent-child relationship ('Subtasks are tasks with a parent'), which adds useful behavioral context. It also mentions the return value ('Returns the created subtask object'). Annotations already indicate non-readonly and non-destructive, and no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and key context. Each sentence serves a purpose: definition, clarification, and pointer to related tool. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and rich schema (all 7 parameters documented), the description is sufficient. It covers the core purpose, the parent constraint, and return value. It does not explain optional fields or edge cases, but these are already in the schema, so the description remains complete enough for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so descriptive parameter info is already present. The description does not add additional parameter semantics beyond noting the parent task context in the text, which is already reflected in the schema property description. Baseline of 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('subtask under an existing task'), and distinguishes it from creating a top-level task by emphasizing the parent relationship. It also notes that the tool returns the created subtask object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need a subtask under an existing parent task) and mentions an alternative for listing subtasks ('Use asana_get_subtasks to list existing subtasks'). However, it does not explicitly contrast with asana_create_task or other creation tools, so usage boundaries are not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate non-read-only and non-destructive behavior, so the description's job is lighter. It adds context that tags are workspace-scoped and that the tool returns the created tag object, which is useful. However, it doesn't disclose potential side effects like duplicate name handling or permission requirements, which are not covered by annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and every sentence earns its place. It includes the necessary follow-up pointer without any fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema) and the rich annotations, the description covers the essential purpose, scope, and next-step guidance. The lack of error-case or permission details is acceptable because the schema and annotations provide sufficient context. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the note that workspace_gid can be omitted if ASANA_DEFAULT_WORKSPACE_GID is set, which is already mentioned in the schema. It doesn't add significant extra meaning beyond what the schema provides, but it does reinforce the workspace-scoped nature and the return object, keeping it at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new tag in a workspace' with a specific verb and resource, and distinguishes from sibling tools like update_tag, delete_tag, and add_tag_to_task by scoping to creation. It also clarifies that tags are workspace-scoped and can be applied to any task, adding useful context that differentiates it from similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use asana_add_tag_to_task after creating the tag, which guides the agent on the next step. It implies when to use this tool (when a new tag must be created) but doesn't explicitly detail when not to use alternatives like update_tag or delete_tag. However, the clear verb and follow-up instruction provide sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false), and the description adds the return format and a prerequisite (time tracking enabled). It does not elaborate on error behavior or side effects beyond that, but with annotations covering safety, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences, and front-loaded with the primary purpose. Every sentence adds value—the first states action and return, the second gives a crucial prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description covers the return fields and a key prerequisite. It is sufficient for an agent to successfully invoke the tool, though it could mention potential error conditions or permissions explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all parameters with 100% coverage, including examples and constraints. The description does not add much 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Log time spent on a task.' It clearly indicates this tool creates a time tracking entry, distinguishing it from sibling tools that update, delete, or get entries. The return value is also specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool for creating a time entry, and the prerequisite 'time tracking must be enabled' offers useful context. However, it does not explicitly mention alternatives or when not to use it, though the title and sibling list make the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, and the description adds important behavioral context beyond those annotations: the action is irreversible ('cannot be undone') and returns a success message. This helps the agent understand the side effects and expected response without requiring additional inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three short, purposeful sentences: the action, the irreversibility warning, and the return behavior. Every sentence adds distinct value and there is no redundant or extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description fully covers what the tool does, warns about permanence, and states the return value. It omits error conditions and permission requirements, but these are not essential for correctly selecting and invoking this straightforward deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single required parameter goal_gid, including its type and example. The tool description itself does not add any additional parameter meaning, so it appropriately sits at the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' and identifies the resource 'goal,' clearly distinguishing it from sibling tools like asana_create_goal, asana_get_goal, and asana_update_goal. The additional warning 'This cannot be undone' reinforces its purpose as a permanent deletion action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you want to permanently remove a goal) but provides no explicit comparisons to alternatives or exclusions. It does not mention prerequisites, permissions, or when not to use it, leaving the agent to infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description doesn't need to restate safety. It adds return field context, but creates slight ambiguity: it lists fields as if always returned, while the schema says defaults are gid and resource_type and these fields require opt_fields. No annotation contradiction, but behavioral nuance is imperfect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, return fields, and sibling pointer. Each sentence earns its place with no fluff. The most important information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 100% schema coverage and strong annotations, the description is largely complete. It covers what to use, what it returns, and how to obtain the required GID. The only gap is not clarifying that the listed fields depend on opt_fields, which could mislead an agent expecting them by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both portfolio_gid and opt_fields are fully described, including the pointer to asana_get_portfolios for GIDs. The description adds no new parameter-level details beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full details for a portfolio by GID, with a specific verb and resource. It lists the key return fields (name, color, public status, owner, members, workspace), distinguishing it from sibling tools like asana_get_portfolios by explicitly pointing there for GID discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells the agent to use this tool when a portfolio GID is already known and full details are needed. It explicitly directs to asana_get_portfolios for finding GIDs, which is a clear alternative. It doesn't mention other siblings like asana_get_portfolio_items, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the tool returns an array of task objects, which provides some context beyond annotations. There is no contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences that front-load the core purpose and immediately state the return type. Every sentence adds value, and there is no redundant or verbose wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 strong annotations and a comprehensive schema, the description covers the essential purpose and return type. It does not explicitly mention pagination behavior, but the schema's limit and offset parameters fill that gap. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all four parameters (limit, offset, tag_gid, opt_fields) are well-documented in the input schema itself. The description does not add additional parameter semantics or usage details beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tasks that have a specific tag applied' and further differentiates from sibling tools by adding 'regardless of project,' which distinguishes it from asana_get_tasks_for_project and asana_get_tasks_for_section. It also notes the return type as an array of task objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Useful for finding all tasks in a workspace labeled with a particular tag, regardless of project,' which implies usage for cross-project tag queries. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it is a step below a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent, so the description adds contextual detail about the returned fields. However, it doesn't mention that these fields require opt_fields as the default response only includes gid and resource_type, which is a potential behavioral nuance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, no filler words. Every sentence provides actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with detailed schema and strong annotations, the description covers the essential context. The slight ambiguity about field defaults prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (100% coverage), including examples and useful values. The description adds minimal additional param semantics, though the cross-reference to the list tool is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get full details') with a clear resource ('time period') and identifier ('by GID'), and distinguishes from the plural sibling by scoping to a single item. It also lists the return fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs users to asana_get_time_periods for finding GIDs, providing a clear alternative. However, it doesn't explicitly state when to prefer this tool over other get-by-id tools, though the resource-specific nature makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotent and non-destructive hints. The description adds value by specifying the return payload ('updated section object with gid and name'), but does not disclose additional behavioral details like error handling or permission requirements. Given annotation coverage, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and includes only essential details: the operation, the return value, and a pointer to the sibling tool. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool with three parameters and no output schema, the description covers purpose, return value, and an alternative. It gives enough context for correct selection and invocation, though edge-case behavior is not discussed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage, including descriptions for 'name', 'section_gid', and 'opt_fields'. The tool description does not add further parameter-level meaning beyond what the schema already contains; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Rename an existing section,' which precisely identifies the action and resource. It also distinguishes itself from the related 'asana_move_section' by noting that reordering is a separate concern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use an alternative: 'To reorder sections, use asana_move_section instead.' This gives clear guidance for a key distinguishability point, though it does not enumerate all possible section-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds 'This cannot be undone', which is a useful warning but not substantially new behavioral information beyond the annotation. No contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no wasted words. Every element contributes to the purpose or a critical warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one required parameter and no output schema, the description adequately communicates the action and consequence. The permanence warning covers the main risk, making the description complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the single parameter with type, example, and required status (100% coverage). The description adds no parameter-level meaning, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with the resource 'project status update', which clearly distinguishes it from sibling tools like get/create status. The action is unambiguous and directly aligned with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by stating the delete is permanent and irreversible, which signals when this destructive tool is appropriate. It does not explicitly name alternatives or exclusions, but for a simple delete operation the usage is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover read-only, idempotent, and non-destructive behavior, lowering the bar. The description adds useful context about the return fields (text, color, title, author, created_at) and color semantics. However, it does not clarify that those fields require opt_fields, a minor precision issue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and resource, and no unnecessary words. It efficiently covers what the tool does and what it returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description combined with annotations and schema is complete: it explains the purpose, return fields, and parameter usage. The only minor gap (optional vs default fields) is addressed by the schema, so no major missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for both parameters, including examples and default fields. The description adds no parameter-specific semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a single project status update by GID, using the specific verb 'Get' plus the resource and scope. The word 'single' distinguishes it from the plural sibling asana_get_project_statuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a GID and need one status, but it does not explicitly state when to prefer this over alternatives or mention exclusions. The schema hints at getting GIDs from asana_get_project_statuses, but this is not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the list of returned fields, but it omits that these fields require opt_fields (schema notes defaults are only gid and resource_type), so the description may overstate the default return. No contradiction with annotations, but this is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and includes a useful pointer to a sibling tool. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 full schema coverage and strong annotations, the description is mostly complete. However, the potential ambiguity about default vs. opt_fields returns means it isn't fully self-contained; an agent might not realize that the listed fields are not all returned by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with detailed descriptions for both parameters, including where to find tag GIDs and useful opt_fields values. The description adds minimal new info beyond pointing to asana_get_tags_for_workspace, and it doesn't clarify the relationship between opt_fields and the listed returned fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('full details for a single tag') and method ('by GID'). It distinguishes from sibling tools by referencing asana_get_tags_for_workspace for finding GIDs, clearly communicating 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (when you have a tag GID and need full details) and directs to asana_get_tags_for_workspace to find GIDs. The param schema reinforces this by telling users where to get GIDs, providing clear alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotent, non-destructive), so the bar for additional behavioral disclosure is lower. The description adds valuable context by stating the return format: 'an array of tag objects with gid, name, and color,' and clarifies the workspace-scoped nature of tags, enriching understanding of what the tool does beyond mere safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action ('List all tags currently applied to a task') and including a concise explanatory sentence about tag semantics. There is no redundant or filler content; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description is complete enough. It states the return format (array of tag objects with key fields), and pagination is already documented in the schema via limit and offset parameters. Combined with the safety annotations, the agent has all necessary context to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the schema already fully documents task_gid, limit, offset, and opt_fields. The description does not add any parameter-specific meaning beyond what the schema provides, thus the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'List all tags currently applied to a task.' This is a specific verb-resource pair that immediately clarifies the tool's purpose. It also distinguishes from sibling tools like asana_get_tags_for_workspace (tags in a workspace) and asana_get_tasks_for_tag (tasks for a tag) by explicitly focusing on tags per task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case—viewing tags on a given task—but provides no explicit comparison with alternatives such as asana_get_tags_for_workspace or asana_add_tag_to_task. The sentence about tags being 'workspace-scoped labels' gives context but does not say when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructive, yet the description adds crucial nuance: it removes the association, not the tag itself, and documents the return value (empty object). This goes beyond the annotations and clarifies the side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs the core action, a key caveat, and the success response. No wasted words, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 no output schema, the description is sufficient. It covers what, the caveat, and the return value, while schema and annotations handle the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (task_gid, tag_gid) with examples, achieving 100% coverage. The description adds nothing about parameter semantics, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove'), identifies the exact resource ('tag from a task'), and explicitly distinguishes itself from deleting the tag itself. This clearly differentiates it from sibling tools like delete_tag or add_tag_to_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not explicitly say when to use it versus alternatives. Usage is implied for detaching a tag from a task, but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: new options are appended to the end of the list by default, and the tool returns the created enum option with its GID. This complements the readOnlyHint=false and openWorldHint annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the action, the default behavior, and the return value/usage. It is front-loaded with the primary purpose and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description adequately covers the return value (created enum option with GID) and a key behavioral default (appending to end). It does not explain potential errors or prerequisites, but the schema and annotations cover the parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add extra meaning to the parameters themselves; it only references the returned GID for follow-up use, which does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add a new option to an enum or multi_enum custom field.' It clearly distinguishes the creation action from the sibling tool asana_update_enum_option by focusing on adding a new option rather than modifying an existing one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool (adding an option) and provides a follow-up usage hint: 'Use the GID to set this option on tasks via asana_update_task.' It does not explicitly exclude alternatives like update_enum_option, but the creation intent is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses an important behavioral trait: time_period is required by the API even though the schema only lists name as required. It also explains the status limitation and states the return value. These details go beyond what the annotations (readOnlyHint, idempotentHint, destructiveHint) provide, making the tool's behavior more predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at just three sentences. It front-loads the core purpose, then delivers critical caveats (time_period requirement, status limitation) without any fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters and no output schema, the description covers essential non-obvious details: the API-required time_period, the status restriction, and the return value. It could mention potential error scenarios or prerequisites for workspace, but the schema covers the workspace parameter. Overall, it is quite complete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter having a description. The description adds emphasis on time_period and status, but these details are already present in the schema. The cross-reference to asana_get_time_periods is helpful but also redundant, so the description provides marginal additional value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new goal in a workspace' with a specific verb and resource. This distinguishes it from sibling tools like asana_create_task and asana_create_project, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance by highlighting that time_period is required and directing the agent to asana_get_time_periods for valid GIDs. It also notes the status constraint, which helps the agent decide when a goal can be created vs. updated. It does not explicitly mention when not to use this tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, open-world, non-idempotent operation. The description adds useful behavioral context beyond annotations by stating the team GID requirement and that it returns the created project object. This is meaningful disclosure of constraints and return behavior, though it does not elaborate on side effects or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, followed by the key prerequisite and return value. Every sentence adds necessary information with no filler, achieving ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 8 parameters and no output schema, the description covers the essential points: what it does, where it applies, the critical team GID requirement, and what it returns. It does not cover potential errors or permission caveats, but given the rich schema and annotations, this is a reasonable level of completeness, slightly above minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter descriptions, so the baseline is 3. The description repeats the team GID requirement already in the schema and adds no new parameter-level semantics beyond what the schema's property descriptions already offer. Thus it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new project in a workspace' with a specific verb+resource, and adds scoping ('in a workspace') and a key prerequisite (team GID for organization workspaces). This distinguishes it from sibling create tools like create_portfolio or create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on where the tool applies ('in a workspace') and when a team GID is required ('In organization workspaces (most)'), which helps the agent decide prerequisites. However, it does not explicitly mention alternatives or exclusions (e.g., when to use create_portfolio instead), so it lacks the explicit when-not guidance for a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and not read-only. The description adds the critical context that deleting a project also permanently deletes all its tasks and cannot be undone, which is important behavioral information beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and consequence. No filler words. Each sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and clear annotations, the description adequately covers the operation's effects: permanent deletion of project and tasks, irreversibility. It is complete for a delete operation, though it could optionally mention permissions or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of the single parameter project_gid with description and example. The description does not add additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'delete' with resource 'project' and explains the consequence 'all its tasks' and irreversibility. This distinguishes it from sibling delete tools like delete_task or delete_section. Clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for permanently deleting a project with cascade to tasks. It does not explicitly name alternatives but the context makes it obvious when to use. No exclusions are mentioned, but the irreversible warning implies caution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the bar is lower. The description adds valuable context beyond annotations by specifying exactly what gets destroyed (the tag itself, not its task associations) and describing the success response ('Returns an empty object `{}` on success'). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each earning its place: purpose, scope clarification, and return value. It is front-loaded with the main action and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with full schema coverage and useful annotations, the description covers the core behavior, the critical edge case of task associations, and the return value. It omits error cases (e.g., tag not found) but is otherwise complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, as the single parameter tag_gid is thoroughly described in the schema with type and example. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Permanently delete a tag from the workspace.' It clearly distinguishes from sibling tag tools by clarifying that deleting the tag does not remove it from tasks, which sets it apart from asana_remove_tag_from_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (permanently delete a tag) and includes a when-not signal: 'This does NOT remove the tag from tasks.' However, it stops short of explicitly naming the alternative tool (e.g., asana_remove_tag_from_task), so it falls just below the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds the 25-task limit and notes that it returns the same fields as asana_get_task, providing useful behavioral context beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, followed by efficiency and use case. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch read operation, the description covers the key aspects: limit (up to 25), efficiency benefit, appropriate use case, and return field equivalence. It could mention error handling for invalid GIDs, but given the annotations and schema, it is sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for both task_ids and opt_fields. The description does not add further parameter-specific detail beyond referencing task GIDs and the fact that return fields match asana_get_task, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Fetch up to 25 tasks by GID in a single call', clearly identifying the verb (fetch), resource (tasks), and scope (by GID, up to 25). It also distinguishes itself from the sibling tool asana_get_task by positioning itself as a batch alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage guidance: 'Use when you have a known list of task GIDs (e.g. from a search result)' and explicitly compares to asana_get_task ('More efficient than calling asana_get_task repeatedly'). It does not explicitly state when not to use, but the context is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds two useful behavioral facts: the owner parameter is mandatory (despite no schema required) and the return type is an array of portfolio objects. It does not contradict annotations, and it provides value beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the main action stated first and the critical warning second. No filler or redundant content. The structure is efficient and front-loaded, ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (pagination via limit/offset, optional fields, workspace filter) and the rich annotations, the description covers the essential usage trap and return type. It doesn't explain pagination behavior, but the schema already documents offset/limit. For a list operation with strong annotations, this is adequate, though it could mention pagination in plain language.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats the owner requirement already documented in the schema, adding only the phrase 'Bad Request error' and the example 'owner: 'me''. This is minor additional emphasis, not new semantic meaning. Other parameters (limit, offset, workspace, opt_fields) are fully covered by the schema, and the description doesn't add further detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('portfolios') with a scope ('in a workspace'). It clearly distinguishes from sibling asana_get_portfolio (singular) and mutation tools like create/update/delete. The sentence is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides key usage guidance: the owner parameter is required and omitting it causes a Bad Request, with a recommended value 'me'. It implies this tool is for listing, not fetching a single portfolio, but does not explicitly mention alternatives or exclusion criteria. Still, the context is clear enough for an agent to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent safe operation. The description adds return format ('Returns gid and name for each team') and pagination support, which are behavioral traits beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose. Every sentence adds value: what it does, return fields, usage context, pagination.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with comprehensive schema and safety annotations, the description is nearly complete. Mentions return format and pagination. Could add a pointer to asana_get_team for single-team lookup, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 4 parameters are fully described in the schema (100% coverage). The description does not add new parameter-specific meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('teams in a workspace'), clearly distinguishing from asana_get_team (single team), asana_get_users_for_workspace, and asana_list_workspaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states a use case: 'Use this to find a team GID before calling asana_create_project', and explains why ('most organization workspaces require a team'). Lacks explicit exclusions/alternatives, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds value by detailing the return structure (hierarchical array FY → H → Q, with fields gid, display_name, start_on, end_on, parent), which is not provided by annotations or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover purpose, scope, return structure, and downstream usage. Every sentence earns its place, with no redundant or filler content. The description is front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return hierarchy, typical fields, and how to use the results with goal tools, compensating for the lack of an output schema. It doesn't explicitly mention pagination or default workspace behavior, but those are covered in the schema. Well-rounded for a list tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all six parameters. The description does not add significant new parameter semantics beyond stating the workspace scope and return fields, which are already captured in the opt_fields description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'List all time periods in a workspace (fiscal years, halves, and quarters).' It specifies the types and hierarchical structure, distinguishing it from sibling tools like asana_get_time_period (singular) by emphasizing the list-all behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: time periods are used to scope goals, and it says 'Use the GIDs with asana_create_goal or asana_get_goals.' This is clear guidance for when to use the tool, though it does not explicitly mention when not to use it or alternatives for single time period retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by disclosing the return shape (array of entry objects with gid, duration_minutes, entered_on, created_by) and a workspace prerequisite. This goes beyond the structured annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first states the core purpose, the second describes the return object, and the third gives a critical prerequisite. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only list tool, the description covers purpose, return format, and a key prerequisite. The schema handles pagination parameters, so the lack of explicit pagination detail is acceptable. It does not describe edge cases like empty results or partial pagination, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage with descriptions for all four parameters (limit, offset, task_gid, opt_fields), so the baseline is 3. The description does not add substantial parameter-level detail beyond what the schema already provides, only referencing task and return fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource-object construction: "List all time tracking entries logged for a task," which clearly distinguishes it from singular get, create, update, and delete time-tracking siblings. It also explicitly names the target object (task) and the information returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for listing time tracking entries for a task, and it notes the prerequisite that time tracking must be enabled. It does not explicitly exclude alternatives like get_time_tracking_entry, so it stops short of a 5, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 operation. The description adds the specific return fields and the GID source context, but doesn't disclose additional behavioral traits such as rate limits, pagination, or error conditions. Since annotations cover the safety profile, a score of 3 is appropriate: the description adds value but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action ('Get a single time tracking entry by GID'), lists the return fields concisely, and ends with a pointer to the sibling tool. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With high schema coverage, accurate annotations, and no output schema (so return values are described), the description is sufficient for an agent to select and invoke the tool. The only minor gap is that it doesn't mention the 'opt_fields' parameter behavior for expanding fields, but the overall context is complete enough for a straightforward read operation. The pointer to the sibling tool for finding GIDs adds needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters already have descriptions in the schema. The description reinforces that 'time_tracking_entry_gid' is the key input and where to find it, but it does not add new semantic meaning beyond the schema. The 'opt_fields' parameter is only referenced by the return fields list in the description, not explicitly explained as a parameter. Baseline 3 is correct given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('a single time tracking entry by GID') and lists the returned fields. It also distinguishes itself from the sibling tool 'asana_get_time_tracking_entries' by explicitly pointing to it for finding entry GIDs, which differentiates this singular retrieval tool from the list/find tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('Get a single time tracking entry by GID') and directs to the alternative for finding GIDs ('Use asana_get_time_tracking_entries to find entry GIDs'). This provides clear usage context and an explicit exclusion/alternative reference, which is exactly what the guideline dimension asks for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructiveHint and readOnly=false, but the description adds important nuance: the project itself is not deleted, only the portfolio association. It also discloses the return behavior (success message), which is valuable given no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action, followed by a clarifying caveat. Every word contributes meaning; there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation, the description covers the action, non-destructive scope, and return type. Combined with complete schema and annotations, it provides sufficient context. Minor gaps: no mention of error cases or effects on ordering within the portfolio.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for both parameters, including types and format examples. The description adds no additional parameter detail beyond restating the overall action, so it does not exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Remove a project from a portfolio.' It further distinguishes itself from deletion tools by noting 'This does NOT delete the project — it only removes the association,' which separates it from asana_delete_project and asana_delete_portfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use it (removing a project from a portfolio) and an explicit when-not-to-use (not for deleting the project). It does not name alternatives, but the exclusion is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context beyond those: fetches all projects (auto-paginated) then filters client-side (implying performance considerations), plus the default return shape (array with gid, name, resource_type). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, implementation behavior, a practical usage tip, and return format. Front-loaded with the main verb+resource. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 100% schema coverage, safety annotations, and no output schema, the description is solid. It covers return format (necessary since no output schema exists), pagination/filtering behavior, and a list-all pattern. Minor gaps: no explicit performance caveat or error handling, but the client-side filtering mention sufficiently hints at the main caveat.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with rich parameter docs (regex examples, workspace GID guidance, default vs. extended fields). The description reinforces the '.' list-all tip and default fields, but adds little semantic value beyond the schema. Baseline 3 is appropriate when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource+scope: 'Search for projects in a workspace by name using a regex pattern.' It clearly distinguishes from siblings like asana_get_project (single project by GID) and asana_search_tasks (task search) by highlighting the regex approach and client-side filtering behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: regex pattern matching, listing all projects with '.' , and a cross-reference to asana_list_workspaces for the workspace GID. However, it does not explicitly name alternatives or exclusion cases (e.g., when to use asana_get_project instead), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds key behavioral context beyond annotations by disclosing that the type field cannot be changed after creation and by stating that the updated custom field is returned. It aligns with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action, followed by a necessary note and return statement. Every sentence adds value with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an update tool with full schema coverage and relevant annotations, this description adequately covers the key constraints, alternatives, and return behavior. It does not delve into error handling or exhaustive parameter details, but those are largely served by the schema and annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have complete descriptions in the schema (100% coverage), so the description does not need to repeat them. It provides a high-level summary of updatable fields (name, description, settings) but does not add significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a custom field's name, description, or settings, which is a specific verb+resource. It distinguishes itself from related siblings like create/delete/get custom field and explicitly points to enum option tools for that specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit alternative for enum options (asana_create_enum_option or asana_update_enum_option) and notes that the type field is immutable. It does not explicitly state the general 'when to use' context, but the alternative and constraint give clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond annotations, noting that disabled options are hidden but existing values are preserved, and that the updated enum option is returned. This aligns with the non-destructive and idempotent hints, reinforcing safety. It doesn't cover every edge case but provides essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action and specific attributes. Every sentence adds value: purpose, use cases, and behavioral note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple update tool with five parameters, the description covers the key behavior (disabling preserves values) and return value. With schema fully describing parameters and annotations providing safety hints, the description is sufficient. It could mention idempotency explicitly but annotations already cover that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces the meanings of name, color, and enabled by mentioning 'rename', 'change their color', and 'disable/enable', but it doesn't add new syntax details. It also references the return of the updated option, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an enum option's name, color, or enabled status, using the specific verb 'update' and identifying the resource. It distinguishes from siblings like asana_create_enum_option by focusing on modification of existing options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'rename options, change their color, or disable/enable them.' It also adds context that disabling hides options without deleting, guiding appropriate use. It doesn't explicitly name alternatives, but the purpose is distinct enough from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the annotations: it notes that only provided fields are changed (partial update) and that the updated tag object is returned. Annotations already indicate mutability and non-destructiveness, but the description complements them with these operational details, without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loads the action, and contains no filler. Every word contributes to understanding the tool's purpose, partial update behavior, and return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool, the description is sufficiently complete: it states what can be updated, partial update semantics, and the return value. No output schema is needed since the return is explicit. It could mention error cases or permissions, but those are not essential for this straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions the main updatable fields (name, color, notes) but adds little beyond what the schema already provides. The 'only supply fields you want to change' note is more of a usage guideline than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing tag's name, color, or notes, using a specific verb and resource. This distinguishes it from sibling tools like get_tag, delete_tag, and create_tag_for_workspace, making the purpose immediately apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by stating 'Only supply the fields you want to change,' which is essential for partial updates. While it doesn't explicitly mention alternatives, the context of sibling tools (e.g., create_tag_for_workspace) makes the appropriate use case inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true, which covers safety and idempotency. The description adds that the operation returns the updated entry with specific fields, providing useful behavioral context beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and resource, followed by return value details. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple update tool with 4 params and no output schema, the description covers the return value and the schema covers inputs. Minor gaps like whether both fields can be updated simultaneously are not explicitly stated, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all parameters, so the baseline is 3. The description only mentions 'duration or date' which maps to existing parameters, adding no new meaning beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update the duration or date') and the resource ('existing time tracking entry'), distinguishing it from sibling create/delete/get tools. The specific fields (duration, date) are named, making intent unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing time tracking entry' provides clear context that this is for modifying entries that already exist, and the sibling names (create/delete/get) make alternatives obvious. However, it does not explicitly state when to use this over alternatives or list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that it 'Returns the created status object,' which is useful behavioral information not covered by the annotations. It also adds context about the health check-in. The annotations already indicate it's not read-only, not idempotent, and not destructive, and the description aligns with these.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and includes only relevant details. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 user what to expect ('Returns the created status object'). Combined with the fully self-documenting schema and annotations, the description is complete for this simple creation tool. It also fits well within the broader sibling-tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, so the schema already documents all parameters. The description adds a minor reinforcement about the 'color' parameter ('Use color to visually signal project health'), but this largely repeats the schema's enum descriptions. No significant new meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a new status update for a project' with specific detail about it being the health check-in shown in the status tab. This uses a specific verb and resource, and distinguishes it from sibling tools like asana_get_project_status and asana_delete_project_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for creating status updates, and even provides guidance on using the 'color' parameter. It doesn't explicitly mention alternatives or when not to use it, but the action of 'Create' is unambiguous enough to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, but the description adds important context: 'This cannot be undone' and 'Returns a success message.' This goes beyond the structured annotations, making the irreversibility and output explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Each sentence adds value: the action, the irreversibility, and the return result. Front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description fully covers the essential behaviors: what it does, that it's permanent, and what the response looks like. Annotations provide the safety profile. Nothing else is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter description is already detailed (GID, numeric string example). The tool description adds no extra parameter semantics beyond the schema, but it does clarify the action's scope ('from a task'), which slightly adds context. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific action: 'Permanently delete a time tracking entry from a task.' It uses a specific verb+resource and distinguishes itself from sibling time tracking tools (get/create/update/delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the primary use case: when you want to permanently delete a time tracking entry. It does not explicitly mention alternatives or exclusions, but the context is clear for a delete operation, and the destructive nature is highlighted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by enumerating the returned fields (including nested enum_options with gid, name, color, enabled), which is valuable given there is no output schema. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and return details. Every sentence serves a purpose: the first states what it does, the second explains the use case. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 2 params, no output schema, and strong annotations, the description is complete. It covers the action, return fields, and usage context (obtaining enum option GIDs). It does not need to explain permissions or error cases given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described (custom_field_gid and opt_fields). The description does not add parameter semantics beyond the schema; the mention of 'by GID' reiterates the parameter. Since the schema fully documents the parameters, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full details for a custom field by GID' and lists the specific return fields (name, type, description, enum_options, precision, format). This distinguishes it from sibling tools like asana_get_custom_fields_for_workspace, which retrieves multiple custom fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use this to get enum option GIDs before setting custom field values on tasks.' It also references how to obtain the required custom_field_gid via asana_get_custom_fields_for_workspace. However, it does not explicitly state when not to use it or alternatives, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds behavioral value by stating what fields are returned and framing it as a discovery step. It does not mention pagination behavior, but the schema covers limit/offset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The first sentence states the core function and return fields; the second provides practical usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with rich schema annotations and no output schema, the description sufficiently explains purpose, return values, and why it should be invoked. No major gaps for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters. The description reinforces the workspace concept and GID usage but adds no parameter-level 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all custom field definitions in a workspace,' which is a specific verb+resource+scope combo. It also lists what is returned (gid, name, type, enum_options), clearly distinguishing this from sibling tools like asana_get_custom_field or custom field mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to discover available custom fields and their GIDs before reading or writing custom field values on tasks.' This gives clear task context, though it does not explicitly name alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds value by listing the returned fields (name, status, notes, owner, etc.), which is useful for understanding output. However, it doesn't disclose additional behaviors such as pagination or permission requirements beyond what annotations imply. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, followed by return field list and a pointer to the sibling list tool. Every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID read operation, the description is complete. It specifies the input (GID), the output details (returned fields), and how to obtain the GID (via asana_get_goals). The annotations cover the read-only and idempotent nature. No output schema exists, but the description compensates by listing return fields. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 (goal_gid and opt_fields), so the baseline is 3. The description's mention of 'by GID' reinforces the primary parameter but adds no new syntax or format details beyond the schema. The opt_fields parameter is not explained in the description, but the schema covers it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full details for a goal by GID.' It specifies the resource (goal), the key identifier (GID), and differentiates from the list tool (asana_get_goals) by describing the 'full details' retrieval. It also enumerates the returned fields, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the user to asana_get_goals for listing goals and finding GIDs, providing a clear alternative for the discovery phase. This tells the agent when to use this tool versus its sibling list operation. The context is concise and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 known. The description adds valuable behavioral context beyond annotations by specifying the returned fields (gid, name, status, owner, team), supporting pagination, and indicating filter options, which helps set expectations about the tool's output and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then a concise summary of return fields and capabilities (filters, pagination). No redundant or filler content; every sentence provides necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward read-only list operation with comprehensive annotations and 100% schema parameter coverage. The description covers the essential behavior (what is returned, filtering, pagination) and works together with the schema/annotations to give the agent full understanding without needing an output schema. It is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all 7 parameters richly documented (e.g., team, limit, offset, workspace, opt_fields, time_periods, is_workspace_level). The description adds minimal extra parameter meaning, only mentioning 'team or time period' filters, which maps directly to the schema. Per the rubric, baseline 3 is appropriate when schema fully covers parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List goals in a workspace' with a specific verb and resource, and it distinguishes this from the singular asana_get_goal tool by indicating it returns multiple goal objects. It also mentions the return array and key fields, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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: listing goals within a workspace, with optional team/time period filters and pagination support. It does not explicitly exclude alternatives or mention asana_get_goal for single-goal retrieval, so it lacks explicit when-not-to-use guidance but still conveys applicable usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds value by enumerating the default return fields (gid, name, archived, etc.), giving the agent clear expectations about the response structure beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, then provides a comprehensive but necessary list of default fields. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple read-only lookup by ID, the description, combined with the high-quality schema and annotations, is fully sufficient. It clarifies the default output fields and the key parameter source, making the tool easy to invoke correctly without needing output schema or further details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with detailed descriptions for both project_id and opt_fields. The description repeats the default field list already present in the opt_fields schema but adds no new semantic 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details for a project by GID' with a specific verb and resource, and it lists the default return fields. This distinguishes it from sibling tools like asana_get_project_sections or asana_get_project_status, which have narrower scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when full project details are needed by GID, and the schema notes that project_id can be obtained from asana_search_projects. However, it does not explicitly mention when not to use this tool versus alternatives like asana_get_project_task_counts, leaving the guidance slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it returns an array with gid, name, resource_type and explains downstream usage, which is valuable beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the main action in the first and return value/use case in the second. No wasted words, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with full schema coverage, the description covers what it returns and why it's needed. The absence of output schema is compensated by the return type statement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (100% coverage), so the description adds no new parameter semantics. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'all sections in a project'. It also differentiates from section-specific tools by explaining the need for section GIDs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states that section GIDs are needed to place tasks in sections or call section-specific tools, providing a clear use case. It does not explicitly name alternatives but the context is sufficient to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the ordering behavior (newest first) and the return type (array of status objects), which are not captured by the read-only/idempotent annotations. It also clarifies the domain concept of health check-ins, adding context beyond the 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and resource, and contains no redundant information. Every phrase earns its place, making it highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description is complete: it states what is listed, the ordering, the domain meaning, and the return shape. The schema covers pagination and field selection, and annotations cover safety, so no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are well-documented in the input schema. The description does not add parameter-specific meaning beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all status updates for a project, ordered newest first, and explains what status updates are (health check-ins with green/yellow/red). This distinguishes it from the singular get_project_status sibling and other project tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by explaining that status updates are periodic health check-ins visible in the project's status tab, implying when this list tool is appropriate. However, it does not explicitly mention alternatives or exclusions, such as when to use the singular status getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations: results are limited to direct subtasks and return minimal fields by default. This is useful, though it doesn't detail pagination or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, then states key constraints and usage tips. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with rich annotations and fully described schema parameters, the description covers the essential behavioral nuances: depth, nested recursion, and default vs. extended fields. No output schema exists, but the return type (list of subtasks) is clear from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented. The description adds little beyond the schema—'minimal fields by default' and 'use opt_fields' are already reflected in the opt_fields parameter description. It gives no additional parameter-level insight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('direct subtasks of a task'), clearly distinguishing it from related tools like get_tasks_for_project or get_tasks_for_section. The phrase 'direct subtasks' and 'one level deep' precisely defines scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by explaining the one-level-depth limitation and instructing to call recursively for nested subtasks. It also advises using opt_fields for more fields. However, it does not explicitly name alternative sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint, idempotentHint, and no destructive action, the description adds value by stating the return format (array of tag objects) and pagination behavior for large workspaces. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the main purpose front-loaded. Every sentence contributes meaningful detail (workspace scoping, array return, pagination), with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, complete schema coverage, read-only annotations, and the clear return type mentioned in the description, all necessary context is provided. The optional workspace_gid and default workspace behavior are documented in the schema, so no gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all four parameters are well-documented with examples and defaults. The description's mention of limit/offset for pagination merely reiterates schema details, adding no new semantic information beyond what's already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all tags in a workspace, specifying the verb and resource. It distinguishes from sibling tools like asana_get_tag (single tag) and asana_get_tags_for_task (tags for a task) by emphasizing workspace scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that tags are workspace-scoped and can be applied to any task, implying this is for workspace-level listing. However, it does not explicitly mention alternative tools for task-specific or single-tag retrieval, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds behavioral context beyond the annotations: the default minimal response, the need for opt_fields, and the list of rich data types returned (custom fields, memberships, HTML notes, etc.). This helps the agent know what to expect and what parameters to set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose, followed by a critical usage warning and a summary of available rich data. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only single-task retrieval tool with strong annotations and a fully described parameter schema, the description is complete. It covers default behavior, parameter requirements, and return content expectations. An output schema is absent, but the description enumerates the major return fields, making it sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters have detailed descriptions in the schema. The tool description itself does not add new parameter semantics beyond saying 'always use opt_fields' and mentioning that task_id comes from other tools. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Get full details for a single task by GID.' It clearly distinguishes from sibling tools like search_tasks (search) or get_tasks_for_project (list) by emphasizing 'single task' and 'by GID.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance: default response is minimal, so always use opt_fields. It also tells the user where to obtain the task_id (from asana_search_tasks or asana_get_tasks_for_project), implying those are discovery tools and this is for retrieving full detail once the GID is known. Not explicit about when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the annotations by mentioning default return fields and the 'me' behavior. However, it states default fields as 'gid, name, and email' while the schema's opt_fields description says default fields are 'gid, resource_type, name', creating an inconsistency that could mislead the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences), front-loaded with the primary purpose, and contains no redundant information. Every sentence contributes to understanding usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-identifier tool, the description covers the key aspects: how to specify the user, what is returned by default, and the alternative tool for finding GIDs. The sibling tool reference adds necessary context, making the description complete enough for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to add much. It reiterates the acceptable values for user_gid (GID, email, 'me') and adds a brief note about 'me' meaning the current user, but this adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get details for an Asana user by GID, email, or 'me'. It also distinguishes itself from sibling tool asana_get_users_for_workspace by mentioning that the latter is for finding GIDs by name or email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool and when to use an alternative. It explains that 'me' identifies the current token's user and directs users to asana_get_users_for_workspace for finding GIDs by name or email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description only needs to add context. It adds value by stating return fields and pagination support, which are not fully captured by annotations. However, it could further disclose behavior like default limit or empty-workspace handling, but the existing context is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: the first states the action, the second describes returns, and the third gives usage guidance and pagination note. Every sentence contributes unique information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (gid, name, email) and usage context. It covers the main purpose, pagination, and a practical use case, making the tool self-sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description mentions pagination but does not add substantial meaning beyond the schema's existing parameter descriptions for limit and offset. It reinforces the workspace parameter's role but doesn't enrich semantics significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all users in a workspace, with specific verb and resource, and distinguishes it from the singular asana_get_user by emphasizing 'all users' and the workspace scope. It also specifies return fields (gid, name, email), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this to find a user's GID before assigning tasks or filtering by assignee.' It does not explicitly name alternative tools or exclusion conditions, but the context is sufficient for an agent to select this tool over similar ones like asana_typeahead or asana_get_user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds context about token-scoped access, the default return fields, and the typical workspace count. It does not contradict annotations and provides useful behavioral details beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences) and front-loaded with the primary purpose. Each sentence adds value: scope, usage order, typical case, and return schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with strong annotations and a well-documented schema, the description is complete. It explains the purpose, usage context, and return shape, requiring no further elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter opt_fields is fully described in the schema, including useful values and defaults. The description briefly mentions default return fields, but does not add significant meaning beyond what the schema already provides. Baseline of 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('List all Asana workspaces accessible to the current token') and resource (workspaces), and distinguishes it from sibling tools by noting it should be called first to obtain the workspace GID required by most other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to call this tool first and explains its role as a prerequisite for other tools. It also notes that most accounts have exactly one workspace, setting expectations. However, it does not mention when not to use it or name alternative tools, though no direct alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, so the tool's mutating nature is known. The description adds the return value ('empty object {} on success'), which is useful. However, it does not disclose additional behavioral details (e.g., error cases, dependencies on section membership) beyond the annotations, so the added value is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states the action, second gives the return value and an alternative. Every word earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple reorder operation, the description provides all essential context: purpose, return behavior, and alternate tool for rename. The lack of an output schema is mitigated by the explicit return type statement, and annotations cover the side-effect profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with each parameter described, including mutual exclusivity of after_section and before_section. The description does not add further parameter-level nuance beyond restating the 'before or after' concept, so it meets the baseline but no more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Reorder a section within a project') with a specific verb and resource. It distinguishes from asana_update_section by explicitly noting the rename use case, preventing confusion among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells users when to use this tool (reorder a section) and provides an alternative for a related but different operation ('To rename a section, use asana_update_section'), which is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds value by detailing the non-destructive effects: the task remains, other project memberships are preserved, and only the association is removed. This goes beyond the annotations to clarify the exact scope of the destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the primary action and then clarify boundaries. Every sentence earns its place with no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with full annotations and complete schema descriptions, this description is complete enough. It explains the exact effect, what remains unaffected, and the limited scope of the operation. No output schema exists, but none is needed for such a straightforward removal action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters fully with clear descriptions: task_id is the GID of the task, project_id is the GID of the project to remove from. The description adds no additional parameter-level information beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: remove a task from a project. It explicitly distinguishes this from deleting the task ('The task still exists...') and from removing tag associations by specifying 'Only removes the association.' This is a specific verb+resource with clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: when you want to unlink a task from a project without deleting it. It implies when not to use it (not for deleting tasks, not for affecting other project memberships). However, it does not explicitly name alternatives like delete_task or remove_tag, so it lacks explicit when-not/alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly=false, idempotent=true, destructive=false). The description adds valuable behavioral context: the partial-update behavior, the returned object, and the critical constraint that setting status requires a configured metric, which is not evident from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource, no filler. The warning about status is essential and placed at the end without disrupting the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter update tool with full schema coverage and annotations, the description covers the key semantics: partial update, return value, and an important edge case. No output schema exists, so mentioning the returned goal object is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 reinforces partial-update semantics and repeats the status/metric warning, but does not add new parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the resource ('an existing goal'), and the scope ('fields'), distinguishing it from sibling tools like create_goal, get_goal, and delete_goal. The 'Only supply the fields to change' adds precision about the update semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it updates an existing goal, not creates one, and explicitly instructs to supply only changing fields. It does not name alternatives explicitly, but the sibling list makes it obvious; no exclusions are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a non-read-only, non-destructive, idempotent write operation. The description adds useful behavioral details: default placement at the end of the project and the mutual exclusivity of placement parameters. These go beyond what the annotations provide and do not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: the first states the core action, the second gives the default behavior, and the third explains the optional parameters with a clear constraint. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, full schema coverage, and rich annotations, the description is largely complete. It covers purpose, default behavior, and parameter constraints. A minor omission is the behavior when the task is already in the project, but the idempotentHint annotation implies that such calls are safe and likely have no adverse effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 5 parameters with descriptions (100% coverage), so a baseline of 3 is appropriate. The description adds value by stating the default end-of-project behavior and reinforcing the mutual exclusivity constraint, which enriches the understanding of how the optional parameters relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action: 'Add an existing task to a project' with a specific verb and resource. It also notes that tasks can belong to multiple projects, which distinguishes it from sibling tools like removing a task from a project or adding a task to a section. This is a clear, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the default behavior (added to the end of the project) and specifies the optional placement parameters with the constraint 'Use at most one of: section, insert_after, insert_before.' This gives clear usage context. However, it does not explicitly mention alternative tools (e.g., asana_add_task_to_section) or when not to use this tool, so it's not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default top placement, the effect of insert_before/insert_after, and that it returns a success message. Annotations already indicate non-read-only, non-destructive, idempotent behavior; description adds placement specifics 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: action, behavior, and alternative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple move operation with complete schema and annotations. The description covers key behavioral aspects and provides an alternative for creation-time placement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all parameters (100%). The description adds default placement behavior (top of section) that is not in the schema, enhancing understanding of insert_before/insert_after.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool moves a task into a specific section within a project, using a specific verb and resource. It distinguishes from sibling tools like asana_add_project_to_task by focusing on section placement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to prefer asana_create_task with memberships when placing tasks at creation time. However, it does not fully cover when to use this tool versus other update/move alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly, non-destructive, non-idempotent behavior. The description adds valuable behavioral context beyond that: the precedence rule for html_text over text, and the return fields (gid, text, created_at, created_by). It does not cover permissions or rate limits, but the annotations lower the burden, making this a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry essential information: the action, parameter selection guidance, precedence, and return value. It is front-loaded with 'Add a comment to a task' and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately lists the return fields. It also covers the main decision point (text vs html_text). It does not mention potential side effects beyond what annotations imply, but given the schema's exhaustive parameter descriptions and annotation coverage, the description 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the critical precedence rule ('html_text is used and text is ignored') which is not present in any parameter description, and clarifies the return object's fields. This goes beyond the schema's already detailed parameter docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Add a comment to a task,' which is a specific verb+resource that clearly distinguishes this tool from siblings like asana_get_task_stories (read) and asana_update_task (modify task fields). The purpose is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on choosing between text and html_text, including precedence behavior ('If both are given, html_text is used and text is ignored'). It implies the usage context (adding a comment) but does not name alternative tools or explicit exclusions, so it earns a 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, idempotent, non-destructive. The description adds valuable behavioral context beyond annotations: it notes that cycle time is only computed for the top 12 comparables due to API cost, and it explains that similarity is computed from term overlap, tags, and section match. This helps the agent set expectations about performance and results. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: (1) state the tool's core function and value, (2) detail key return values and their significance, (3) explain similarity logic and provide usage guidance. No filler words, front-loaded with the most important information, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description still discloses the key return values (story points and cycle time) and a practical limitation (top 12 cycle time computation). It also explains the similarity matching approach and the intended use case. This is complete enough for an agent to use the tool effectively without surprises, though it could have mentioned pagination or error conditions if applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters. The description adds extra meaning by explaining that the 'task' parameter accepts multiple formats (name, URL, or GID) and by highlighting that 'limit' affects cycle-time computation due to API costs. This goes beyond the schema's literal field descriptions and helps the agent choose parameter values wisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Find') and resource ('completed tasks similar to a target task'), and immediately clarifies its purpose ('anchor an estimate on real history'). It also distinguishes itself from sibling tools by mentioning reference-class forecasting and the specific similarity criteria, making it clearly different from generic search or match tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use it: 'Use this before estimating' so the estimate is grounded in real costs. It provides clear context on what the tool returns and why it's valuable. It does not explicitly mention when not to use it or name alternatives, but the guidance is strong enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by listing the specific fields returned (gid, name, resource_subtype, created_at, host) and clarifying that download URLs are not included here, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences, with the first stating the core function and return fields, and the second offering a relevant alternative. No redundant or superfluous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-type tool with 4 parameters and no output schema, the description adequately covers return fields and the primary alternative. However, it does not mention pagination or that 'all' attachments may require multiple pages, though the schema's limit/offset parameters imply this. Still, the description is largely complete for an agent to understand what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (limit, offset, parent, opt_fields) having clear descriptions. The tool description does not add additional parameter-level meaning beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('attachments on a task or project') and explicitly differentiates from the sibling asana_get_attachment by stating that the latter is for download URLs. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance by pointing to asana_get_attachment as the alternative when a download URL is needed, implying this tool is for listing attachments rather than fetching a single attachment's URL. This is an explicit when-to-use vs. alternative instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, read-only, idempotent operation. The description adds valuable behavioral context beyond annotations: it returns an event timeline, computes derived metrics, triggers risk signals, and explicitly notes the API cost (2–3 requests, more for long streams). It also discloses that include_subtasks does not compute full lifecycles for subtasks due to cost. These are meaningful behavioral disclosures not captured by 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly efficient: the first sentence defines what the tool returns, the second gives concrete use cases, and the third covers input flexibility and cost. Every sentence earns its place, and the content is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is analytically complex with no output schema, so the description must compensate. It lists the major return components (timeline, section times, cycle time, slip days, ownership churn, risk signals) and covers input variants, disambiguation, and cost. Minor gaps remain, such as explicit error handling for missing tasks or output structure details, but the description is comprehensive enough for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. However, the description adds extra semantic clarity beyond the schema: it explains how the 'project' parameter disambiguates multi-project tasks and how 'include_subtasks' returns a compact list without full lifecycles. The tool description also clarifies that the task parameter accepts GIDs, URLs, or names, with a disambiguation fallback, enriching the schema's dry specifications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Reconstruct a task's full lifecycle from its Asana activity stream.' It enumerates the specific outputs (timeline, section durations, cycle/lead time, reschedule history, ownership churn, risk signals), which distinguishes it from sibling tools like asana_get_task (which fetches current state) or asana_get_task_stories (which fetches stories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: "Use this to answer 'why is this task late?', 'where did it get stuck?' or 'who has touched it?'." This provides clear context for usage, though it does not explicitly name alternative tools or provide when-not-to-use guidance, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context: tasks are direct members only, results span all sections, and the response uses minimal fields unless opt_fields is provided. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences with no filler. The first sentence states the primary action, the second gives sibling guidance, and the third explains the default field behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 detailed schema descriptions, the description covers the key gotchas: exclusion of subtasks, section coverage, and minimal return fields. It also provides sibling differentiation, making it sufficiently complete despite the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides comprehensive descriptions for all 5 parameters, so the description is not required to add much. It does reinforce the use of opt_fields, but doesn't introduce meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tasks in a project', using a specific verb and resource, and immediately clarifies scope with 'direct members only, not subtasks'. It explicitly distinguishes itself from the sibling tool asana_get_tasks_for_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit alternative: 'For tasks in a specific section use asana_get_tasks_for_section', and sets clear boundaries by excluding subtasks and stating that results span sections. This helps the agent choose between related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral detail: 'Returns minimal fields by default — use opt_fields.' This informs the agent about the default response shape and how to request more fields. However, it doesn't clarify pagination behavior despite saying 'List all tasks,' leaving a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place. The first states the core action; the second provides an essential prerequisite and a usage tip. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, the prerequisite for the required parameter, and a hint about controlling returned fields. With rich annotations (read-only, idempotent) and a 100% schema-described parameter set, this is adequate. Minor omission: no explicit mention of pagination despite saying 'List all tasks,' but the schema documents limit/offset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (section_gid, limit, offset, opt_fields) are already documented. The description adds value by explaining the default return fields and advising the use of opt_fields, which enhances the semantics of that parameter. It also reiterates how to obtain section_gid, though that's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all tasks') and the resource ('a specific project section'), distinguishing it from related tools like asana_get_tasks_for_project and asana_get_tasks_for_tag. It also references asana_get_project_sections as a prerequisite, which reinforces the specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Use asana_get_project_sections to get section GIDs.' However, it doesn't explicitly mention when not to use this tool or contrast it with alternatives such as asana_get_tasks_for_project or asana_search_tasks. This gives clear context for the required parameter but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by specifying the exact fields returned. For a simple GET-by-ID, no further behavioral caveats (pagination, auth) are necessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action ('Get details for a team by GID'). No wasted words or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with rich annotations and complete schema, the description fully covers purpose, return values, and sibling alternative. No output schema means the listed return fields serve as adequate context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, with detailed descriptions for team_gid and opt_fields. The description reinforces 'by GID' but adds no new 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does: 'Get details for a team by GID' and explicitly lists the return fields (gid, name, description, organization). It distinguishes itself from the sibling asana_get_teams_for_workspace by noting that the sibling is for finding GIDs, not retrieving team details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use asana_get_teams_for_workspace to find team GIDs.' This tells the agent when to use the alternative, and implicitly conveys that this tool requires an existing team GID to be useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral context: it returns the updated task object and explicitly explains that setting parent to null promotes a subtask to top-level. This goes beyond what annotations provide and aligns with them, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, each earning its place. It front-loads the core action, then covers optional positioning, then explains removal behavior. No redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with five parameters and no output schema, the description covers the essential behaviors: conversion, optional positioning, null removal, and return value. It does not mention preconditions like the task needing to exist or the parent being a task, but the schema and annotations carry much of the burden. Overall, it is sufficiently complete for most agent use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters. The description adds contextual meaning by framing insert_after/insert_before as controlling 'the subtask's position among its siblings' and reinforcing the null-parent removal behavior. This provides a higher-level understanding that the schema's individual descriptions don't fully convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Convert a task into a subtask by assigning it a parent task.' It distinguishes this from sibling tools like asana_create_subtask (which creates new subtasks) by focusing on converting an existing task. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool: to assign a parent to an existing task, optionally control placement among siblings, or remove a parent by setting it to null. While it doesn't explicitly name alternative tools, the wording implies the distinction from create_subtask and makes the use case clear. It lacks an explicit 'use this instead of X' statement but is more than sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral details beyond that: returns up to 100 compact results, results are ordered by relevance (recency for projects, contact frequency for users), and the tip about opt_fields for emails. This meaningfully supplements the annotation-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and every sentence adds value: purpose, usage guidance, and behavioral/parameter tips. There is no fluff or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 5 parameters and no output schema, the description covers the core return shape ('compact results with gid and name'), the primary use case, and ordering behavior. It omits edge cases like empty results or error handling, but given the simple read-only nature and explicit annotations, the description is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters at 100%, so baseline is 3. The description adds concrete guidance beyond the schema: 'For users, include opt_fields: 'gid,name,email'' and gives an example of using the query parameter. This enriches parameter understanding beyond mere field definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and names the resource ('Asana objects') with explicit types listed. It clearly defines the scope ('by partial name') and distinguishes itself from siblings by positioning itself as the GID-lookup tool ('find the GID of a resource when you only know its name').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use the tool: when you need a resource's GID from a name, with a concrete example ('find a task called 'Fix login bug''). It does not mention exclusions or alternatives, but the 'Use this to...' phrasing gives clear context that this is a lightweight lookup, contrasting with the more specialized search tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, idempotent operation. The description adds that the updated project object is returned, which is useful behavioral information. No contradictions with annotations, but no additional details on side effects or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding meaningful information: purpose, partial-update behavior, and return value. It is front-loaded and contains no filler or repetition, ideal for a tool with a well-documented schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11-parameter schema and no output schema, the description covers essential use context (partial updates, return object). Field-level details are already in the schema. It lacks notes on field interactions or error conditions, but this is not critical for a straightforward update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 11 parameters have individual descriptions in the schema (100% coverage), so the baseline is 3. The description adds a key semantic beyond the schema: only supplied fields are changed, implying unspecified parameters retain their current values. This is valuable agent guidance for constructing the request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Update fields on an existing project.' It specifies the resource (project) and distinguishes from sibling tools like create_project or delete_project. The partial-update instruction ('Only supply the fields you want to change') further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage guideline: 'Only supply the fields you want to change', signaling that this is a partial update and the agent need not send all fields. It does not explicitly compare with alternatives like update_task, but for a generic update tool, this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses partial update semantics, return value ('Returns the updated task object'), and a shorthand for completion. Annotations already cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds actionable context without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded sentences cover purpose, usage rule, return value, and key exceptions. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and a nested object (custom_fields), the description sufficiently covers key behaviors: partial update, return value, completion, and section-moving exclusion. It does not explain permissions or all side effects, but 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter descriptions already provide full semantics. The description only adds a note about the 'completed' parameter, which slightly reinforces schema info but does not deepen understanding of other parameters like custom_fields or html_notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update fields on an existing task' with a specific verb and resource, distinguishing it from siblings like create_task and delete_task. The additional note about moving sections via asana_add_task_to_section clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage instructions: 'Only supply the fields you want to change' and a specific how-to for completion ('set completed: true'). Also gives a clear alternative for moving sections, directing users to asana_add_task_to_section instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the description's mention of returning an empty object `{}` on success adds useful behavioral context about the return contract without contradicting annotations. It doesn't elaborate on side effects, but that's covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: action, return value, and related-tool guidance. No filler or repetition; front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 full schema coverage and robust annotations, the description covers return behavior and related tools. It is complete enough for an agent to select and execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions (e.g., numeric string examples), so the description adds no extra parameter meaning. Baseline of 3 is appropriate as the schema carries the full parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Apply a tag to a task', a specific verb+resource pairing that clearly distinguishes it from sibling asana_remove_tag_from_task. This is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use asana_get_tags_for_workspace to find the tag GID first, and names asana_remove_tag_from_task as the alternative for removal. This provides both a prerequisite and a clear when-to-use vs. when-not-to-use boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds concrete behavior by stating the return value (empty object `{}`) and elaborating the dependency effect on task scheduling. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, includes a clarifying parenthetical, and states the return value. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, full schema coverage, clear annotations), the description fully covers purpose, usage, and return behavior. No output schema is needed, and the inverse sibling is referenced, making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are thoroughly described in the schema. The description adds no additional parameter-level detail beyond restating the relationship, 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.
Purpose5/5
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 as dependents of a given task') and clearly explains the dependency semantics. It explicitly differentiates from the sibling asana_add_task_dependencies by calling it the inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool (asana_add_task_dependencies) and clarifies the inverse relationship, giving the agent clear guidance on when to use this tool versus the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a write operation (readOnlyHint=false, destructiveHint=false), and the description adds meaningful behavioral context: it creates a named link that appears in the task's attachments panel, and it explicitly disallows binary file uploads. This goes beyond annotations to clarify the attachment type and the resulting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four concise sentences, each adding essential information: the action, the result, typical use cases, and a critical limitation. It is front-loaded with the core purpose and contains no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with full schema coverage and annotations, provides sufficient context for correct tool invocation. It explains the tool's purpose, the type of attachment, typical usage, and the important restriction against binary uploads. No output schema is present, but the description need not detail return values for a simple creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed descriptions for all four parameters, including the purpose of `parent`, `url`, `name`, and `opt_fields`. The description does not add significant new parameter-level information beyond restating that the parent is a task or project and the attachment is a URL, so it relies on the schema for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool attaches an external URL link to a task or project and creates a named link in the attachments panel. It distinguishes this from file/binary uploads by explicitly noting that only URL-based attachments are supported, and it aligns with sibling tools for attachment management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: to link external resources like GitHub PRs, documents, or design files to a task. It also states when not to use it, clearly excluding file uploads and stating that only URL-based attachments are supported. This provides clear context and a distinction from other attachment-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: 'Permanently delete', cascade effect, locked-field deletion permission, and the specific success response (`{}`). It thoroughly discloses the operational implications, which is highly valuable given the destructive action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient sentences, each providing essential information: action, consequence, condition, and return value. No filler, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one param and no output schema, the description fully covers the operational context: what happens, who can delete locked fields, and what to expect on success. There are no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter with a clear description (including a type and example). The tool description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Permanently delete a custom field') and the resource affected ('from the workspace'), and distinguishes from sibling tools by emphasizing the cascading removal ('removes the field from all tasks and projects'). This differentiates it from create/update/get operations on custom fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance, including the permanent nature and the effect on all tasks/projects. It also mentions the locked-field condition, which affects when the tool can be used. However, it does not explicitly contrast with update_custom_field or other alternatives, though the usage is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the annotations: it confirms the permanent destructive nature, explicitly states that projects are not deleted, and discloses the return value (success message). This complements the destructiveHint=true annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary action, and every word adds value. No repetition or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with strong annotations, the description fully covers the action, side effects, and return type. No output schema exists, but the success message disclosure is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description of portfolio_gid. The tool description does not add parameter-specific detail beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Permanently delete a portfolio' with a specific verb and resource, clearly distinguishing it from sibling delete tools (e.g., delete_project, delete_goal). The clarification that projects within the portfolio are not deleted further sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to delete a portfolio) and provides a key exclusion: it does not delete the contained projects, signaling that project deletion requires a separate tool. It does not explicitly name an alternative tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds crucial behavioral details: tasks are moved to the default section (NOT deleted), and the last section cannot be deleted. This goes beyond the structured annotations and clarifies the exact impact, reducing surprise for the agent. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose, followed by the two most important caveats (task preservation and last-section restriction). Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter delete tool, the description covers the action, its side effects, an edge case, and the return type (success message). Combined with rich annotations and a clear schema, the description is complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers the sole parameter section_gid with type, required status, and an example. The description does not add extra semantics about the parameter itself, but it does explain what the section deletion entails. Per calibration, high schema coverage (>80%) sets a baseline of 3, and description adds no additional parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Delete'), the resource ('a section from a project'), and the scope of action. It distinguishes this from sibling tools like asana_delete_task or asana_update_section by specifying that tasks are moved (not deleted) and that the last section cannot be deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear operational context: the action deletes a section but preserves tasks, and it cannot delete the final remaining section. However, it does not explicitly name alternative tools (e.g., 'asana_move_section' for repositioning, 'asana_delete_task' for deleting tasks), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint and readOnlyHint, but the description adds valuable context: the deletion cascades to subtasks and is irreversible. This goes beyond the structured metadata, though it could mention permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and scope, followed by the alternative. No wasted words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one fully-documented parameter and annotations covering safety, the description provides complete context: purpose, effect (subtasks, irreversibility), and alternative. No output schema is needed for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully covers the only parameter `task_id` with a clear description and example. The tool description adds no new param detail, so baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'task', and adds scope ('including all its subtasks') and consequence ('cannot be undone'). It distinguishes the tool from asana_update_task, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides an alternative usage: 'Use asana_update_task with `completed: true` instead if you just want to mark it done.' This tells the agent when not to use the tool and directs to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context by listing the exact fields returned (name, download_url, view_url, size, host, created_at, parent) and explains the download_url's purpose. This goes beyond the annotations and helps the agent understand the tool's output and usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary purpose. Every sentence adds value: purpose, return fields, and usage guidance. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-attachment getter, the description is complete. It explains what the tool returns, how to access the file, and names the alternative for listing. Annotations cover safety and idempotency, and the schema covers parameters. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the input schema. The description does not add extra meaning beyond the schema, only reiterating that it fetches by GID. Baseline 3 is appropriate as the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details for a single attachment by GID', which is a specific verb+resource+scope. It also distinguishes itself from the sibling tool asana_get_attachments_for_object by explicitly mentioning that the sibling is for listing all attachments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use the download_url to access the file' and 'Use asana_get_attachments_for_object to list all attachments on a task.' This clearly tells when to use this tool vs. the alternative, with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnly/idempotent annotations, it reveals the cost model ('roughly one API request per sampled task'), the sampling bound (max_tasks hard cap 100), server-wide request budget, and that the response reports sampling coverage. It also notes the statistical treatment of cycle time (mean as secondary due to right skew), which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but rich: main action first, then return list, then cost warning, then usage questions. Each sentence adds distinct information without fluff, making it appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex analytics tool with no output schema, it conveys the full return payload (percentiles, dwell times, throughput, reschedule stats, offender lists with permalinks), the cost/sampling behavior, and when to apply it. Combined with fully-described parameters, it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% parameter coverage, so the description doesn't need to carry semantics. The only extra value is reiterating that max_tasks bounds the cost, but that's already in the parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compute delivery-flow statistics for a project by replaying the activity stream of its recently-completed tasks.' It enumerates concrete outputs (cycle-time/lead-time percentiles, dwell times, throughput) and the questions it answers ('where does work get stuck?'), clearly distinguishing it from simple getter siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases ('Use this to answer...') and cost guidance (EXPENSIVE: costs one API request per sampled task, bounded by max_tasks). It does not name alternative tools for exclusions, but the context is clear, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations that establish read-only and idempotent behavior, the description discloses ordering ('oldest first'), return structure (array of story objects), and the semantic distinction between 'comment' and 'system' types with examples. This adds substantial value for predicting tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every clause adds meaningful detail (ordering, types, filtering). No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value (array of story objects), the meaning of `type` values, and how to filter for comments. Combined with clear annotations and full schema coverage, this gives a complete understanding for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (task_id, opt_fields), so the schema already provides full parameter descriptions. The tool description does not add parameter-specific semantics, but the high schema coverage warrants a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all stories for a task'), specifying that stories include both comments and system activity, and ordering oldest first. This distinguishes it from sibling tools like asana_create_task_story or asana_get_task_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 this tool (to retrieve a task's stories) and includes a practical filtering tip for isolating user comments. It does not explicitly name alternative tools for different purposes, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description goes further by disclosing the windowed search behavior, coverage reporting guarantee, and the critical caveat that `assignee` reflects the current assignee, not the actual actor. This is essential behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, technical reliability, and caveat. Each sentence delivers distinct, high-value information with no fluff. The most important use-case and caveats are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex reporting tool with no output schema, the description explains what is returned (aggregates, coverage, methodology caveats) and why it works reliably beyond Asana's search cap. Combined with the fully documented schema, the description is complete enough for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 7 parameters, each with clear meaning and defaults. The description adds high-level context but does not need to repeat parameter details. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Summarize what a person did in Asana over a date range'. It lists concrete data categories (tasks completed, created, commented, open workload) and aggregation dimensions (month, project), clearly distinguishing this from raw task-listing tools like asana_search_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for aggregated activity reporting and gives a strong reason to prefer it over naive search ('Uses windowed search to work correctly beyond Asana's 100-result search cap'). It also mentions always reporting coverage to avoid misinterpreting partial results. However, it does not explicitly name alternatives or state when not to use, so a perfect score is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses critical behavioral traits: it uses median and MAD instead of mean/stddev, detects and excludes bulk-close periods, reports story-point coverage, suppresses point velocity below 50% coverage, and always returns a range. This is substantial added value that an agent needs to interpret the output correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long and front-loaded with the core purpose. Every sentence adds meaningful detail—method statistics, bulk-close handling, coverage suppression rationale, and the range output—without redundancy or fluff. It is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description appropriately explains the key output behavior ('Always returns a commitment RANGE, never a single number') and covers the main edge cases (bulk-close exclusion, low-coverage suppression). It also clarifies the statistical approach, making the tool's behavior predictable and complete for an agent to select and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all six parameters with descriptions (100% coverage), so the description doesn't need to compensate. The description adds a little context about 'recent periods' and 'bulk-close periods' that relates to the `periods` and `exclude_dates` parameters, but it does not go beyond what the schema provides in terms of parameter-specific meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Compute delivery velocity for a person or project over recent periods,' using a specific verb and resource. It distinguishes itself from sibling Asana getters by focusing on a computed metric, and the detail about median/MAD and coverage thresholds sets it apart from simple data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use—'when you need delivery velocity'—and explains several methodological behaviors that imply when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it, such as comparing to asana_get_project_flow_metrics or task-count-only tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses important matching behaviors: recognizes multiple formats, falls back to a conservative fuzzy match, only accepts single unambiguous hits. This adds real behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose, no filler. Each clause earns its place—input examples, recognition formats, fuzzy fallback, and use cases are all compactly included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description fully covers purpose, input scope, matching behavior, and usage scenarios. It is complete enough for an agent to select and invoke correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context about the 'refs' parameter (branch names, commit subjects, PR titles) already partially in the schema, but does not significantly clarify the 'workspace' parameter beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resolve') and clearly identifies the resource (code references → Asana tasks). It lists example inputs and distinguishes itself from all sibling tools by being the only one that matches refs to tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Use this to connect repository history to Asana work') and gives two concrete use cases. It lacks an explicit 'when not to use' or mention of alternatives, but no sibling tool overlaps, making the guidance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the action is permanent and returns an empty object {} on success, adding behavioral detail beyond the annotations (destructiveHint, idempotentHint). It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each providing essential information: the action, the return value, and the permanence warning. No wasted words, with the most important information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete operation, the description fully covers the core action, result, irreversibility, and how to obtain the required ID. Combined with the annotations and schema, there are no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the attachment_gid parameter (100% coverage). The description adds value by pointing to asana_get_attachments_for_object as the source for GIDs, enriching the parameter's contextual meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an attachment from a task or project' with a specific verb and resource. It clearly distinguishes from sibling attachment tools like asana_get_attachment and asana_create_attachment_for_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context by instructing users to obtain attachment GIDs from asana_get_attachments_for_object, which is a prerequisite for using this tool. It does not explicitly discuss alternatives, but the deletion scope is unambiguous given the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the surprising behavior that an empty object is returned unless opt_fields is specified, which is not covered by annotations. This adds significant value beyond the readOnly/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the core purpose, the second delivers a crucial warning. No unnecessary words, perfectly front-loaded and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 no output schema, the description is complete: it explains the main behavior, the requirement for opt_fields, and the breakdown by completion status. This is sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents both parameters (100% coverage), but the description reinforces the critical requirement for opt_fields and provides a recommended value, going beyond the schema's static description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets task counts broken down by completion status, using a specific verb and resource. This distinguishes it from siblings like asana_get_tasks_for_project, which fetches tasks rather than counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use (obtaining task counts for a project) and a critical usage rule (must include opt_fields). However, it does not explicitly mention alternative tools or when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds context beyond these by specifying what the returned details include and that the operation is scoped to a single section by GID. It does not contradict annotations and provides useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core purpose and return fields; the second gives a cross-reference to a sibling tool. Every sentence serves a purpose, and the structure is front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only retrieval tool with full annotation coverage and a descriptive schema, the description is complete. It explains what the tool returns, how to obtain the required parameter, and how it relates to the sibling list operation. No significant gaps exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The description enhances section_gid semantics by pointing to asana_get_project_sections as the source for GIDs, which aids correct invocation. The opt_fields parameter is not expanded in the description, but the schema's description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific verb and resource: 'Get details for a single section by GID.' It also lists the returned fields (name, created_at, parent project) and explicitly distinguishes from the sibling tool asana_get_project_sections, which lists all sections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it tells the agent to use asana_get_project_sections to list all sections and find GIDs, implying this tool is for fetching a single section when the GID is already known. This directly addresses when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already declaring read-only, idempotent, and non-destructive, the description adds substantial behavioral context: searches both names and descriptions, caps results at 100 with no auto-pagination, and returns minimal fields by default requiring opt_fields. These are critical runtime behaviors not inferable from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses five short, non-redundant sentences. Each sentence carries unique information: purpose, search scope, result cap, filter selection guidance, and output field requirement. It is front-loaded with the core purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large parameter schema and rich annotations, the description supplies all missing high-level context: workspace-wide search semantics, searchable fields (names+descriptions), result limits, pagination absence, and default response shape. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds value by recommending specific filter parameters (projects_any, assignee_any, completed, due_on_before) and by emphasizing the opt_fields requirement, giving agents a strategic entry point into the 56-parameter surface.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Full-text search for tasks across a workspace with advanced filters' and adds 'Searches task names AND descriptions,' making the verb, resource, and scope explicit. This clearly distinguishes it from sibling tools like asana_search_projects and get_tasks_for_project by emphasizing workspace-wide full-text search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational guidance: 'Prefer filters like projects_any, assignee_any, completed, or due_on_before to narrow results' and 'Returns up to 100 results (no auto-pagination).' However, it does not explicitly name alternative tools or state when-not-to-use this tool, so it misses the 'explicit alternatives' criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![asana-mcp-server MCP server](https://glama.ai/mcp/servers/BlZvi/asana-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/BlZvi/asana-mcp-server)

Score Badge

Copy to your README.md:

[![asana-mcp-server MCP server](https://glama.ai/mcp/servers/BlZvi/asana-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/BlZvi/asana-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BlZvi/asana-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server