Skip to main content
Glama
deenesjakoruzh
roychri

mcp-server-asana

by roychri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

MCP Server for Asana

npm version

This Model Context Protocol server implementation of Asana allows you to talk to Asana API from MCP Client such as Anthropic's Claude Desktop Application, and many more.

More details on MCP here:

Environment Variables

  • ASANA_ACCESS_TOKEN: (Required) Your Asana access token

  • READ_ONLY_MODE: (Optional) Set to 'true' to disable all write operations. In this mode:

    • Tools that modify Asana data (create, update, delete) will be disabled

    • The create-task prompt will be disabled

    • Only read operations will be available This is useful for testing or when you want to ensure no changes can be made to your Asana workspace.

Related MCP server: MCP Server for Asana

Usage

In the AI tool of your choice (ex: Claude Desktop) ask something about asana tasks, projects, workspaces, and/or comments. Mentioning the word "asana" will increase the chance of having the LLM pick the right tool.

Example:

How many unfinished asana tasks do we have in our Sprint 30 project?

Another example:

Claude Desktop Example

Tools

  1. asana_list_workspaces

    • List all available workspaces in Asana

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of workspaces

  2. asana_search_projects

    • Search for projects in Asana using name pattern matching

    • Required input:

      • workspace (string): The workspace to search in

      • name_pattern (string): Regular expression pattern to match project names

    • Optional input:

      • archived (boolean): Only return archived projects (default: false)

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of matching projects

  3. asana_search_tasks

    • Search tasks in a workspace with advanced filtering options

    • Required input:

      • workspace (string): The workspace to search in

    • Optional input:

      • text (string): Text to search for in task names and descriptions

      • resource_subtype (string): Filter by task subtype (e.g. milestone)

      • completed (boolean): Filter for completed tasks

      • is_subtask (boolean): Filter for subtasks

      • has_attachment (boolean): Filter for tasks with attachments

      • is_blocked (boolean): Filter for tasks with incomplete dependencies

      • is_blocking (boolean): Filter for incomplete tasks with dependents

      • assignee, projects, sections, tags, teams, and many other advanced filters

      • sort_by (string): Sort by due_date, created_at, completed_at, likes, modified_at (default: modified_at)

      • sort_ascending (boolean): Sort in ascending order (default: false)

      • opt_fields (string): Comma-separated list of optional fields to include

      • custom_fields (object): Object containing custom field filters

    • Returns: List of matching tasks

  4. asana_get_task

    • Get detailed information about a specific task

    • Required input:

      • task_id (string): The task ID to retrieve

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Detailed task information

  5. asana_create_task

    • Create a new task in a project

    • Required input:

      • project_id (string): The project to create the task in

      • name (string): Name of the task

    • Optional input:

      • notes (string): Description of the task

      • html_notes (string): HTML-like formatted description of the task

      • due_on (string): Due date in YYYY-MM-DD format

      • assignee (string): Assignee (can be 'me' or a user ID)

      • followers (array of strings): Array of user IDs to add as followers

      • parent (string): The parent task ID to set this task under

      • projects (array of strings): Array of project IDs to add this task to

      • resource_subtype (string): The type of the task (default_task or milestone)

      • custom_fields (object): Object mapping custom field GID strings to their values

    • Returns: Created task information

  6. asana_get_task_stories

    • Get comments and stories for a specific task

    • Required input:

      • task_id (string): The task ID to get stories for

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of task stories/comments

  7. asana_update_task

    • Update an existing task's details

    • Required input:

      • task_id (string): The task ID to update

    • Optional input:

      • name (string): New name for the task

      • notes (string): New description for the task

      • html_notes (string): HTML-like formatted description of the task (subset of HTML tags supported)

      • due_on (string): New due date in YYYY-MM-DD format

      • assignee (string): New assignee (can be 'me' or a user ID)

      • followers (array): Array of user IDs to add as followers

      • parent (string): The parent task ID to move this task under

      • completed (boolean): Mark task as completed or not

      • resource_subtype (string): The type of the task (default_task or milestone)

      • custom_fields (object): Object mapping custom field GID strings to their values

    • Returns: Updated task information

  8. asana_get_project

    • Get detailed information about a specific project

    • Required input:

      • project_id (string): The project ID to retrieve

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Detailed project information

  9. asana_get_project_task_counts

    • Get the number of tasks in a project

    • Required input:

      • project_id (string): The project ID to get task counts for

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Task count information

  10. asana_get_project_sections

    • Get sections in a project

    • Required input:

      • project_id (string): The project ID to get sections for

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of project sections

  11. asana_create_task_story

    • Create a comment or story on a task

    • Required input:

      • task_id (string): The task ID to add the story to

      • text (string): The text content of the story/comment

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Created story information

  12. asana_add_task_dependencies

    • Set dependencies for a task

    • Required input:

      • task_id (string): The task ID to add dependencies to

      • dependencies (array of strings): Array of task IDs that this task depends on

    • Returns: Updated task dependencies

  13. asana_add_task_dependents

    • Set dependents for a task (tasks that depend on this task)

    • Required input:

      • task_id (string): The task ID to add dependents to

      • dependents (array of strings): Array of task IDs that depend on this task

    • Returns: Updated task dependents

  14. asana_create_subtask

    • Create a new subtask for an existing task

    • Required input:

      • parent_task_id (string): The parent task ID to create the subtask under

      • name (string): Name of the subtask

    • Optional input:

      • notes (string): Description of the subtask

      • due_on (string): Due date in YYYY-MM-DD format

      • assignee (string): Assignee (can be 'me' or a user ID)

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Created subtask information

  15. asana_get_multiple_tasks_by_gid

    • Get detailed information about multiple tasks by their GIDs (maximum 25 tasks)

    • Required input:

      • task_ids (array of strings or comma-separated string): Task GIDs to retrieve (max 25)

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of detailed task information

  16. asana_get_project_status

    • Get a project status update

    • Required input:

      • project_status_gid (string): The project status GID to retrieve

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Project status information

  17. asana_get_project_statuses

    • Get all status updates for a project

    • Required input:

      • project_gid (string): The project GID to get statuses for

    • Optional input:

      • limit (number): Results per page (1-100)

      • offset (string): Pagination offset token

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of project status updates

  18. asana_create_project_status

    • Create a new status update for a project

    • Required input:

      • project_gid (string): The project GID to create the status for

      • text (string): The text content of the status update

    • Optional input:

      • color (string): The color of the status (green, yellow, red)

      • title (string): The title of the status update

      • html_text (string): HTML formatted text for the status update

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Created project status information

  19. asana_delete_project_status

    • Delete a project status update

    • Required input:

      • project_status_gid (string): The project status GID to delete

    • Returns: Deletion confirmation

  20. asana_set_parent_for_task

    • Set the parent of a task and position the subtask within the other subtasks of that parent

    • Required input:

      • task_id (string): The task ID to operate on

      • data (object):

        • parent (string): The new parent of the task, or null for no parent

    • Optional input:

      • insert_after (string): A subtask of the parent to insert the task after, or null to insert at the beginning of the list

      • insert_before (string): A subtask of the parent to insert the task before, or null to insert at the end of the list

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Updated task information

  21. asana_get_tag

    • Get detailed information about a specific tag

    • Required input:

      • tag_gid (string): Globally unique identifier for the tag

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Detailed tag information

  22. asana_get_tags_for_task

    • Get a task's tags

    • Required input:

      • task_gid (string): The task to operate on

    • Optional input:

      • limit (number): Results per page. The number of objects to return per page. The value must be between 1 and 100.

      • offset (string): Offset token. An offset to the next page returned by the API.

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of tags associated with the task

  23. asana_get_tasks_for_tag

    • Get tasks for a specific tag

    • Required input:

      • tag_gid (string): The tag GID to retrieve tasks for

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

      • opt_pretty (boolean): Provides the response in a 'pretty' format

      • limit (integer): The number of objects to return per page. The value must be between 1 and 100.

      • offset (string): An offset to the next page returned by the API.

    • Returns: List of tasks for the specified tag

  24. asana_get_tags_for_workspace

    • Get tags in a workspace

    • Required input:

      • workspace_gid (string): Globally unique identifier for the workspace or organization

    • Optional input:

      • limit (integer): Results per page. The number of objects to return per page. The value must be between 1 and 100.

      • offset (string): Offset token. An offset to the next page returned by the API.

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: List of tags in the workspace

  25. asana_update_tag

    • Update an existing tag

    • Required input:

      • tag_gid (string): Globally unique identifier for the tag

    • Optional input:

      • name (string): Name of the tag

      • color (string): Color of the tag. Can be one of: dark-pink, dark-green, dark-blue, dark-red, dark-teal, dark-brown, dark-orange, dark-purple, dark-warm-gray, light-pink, light-green, light-blue, light-red, light-teal, light-brown, light-orange, light-purple, light-warm-gray

      • notes (string): Notes about the tag

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Updated tag information

  26. asana_delete_tag

    • Delete a tag

    • Required input:

      • tag_gid (string): Globally unique identifier for the tag

    • Returns: Deletion confirmation

  27. asana_create_tag_for_workspace

    • Create a new tag in a workspace

    • Required input:

      • workspace_gid (string): Globally unique identifier for the workspace or organization

      • name (string): Name of the tag

    • Optional input:

      • color (string): Color of the tag. Can be one of: dark-pink, dark-green, dark-blue, dark-red, dark-teal, dark-brown, dark-orange, dark-purple, dark-warm-gray, light-pink, light-green, light-blue, light-red, light-teal, light-brown, light-orange, light-purple, light-warm-gray

      • notes (string): Notes about the tag

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Created tag information

  28. asana_add_tag_to_task

    • Add a tag to a task

    • Required input:

      • task_gid (string): The task GID to add the tag to

      • tag_gid (string): The tag GID to add to the task

    • Returns: Success response

  29. asana_remove_tag_from_task

    • Remove a tag from a task

    • Required input:

      • task_gid (string): The task GID to remove the tag from

      • tag_gid (string): The tag GID to remove from the task

    • Returns: Success response

  30. asana_add_project_to_task

    • Add an existing task to a project

    • Required input:

      • task_id (string): The task ID to add to the project

      • project_id (string): The project ID to add the task to

    • Optional input:

      • section (string): The section ID to add the task to within the project

      • insert_after (string): A task ID to insert this task after. At most one of insert_before, insert_after, or section should be specified.

      • insert_before (string): A task ID to insert this task before. At most one of insert_before, insert_after, or section should be specified.

    • Returns: Success message confirming the task was added to the project

    • Notes: If no positioning arguments are given, the task will be added to the end of the project

  31. asana_remove_project_from_task

    • Remove a task from a project

    • Required input:

      • task_id (string): The task ID to remove from the project

      • project_id (string): The project ID to remove the task from

    • Returns: Success message confirming the task was removed from the project

    • Notes: The task will still exist in the system, but it will not be in the project anymore

  32. asana_delete_task

    • Delete a task permanently

    • Required input:

      • task_id (string): The task ID to delete

    • Returns: Success message confirming the task was deleted

    • Notes: This action cannot be undone. The task will be permanently removed.

  33. asana_create_project

    • Create a new project in a workspace or team

    • Required input:

      • workspace (string): The workspace GID to create the project in

      • name (string): Name of the project

    • Optional input:

      • team (string): The team GID (required for organization workspaces)

      • notes (string): Description or notes for the project

      • color (string): Color of the project (e.g., dark-pink, dark-green, light-blue)

      • privacy_setting (string): Privacy setting (public_to_workspace, private_to_team, private)

      • default_view (string): Default view (list, board, calendar, timeline)

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: The created project object

  34. asana_update_project

    • Update a project's details (name, description, etc.)

    • Required input:

      • project_id (string): The project GID to update

    • Optional input:

      • name (string): New name for the project

      • notes (string): New plain text description for the project

      • html_notes (string): New HTML formatted description (must be valid Asana XML)

      • color (string): Color of the project (e.g., dark-pink, dark-green, light-blue)

      • privacy_setting (string): Privacy setting (public_to_workspace, private_to_team, private)

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Updated project information

  35. asana_create_section

    • Create a new section in a project

    • Required input:

      • project_id (string): The project GID to create the section in

      • name (string): Name of the new section

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Created section information

  36. asana_update_section

    • Update a section (rename it)

    • Required input:

      • section_id (string): The section GID to update

      • name (string): New name for the section

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

    • Returns: Updated section information

  37. asana_delete_section

    • Delete a section from a project

    • Required input:

      • section_id (string): The section GID to delete

    • Returns: Deletion confirmation

  38. asana_add_task_to_section

    • Move a task to a section within its project

    • Required input:

      • section_id (string): The section GID to add the task to

      • task_id (string): The task GID to move

    • Optional input:

      • insert_before (string): A task GID to insert the task before

      • insert_after (string): A task GID to insert the task after

    • Returns: Success confirmation

  39. asana_get_subtasks

    • Get all subtasks of a given task. Returns a compact representation of each subtask.

    • Required input:

      • task_gid (string): The GID of the parent task

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include (e.g. 'name,completed,assignee,due_on')

    • Returns: Array of subtask objects

  40. asana_get_tasks_for_project

    • Get all tasks in a project. Use this instead of search_tasks when you need to list tasks in a specific project. Works on free Asana plans (unlike search_tasks which requires premium). Supports pagination and optional field selection.

    • Required input:

      • project_id (string): The project GID to get tasks for

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

      • limit (number): Results per page (1-100)

      • offset (string): Pagination offset token from a previous response

    • Returns: Array of task objects

  41. asana_get_my_tasks

    • Get tasks from the authenticated user's 'My Tasks' list in a workspace

    • Required input:

      • workspace (string): The workspace GID to get My Tasks from

    • Optional input:

      • opt_fields (string): Comma-separated list of optional fields to include

      • completed_since (string): Only return tasks completed since this time (ISO 8601). Use 'now' to only return incomplete tasks.

    • Returns: List of tasks from the user's My Tasks list

