Skip to main content
Glama

delete_task

Destructive

Borra una tarea para siempre. IRREVERSIBLE.

Casi nunca es lo que se quiere: una tarea terminada se cierra con
complete_task y una que ya no va se cancela con `status: 'cancelled'` —
las dos quedan en el historial, que es de donde salen los informes. Borrar
es sólo para lo que se creó por error.

Input Schema

NameRequiredDescriptionDefault
task_idYesID de la task
workspace_idNoUUID del workspace, o su nombre tal como lo dice el usuario ('Acme', 'el personal'). Omitir si el token ya tiene workspace fijo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description reinforces and extends this with the permanence claim ('IRREVERSIBLE', 'para siempre') and the consequence that removed tasks no longer appear in history, which is where reports come from. It does not say whether related artifacts (comments, relations) are cascaded, nor whether any recovery path exists despite a restore_from_trash sibling, so it stops short of a 5.

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 irreversible warning is front-loaded in the first sentence, and the second paragraph spends its length only on misuse prevention. No filler or redundant restatement of the title.

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

Completeness4/5

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

For a two-parameter destructive tool with no output schema, the description covers permanence and the correct routing decisively. The one remaining gap is side effects on dependent data and any restore path, which an agent deciding on a hard delete would benefit from knowing.

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 both task_id and workspace_id are already documented in the schema, including the workspace-name fallback guidance. The description adds no parameter-level detail, which is the expected baseline when the schema carries the load.

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?

States a specific verb and resource ('Borra una tarea para siempre') and immediately scopes it against siblings: complete_task for finished tasks and a status:'cancelled' update for dropped ones. An agent can distinguish this from delete_document/delete_event-style siblings and from complete_task without opening any schema.

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

Usage Guidelines5/5

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

Explicitly frames this as a rarely-correct choice ('Casi nunca es lo que se quiere') and names the two preferred alternatives with the condition that selects each, plus the narrow case where deletion is right ('sólo para lo que se creó por error'). Nothing is left to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources