Skip to main content
Glama

Delete a job

tourwright_delete_job
DestructiveIdempotent

Deletes a completed or failed job and its video, subtitles, poster, and manifest files. Queued or rendering jobs cannot be deleted.

Instructions

Delete a finished (done or failed) job and its files: the video, subtitles, poster and manifest. A job that is queued or rendering cannot be deleted.

Input Schema

NameRequiredDescriptionDefault
idYesThe job id, from tourwright_render or tourwright_jobs

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.3.0

TDQS

A4.2/5.0
Behavior4/5

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

Destructive, idempotent, and mutation semantics are already supplied by annotations, so the description's job is to add specifics, and it does: it enumerates the four file types that are destroyed and states the job-state precondition that silently blocks deletion. It stops short of saying what happens on a rejected call (error vs. no-op), which keeps it from 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?

Two sentences, both earning their place, with the destructive payload front-loaded before the eligibility caveat. There is no filler or 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 single-parameter destructive tool whose safety profile is already in annotations and which has no output schema, the description covers the essentials: exactly what is removed and what state the job must be in. Only the failure mode for an ineligible job is left unstated.

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?

With one parameter at 100% schema description coverage, the schema already explains that 'id' is the job id, sourced from tourwright_render or tourwright_jobs. The description adds no format, validation, or sourcing detail beyond that, so the 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 states a specific verb (delete) and resource (a finished job) together with the exact artifacts removed: video, subtitles, poster, and manifest. The state precondition ('finished (done or failed)') further narrows the scope, so an agent can separate this from read-only siblings like tourwright_job or tourwright_jobs without opening the schema.

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?

It clearly says when the tool applies (a done or failed job) and when it does not (a queued or rendering job), which is the key gating decision. It does not name any alternative route for cleaning up a queued or rendering job, but no sibling offers one, so the gap is minor.

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