Prompts

  1. task-summary

    • Get a summary and status update for a task based on its notes, custom fields and comments

    • Required input:

      • task_id (string): The task ID to get summary for

    • Returns: A detailed prompt with instructions for generating a task summary

  2. task-completeness

    • Analyze if a task description contains all necessary details for completion

    • Required input:

      • task_id (string): The task ID or URL to analyze

    • Returns: A detailed prompt with instructions for analyzing task completeness

  3. create-task

    • Create a new task with specified details

    • Required input:

      • project_name (string): The name of the Asana project where the task should be created

      • title (string): The title of the task

    • Optional input:

      • notes (string): Notes or description for the task

      • due_date (string): Due date for the task (YYYY-MM-DD format)

    • Returns: A detailed prompt with instructions for creating a comprehensive task

Resources

  1. Workspaces - asana://workspace/{workspace_gid}

    • Representation of Asana workspaces as resources

    • Each workspace is exposed as a separate resource

    • URI Format: asana://workspace/{workspace_gid}

    • Returns: JSON object with workspace details including:

      • name: Workspace name (string)

      • id: Workspace global ID (string)

      • type: Resource type (string)

      • is_organization: Whether the workspace is an organization (boolean)

      • email_domains: List of email domains associated with the workspace (string[])

    • Mime Type: application/json

  2. Projects - asana://project/{project_gid}

    • Template resource for retrieving project details by GID

    • URI Format: asana://project/{project_gid}

    • Returns: JSON object with project details including:

      • name: Project name (string)

      • id: Project global ID (string)

      • type: Resource type (string)

      • archived: Whether the project is archived (boolean)

      • public: Whether the project is public (boolean)

      • notes: Project description/notes (string)

      • color: Project color (string)

      • default_view: Default view type (string)

      • due_date, due_on, start_on: Project date information (string)

      • workspace: Object containing workspace information

      • team: Object containing team information

      • sections: Array of section objects in the project

      • custom_fields: Array of custom field definitions for the project

    • Mime Type: application/json

