mcp-server-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 like tasks, projects, statuses, or workspaces. However, some overlap exists: 'asana_get_task' and 'asana_get_multiple_tasks_by_gid' both retrieve task details, which could cause confusion, and dependency-related tools ('asana_add_task_dependencies' vs 'asana_add_task_dependents') are conceptually similar. Descriptions help clarify, but minor ambiguity remains.
Naming Consistency5/5
All tool names follow a consistent 'asana_verb_noun' pattern with snake_case throughout. The verb-noun structure is predictable (e.g., 'asana_create_task', 'asana_get_project', 'asana_update_task'), making it easy to understand each tool's action and target resource without confusion.
Tool Count3/5
With 22 tools, the count is borderline high for an Asana integration, potentially feeling heavy. While Asana's API is feature-rich, this set includes many specific operations (e.g., separate tools for adding dependencies and dependents) that might be consolidated. It's not excessive but leans toward the upper limit of typical scopes.
Completeness4/5
The tool set covers core CRUD operations for tasks, projects, and statuses, including search, listing, and updates. Minor gaps exist: there's no tool to delete tasks or projects, and workspace management is limited to listing. However, agents can work around these with available tools, and the surface supports key workflows like task creation, dependency management, and project tracking.
Average 2.9/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 6 community issues answered or closed 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a read operation ('get'), but doesn't disclose permissions needed, rate limits, error conditions, or what the return format looks like (e.g., JSON structure). This leaves significant gaps for an agent to understand how to handle the tool effectively.
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 no wasted words. It's front-loaded with the core action, though it could be more specific (e.g., 'Retrieve a single project status update by its GID'). Overall, it's appropriately concise 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 no annotations, no output schema, and a read operation with two parameters, the description is incomplete. It doesn't explain what a 'project status update' contains, how results are structured, or any behavioral traits like error handling. For a tool that retrieves data, more context on the return value 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%, with clear descriptions for both parameters (project_status_gid and opt_fields). The description adds no additional meaning beyond the schema, such as examples of valid GIDs or common opt_fields values. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a project status update' clearly states the action (get) and resource (project status update), but it's vague about what exactly a 'project status update' entails. It doesn't distinguish this tool from sibling 'asana_get_project_statuses' (plural), which might retrieve multiple statuses versus this single one.
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 like 'asana_get_project_statuses' or 'asana_get_project'. The description lacks context about prerequisites, such as needing a specific project status GID, or exclusions for 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. It mentions that the task is positioned 'within the other subtasks of that parent', hinting at ordering behavior, but lacks critical details: it doesn't specify if this is a mutating operation (implied by 'Set'), what permissions are required, potential side effects (e.g., impact on dependencies), error conditions, or response format. For a tool that modifies task relationships, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the main action ('Set the parent of a task') and adds positioning detail. It avoids redundancy and is appropriately sized for the tool's complexity, though it could be slightly more structured (e.g., separating purpose from constraints).
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 mutating tool with no annotations, low schema coverage (33%), and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, side effects, or error handling, and parameter semantics are largely undocumented. For a tool that changes task hierarchy, more context is needed to ensure safe and correct usage.
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 low (33%), with only 'parent' parameter documented in the schema. The description adds minimal value beyond the schema: it implies parameters for parent setting and positioning but doesn't explain the semantics of 'insert_after' or 'insert_before', their mutual exclusivity, or the 'opts' parameter. It fails to compensate for the poor schema coverage, leaving most parameters unclear.
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 the parent of a task') and the resource ('task'), making the purpose understandable. It also mentions positioning the subtask, which adds specificity. However, it doesn't explicitly differentiate this tool from sibling tools like 'asana_update_task' or 'asana_create_subtask', which might also involve task hierarchy modifications.
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., the task must exist), compare it to siblings like 'asana_update_task' for general updates or 'asana_create_subtask' for creating new subtasks, or specify scenarios where setting a parent is appropriate versus other 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Set dependencies for a task' implies a mutation operation, but it doesn't specify whether this overwrites existing dependencies, appends to them, or requires specific permissions. It also lacks details on error handling (e.g., invalid task IDs) or rate limits. 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 unnecessary words. It's appropriately sized for a simple tool 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?
Given the complexity (a mutation tool with 2 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like whether dependencies are overwritten or appended, error conditions, or return values. For a tool that modifies task relationships, more context is needed to ensure safe and correct usage by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for 'task_id' and 'dependencies'. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain the format of task IDs or constraints on the dependencies array). According to the rules, with high schema coverage (>80%), the baseline score is 3, which is appropriate here 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 verb ('Set') and resource ('dependencies for a task'), making the purpose immediately understandable. It distinguishes from siblings like 'asana_add_task_dependents' (which likely sets dependents rather than dependencies) and 'asana_update_task' (which might handle broader updates). However, it doesn't explicitly mention that this adds dependencies to an existing task versus creating new ones, which slightly limits specificity.
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., task must exist), exclusions (e.g., cannot set circular dependencies), or comparisons to siblings like 'asana_update_task' (which might also handle dependencies). Without such context, an agent must infer usage from the tool name and schema 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 action without behavioral details. It doesn't disclose permissions needed, whether this overwrites or appends dependents, error conditions, or rate limits, leaving 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 that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every part contributing 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 incomplete. It lacks details on behavioral traits, return values, error handling, and usage context, which are critical for an AI agent to invoke it 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 fully documents both parameters. The description adds no additional meaning beyond what the schema provides, such as format examples or edge cases, 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 ('Set') and resource ('dependents for a task'), specifying that it adds tasks that depend on the given task. It distinguishes from sibling 'asana_add_task_dependencies' by focusing on dependents rather than dependencies, but 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 dependents but lacks context about prerequisites, constraints, or typical 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description doesn't mention authentication requirements, rate limits, whether the operation is idempotent, what happens on failure, or what the response looks like. For a creation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 that gets straight to the point with zero wasted words. It's perfectly front-loaded with the essential information and doesn't include any unnecessary elaboration or repetition. This is an excellent example of conciseness in tool descriptions.
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 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address what the tool returns, error conditions, authentication needs, or how it fits within the broader Asana API context. The user would need to consult external documentation to understand the full operational context of this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify semantics like what 'GID' means or how 'opt_fields' should be used. The baseline score of 3 reflects adequate but minimal value added.
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 sibling tools like 'asana_create_task_story' or 'asana_create_subtask' that also create content in Asana, leaving room for confusion about when to choose this specific 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 sibling tools like 'asana_get_project_status' and 'asana_delete_project_status' available, there's no indication of whether this is for initial creation versus updates, or how it relates to other project management tools in the set. The user must infer usage from the 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 offers minimal behavioral insight. It states 'Create' which implies a write/mutation operation, but doesn't disclose permissions needed, rate limits, whether the operation is idempotent, what happens on failure, or what the response contains. For a creation 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, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for what it communicates. Every word earns its place without being overly terse.
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 7 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what a successful creation returns, error conditions, or important behavioral aspects like whether subtasks inherit properties from parent tasks. The high parameter count and mutation nature demand more contextual information 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?
Schema description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. However, it does imply the existence of a parent-child relationship through 'subtask for an existing task,' which contextualizes the 'parent_task_id' parameter. 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 action ('Create') and resource ('new subtask for an existing task'), making the purpose immediately understandable. It distinguishes this from general task creation tools like 'asana_create_task' by specifying it's for subtasks, though it doesn't explicitly contrast with sibling tools beyond this inherent 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. It doesn't mention prerequisites (like needing an existing parent task), compare it to 'asana_create_task' for regular tasks, or indicate when subtasks are appropriate versus dependencies or other task relationships available in 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. 'Create a new task' implies a write/mutation operation, but the description doesn't mention permissions required, whether this is idempotent, rate limits, error conditions, or what happens on success (e.g., returns a task ID). For a mutation tool with zero annotation coverage, this is inadequate.
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 basic create operation and front-loads the essential information 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 11 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address what the tool returns, error handling, authentication requirements, or how it differs from similar tools. The 100% schema coverage helps with parameters, but other critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema (e.g., it doesn't explain relationships between parameters like 'project_id' vs 'projects', or provide usage examples). 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 'Create a new task in a project' clearly states the action (create) and resource (task), with the project context providing specificity. However, it doesn't differentiate from sibling tools like 'asana_create_subtask' or 'asana_update_task', which would require explicit comparison to earn 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. There are multiple sibling tools for task creation and modification (e.g., asana_create_subtask, asana_update_task, asana_set_parent_for_task), but the description offers no context about prerequisites, when this is appropriate versus other tools, or any 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a comment/story, implying a write operation, but doesn't mention permissions needed, rate limits, whether the action is reversible, or what the response looks like. For a mutation tool with zero annotation coverage, this is 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 extremely concise—just one sentence that directly states the purpose and a key requirement. Every word earns its place with no redundancy or fluff, making it front-loaded and efficient 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 this is a mutation tool (creates comments/stories) with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits like permissions, side effects, or response format. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially compared to sibling tools that might handle similar operations.
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 four parameters thoroughly. The description adds minimal value by noting that either 'text' or 'html_text' is required, which is already implied in the schema descriptions. It doesn't provide additional semantic context beyond what's in the structured fields, 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 action ('Create a comment or story on a task') and specifies the resource ('task'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from potential alternatives like 'asana_create_task' or 'asana_get_task_stories' beyond the basic function, missing explicit 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 provides no guidance on when to use this tool versus alternatives. It mentions that either 'text' or 'html_text' is required, but this is a parameter requirement, not usage context. There's no mention of prerequisites, when this operation is appropriate, or how it differs from sibling tools like 'asana_create_task' or 'asana_update_task'.
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 action without behavioral details. It doesn't disclose if deletion is permanent, requires specific permissions, has side effects (e.g., affecting project data), or error handling, which is inadequate for a destructive operation.
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 zero waste, front-loading the core action and resource. It's appropriately sized for a simple tool, 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 the tool's destructive nature (implied by 'Delete'), lack of annotations, and no output schema, the description is incomplete. It should cover behavioral risks, permissions, or result expectations, but provides only minimal context, leaving gaps for safe 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%, with the parameter 'project_status_gid' well-documented in the schema. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high 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 action ('Delete') and target resource ('a project status update'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'asana_create_project_status' or 'asana_get_project_status' beyond the verb, missing explicit contrast.
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. It doesn't mention prerequisites (e.g., needing a valid project status GID), exclusions, or related tools like 'asana_create_project_status' for creation, 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 the full burden of behavioral disclosure. It states 'Get sections in a project', implying a read-only operation, but does not specify whether this requires authentication, returns paginated results, or handles errors. For a tool with zero annotation coverage, this is insufficient to inform safe and effective usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action and resource, making it easy to parse quickly. This minimal structure is appropriate for a straightforward tool, though it sacrifices detail for brevity.
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 lack of annotations and output schema, the description is incomplete for effective tool use. It does not explain what the tool returns (e.g., list of sections, error formats) or behavioral aspects like rate limits. For a tool with no structured metadata, the description should provide more context to compensate, which it fails to do.
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: '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 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 verb 'Get' and the resource 'sections in a project', making the purpose unambiguous. However, it does not differentiate from sibling tools like 'asana_get_project' or 'asana_get_project_statuses', which also retrieve project-related data, leaving room for potential 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. It does not mention prerequisites, such as needing a valid project ID, or compare it to sibling tools like 'asana_get_project' for broader project details. This lack of context could lead to misuse or redundant tool calls.
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 retrieving status updates but fails to describe key traits like pagination behavior (implied by 'limit' and 'offset' parameters), rate limits, authentication needs, or the format of returned data. This leaves significant gaps for a tool with multiple 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 no wasted words. It is front-loaded with the core purpose, making it easy to parse quickly, though its brevity contributes to gaps in other dimensions.
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 tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, usage context, and output format, which are essential for effective tool invocation by 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 input schema fully documents all parameters. The description adds no additional meaning beyond what the schema provides, such as clarifying the relationship between 'project_gid' and other parameters or usage examples. Baseline 3 is appropriate as the schema handles 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') and resource ('all status updates for a project'), making the tool's purpose understandable. However, it does not differentiate from sibling tools like 'asana_get_project_status' (singular vs. plural) or explain the relationship between them, which prevents 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_project_status' (singular) or other project-related tools. It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent with minimal 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 the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error conditions, or what the output format looks like (e.g., raw count vs structured data). This leaves significant gaps for an agent to understand how to interact with it 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 avoids unnecessary elaboration, making it efficient and easy to parse.
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 lack of annotations and output schema, the description is incomplete for a tool with two parameters. It doesn't explain the return value (e.g., whether it's a simple integer, a JSON object with counts, or includes optional fields), nor does it address potential behavioral nuances like pagination or error handling. This leaves the agent with insufficient context for reliable 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 input schema has 100% description coverage, fully documenting both parameters ('project_id' and 'opt_fields'). The description adds no additional semantic context about parameters beyond what's in the schema, such as explaining what 'opt_fields' might include or how task counts are calculated. 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 action ('Get') and resource ('number of tasks in a project'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'asana_get_project' or 'asana_get_task', which also retrieve project/task information but for different data.
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 scenarios where task counts are needed over detailed task lists (e.g., from 'asana_get_tasks_for_tag') or other project metrics, nor does it specify 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get tags' implies a read-only operation, but the description doesn't mention pagination behavior (despite limit/offset parameters), rate limits, authentication requirements, or what the return format looks like (e.g., list of tag objects). For a tool with 4 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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 ('Get tags in a workspace'), making it immediately scannable. Every word earns its place, and there's no redundancy or fluff.
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 (4 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't address behavioral aspects like pagination, return format, or error conditions. For a tool that likely returns a list of tag objects with optional fields, the agent lacks critical context to use it effectively beyond basic parameter passing.
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 fully documents all 4 parameters (workspace_gid, limit, offset, opt_fields). The description adds no additional meaning about parameters beyond what's in the schema—it doesn't explain why you'd use limit/offset for pagination or what opt_fields might include. With high schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the resource 'tags in a workspace', making the purpose immediately understandable. It distinguishes this tool from siblings like 'asana_get_tasks_for_tag' or 'asana_list_workspaces' by focusing specifically on tags. However, it doesn't specify the scope (e.g., all tags vs. filtered tags), which prevents 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. There's no mention of prerequisites (e.g., needing workspace access), when not to use it, or how it differs from other tag-related operations that might exist in the broader Asana API. The agent must infer usage from the tool name and schema 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. It states this is a read operation ('Get'), implying it's non-destructive, but doesn't cover aspects like authentication requirements, rate limits, error handling, or the format of returned data. This leaves significant gaps for an agent to understand how to use it 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, efficient sentence that directly states the tool's purpose without any redundant information. It's appropriately sized for a simple retrieval tool and front-loaded with the core action.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, the response format, or any behavioral traits like pagination or error cases. For a tool with no structured metadata, this leaves too much unspecified 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?
The input schema has 100% description coverage, clearly documenting both parameters. The description adds no additional semantic context beyond what the schema provides, such as examples of 'opt_fields' values or constraints on 'task_id'. 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 differentiate from sibling tools like 'asana_get_multiple_tasks_by_gid' or 'asana_get_task_stories', which also retrieve task information but with different scopes or related data.
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 this over 'asana_get_multiple_tasks_by_gid' for bulk retrieval or 'asana_get_task_stories' for historical data, nor does it specify prerequisites like needing a valid task ID.
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. While 'Get' implies a read-only operation, the description doesn't mention any behavioral traits such as pagination behavior (implied by 'limit' and 'offset' parameters but not explained), rate limits, authentication requirements, or what the response format looks like. For a tool with 5 parameters and no annotations, this leaves significant gaps in understanding how it behaves.
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, clear sentence that states the tool's purpose without any wasted words. It's front-loaded with the core functionality, making it easy to parse quickly. Every word earns its place, and there's no 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 (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't address key contextual elements like what the tool returns (e.g., a list of tasks, paginated results), error conditions, or how it differs from similar sibling tools. For a tool with multiple parameters and no structured output documentation, 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%, meaning all parameters are well-documented in the input schema itself. The description adds no additional meaning beyond the schema—it doesn't explain parameter interactions, default values, or usage examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract from the schema's 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 ('Get') and resource ('tasks for a specific tag'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'asana_get_task' or 'asana_search_tasks', which also retrieve tasks but through different mechanisms. The description is specific 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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'asana_get_task' (for single tasks by GID), 'asana_search_tasks' (for broader searches), and 'asana_get_multiple_tasks_by_gid' (for batch retrieval by GID), there's no indication that this tool is specifically for retrieving tasks associated with a particular tag. No context or exclusions are 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but does not specify aspects like authentication requirements, rate limits, error handling, or the format of returned stories/comments. For a tool with no annotations, 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, concise sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it efficient and easy to parse. Every part of the sentence contributes essential information, earning its place in the description.
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 lack of annotations and output schema, the description is incomplete for a tool that retrieves task stories and comments. It does not explain the return format, such as whether stories include metadata or how comments are structured, nor does it cover behavioral aspects like pagination or error cases. For a read operation with no structured output guidance, more context is needed to ensure proper usage.
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 clear documentation for both parameters ('task_id' and 'opt_fields'). The description does not add any additional meaning beyond what the schema provides, such as examples of optional fields or usage tips. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter semantics without extra description input.
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 ('comments and stories for a specific task'), making the purpose immediately understandable. However, it does not explicitly differentiate this tool from similar siblings like 'asana_get_task' or 'asana_get_multiple_tasks_by_gid', which might also retrieve task-related data, leaving some ambiguity in 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 does not mention prerequisites, such as needing a valid task ID, or compare it to other tools like 'asana_get_task' for general task info or 'asana_create_task_story' for adding stories. This lack of context could lead to misuse in scenarios where 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 full burden but offers minimal behavioral insight. It mentions 'search' and 'pattern matching' but doesn't disclose critical traits like whether results are paginated, rate limits, authentication requirements, or what the output format looks like (especially important without an output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes the key constraint (name pattern matching). Every element earns its place.
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 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks behavioral context (e.g., pagination, error handling), usage guidance relative to siblings, and any mention of output structure, leaving 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 all 4 parameters. The description adds no additional parameter semantics beyond implying 'name_pattern' uses regular expressions (which is already in the schema). 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 ('Search for projects') and resource ('in Asana') with the specific method 'using name pattern matching'. It distinguishes itself from siblings like 'asana_get_project' (singular retrieval) and 'asana_search_tasks' (different resource), but doesn't explicitly contrast with other project-related tools like 'asana_get_project_statuses'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 is provided. The description doesn't mention when to prefer this over 'asana_get_project' (for specific projects) or 'asana_list_workspaces' (for broader context), nor does it specify prerequisites like needing workspace access.
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 only mentions 'advanced filtering options' without addressing critical behaviors like whether this is a read-only operation, potential rate limits, authentication requirements, pagination handling, or error conditions. This leaves significant gaps for a search tool with 55 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 that directly states the tool's function. It's appropriately sized and front-loaded with the core purpose, with no wasted words or 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 complex search tool with 55 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the search returns, how results are structured, pagination behavior, or error handling. The agent would struggle to use this tool effectively despite the comprehensive parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, providing detailed documentation for all 55 parameters. The description adds minimal value beyond this, only hinting at 'advanced filtering options' without explaining parameter interactions or usage patterns. 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 ('Search') and resource ('tasks in a workspace'), making the purpose evident. However, it doesn't distinguish this tool from sibling tools like 'asana_get_multiple_tasks_by_gid' or 'asana_get_tasks_for_tag', which also retrieve tasks but through different mechanisms.
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 mentions 'advanced filtering options' but doesn't specify scenarios where this is preferable over simpler sibling tools like 'asana_get_task' or 'asana_get_multiple_tasks_by_gid', leaving the agent without contextual 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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states it 'updates' an existing task, implying a mutation operation, but doesn't cover critical aspects like authentication requirements, error handling (e.g., invalid task IDs), rate limits, or what happens to unspecified fields (partial vs. full updates). For a mutation tool with zero annotation coverage, this leaves significant 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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('update an existing task's details'), making it immediately clear. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation operation, nested objects) and lack of both annotations and an output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances like partial updates. For a tool that modifies tasks with multiple fields, more context is needed to guide 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?
The schema description coverage is 100%, with each parameter well-documented in the schema itself (e.g., 'due_on' specifies YYYY-MM-DD format, 'assignee' explains 'me' or user ID). The description adds no additional parameter semantics 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 clearly states the action ('update') and resource ('existing task's details'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'asana_create_task' by specifying it updates existing tasks rather than creating new ones. However, it doesn't explicitly differentiate from other update-related tools like 'asana_set_parent_for_task' which also modifies tasks.
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 task ID), compare with similar tools like 'asana_create_subtask' or 'asana_set_parent_for_task', or indicate when not to use it (e.g., for bulk updates). The agent must infer usage from the name and schema 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. It states it's a list operation but doesn't mention whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this is insufficient 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 with zero wasted words. It's appropriately sized for a simple list operation and front-loads the core functionality.
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 list tool with one optional parameter and no output schema, the description provides the basic purpose but lacks important contextual information. Without annotations or output schema, it should explain more about authentication requirements, return format, or behavioral constraints to be truly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention any parameters, but the input schema has 100% description coverage for its single optional parameter 'opt_fields'. The baseline score of 3 is appropriate since the schema adequately documents the parameter, and the description doesn't need to compensate for gaps.
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 ('List') and resource ('all available workspaces in Asana'), making the purpose immediately understandable. However, it doesn't distinguish this tool from potential sibling list operations (though none exist in the provided sibling list), which prevents 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. There's no mention of prerequisites, context for listing workspaces, or comparison with other workspace-related tools (though none are in the sibling list). This leaves the agent without usage context.
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 the 25-task limit, which is useful, but fails to describe other critical behaviors: whether this is a read-only operation, what authentication is required, rate limits, error handling for invalid GIDs, or the structure of returned data. For a batch retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 ('Get detailed information about multiple tasks') followed by the key constraint ('by their GIDs (maximum 25 tasks)'). Every word earns its place with zero redundancy or 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 of batch retrieval, absence of annotations, and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, how results are structured, error scenarios, or authentication requirements. While concise, it lacks sufficient context for an agent to confidently use this tool without additional assumptions or trial-and-error.
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 fully documents both parameters (task_ids with format options and max limit, opt_fields). The description adds minimal value beyond the schema by mentioning 'maximum 25 tasks' which aligns with the schema's maxItems constraint. No additional parameter semantics are provided, so the 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 ('Get detailed information') and resource ('multiple tasks by their GIDs'), making the purpose immediately understandable. It distinguishes from the single-task retrieval sibling 'asana_get_task' by specifying 'multiple tasks' and the batch limit. However, it doesn't explicitly contrast with other task-related siblings like 'asana_get_tasks_for_tag' or 'asana_search_tasks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'maximum 25 tasks' and the GID-based retrieval approach, suggesting this is for batch fetching of known tasks. However, it provides no explicit guidance on when to use this versus alternatives like 'asana_get_task' (single task) or 'asana_search_tasks' (filter-based search). The agent must infer appropriate usage from the description's constraints.
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 'Get detailed information' but doesn't disclose behavioral traits such as whether this is a read-only operation, authentication requirements, rate limits, error handling, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 retrieval tool, 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 and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, the return format, or any behavioral context. For a tool with 2 parameters and no structured support, the description should provide more guidance to compensate for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (project_id and opt_fields) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as examples or context for opt_fields usage. 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 'Get' and resource 'detailed information about a specific project', making the purpose unambiguous. It distinguishes from siblings like asana_search_projects (which searches multiple projects) and asana_get_project_sections (which gets sections within a project). However, it doesn't explicitly mention what constitutes 'detailed information' or contrast with asana_get_project_task_counts, which is slightly less specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details for a specific project (vs. searching multiple projects with asana_search_projects), but it doesn't explicitly state when to use this tool versus alternatives like asana_get_project_statuses or asana_get_project_task_counts. No guidance on prerequisites or exclusions is provided, leaving usage context somewhat inferred.
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/roychri/mcp-server-asana/badges/card.svg)](https://glama.ai/mcp/servers/roychri/mcp-server-asana)

Score Badge

Copy to your README.md:

[![mcp-server-asana MCP server](https://glama.ai/mcp/servers/roychri/mcp-server-asana/badges/score.svg)](https://glama.ai/mcp/servers/roychri/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/roychri/mcp-server-asana'

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