Skip to main content
Glama

asana_delete_task

DestructiveIdempotent

Permanently delete a task from Asana after confirming. Requires confirm flag to execute; otherwise returns a confirmation gate.

Instructions

DESTRUCTIVE — permanently delete (trash) a task. Requires confirm:true (C13 gate). Without confirm it is a no-op that reports the gate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoMust be true to actually delete
task_gidYesTask GID to delete
Install Server

TDQS

A4.3/5.0
Behavior4/5

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

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

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

Conciseness5/5

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

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

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

Completeness5/5

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

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

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

Parameters3/5

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

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

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

Purpose5/5

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

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

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

Usage Guidelines4/5

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

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

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

Other Tools

Latest Blog Posts

MCP directory API

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

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

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