Setup

  1. Create an Asana account:

    • Visit the Asana.

    • Click "Sign up".

  2. Retrieve the Asana Access Token:

  3. Installation Options:

    For Claude Desktop:

    Add the following to your claude_desktop_config.json:

    {
  "mcpServers": {
    "asana": {
      "command": "npx",
      "args": ["-y", "@roychri/mcp-server-asana"],
      "env": {
        "ASANA_ACCESS_TOKEN": "your-asana-access-token"
      }
    }
  }
}

    For Claude Code:

    Use the following command to install and configure the MCP server:

    claude mcp add asana -e ASANA_ACCESS_TOKEN=<TOKEN> -- npx -y @roychri/mcp-server-asana

    Replace <TOKEN> with your Asana access token.

    For Codex CLI:

    Add the following to your ~/.codex/config.toml:

    [mcp_servers.asana]
command = "npx"
args = [
  "-y", "@roychri/mcp-server-asana"
]
env = {ASANA_ACCESS_TOKEN= "<TOKEN>"}

    Replace <TOKEN> with your Asana access token.

If you want to install the beta version (not yet released), you can use:

  • @roychri/mcp-server-asana@beta

You can find the current beta release, if any, with either:

  1. https://www.npmjs.com/package/@roychri/mcp-server-asana?activeTab=versions

  2. npm dist-tag ls @roychri/mcp-server-asana

Troubleshooting

If you encounter permission errors:

  1. Ensure the asana plan you have allows API access

  2. Confirm the access token and configuration are correctly set in claude_desktop_config.json.

Contributing

Clone this repo and start hacking.

Test it locally with the MCP Inspector

If you want to test your changes, you can use the MCP Inspector like this:

npm run inspector

This will expose the client to port 5173 and server to port 3000.

If those ports are already used by something else, you can use:

CLIENT_PORT=5009 SERVER_PORT=3009 npm run inspector

License

This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

22 tools
asana_add_task_dependenciesC

Set dependencies for a task

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID to add dependencies to
dependenciesYesArray of task IDs that this task depends on

TDQS

C2.4/5.0
Behavior1/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 says 'Set dependencies' without explaining whether this replaces or adds to existing dependencies, what happens on error, or if special permissions are required. This is a minimal mutation description with zero 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence with no fluff, but it is under-specified. It essentially restates the tool name with minimal added value. While concise, it lacks the detail expected for a tool description, so it is not well-optimized for usefulness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with no annotations and no output schema. The description fails to explain return values, idempotency, whether dependencies are appended or replaced, or how it relates to sibling tools. For a simple but consequential operation, this is severely 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?

The input schema has 100% coverage, describing both task_id and dependencies array. The description adds no additional meaning beyond the schema, such as relationship semantics or edge cases. Baseline 3 is appropriate given the schema completeness.

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 specific action unambiguous. However, it does not explicitly differentiate from the sibling tool asana_add_task_dependents, though the term 'dependencies' helps indicate direction.

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_task_dependents or asana_update_task. There are no preconditions, exclusions, or context about when this action is appropriate.

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

asana_add_task_dependentsB

Set dependents for a task (tasks that depend on this task)

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID to add dependents to
dependentsYesArray of task IDs that depend on this task

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It explains the direction of dependencies but uses 'Set' which could imply replacing all dependents rather than adding to existing ones (the tool name says 'add'). No side effects, mutability, or return behavior are disclosed, which 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no filler. Every word contributes to explaining the operation, making it highly concise and well-structured for quick parsing.

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 no annotations and no output schema, the description should provide more context about behavior, such as whether it appends or replaces dependents, and what the successful response looks like. The description only covers the bare purpose, leaving critical usage details unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains both parameters clearly. The description's parenthetical 'tasks that depend on this task' is redundant with the schema's own wording, so it adds no additional semantic value beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Set') and resource ('dependents for a task'), with a parenthetical clarifying that the dependents are tasks that depend on this task. This direction disambiguates it from the sibling 'asana_add_task_dependencies', which sets the opposite dependency direction.

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 explicit guidance is given on when to use this tool versus alternatives like asana_add_task_dependencies. The description implies a use case but does not state prerequisites, exclusions, or relational context, leaving the agent to infer when this is the appropriate choice.

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

asana_create_project_statusB

Create a new status update for a project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_gidYesThe project GID to create the status for
textYesThe text content of the status update
colorNoThe color of the status (green, yellow, red)
titleNoThe title of the status update
html_textNoHTML formatted text for the status update
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says that a status update is created, but does not mention required permissions, the effect on existing project statuses, whether the operation is reversible, or what the response contains. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action ('Create') and the resource ('status update for a project'). It contains no redundancy or unnecessary words, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having six parameters and no output schema, the description offers only the barest functional statement. It lacks usage context, behavioral details, and return value information, leaving the agent under-informed about the tool's broader implications and expected response.

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 all six parameters are already well-documented. The tool description adds no additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') and a clear resource ('status update for a project'), making the tool's purpose explicit. It distinguishes this tool from sibling tools like asana_get_project_status and asana_delete_project_status, which are distinctly 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, no mention of prerequisites, and no exclusion criteria. It simply states the function without any contextual advice, 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.

asana_create_subtaskB

Create a new subtask for an existing task

ParametersJSON Schema
NameRequiredDescriptionDefault
parent_task_idYesThe parent task ID to create the subtask under
nameYesName of the subtask
notesNoDescription of the subtask
html_notesNoHTML-like formatted description of the subtask. Does not support ALL HTML tags. Only a subset. The only allowed TAG in the HTML are: <body> <h1> <h2> <ol> <ul> <li> <strong> <em> <u> <s> <code> <pre> <blockquote> <a data-asana-type="" data-asana-gid=""> <hr> <img> <table> <tr> <td>. No other tags are allowed. Use the \n to create a newline. Do not use \n after <body>. Example: <body><h1>Motivation</h1> A customer called in to complain <h1>Goal</h1> Fix the problem</body>
due_onNoDue date in YYYY-MM-DD format
assigneeNoAssignee (can be 'me' or a user ID)
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states the basic action without mentioning prerequisites (e.g., parent task must exist), failure modes, permissions, or any side effects. The description adds no context beyond what is obvious from the tool name.

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, concise sentence that directly states the purpose. It is efficient with no filler, but it is so minimal that it may leave out useful details without becoming verbose.

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?

The tool has 7 parameters, no output schema, and no annotations. The description explains only the core operation, leaving the agent without guidance on response format, parameter specifics (e.g., how assignee 'me' works), or edge cases. For a tool of this complexity, the description 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 coverage is 100%, and the description adds no parameter-specific semantics beyond the schema. Baseline for high schema coverage is 3, and the description does not improve or detract from this.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') and resource ('subtask for an existing task'), clearly distinguishing it from sibling tools like create_task or set_parent_for_task. It is unambiguous about the operation performed.

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 such as asana_create_task or asana_set_parent_for_task. The description does not mention any prerequisites, validations, or scenarios where another tool would be more appropriate.

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

asana_create_taskB

Create a new task in a project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesThe project to create the task in
nameYesName of the task
notesNoDescription of the task
html_notesNoHTML-like formatted description of the task. Does not support ALL HTML tags. Only a subset. The only allowed TAG in the HTML are: <body> <h1> <h2> <ol> <ul> <li> <strong> <em> <u> <s> <code> <pre> <blockquote> <a data-asana-type="" data-asana-gid=""> <hr> <img> <table> <tr> <td>. No other tags are allowed. Use the \n to create a newline. Do not use \n after <body>. Example: <body><h1>Motivation</h1> A customer called in to complain <h1>Goal</h1> Fix the problem</body>
due_onNoDue date in YYYY-MM-DD format
assigneeNoAssignee (can be 'me' or a user ID)
followersNoArray of user IDs to add as followers
parentNoThe parent task ID to set this task under
projectsNoArray of project IDs to add this task to
resource_subtypeNoThe type of the task. Can be one of 'default_task' or 'milestone'
custom_fieldsNoObject mapping custom field GID strings to their values. For enum fields use the enum option GID as the value.

TDQS

B3.2/5.0
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 disclosing behavioral traits. However, it only states the basic action and omits any context such as whether authentication is required, what the response contains, or side effects (e.g., task appears in project timeline). It adds no value beyond the 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, direct sentence with zero wasted words. It is front-loaded and immediately states the action and object, making it optimally concise for quick parsing.

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?

The tool has 11 parameters, no output schema, and no annotations, yet the description is only one sentence. It fails to convey expected return values, error conditions, or important behavioral nuances (e.g., that project_id is required despite being listed among optional-looking properties). For a create operation with this complexity, the description is insufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 11 parameters in detail, including the complex html_notes restrictions and custom_fields format. The description adds no parameter-level meaning, but the baseline of 3 is appropriate because the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/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' uses a specific verb ('Create') and resource ('task in a project'), clearly distinguishing it from sibling tools like asana_create_subtask and asana_update_task. It unambiguously states the tool's primary action.

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_subtask or asana_update_task. It does not mention any exclusions, prerequisites, or contextual clues, leaving the agent to infer usage solely from the name and schema.

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

asana_create_task_storyA

