MCP Server for Asana

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 distinct purposes targeting specific Asana resources and actions, such as 'asana_create_task' vs. 'asana_update_task' or 'asana_get_project' vs. 'asana_search_projects'. However, there is some potential overlap between 'asana_get_tasks_for_project' and 'asana_get_project_hierarchy' (which includes tasks), and between 'asana_get_project_status' and 'asana_get_project_statuses', which could cause minor confusion in selection.
Naming Consistency5/5
All tools follow a consistent 'asana_verb_noun' pattern with snake_case throughout, such as 'asana_create_project', 'asana_get_task', and 'asana_update_task'. The naming is predictable and uniform, making it easy for agents to understand and use the toolset without ambiguity in formatting.
Tool Count2/5
With 41 tools, the count is excessive for a typical MCP server, making it heavy and potentially overwhelming for agents to navigate. While Asana's API is feature-rich, this many tools suggests over-fragmentation of operations that could have been consolidated, such as separate tools for adding followers to projects vs. tasks, which might be better handled with parameters.
Completeness5/5
The toolset provides comprehensive coverage of Asana's core functionalities, including CRUD operations for tasks, projects, sections, and attachments, as well as advanced features like dependencies, stories, statuses, and searches. There are no obvious gaps; agents can perform full lifecycle management and complex workflows without dead ends.
Average 3/5 across 41 of 41 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get users' implies a read operation, but the description doesn't cover critical behaviors like pagination handling (though the schema hints at it), rate limits, authentication requirements, or error conditions. It mentions nothing about the return format or what 'users' entails (e.g., basic vs. detailed info).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple tool, though it could be more front-loaded with key details (e.g., 'List all users in a workspace with pagination support'). No fluff or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 parameters, no annotations, no output schema), the description is incomplete. It lacks information on return values (e.g., user object structure), error handling, authentication needs, and usage context. While the schema covers parameters well, the description fails to compensate for missing behavioral and output details, making it inadequate for reliable 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 schema fully documents all 6 parameters (workspace_id, opt_fields, limit, offset, auto_paginate, max_pages). The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions (e.g., how auto_paginate affects limit) or provide examples. Baseline 3 is appropriate when the schema does all the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get users in a workspace' clearly states the verb ('Get') and resource ('users in a workspace'), but it's vague about scope and doesn't distinguish from potential siblings. It doesn't specify if this retrieves all users, active users, or a filtered subset, nor does it differentiate from other user-related tools that might exist (though none are listed in siblings).
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., workspace access), compare it to other user-fetching methods, or indicate scenarios where it's preferred. With no annotations and no output schema, this lack of context leaves the agent guessing about appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get sections' but does not clarify if this is a read-only operation, what permissions are required, whether it returns paginated results, or the format of the output. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 'Get sections in a project' is extremely concise and front-loaded, consisting of a single, direct sentence with no unnecessary words. It efficiently communicates the core purpose without any structural waste, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It lacks details on behavioral aspects (e.g., read-only nature, error handling), output format, and usage context. Given the complexity of interacting with a project management API and the absence of structured data, the description should provide more guidance to be fully 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 description coverage is 100%, with clear descriptions for both parameters ('project_id' and 'opt_fields'). The description does not add any additional meaning beyond the schema, such as examples for 'opt_fields' or constraints on 'project_id'. Given the high schema coverage, a baseline score of 3 is appropriate as the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get sections in a project' clearly states the verb ('Get') and resource ('sections in a project'), making the purpose understandable. However, it lacks specificity about what 'sections' are (e.g., task sections, project phases) and does not differentiate from sibling tools like 'asana_get_tasks_for_section' or 'asana_reorder_sections', leaving room for ambiguity.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid project ID), exclusions, or comparisons to siblings such as 'asana_get_project' or 'asana_get_tasks_for_section', leaving the agent to infer usage context independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get'), implying a read operation, but lacks details on permissions, rate limits, error handling, or response format. For a tool with zero annotation coverage, this is a significant gap—it doesn't describe what 'Get' entails beyond the basic verb, missing critical context for safe and effective use.
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, clear sentence with zero waste—it directly states the tool's purpose without redundancy or fluff. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every word earns its place, meeting the highest standard for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a read operation with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'project status update' returns, how to handle the optional fields, or any behavioral traits. With siblings present, it also fails to differentiate contextually. For a tool with these gaps, the description should provide more guidance to be fully 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 description coverage is 100%, with both parameters ('project_status_gid' and 'opt_fields') documented in the schema. The description adds no additional meaning beyond the schema, such as examples or usage notes for parameters. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which applies here as the description doesn't compensate but doesn't need to given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get') and resource ('project status update'), providing a basic purpose. However, it's vague about what a 'project status update' entails compared to siblings like 'asana_get_project_statuses' (plural) or 'asana_get_project'—it doesn't specify if this retrieves a single status update, its details, or how it differs from related tools. This meets the minimum viable threshold but lacks sibling differentiation.
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 offers no guidance on when to use this tool versus alternatives. With siblings like 'asana_get_project_statuses' (likely for listing multiple statuses) and 'asana_get_project' (for project details), there's no indication of context, prerequisites, or exclusions. This leaves the agent to infer usage, which is inadequate for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states a basic action without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, pagination behavior (implied by parameters but not explained), rate limits, authentication needs, or error handling, leaving significant gaps for agent understanding.
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, efficient sentence with zero waste. It's appropriately sized for a simple retrieval tool and front-loaded with the core action, though it could benefit from more detail given the lack of annotations and output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 4 parameters, the description is incomplete. It doesn't explain return values, error cases, or behavioral context, making it inadequate for an agent to fully understand tool usage beyond basic purpose. More detail is needed to compensate for missing structured data.
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 4 parameters. The description adds no meaning beyond the schema—it doesn't explain parameter interactions, defaults, or usage examples. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tags in a workspace' clearly states the verb ('Get') and resource ('tags'), but it's vague about scope and doesn't differentiate from sibling tools like 'asana_get_tasks_for_tag' or 'asana_get_attachments_for_object'. It lacks specificity about what 'Get' entails (e.g., list, retrieve, fetch).
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context (e.g., workspace management vs. task operations), or exclusions, despite having siblings like 'asana_list_workspaces' that might relate to workspace data retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add followers' implies a write/mutation operation, the description doesn't address permission requirements, whether this operation is idempotent, what happens if followers already exist, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this represents significant gaps in 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 a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward operation and front-loads the essential information. Every word earns its place in this concise formulation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what constitutes a successful operation, what the response looks like, error conditions, or how this tool relates to similar operations in the sibling set. The 100% schema coverage helps with parameters, but the overall context for using this tool effectively is incomplete.
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 already documents all three parameters thoroughly. The description doesn't add any meaningful semantic context beyond what's in the schema - it doesn't explain what 'followers' represent in Asana's context, how user GIDs should be obtained, or provide examples of valid opt_fields values. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add followers') and target resource ('to a project'), providing a specific verb+resource combination. However, it doesn't differentiate this tool from its sibling 'asana_add_followers_to_task' which performs a similar action on a different resource type, missing an opportunity for clear sibling distinction.
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 guidance on when to use this tool versus alternatives. With siblings like 'asana_add_members_for_project' and 'asana_add_followers_to_task' available, there's no indication of when followers vs members should be added, or when to use this project-focused tool versus the task-focused follower tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add followers' implies a mutation operation, the description doesn't disclose important behavioral aspects: whether this requires specific permissions, whether followers are added cumulatively or replace existing ones, what happens if invalid user IDs are provided, or what the expected response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single four-word phrase that communicates the core purpose without any wasted words. It's front-loaded with the essential information and has zero unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like permission requirements, error conditions, or what constitutes a successful operation. Given the complexity of adding followers (which involves user validation and potentially permission checks), the description should provide more context about how the operation works.
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, with both parameters clearly documented in the schema itself. The description doesn't add any meaningful parameter semantics beyond what's already in the schema descriptions. The baseline score of 3 is appropriate when the schema does the heavy lifting of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add followers') and target resource ('to a task'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'asana_add_members_for_project' or 'asana_add_tags_to_task' which also add entities to Asana objects, leaving room for confusion about when to use this specific tool.
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 guidance on when to use this tool versus alternatives. With many sibling tools that add various entities to Asana objects (followers, members, tags, dependencies, etc.), there's no indication of when this specific 'add followers to task' operation is appropriate versus other similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Add members' implies a mutation operation, but the description doesn't specify required permissions, whether this operation is idempotent, what happens if members already exist, rate limits, or what the response contains. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a straightforward operation and gets directly to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is inadequate. It doesn't address behavioral aspects like permissions, idempotency, or error conditions. The presence of a similar sibling tool ('asana_add_followers_for_project') creates ambiguity that the description doesn't resolve.
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 documented in the schema. The description doesn't add any meaningful semantic context beyond what's already in the schema descriptions. It doesn't explain member vs follower distinctions, GID format expectations, or practical examples of opt_fields usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add members') and target resource ('to a project'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from its sibling 'asana_add_followers_for_project', which appears to serve a similar but distinct purpose in the Asana context.
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 guidance on when to use this tool versus alternatives like 'asana_add_followers_for_project' or other member-related operations. There's no mention of prerequisites, constraints, or typical use cases for adding members versus followers in Asana projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Set dependencies' implies a mutation operation, but the description doesn't specify whether this overwrites existing dependencies or appends to them, what permissions are required, whether it's idempotent, or what happens on failure. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that directly states the tool's purpose with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, how errors are handled, or important behavioral details like whether dependencies are replaced or appended. Given the complexity of modifying task relationships, more 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?
Schema description coverage is 100%, with both parameters ('task_id' and 'dependencies') clearly documented in the schema. The description adds no additional parameter information beyond what's already in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set dependencies for a task' clearly states the verb ('Set') and resource ('dependencies for a task'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'asana_add_task_dependents', which appears to be a related but distinct operation (dependencies vs. dependents).
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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., task must exist), when not to use it, or how it relates to similar tools like 'asana_add_task_dependents' or 'asana_update_task' which might also affect task relationships.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Set dependents' which implies a write/mutation operation, but doesn't disclose behavioral traits like whether this overwrites existing dependents, requires specific permissions, has rate limits, or what happens on success/failure. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with a clarifying parenthetical. It's front-loaded with the core action and resource, though it could be slightly more structured by separating the clarification into a second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error conditions, or side effects. Given the complexity of modifying task relationships and the lack of structured behavioral data, more context is needed for an agent to use this effectively.
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 both parameters (task_id and dependents). The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set dependents') and target resource ('for a task'), with parenthetical clarification about what dependents are. It distinguishes from the sibling 'asana_add_task_dependencies' by focusing on dependents rather than dependencies, though it doesn't explicitly contrast them.
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?
No guidance on when to use this tool versus alternatives like 'asana_add_task_dependencies' or 'asana_update_task'. The description implies usage for setting task dependents but provides no context about prerequisites, constraints, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Add' implies a mutation operation, it doesn't specify whether this requires specific permissions, what happens if the task is already in the section, whether the operation is idempotent, or what the response looks like. This leaves significant gaps for an agent to understand the tool's 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 a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward tool and is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or behavioral nuances. Given the complexity of modifying project structures in Asana, more context about the operation's effects and limitations would be necessary for an agent to use it effectively.
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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any additional meaning about the parameters beyond what's in the schema, such as format examples or constraints. This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target resources ('task to a specific section in a project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'asana_reorder_sections' or 'asana_get_tasks_for_section', which would require a more specific distinction.
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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., existing task and section), when not to use it, or how it differs from related tools like 'asana_update_task' or 'asana_create_section_for_project'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the basic action. It doesn't mention authentication requirements, rate limits, error conditions, what happens on success (e.g., returns project ID), or side effects like notifications to members. For a creation tool with 16 parameters, this is insufficient.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 16 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (critical for a creation operation), doesn't mention behavioral aspects like permissions or side effects, and provides no usage context. The schema handles parameter documentation, but the description fails to add necessary operational 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 schema description coverage is 100%, so all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's in the schema, not explaining relationships between parameters (e.g., 'team_id' requirement for organization workspaces is only in schema). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('new project in a workspace'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'asana_create_task' or 'asana_create_project_status' beyond the obvious resource difference, missing explicit differentiation.
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 guidance on when to use this tool versus alternatives like 'asana_update_project' or 'asana_search_projects'. There's no mention of prerequisites, dependencies, or typical use cases, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't specify required permissions, whether the status is publicly visible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding the tool's 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 a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with a clear primary function and doesn't bury important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters and no annotations or output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns the new status object), error conditions, authentication requirements, or how this fits into Asana's project workflow. The context signals indicate this is a non-trivial tool that needs more comprehensive documentation.
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 description coverage is 100%, so all parameters are documented in the schema itself. The description doesn't add any additional parameter context beyond what's already in the schema (like explaining the relationship between 'text' and 'html_text', or when to use 'opt_fields'). This meets the baseline expectation when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new status update for a project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'asana_create_task_story' or 'asana_create_project', which also create content in Asana projects.
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 guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing project), when not to use it, or how it differs from other creation tools in the sibling list like 'asana_create_project' or 'asana_create_task_story'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a section, implying a write/mutation operation, but doesn't cover permissions, side effects, error handling, or what the response looks like. This leaves significant gaps for an agent to understand how to use it safely and effectively.
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, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a write operation with no annotations and no output schema), the description is incomplete. It doesn't address behavioral aspects like permissions, error cases, or response format, which are critical for an agent to use this tool correctly in 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 schema description coverage is 100%, so the schema already documents all three parameters (project_id, name, opt_fields). The description doesn't add any meaning beyond this, such as explaining what 'opt_fields' might include or providing examples. The baseline score of 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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') and the target resource ('in a project'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'asana_reorder_sections' or 'asana_get_project_sections', which also deal with sections but perform different operations.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to similar tools like 'asana_reorder_sections' or 'asana_get_project_sections'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'Create' implying a write/mutation operation but doesn't mention permissions, side effects, error conditions, or response format. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.
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, focused sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after creation, error handling, or how this differs from similar tools. Given the complexity of task management and sibling tools, more context is needed for effective 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 schema already documents all 6 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high schema coverage but not enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 subtask') and target resource ('for an existing task'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'asana_create_task' or explain the parent-child relationship beyond what's implied by 'subtask.'
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 guidance on when to use this tool versus alternatives like 'asana_create_task' or 'asana_set_parent_for_task.' It mentions 'for an existing task' but doesn't clarify prerequisites or contextual constraints, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new task' implies a write/mutation operation, but the description doesn't mention authentication requirements, permission levels needed, rate limits, whether the operation is idempotent, or what happens on success/failure. For a mutation tool with zero annotation coverage, this represents a significant gap in 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 a single, efficient sentence that states exactly what the tool does without any unnecessary words. It's appropriately sized and front-loaded with the essential information, making it easy for an agent to quickly understand the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 11 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like authentication needs, error conditions, or what the tool returns. While the schema covers parameters well, the description fails to provide the broader context needed for an agent to use this tool effectively in practice.
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?
With 100% schema description coverage, the schema already documents all 11 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('new task in a project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'asana_create_subtask' or 'asana_create_task_story', which would require more specific context about when to use each creation tool.
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 guidance on when to use this tool versus alternatives. With multiple sibling creation tools (create_project, create_subtask, create_task_story), there's no indication of when this specific task creation tool is appropriate versus those other options, nor any prerequisites or constraints mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It mentions creation but doesn't disclose if this requires specific permissions, whether it's idempotent, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero waste—it directly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a mutation tool with 3 parameters, the description is incomplete. It doesn't cover behavioral aspects like permissions or side effects, nor does it explain return values. For this complexity, more context is needed to be fully 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 description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'text' is for the story/comment content, which the schema already states. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and target ('a comment or story on a task'), which is specific and distinguishes it from siblings like 'asana_create_task' (creates tasks) or 'asana_get_task_stories' (reads stories). However, it doesn't explicitly differentiate between 'comment' and 'story' or clarify if they're synonymous in Asana's context.
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?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites (e.g., needing an existing task), compare to 'asana_update_task' for task modifications, or reference sibling 'asana_get_task_stories' for reading stories. The description only states what it does, not when to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive mutation, but the description doesn't mention permissions required, whether deletion is permanent/reversible, rate limits, or what happens after deletion. This leaves significant gaps for a mutation tool.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple deletion tool and front-loads the essential information immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after deletion, whether there are side effects, what permissions are needed, or what the return value might be. The description should provide more context given the tool's complexity and lack of structured metadata.
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 the single parameter 'project_status_gid' well-documented in the schema. The description doesn't add any additional parameter semantics beyond what the schema provides, which is acceptable given the high schema coverage, resulting in the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and target resource ('a project status update'), providing specific verb+resource information. However, it doesn't differentiate from sibling tools like 'asana_create_project_status' or 'asana_get_project_status', which would require explicit comparison for a score of 5.
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 guidance on when to use this tool versus alternatives. There are no prerequisites mentioned, no context about when deletion is appropriate, and no reference to related tools like 'asana_create_project_status' or 'asana_get_project_status' for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('download locally') but doesn't mention critical traits like file format handling, error conditions (e.g., invalid GID), network usage, or whether it overwrites existing files. For a tool that interacts with external resources and local storage, this is a significant gap in transparency.
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, efficient sentence with zero waste—it directly states the tool's action without unnecessary words. It's appropriately sized for a simple download operation and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple download with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like error handling or file management, and while the schema covers parameters well, the overall context for safe and effective use is lacking.
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 clear parameter descriptions in the input schema. The description adds no additional meaning beyond implying local file saving, which is already covered by the schema's 'output_dir' description. This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('download') and resource ('attachment'), making the purpose immediately understandable. It distinguishes from sibling tools like 'asana_upload_attachment_for_object' by focusing on retrieval rather than creation. However, it doesn't specify the source (Asana) beyond the tool name prefix, which keeps it from being fully specific.
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 guidance on when to use this tool versus alternatives like 'asana_get_attachments_for_object' (which lists attachments) or other download methods. It lacks context about prerequisites, such as needing an attachment GID from another operation, or exclusions for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation, implying read-only behavior, but doesn't cover pagination details (beyond what the schema shows), rate limits, authentication needs, or what the output looks like. This is a significant gap for a tool with 4 parameters and 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?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, no annotations), the description is incomplete. It lacks behavioral context, usage guidelines, and output details, making it inadequate for an agent to fully understand how to invoke and interpret results 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 schema already documents all parameters thoroughly. The description adds no additional meaning beyond implying the object can be a task or project, which is minimal value over the schema's 'object GID' description. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('attachments for an object'), specifying it works for tasks, projects, etc. However, it doesn't explicitly differentiate from the sibling 'asana_upload_attachment_for_object', which handles uploads rather than listing.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the maximum task limit (25). It lacks critical behavioral details: whether this is a read-only operation, authentication requirements, rate limits, error responses for invalid GIDs, or pagination. The description is minimal and misses key operational 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 a single, efficient sentence that front-loads the core purpose and includes the key constraint (maximum 25 tasks). There's no wasted verbiage or redundancy, making it appropriately concise for this tool type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, error conditions, or authentication needs. For a tool with 2 parameters and no structured safety hints, this leaves significant gaps for an AI 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%, so the schema fully documents both parameters (task_ids with max 25 items and opt_fields). The description adds no additional parameter semantics beyond what's in the schema, such as examples or formatting nuances, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get detailed information') and resource ('multiple tasks by their GIDs'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'asana_get_task' (singular) or 'asana_search_tasks', which would require a 5.
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 guidance on when to use this tool versus alternatives like 'asana_get_task' (for single tasks) or 'asana_search_tasks' (for filtered searches). It mentions the maximum 25 tasks but offers no context about prerequisites, error handling, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get all status updates' but doesn't describe what 'status updates' entail, whether this is a read-only operation, if it requires authentication, any rate limits, pagination behavior (implied by limit/offset parameters but not explained), or the format of returned data. This leaves significant gaps for a tool with 4 parameters and 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?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for what it conveys, though it could benefit from additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain what 'status updates' are, how results are structured, pagination behavior, or authentication needs. For a data retrieval tool with multiple parameters, this leaves too much undefined for effective 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?
The description doesn't mention any parameters beyond implying a 'project' context. However, the input schema has 100% description coverage, with clear documentation for all 4 parameters (project_gid, limit, offset, opt_fields). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description adds no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all status updates for a project' clearly states the action (get) and resource (status updates for a project). It's specific enough to understand the tool's function, though it doesn't explicitly differentiate from sibling tools like 'asana_get_project_status' (singular) or 'asana_get_project' which might also provide status information.
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 guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'asana_get_project_status' (singular) or 'asana_get_project' that might overlap in functionality, nor does it specify prerequisites or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' data, implying a read-only operation, but doesn't mention pagination behavior (handled by 'limit', 'offset', and 'auto_paginate' parameters), rate limits, authentication needs, or error conditions. This leaves significant gaps for an agent to understand how the tool behaves in practice.
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, clear sentence with no wasted words. It's front-loaded with the core purpose ('Get the list of subtasks'), making it easy to parse. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like pagination, error handling, or return format, which are critical for an agent to use the tool effectively. The high parameter count and lack of structured metadata mean the description should do more to compensate.
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, so parameters like 'task_id', 'opt_fields', 'limit', 'offset', and 'auto_paginate' are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining the format of 'opt_fields' or how pagination works. This meets the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('list of subtasks for a specific task'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'asana_get_task' or 'asana_get_tasks_for_project', which also retrieve task-related data but with different scopes.
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 guidance on when to use this tool versus alternatives. For example, it doesn't mention when to prefer this over 'asana_get_task' (which might include subtasks) or 'asana_create_subtask' for adding subtasks. There's no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves tasks but omits critical details: whether it's paginated (implied by parameters but not explicitly stated), rate limits, authentication requirements, error handling, or the format of returned data. This leaves significant gaps for an agent to understand operational 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. It avoids redundancy and wastes no space, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It lacks information on behavioral traits (e.g., pagination, auth), output format, error conditions, and usage context relative to siblings. The high parameter count and absence of structured metadata require more descriptive support than provided.
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 description coverage is 100%, providing detailed documentation for all 7 parameters. The description adds no additional parameter semantics beyond implying retrieval from a section, which is already covered by the schema's 'section_id' description. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 tasks from a specific section in a project'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'asana_get_tasks_for_project' or 'asana_get_tasks_for_tag', which have similar retrieval patterns but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'asana_get_tasks_for_project' (for project-level tasks) or 'asana_search_tasks' (for broader searches), nor does it specify prerequisites such as needing a valid section ID or appropriate permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Get[s] tasks' but doesn't describe key behaviors: whether this is a read-only operation, if it requires authentication, how it handles pagination (implied by 'limit' and 'offset' parameters but not explained), rate limits, or error conditions. The description adds minimal value beyond the basic 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 a single, efficient sentence with zero waste: 'Get tasks for a specific tag'. It is front-loaded and appropriately sized for a simple retrieval tool, avoiding unnecessary elaboration while clearly stating the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 (5 parameters, no output schema, and no annotations), the description is incomplete. It lacks information on behavioral traits (e.g., pagination, authentication), output format, error handling, or usage context. While the schema covers parameters well, the description doesn't compensate for missing annotations or output details, making it inadequate for full agent understanding.
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 parameters well-documented in the input schema (e.g., 'tag_gid' for filtering, 'limit' for pagination). The description adds no additional meaning beyond implying tag-based filtering, which is already clear from the parameter names and schema. This meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tasks for a specific tag' clearly states the verb ('Get') and resource ('tasks'), specifying the filtering criterion ('for a specific tag'). It distinguishes this tool from siblings like 'asana_get_tasks_for_project' or 'asana_get_tasks_for_section' by indicating tag-based filtering, though it doesn't explicitly contrast with 'asana_search_tasks' which might also filter by tag.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid tag GID), exclusions, or comparisons to sibling tools like 'asana_get_tasks_for_project' or 'asana_search_tasks', leaving the agent to infer usage context solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose whether this is a read-only operation, pagination behavior, rate limits, authentication needs, or error handling, which are critical for a tool accessing user data.
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, clear sentence with zero wasted words. It's front-loaded with the core purpose, making it easy for an agent to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It lacks details on return format, error conditions, or behavioral traits needed for safe invocation, especially given the complexity of accessing user-specific team data in Asana.
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 in the schema. The description adds no additional meaning beyond implying user context, meeting the baseline of 3 where the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('teams'), specifying the scope ('to which the user has access'). It distinguishes from siblings like 'asana_get_teams_for_workspace' by focusing on user-specific access, but doesn't explicitly contrast with other team-related tools, keeping it at 4 rather than 5.
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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, exclusions, or compare with sibling tools like 'asana_get_teams_for_workspace', leaving the agent to infer usage context independently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It lacks details on permissions required, rate limits, pagination, error handling, or what the output looks like (e.g., list format, fields included). This is inadequate for a tool with potential complexity in API interactions.
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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a read operation with potential behavioral nuances (e.g., authentication, data scope), the description is incomplete. It doesn't address return values, error cases, or usage constraints, leaving significant gaps for an AI agent to operate effectively.
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 documented in the schema. The description adds no additional meaning beyond implying workspace filtering, which is already covered. Baseline 3 is appropriate as the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('teams in a workspace'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'asana_get_teams_for_user' or 'asana_list_workspaces', which also retrieve workspace-related data, leaving some ambiguity about when to choose this specific tool.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workspace access), exclusions, or compare to siblings like 'asana_get_teams_for_user' or 'asana_list_workspaces', leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't disclose permissions required, rate limits, whether the operation is idempotent, what happens on error, or the response format. For a mutation tool with zero annotation coverage, this is inadequate, scoring a 2 for limited transparency beyond the core 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 a single, efficient sentence that front-loads the key action ('reorder a section within a project') and adds necessary detail ('by specifying its position relative to another section'). There's zero waste or redundancy, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, permissions, or return values, leaving gaps for an AI agent to invoke it correctly. For a tool with this context, it should do more, scoring a 2 for insufficient completeness.
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 4 parameters with clear descriptions (e.g., 'Use null for first position'). The description adds no additional parameter semantics beyond what's in the schema, such as explaining interactions between 'before_section_id' and 'after_section_id'. Baseline is 3 when schema does the heavy lifting, and the description doesn't compensate further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('reorder') and resource ('a section within a project'), specifying it involves positioning relative to another section. It distinguishes from siblings like 'asana_create_section_for_project' or 'asana_get_project_sections' by focusing on reordering rather than creation or retrieval. However, it doesn't explicitly differentiate from all siblings (e.g., 'asana_set_parent_for_task' also involves ordering), so it's not a perfect 5.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing existing sections), exclusions (e.g., not for reordering tasks), or compare to siblings like 'asana_update_task' for task ordering. Usage is implied from the action but lacks explicit context, scoring a 2 for minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose whether this is a read-only operation, what permissions are required, whether it's paginated (though schema hints at offset), rate limits, or what the return format looks like. The description adds minimal behavioral context beyond the name.
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, efficient sentence with zero wasted words. It's front-loaded with the core purpose and uses precise terminology. Every word earns its place in conveying the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what results look like, how pagination works (despite offset parameter), authentication requirements, or error conditions. The description leaves too many behavioral questions unanswered given 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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds the 'name pattern matching' concept which is already covered in the schema's 'name_pattern' description. No additional parameter semantics are provided beyond what's in the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('projects in Asana') with the specific mechanism ('using name pattern matching'). It distinguishes from siblings like 'asana_get_project' (single project) and 'asana_get_tasks_for_project' (different resource), but doesn't explicitly contrast with 'asana_search_tasks' (similar operation on different resource).
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 guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'asana_get_project' for single projects, 'asana_get_tasks_for_project' for project contents, or 'asana_search_tasks' for task-level searches. No context about prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'advanced filtering options' but doesn't describe key behaviors like pagination, rate limits, authentication requirements, error handling, or what the output looks like. For a search tool with 55 parameters and no annotations, this leaves significant gaps in understanding how the tool operates.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance while leaving detailed parameter info to the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (55 parameters, no annotations, no output schema), the description is inadequate. It doesn't address behavioral aspects like result format, pagination, or error conditions, nor does it provide usage context relative to sibling tools. For a search tool with extensive filtering options, more guidance on how to effectively use the parameters would be beneficial.
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 detailed descriptions for all 55 parameters in the input schema. The description adds minimal value beyond this, only implying filtering capabilities without explaining parameter interactions or usage patterns. With high schema coverage, the baseline is 3, as the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('tasks in a workspace'), specifying the action and target. It also mentions 'advanced filtering options' which adds context about functionality. However, it doesn't explicitly differentiate from sibling tools like 'asana_get_tasks_for_project' or 'asana_search_projects' beyond the general search nature.
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 guidance on when to use this tool versus alternatives. With many sibling tools for retrieving tasks (e.g., 'asana_get_tasks_for_project', 'asana_get_task', 'asana_search_projects'), there's no indication of when this search tool is preferred over those, nor any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions setting a parent and positioning subtasks, but fails to address critical behavioral aspects such as required permissions, whether the operation is reversible, potential side effects on task dependencies, or error conditions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action. It avoids unnecessary words while conveying the primary functionality, though it could benefit from additional context in subsequent sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, 33% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks essential context about behavioral traits, parameter details, error handling, and expected outcomes, leaving significant gaps for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only the 'parent' parameter documented in the schema. The description adds no information about parameters beyond what's implied by the action, failing to compensate for the low coverage. It doesn't explain the 'data' object structure, 'opts' usage, or clarify parameter interactions like 'insert_after' vs 'insert_before'.
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 ('Set the parent of a task') and includes additional functionality ('position the subtask within the other subtasks of that parent'), which distinguishes it from sibling tools like 'asana_update_task' or 'asana_create_subtask' that handle different task modifications. It uses precise verbs and specifies the resource being modified.
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 guidance on when to use this tool versus alternatives like 'asana_update_task' for general task updates or 'asana_create_subtask' for creating new subtasks. It lacks any mention of prerequisites, exclusions, or contextual cues for selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify permission requirements, whether changes are reversible, rate limits, or what happens to unspecified fields (partial vs. full updates). For a 15-parameter mutation tool, this leaves significant behavioral gaps.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and follows the principle of front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 15 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address behavioral aspects like error conditions, response format, or side effects. The agent must rely entirely on the input schema and trial-and-error, which is inadequate for a complex update 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 schema already documents all 15 parameters thoroughly with descriptions and formats. The description adds no additional parameter semantics beyond implying 'details' covers the schema's fields. This meets the baseline of 3 when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('details of an existing project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'asana_update_task' or other update operations, missing an opportunity to specify it's for project metadata rather than task updates.
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 guidance on when to use this tool versus alternatives like 'asana_create_project' for new projects or 'asana_get_project' for reading. It doesn't mention prerequisites (e.g., needing an existing project ID) or contextual constraints, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Update' implies mutation, but the description doesn't mention required permissions, whether changes are reversible, error handling, or what happens to unspecified fields. It lacks critical context for a mutation tool with 8 parameters.
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, efficient sentence with zero wasted words. It's appropriately sized and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address behavioral aspects like permissions, side effects, or response format. The combination of missing annotations and minimal description creates significant gaps for agent understanding.
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%, providing complete parameter documentation. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing task's details'), making the purpose unambiguous. It distinguishes from creation tools like 'asana_create_task' by specifying 'existing', but doesn't explicitly differentiate from other update tools like 'asana_update_project'.
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?
No guidance is provided about when to use this tool versus alternatives. While 'existing task' implies it's for modification rather than creation, there's no mention of prerequisites, constraints, or comparison to sibling tools like 'asana_set_parent_for_task' or 'asana_update_project'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions uploading a file but lacks details on permissions required, rate limits, error handling, or what happens on success (e.g., returns an attachment ID). This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to grasp quickly with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a file upload operation with no annotations and no output schema, the description is incomplete. It fails to address key aspects like authentication needs, response format, or error conditions, making it inadequate for a tool that modifies data without structured support.
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 already documents all parameters clearly. The description adds no additional meaning beyond what's in the schema, such as examples or constraints, resulting in a baseline score of 3 as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and target ('a local file as attachment to an object'), making the purpose understandable. It distinguishes from sibling tools like 'asana_download_attachment' and 'asana_get_attachments_for_object' by focusing on upload rather than retrieval, though it doesn't explicitly contrast with other attachment-related tools.
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?
No guidance is provided on when to use this tool versus alternatives. While the description implies it's for uploading attachments, it doesn't specify scenarios, prerequisites, or exclusions, such as file size limits or supported object types, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states it 'gets' information without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, requires authentication, has rate limits, or what format the detailed information includes. For a tool with zero annotation coverage, this is a significant 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?
The description is a single, efficient sentence that front-loads the core purpose with zero waste. Every word earns its place, making it easy to parse quickly.
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?
Given the tool's low complexity (2 parameters, no nested objects) and 100% schema coverage, the description is minimally adequate but lacks completeness. With no output schema and no annotations, it should explain return values or behavioral context more thoroughly, leaving gaps for an AI 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%, so the schema already documents both parameters ('project_id' and 'opt_fields'). The description doesn't add meaning beyond what the schema provides, such as explaining what 'detailed information' entails or how 'opt_fields' affects output. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('about a specific project'), making the purpose immediately understandable. It distinguishes from siblings like 'asana_search_projects' by focusing on a single project rather than multiple projects, though it doesn't explicitly name alternatives.
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 guidance on when to use this tool versus alternatives like 'asana_search_projects' or 'asana_get_project_hierarchy'. It mentions retrieving a 'specific project' but doesn't clarify prerequisites (e.g., needing a project ID) or exclusions (e.g., not for listing all projects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'gets' data, implying a read-only operation, but doesn't specify permissions, rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.
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, efficient sentence: 'Get the number of tasks in a project.' It's front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a simple tool. Every part of the sentence earns its place by clearly conveying the tool's function.
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?
Given the tool's low complexity (a read operation with 2 parameters) and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it doesn't fully compensate for missing behavioral details (e.g., what the return value looks like or any limitations). It meets basic needs but lacks depth for optimal 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?
The schema description coverage is 100%, with clear descriptions for both parameters ('project_id' and 'opt_fields'). The description doesn't add any meaning beyond the schema, such as explaining what 'opt_fields' might include or how counts are calculated. With high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: 'Get the number of tasks in a project.' It specifies the verb ('Get') and resource ('tasks in a project'), making the function unambiguous. However, it doesn't differentiate from sibling tools like 'asana_get_tasks_for_project' (which retrieves task details rather than counts), so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'asana_get_tasks_for_project' for detailed task lists or 'asana_get_project' for project metadata, leaving the agent without context for selection. There's no indication of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't mention authentication requirements, rate limits, error conditions, or what 'detailed information' includes. This leaves significant gaps for a tool with potential API constraints.
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, efficient sentence with no wasted words. It's appropriately sized for a simple retrieval tool and front-loads the core purpose immediately.
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 operation with 2 parameters and 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, it should ideally mention what 'detailed information' returns or typical response structure to help the agent understand the tool's behavior better.
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 both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., format of task_id, examples of opt_fields). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('detailed information about a specific task'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'asana_get_multiple_tasks_by_gid' or 'asana_get_task_stories', which would require a 5.
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 guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'asana_get_multiple_tasks_by_gid' for batch retrieval or 'asana_get_task_stories' for activity history, leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'pagination support' which is helpful, but doesn't describe authentication requirements, rate limits, error conditions, or what the response format looks like (especially important since there's no output schema). For a read operation with 7 parameters, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place - 'Get all tasks' (action), 'from a specific project' (scope), 'with pagination support' (key capability). However, it could be slightly more structured by separating core functionality from behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is insufficiently complete. It doesn't explain what the tool returns (task objects? just IDs?), doesn't mention authentication or permissions needed, and doesn't provide error handling context. For a data retrieval tool with multiple filtering and pagination options, users need more guidance about expected behavior and results.
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 already documents all 7 parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'pagination support' which relates to 'offset' and 'auto_paginate' parameters, but doesn't provide additional context about parameter interactions or usage patterns. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 tasks from a specific project', making the purpose unambiguous. It distinguishes from sibling tools like 'asana_get_task' (single task) and 'asana_search_tasks' (search across projects), though it doesn't explicitly name these alternatives. The mention of 'pagination support' adds useful scope information.
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 specifying 'from a specific project', suggesting this tool is for project-scoped task retrieval rather than workspace-wide searches. However, it doesn't provide explicit guidance on when to use this versus alternatives like 'asana_get_tasks_for_section', 'asana_get_tasks_for_tag', or 'asana_search_tasks', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but does not mention potential limitations like authentication requirements, rate limits, pagination, or error handling. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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, direct sentence with no wasted words, efficiently conveying the core purpose. It is appropriately sized and front-loaded, making it easy to grasp quickly without unnecessary elaboration.
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?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format, which are important for a read operation in a system with many sibling tools. It meets the minimum viable standard but has clear 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 input schema has 100% description coverage, clearly documenting both parameters ('task_id' and 'opt_fields'). The description does not add any additional meaning or context beyond what the schema provides, such as examples of optional fields or formatting details. Thus, it meets the baseline for high schema coverage without enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('comments and stories for a specific task'), making the purpose evident. However, it does not explicitly differentiate from sibling tools like 'asana_get_task' or 'asana_get_subtasks_for_task', which focus on different aspects of task data, so it falls short of a perfect score.
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 guidance on when to use this tool versus alternatives, such as 'asana_get_task' for basic task details or 'asana_create_task_story' for adding stories. It lacks explicit context, prerequisites, or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool adds tags but doesn't disclose behavioral traits like whether it's idempotent (e.g., adding duplicate tags), what happens on invalid tag IDs, if it requires specific permissions, or the response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence that front-loads the core action ('Add one or more tags to a task') and includes the purpose ('for categorization purposes'). There is no wasted text, and it's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., error handling, permissions), response format, and how it interacts with sibling tools. While the schema covers parameters well, the overall context for safe and effective use is insufficient.
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 clear descriptions for both parameters, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain tag ID formats or constraints on the array). This meets the minimum viable level given the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and target ('tags to a task') with a purpose ('for categorization purposes'). It distinguishes from siblings like 'asana_update_task' by focusing specifically on tag addition rather than general task updates. However, it doesn't explicitly differentiate from other tag-related tools like 'asana_get_tags_for_workspace' beyond the verb difference.
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 categorizing tasks with tags, and the input schema references 'asana_get_tags_for_workspace' to find available tags, providing some contextual guidance. However, it doesn't explicitly state when to use this tool versus alternatives like 'asana_update_task' (which might also handle tags) or mention prerequisites such as needing existing tags or task access.
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?
No annotations are provided, so the description carries the full burden. It discloses the filtering behavior with DEFAULT_WORKSPACE_ID, which is useful context. However, it doesn't mention rate limits, authentication needs, pagination, or return format, leaving gaps for a read operation with no annotation support.
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 zero waste, front-loading the core purpose and efficiently adding the conditional behavior. Every word earns its place, making it easy to parse.
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 tool with 1 parameter and no output schema, the description is adequate but not complete. It covers the purpose and a key behavioral nuance (DEFAULT_WORKSPACE_ID), but lacks details on return values, error handling, or authentication, which would be helpful given no 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 already documents the single parameter 'opt_fields'. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples of optional fields. Baseline 3 is appropriate when schema coverage is high.
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 ('List') and resource ('all available workspaces in Asana'), making the purpose specific. It distinguishes from siblings by focusing on workspaces rather than projects, tasks, or other entities, and includes the unique DEFAULT_WORKSPACE_ID 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?
The description provides clear context about when to use it (to list workspaces) and includes the DEFAULT_WORKSPACE_ID condition, which implicitly guides usage. However, it doesn't explicitly mention when not to use it or name alternatives among siblings, though the tool's unique focus on workspaces makes this less critical.
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 no annotations provided, the description carries full burden and does well by explaining pagination behavior (auto vs. manual, token usage), performance considerations for large projects, and response structure hints (e.g., 'next_offset' tokens). It doesn't cover error cases or rate limits, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (PAGINATION GUIDE, EXAMPLES), but slightly verbose. Every sentence earns its place by providing actionable guidance. Could be more front-loaded, but the information density is high and organized for usability.
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 complex tool with 13 parameters, no annotations, and no output schema, the description does well by covering usage patterns, pagination, and examples. It doesn't describe the return structure in detail, but given the hierarchical nature implied and lack of output schema, it provides sufficient context for effective use.
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 baseline is 3. The description adds value by explaining pagination strategies (linking auto_paginate, limit, offset), giving tips for parameter combinations (e.g., include_subtasks=false for performance), and providing concrete examples that illustrate parameter interactions beyond schema descriptions.
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 'complete hierarchical structure of an Asana project', specifying it includes 'sections, tasks, and subtasks'. It distinguishes from siblings like 'asana_get_project' (basic project info) or 'asana_get_tasks_for_project' (flat task list) by emphasizing hierarchical retrieval.
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 guidance on when to use auto_paginate vs. manual pagination, with specific scenarios ('Tips for large projects'), and distinguishes from siblings by focusing on hierarchical data rather than flat lists or other operations. It includes practical examples for different use cases.
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:

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

Score Badge

Copy to your README.md:

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

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/cristip73/mcp-server-asana'

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