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

Annotations only declare destructiveHint=true; the description goes far beyond by disclosing the exact blast radius (all steps plus tester answers, uploads and completion records are destroyed), the staging vs immediate application rules, and that the commit — not this call — is the point of no return. It also warns that responses return STAGED rows with unexpected ids and liveVersionId, which is non-obvious behavior an agent would otherwise misread.

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

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

The critical facts are front-loaded (permanent deletion, cascade, cannot-edit archived), but the staging rule is stated twice ('the change is STAGED' near the top and again in the final sentence about the answers being destroyed at commit), and the id-handling paragraph is somewhat tangential to the delete action itself. It is dense and mostly earns its space, but the repetition and length work against scannability.

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

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

For a destructive two-parameter mutation with no output schema, the description covers everything that matters: consequences, reversibility window, environment-dependent behavior, id semantics, and the blocked-state exclusion. Nothing an agent needs to call this safely is missing.

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

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

Schema coverage is already 100%, so the baseline is 3. The description adds real meaning beyond the schema by explaining that while staging, both live and staged ids of a task are accepted but the response always carries the staged row — context the parameter docs do not provide.

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

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

The description opens with a specific verb and resource ('Deletes a task from this beta project') and immediately scopes it against siblings by explaining the cascade (steps, answers, uploads, completion records), which distinguishes it from deleteStep and archiveBeta without requiring schema inspection.

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

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

It explicitly names the conditions that change behavior (draft/scheduled = immediate; running/paused = staged), names the alternative tools that govern the staged outcome (commitTaskChanges, revertTaskChanges, getBetaTasks with version 'unpublished'), and states a hard exclusion: content of finished or archived beta projects cannot be edited.

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