Create a comment or story on a task. Either text or html_text is required.

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID to add the story to
textNoThe plain text content of the story/comment. Required if html_text is not provided.
html_textNoHTML-like formatted text for the comment. Required if text is not provided. Does not support ALL HTML tags. Only a subset. The only allowed TAG in the HTML are: <body> <h1> <h2> <ol> <ul> <li> <strong> <em> <u> <s> <code> <pre> <blockquote> <a data-asana-type="" data-asana-gid=""> <hr> <img> <table> <tr> <td>. No other tags are allowed. Use the \n to create a newline. Do not use \n after <body>.
opt_fieldsNoComma-separated list of optional fields to include

TDQS

A3.6/5.0
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 for behavioral disclosure. It states the required input but does not mention whether this is a write operation requiring permissions, whether the action is reversible, what the response contains, or any side effects. This is insufficient 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, focused sentence that directly states the action and a key requirement. No wasted words, and it is perfectly sized for the tool's simplicity.

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?

The tool has no output schema and no annotations, so the description should explain return values or at least the effect of the action. It doesn't mention what the response will be, any prerequisites (e.g., authentication), or additional behavior. Given its simplicity, it is not fully complete for an agent to understand the full context of invoking this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides detailed descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds value by clarifying the relationship between text and html_text ('Either text or html_text is required'), which is a semantic constraint not enforced by the schema's required fields. This goes beyond mere repetition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Create') and resource ('a comment or story on a task'), clearly distinguishing it from sibling tools like asana_create_task (creates a task) and asana_get_task_stories (retrieves stories). The parenthetical about required input adds clarity without ambiguity.

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 the use case: when you need to add a comment or story to a task. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools. The requirement that text or html_text be provided gives a functional constraint but no comparative guidance.

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

asana_delete_project_statusA

Delete a project status update

ParametersJSON Schema
NameRequiredDescriptionDefault
project_status_gidYesThe project status GID to delete

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden of indicating the destructive nature. It explicitly says 'Delete', which conveys the core behavior, but it does not disclose permanence, side effects, or required permissions. Minimal but acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, clear, and concise sentence. Every word earns its place with no redundant information.

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 delete operation with one parameter and no output schema, the description is functionally adequate but lacks any context about irreversibility, errors, or expected behavior after deletion. It meets minimum viability but doesn't enrich the agent's 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%, and the parameter 'project_status_gid' is clearly described as 'The project status GID to delete'. The description adds no extra semantic detail beyond the schema, but none is needed.

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 'Delete a project status update' uses a specific verb and resource, clearly distinguishing it from sibling tools like get and create project status. It leaves no ambiguity about the tool's function.

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. There is no mention of prerequisites, scenarios for deletion, or warnings about irreversible actions.

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

asana_get_multiple_tasks_by_gidA

Get detailed information about multiple tasks by their GIDs (maximum 25 tasks)

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idsYesArray or comma-separated string of task GIDs to retrieve (max 25)
opt_fieldsNoComma-separated list of optional fields to include

TDQS

A4/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does disclose the 25-task maximum limit, which is a key constraint, but it omits any details about error behavior, permissions, or return format. This is a modest disclosure that avoids contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose and key limit. No filler or redundant content exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's relative simplicity (2 params, no output schema), the description adequately covers the essential use case. It notes the batch aspect and max limit, but lacks any detail about response shape or error cases, which would be expected in a fully complete context. Still, it is sufficient for a straightforward GET 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?

Because schema description coverage is 100%, the schema already fully documents both parameters (task_ids and opt_fields). The description adds little beyond the schema, only hinting at 'detailed information' which is not a strong supplement. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get'), the resource ('tasks'), and the specific qualifier ('by their GIDs', 'multiple', 'maximum 25 tasks'). This distinguishes it from single-task retrieval (asana_get_task) and search tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving multiple tasks by GID, which is a clear context. However, it does not explicitly contrast with alternatives like asana_get_task or mention when not to use it, so there is slight room for improvement.

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

asana_get_projectC

Get detailed information about a specific project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesThe project ID to retrieve
opt_fieldsNoComma-separated list of optional fields to include

TDQS

C2.9/5.0
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 says 'Get detailed information' without explaining what 'detailed' includes, whether pagination or field selection is supported (though opt_fields exists), or what the response structure looks like. The tool is read-only in intent, but that is implied rather than explicit.

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 sentence that is efficient and front-loaded, stating the core action and resource. It avoids redundancy and verbosity. However, its brevity borders on under-specification, which is a completeness issue rather than a conciseness one, so the structure itself is fine.

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 that there are no annotations, no output schema, and a relatively simple tool, the description should still provide more context about what information is returned and when to use it. The vague phrase 'detailed information' does not tell the agent what to expect, and there is no comparison to sibling tools. The description is minimally viable but lacks 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?

The input schema covers both parameters (project_id and opt_fields) with descriptions, so schematically the meaning is clear. The description adds no additional semantics beyond the schema; it merely restates that a specific project is retrieved, which maps to project_id. Since schema coverage is 100%, the baseline 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 tool's purpose: to retrieve detailed information about a specific project. The verb 'Get' and resource 'project' are specific, and the mention of 'a specific project' aligns with the required project_id parameter. However, it does not explicitly distinguish itself from sibling tools like asana_search_projects or asana_get_project_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage 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 that it is for retrieving a project by ID, nor does it suggest when to use search_projects or other get/list tools. There is no mention of exclusions or prerequisites.

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

asana_get_project_sectionsB

Get sections in a project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesThe project ID to get sections for
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.1/5.0
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 says 'Get sections in a project' and does not state whether the operation is read-only, how results are returned, or any pagination or limitations. This adds little beyond the tool's 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 concise sentence, front-loaded with the key information. There is no filler or unnecessary detail, making it highly efficient.

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 complete parameter schema, the description is minimally adequate. However, without an output schema or annotations, it would benefit from stating the return type (e.g., 'list of sections') or any relevant caveats. It is not incomplete but leaves some ambiguities.

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 both parameters already described in the input schema. The description does not add any additional meaning about parameters, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action ('Get') and the resource ('sections in a project'), which is specific and distinguishes it from sibling tools like asana_get_project and asana_get_project_status. However, it is a minimal restatement and does not explicitly elaborate on scope or differentiate further.

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 any context, prerequisites, or exclusions, and there is no reference to sibling tools or alternative approaches.

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

