@jam-jam/convert-mcp

Cancel an audio analysis job

jj_queue_cancel_job

Cancel a queued audio analysis job by ID. The credit is refunded only if analysis has not completed; requests fail with 409 once the job can no longer be stopped.

Instructions

Cancels one job of the caller's own audio queue (DELETE /queue/{id}). The unit is refunded ONLY if the analysis had not completed yet; during alignment, the analysis already delivered is kept, without refund. 409 when the job can no longer be cancelled. Needs the audio:write scope. Only call it when the user asked to stop that job.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "jj_queue_cancel_job"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Job id returned by jj_audio_analyze or jj_queue_list.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.2Nov 13, 2026

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations present, the description carries the full burden and does so well: it discloses refund behavior (refunded only if analysis had not completed), the alignment edge case where delivered analysis is kept without refund, the 409 conflict condition, and the required audio:write scope. These are exactly the consequences an agent needs before invoking a destructive-ish operation.

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?

Three compact sentences, front-loaded with the action and endpoint, then cost consequences, then the error/scope caveats, then the usage rule. 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.

Completeness5/5

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

For a one-parameter mutation with no output schema, the description covers outcome semantics, failure mode, authorization scope, and when to use it. Nothing an agent needs in order to call it safely 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?

There is a single parameter with 100% schema description coverage, which already says the id comes from jj_audio_analyze or jj_queue_list. The description adds only the constraint that the job belongs to the caller's own queue, so the schema does the heavy lifting — baseline 3.

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

Purpose4/5

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

States a specific verb (cancels) and resource (one job of the caller's own audio queue), plus the underlying endpoint DELETE /queue/{id}. It implicitly scopes itself to audio-queue jobs, distinguishing it from the sibling cancel tools for mastering, stems, and AI music, though it never names those siblings explicitly.

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?

Gives a clear usage condition: "Only call it when the user asked to stop that job," which guards against speculative cancellation. It also notes the 409 case when the job can no longer be cancelled, but does not explicitly route to sibling alternatives such as the other cancel tools.

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