Skip to main content
Glama

task_delete_describe

Dry-run deletion of a task: returns planned changes without mutating OmniFocus. Use to verify the task before executing the delete.

Instructions

Preview what task_delete would do without making any changes. Do NOT use to actually delete a task — use task_delete instead. Returns { description, plannedChanges } describing the permanent deletion that would occur. No side effects: read-only by contract — never mutates OmniFocus. Example: dry-run companion — pass the same args you would to the write tool, inspect plannedChanges, then call the write tool once approved.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPersistent ID of the task to delete. Get from task_list or search_query. Verify you have the correct ID before calling — this action is irreversible.
confirmYesExplicit acknowledgement that this deletion is permanent and irreversible. Must be exactly true. The call is rejected if this field is absent or false.
dry_runNoWhen true, validates input and returns a preview envelope with meta.dryRun = true; no adapter call is made and no mutation occurs.
idempotency_keyNoIdempotency key for retry-safe deletes. Identical subsequent calls within the TTL window replay the original envelope with meta.idempotentReplay = true instead of re-deleting (or re-raising NotFound on the second attempt).
expectedModifiedAtNoOptimistic-concurrency guard: ISO-8601 timestamp from a recent task_get. If the task's current modifiedAt differs, the call fails with OF_CONFLICT and no delete is performed. Omit to skip the check.
Behavior5/5

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

Even without annotations, the description fully discloses the tool's behavior: it is read-only, causes no side effects, and never mutates OmniFocus. It also describes the output structure ({description, plannedChanges}) so the agent knows what to expect.

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 concise: two sentences plus an example. Every sentence adds value, and it is front-loaded with the core purpose. No wasted words.

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?

Given the tool's complexity (5 parameters, 2 required) and lack of output schema, the description sufficiently explains the return value and side-effect behavior. It covers what the agent needs to use the tool correctly.

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

Parameters3/5

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

The input schema has 100% coverage with parameter descriptions, so the description adds little extra semantic value beyond stating to 'pass the same args you would to the write tool'. This is adequate but not exceptional.

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's purpose: preview a deletion without making changes. It uses specific language ('Preview what task_delete would do without making any changes') and differentiates itself from the sibling tool task_delete by explicitly warning not to use it for actual deletion.

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?

The description explicitly tells the agent when to use this tool (dry-run companion) and when not to (do not use for actual deletion, use task_delete instead). It also provides an example workflow: pass same args, inspect plannedChanges, then call the write tool.

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

Install Server

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/torsday/omnifocus-mcp'

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