asana_get_project_statusC

Get a project status update

ParametersJSON Schema
NameRequiredDescriptionDefault
project_status_gidYesThe project status GID to retrieve
opt_fieldsNoComma-separated list of optional fields to include

TDQS

C2.6/5.0
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 disclosure. It only states the read action itself and provides no information about authentication, required permissions, return format, or any side effects. This is minimal and leaves the agent to infer the behavior from the tool name.

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, short sentence that is front-loaded and free of filler. However, it is so brief that it omits necessary context, though this is more a completeness issue than a conciseness issue.

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 simple get tool with two well-documented parameters, the description still lacks important context: it does not explain what is returned, that it requires a project status GID, or how it differs from the plural listing tool. With no output schema and no annotations, the description is insufficient to fully guide an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters (opt_fields and project_status_gid), so the schema already documents their meaning. The description adds no additional parameter context, earning the baseline score of 3.

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' states the action and resource clearly enough, but it is vague and does not specify that it fetches a single status by GID. It could easily apply to the sibling tool asana_get_project_statuses, so it fails to distinguish between 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 is provided on when to use this tool versus alternatives. The description does not mention that this tool retrieves a specific project status by GID, nor does it contrast with listing or creating statuses.

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

asana_get_project_statusesB

Get all status updates for a project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_gidYesThe project GID to get statuses for
limitNoResults per page (1-100)
offsetNoPagination offset token
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.2/5.0
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 without mentioning pagination behavior, return format, ordering, or potential errors, which is a meaningful gap for a tool with offset/limit 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, focused sentence with no filler. It clearly conveys the core action and resource without any unnecessary words, making it easy for an agent 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?

With no output schema and no annotations, the description must provide more context but does not. It fails to explain the response shape, pagination semantics despite having limit/offset parameters, or what constitutes a 'status update,' leaving the agent under-informed.

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% for all four parameters, so the schema fully documents them. The description adds no additional semantic value beyond what the schema already provides, thus the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves all status updates for a project, with a specific verb and resource. The word 'all' distinguishes it from the sibling tool asana_get_project_status (singular), making it clear this is for the full list.

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 given on when to use this tool versus alternatives such as asana_get_project_status or asana_get_task_stories. There is no mention of prerequisites, exclusions, or context where this endpoint is preferred.

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

asana_get_project_task_countsB

Get the number of tasks in a project

ParametersJSON Schema
NameRequiredDescriptionDefault
project_idYesThe project ID to get task counts for
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. The 'Get' verb implies a read-only operation, but the description does not add details such as whether the count includes subtasks, whether it reflects a snapshot, or any response structure. It is minimally transparent beyond the name itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that immediately communicates the core function. It is front-loaded with the verb and resource, and there is no wasted wording.

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 an output schema and annotations, the description should clarify the return value format (e.g., a bare integer vs. an object with a count field). It also does not mention how opt_fields might affect the response. The description is too terse to fully prepare an agent to consume the tool's output reliably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter semantics beyond what the schema already provides. It neither clarifies project_id nor opt_fields, so it adds no extra value over the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get the number of tasks in a project' uses a specific verb+resource and clearly identifies the operation. It distinguishes this tool from siblings like asana_get_project (which fetches project details) and asana_get_multiple_tasks_by_gid (which lists tasks). The scope is well-defined.

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. There are no exclusions or mentions of related sibling tools. The description only states what it does, not the context or use cases, leaving the agent without explicit decision support.

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

asana_get_tags_for_workspaceA

Get tags in a workspace

ParametersJSON Schema
NameRequiredDescriptionDefault
workspace_gidYesGlobally unique identifier for the workspace or organization
limitNoResults per page. The number of objects to return per page. The value must be between 1 and 100.
offsetNoOffset token. An offset to the next page returned by the API.
opt_fieldsNoComma-separated list of optional fields to include

TDQS

A3.5/5.0
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 transparency. However, it only restates the tool name without adding context about pagination, read-only nature, or any potential side effects. The schema mentions limit/offset, but the description itself does not elaborate on 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, concise sentence: 'Get tags in a workspace.' It contains no wasteful words and is directly front-loaded with the core action and resource, 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?

The description provides the essential purpose but lacks detail on return values and pagination behavior, especially since there is no output schema. It is adequate for a simple GET endpoint but incomplete for an agent to understand full behavior without relying on external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter having a description in the input schema. The tool description adds no additional parameter semantics, but the schema already provides sufficient detail, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: 'Get tags in a workspace.' It uses a specific verb ('Get'), a specific resource ('tags'), and a scope ('in a workspace'), distinguishing it from sibling tools like asana_get_tasks_for_tag (which retrieves tasks) and asana_get_project.

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 through its resource name but does not explicitly state when to use this tool over alternatives. There are no exclusions or mentions of alternative tools, so usage guidance is minimal but not absent.

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

asana_get_taskB

Get detailed information about a specific task

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID to retrieve
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.3/5.0
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 information, implying read-only behavior, but does not disclose permissions, response format, potential errors, or side effects. The description is too minimal to provide meaningful transparency beyond what the tool name already implies.

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, tightly worded sentence that directly states the tool's purpose without any filler. It is front-loaded and efficient, earning its place in the description.

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 a well-covered schema, the description is minimally adequate. However, since there is no output schema to clarify return values, the vague 'detailed information' leaves some ambiguity. The lack of usage guidance and behavioral context (no annotations) slightly reduces completeness, but the low complexity of the tool makes this a borderline 3.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with descriptions for both task_id and opt_fields. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. The parameter meanings are clear solely from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Get detailed information about a specific task' clearly identifies the action (get) and the resource (specific task), distinguishing it from siblings like asana_search_tasks (searching) and asana_get_multiple_tasks_by_gid (multiple tasks). The phrase 'specific task' aligns with the singular task_id parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this should be used when you have a known task ID, nor does it suggest alternatives like search for finding tasks. Usage context is only implied by the word 'specific'.

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

asana_get_tasks_for_tagC

Get tasks for a specific tag

ParametersJSON Schema
NameRequiredDescriptionDefault
tag_gidYesThe tag GID to retrieve tasks for
opt_fieldsNoComma-separated list of optional fields to include
opt_prettyNoProvides the response in a 'pretty' format
limitNoThe number of objects to return per page. The value must be between 1 and 100.
offsetNoAn offset to the next page returned by the API.

TDQS

C2.9/5.0
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 says 'get' which implies a read-only operation, but does not mention pagination, return format, rate limits, or any side effects. The description adds no behavioral context beyond the verb.

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, concise sentence with no wasted words. It is appropriately sized, though it is essentially a restatement of the tool's name and could have been enriched without losing 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?

The tool has no annotations and no output schema, so the description should compensate by explaining return types, pagination behavior, or typical usage. It does none of this, leaving the agent with minimal context beyond the schema's parameter definitions.

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 five parameters are already documented in the schema. The description adds no additional meaning beyond the schema, which matches the baseline score of 3 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 'Get tasks for a specific tag' with a specific verb and resource. However, it does not distinguish this tool from siblings like asana_search_tasks, which could also retrieve tasks by tag, so it misses the top 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?

No guidance is provided on when to use this tool versus alternatives such as asana_search_tasks or asana_get_multiple_tasks_by_gid. There is no context about use cases, prerequisites, or exclusions.

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

asana_get_task_storiesB

Get comments and stories for a specific task

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID to get stories for
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description is the only source of behavioral info. It implies a read-only operation ('Get') but does not disclose details like permissions required, pagination, ordering, or the structure of returned stories. This falls short of the burden placed on descriptions when annotations are absent.

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, front-loaded sentence of nine words, directly stating the tool's purpose without any filler. It 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?

While the description is clear, it is minimal. It lacks any usage guidance, exclusions, or behavioral context beyond the basic action, and there is no output schema to clarify return values. For a tool with no annotations, this is inadequate.

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 adds no semantic information about parameters beyond the schema. The schema already fully documents task_id and opt_fields with clear descriptions, so with 100% schema coverage, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with clear objects 'comments and stories' and scope 'for a specific task'. This distinguishes it from sibling tools like asana_get_task (which retrieves the task itself) and asana_create_task_story (which creates a story).

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?

There is no guidance about when to use this tool versus alternatives. It merely states its function without mentioning exclusions or alternative tools for related operations, such as asana_get_task for task details.

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

asana_list_workspacesB

List all available workspaces in Asana

ParametersJSON Schema
NameRequiredDescriptionDefault
opt_fieldsNoComma-separated list of optional fields to include

TDQS

B3/5.0
Behavior1/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 states the action without mentioning authentication, pagination, response shape, or side effects. This is a significant gap for an agent deciding whether to call the 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, concise sentence with no unnecessary words. It is fully front-loaded 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 simple list operation with one optional parameter, the description covers the basic purpose but lacks usage guidance and return-value context. Without an output schema, the agent may not know the structure of the response, making the description incomplete for a safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter opt_fields is fully described in the schema, so the description adds no additional meaning. Schema description coverage is 100%, warranting a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the action verb 'List' and clearly identifies 'workspaces' as the resource, which distinguishes it from sibling tools that operate on tasks, projects, and users. This is a specific and unambiguous purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided for when to use this tool versus alternatives such as asana_get_tags_for_workspace or asana_get_users_in_workspace. There is no mention of prerequisites, when not to use it, or how it fits into a workflow.

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

asana_search_projectsA

Search for projects in Asana using name pattern matching

ParametersJSON Schema
NameRequiredDescriptionDefault
workspaceYesThe workspace to search in
name_patternYesRegular expression pattern to match project names
archivedNoOnly return archived projects
opt_fieldsNoComma-separated list of optional fields to include

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention that name_pattern is a regular expression, how archived projects are handled, or that the tool returns a list of matching projects. The behavior is under-specified.

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 one concise sentence, front-loaded with the action and resource. No extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is too brief for a tool with no output schema and no annotations. It doesn't explain the return format or any filtering details beyond the schema-visible parameters, leaving the agent uncertain about expected response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter described, so the description does not need to add parameter semantics. The description aligns with the name_pattern field but adds no new information beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for projects in Asana using name pattern matching. It uses a specific verb ('search') and resource ('projects'), distinguishing it from project retrieval by GID (asana_get_project) and task search (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 provides no explicit guidance on when to use this tool versus alternatives. There is no mention of alternatives, prerequisites, or exclusions; usage is only implied by the search semantics.

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

asana_search_tasksB

Search tasks in a workspace with advanced filtering options

ParametersJSON Schema
NameRequiredDescriptionDefault
workspaceYesThe workspace to search in
textNoText to search for in task names and descriptions
resource_subtypeNoFilter by task subtype (e.g. milestone)
portfolios_anyNoComma-separated list of portfolio IDs
assignee_anyNoComma-separated list of user IDs
assignee_notNoComma-separated list of user IDs to exclude
projects_anyNoComma-separated list of project IDs
projects_notNoComma-separated list of project IDs to exclude
projects_allNoComma-separated list of project IDs that must all match
sections_anyNoComma-separated list of section IDs
sections_notNoComma-separated list of section IDs to exclude
sections_allNoComma-separated list of section IDs that must all match
tags_anyNoComma-separated list of tag IDs
tags_notNoComma-separated list of tag IDs to exclude
tags_allNoComma-separated list of tag IDs that must all match
teams_anyNoComma-separated list of team IDs
followers_notNoComma-separated list of user IDs to exclude
created_by_anyNoComma-separated list of user IDs
created_by_notNoComma-separated list of user IDs to exclude
assigned_by_anyNoComma-separated list of user IDs
assigned_by_notNoComma-separated list of user IDs to exclude
liked_by_notNoComma-separated list of user IDs to exclude
commented_on_by_notNoComma-separated list of user IDs to exclude
due_onNoISO 8601 date string or null
due_on_beforeNoISO 8601 date string
due_on_afterNoISO 8601 date string
due_at_beforeNoISO 8601 datetime string
due_at_afterNoISO 8601 datetime string
start_onNoISO 8601 date string or null
start_on_beforeNoISO 8601 date string
start_on_afterNoISO 8601 date string
created_onNoISO 8601 date string or null
created_on_beforeNoISO 8601 date string
created_on_afterNoISO 8601 date string
created_at_beforeNoISO 8601 datetime string
created_at_afterNoISO 8601 datetime string
completed_onNoISO 8601 date string or null
completed_on_beforeNoISO 8601 date string
completed_on_afterNoISO 8601 date string
completed_at_beforeNoISO 8601 datetime string
completed_at_afterNoISO 8601 datetime string
modified_onNoISO 8601 date string or null
modified_on_beforeNoISO 8601 date string
modified_on_afterNoISO 8601 date string
modified_at_beforeNoISO 8601 datetime string
modified_at_afterNoISO 8601 datetime string
completedNoFilter for completed tasks
is_subtaskNoFilter for subtasks
has_attachmentNoFilter for tasks with attachments
is_blockedNoFilter for tasks with incomplete dependencies
is_blockingNoFilter for incomplete tasks with dependents
sort_byNoSort by: due_date, created_at, completed_at, likes, modified_atmodified_at
sort_ascendingNoSort in ascending order
opt_fieldsNoComma-separated list of optional fields to include
custom_fieldsNoObject containing custom field filters. Keys should be in the format "{gid}.{operation}" where operation can be: - {gid}.is_set: Boolean - For all custom field types, check if value is set - {gid}.value: String|Number|String(enum_option_gid) - Direct value match for Text, Number or Enum fields - {gid}.starts_with: String - For Text fields only, check if value starts with string - {gid}.ends_with: String - For Text fields only, check if value ends with string - {gid}.contains: String - For Text fields only, check if value contains string - {gid}.less_than: Number - For Number fields only, check if value is less than number - {gid}.greater_than: Number - For Number fields only, check if value is greater than number Example: { "12345.value": "high", "67890.contains": "urgent" }

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the burden of disclosing behavioral traits. The verb 'search' implies a read-only operation, but the description does not mention pagination, result limits, return format, or any side effects. This is a significant gap for a tool with 55 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose. However, it lacks any structural elements (e.g., bullet points or usage notes) that might help navigate a tool with a very large parameter set.

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, nested objects, no output schema, no annotations), the description is far from complete. It does not explain what results are returned, how pagination works, or any usage caveats. The schema covers parameter definitions, but the description does not help the agent understand the overall behavior or expected output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the phrase 'advanced filtering options,' which is already evident from the extensive parameter list. It neither compensates for missing schema details nor adds context beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('search'), a clear resource ('tasks'), and a scoping context ('in a workspace'). It distinguishes from sibling tools like asana_search_projects (which searches projects) and asana_get_multiple_tasks_by_gid (which retrieves tasks by known IDs) by emphasizing the search/filtering 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 prefer this tool over alternatives, nor any exclusions or prerequisites. It only states the generic action of searching tasks with filters, leaving the agent to infer appropriate use cases from the parameter list.

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

asana_set_parent_for_taskA

Set the parent of a task and position the subtask within the other subtasks of that parent

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYes
task_idYesThe task ID to operate on
optsNo

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does mention the positioning behavior, which is beyond the name, but it omits side effects (e.g., removal from old parent), prerequisites, or auth requirements. For a mutation tool, this is only a partial disclosure.

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, front-loaded sentence with no wasted words. It efficiently conveys the core action and the additional positioning behavior.

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?

The description is too brief for a mutation tool with no annotations and no output schema. It does not state what the tool returns, potential errors, or prerequisites. The positioning detail is helpful but does not make the description complete.

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 coverage is low (33%) and the description does not compensate. It mentions 'position' and 'parent' but does not explain how to use insert_after/insert_before or null values. The schema provides some details, but the description adds no parameter-level meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Set') and clearly identifies the resource ('parent of a task') plus the additional behavior of positioning the subtask among siblings. This distinguishes it from related tools like create_subtask or update_task, which handle 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for re-parenting tasks and controlling their order, but it does not explicitly state when to use this versus alternatives or provide exclusions. The usage context is inferred rather than explicitly guided.

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

asana_update_taskC

Update an existing task's details

ParametersJSON Schema
NameRequiredDescriptionDefault
task_idYesThe task ID to update
nameNoNew name for the task
notesNoNew description for the task
due_onNoNew due date in YYYY-MM-DD format
assigneeNoNew assignee (can be 'me' or a user ID)
completedNoMark task as completed or not
resource_subtypeNoThe type of the task. Can be one of 'default_task' or 'milestone'
custom_fieldsNoObject mapping custom field GID strings to their values. For enum fields use the enum option GID as the value.

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'update details' and fails to mention side effects, required permissions, reversibility, or behavior when fields are omitted. For a mutation tool, 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 compact sentence that is front-loaded with the main action, containing no unnecessary words or repetition.

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?

Despite having 8 parameters and no output schema, the description is too short to convey return values, error behavior, or special considerations like custom field handling. The schema helps but the description alone is insufficient for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% coverage with descriptions for all 8 parameters, so the baseline is 3. The description adds no extra meaning beyond what the schema already offers.

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 uses a clear verb 'update' and identifies the resource as 'an existing task's details', distinguishing it from create_task. However, it doesn't explicitly differentiate from other update-type siblings like set_parent_for_task or add_task_dependencies, so it doesn't get full marks.

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 only states the action without mentioning prerequisites, exclusions, or situations where a different tool would be more appropriate.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 11 tool updatesv1.0.0
    • Addedasana_create_task
    • Addedasana_get_multiple_tasks_by_gid
    • Addedasana_get_project_sections
    • Addedasana_get_project_statuses
    • Addedasana_get_project_task_counts
    • Addedasana_get_task
    • Addedasana_get_task_stories
    • Addedasana_get_tasks_for_tag
    • Addedasana_list_workspaces
    • Addedasana_search_projects
    • Addedasana_set_parent_for_task
  2. 11 tool updates
    • First observedasana_add_task_dependencies
    • First observedasana_add_task_dependents
    • First observedasana_create_project_status
    • First observedasana_create_subtask
    • First observedasana_create_task_story
    • First observedasana_delete_project_status
    • First observedasana_get_project
    • First observedasana_get_project_status
    • First observedasana_get_tags_for_workspace
    • First observedasana_search_tasks
    • First observedasana_update_task
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored across 22 tools

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.

Maintenance

ActivityInactive
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers

  • Asana MCP Server

    mcp-ag2
    F
    license
    Not graded
    quality
    C
    maintenance
    An MCP (Multi-Agent Conversation Protocol) server that enables interacting with the Asana API through natural language commands for task management, project organization, and team collaboration.
    -

  • asana-mcp

    djy89
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables to interact with Asana through Claude, with read and write tools for tasks, projects, tags, and custom fields, with no destructive operations.
    34 npm
    MIT

Appeared in Searches