Skip to main content
Glama

Cancel Batch

cancel_batch
DestructiveIdempotent

Cancel queued tasks and terminate running shell process groups in a batch to stop work and free resources.

Instructions

Cancel queued tasks and terminate running shell process groups.

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": {
      "batch_id": "<batch_id>"
    },
    "name": "cancel_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
batch_idYes

Output Schema

NameRequiredDescriptionDefault
taskNo
errorNo
statusNo
resultsNo
batch_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructive=true, idempotent=true, openWorld=false, so the safety profile is covered. The description earns credit by adding real behavioral detail beyond that: it distinguishes soft cancellation of queued tasks from hard termination of running process groups, which tells the agent the blast radius. It stops short of saying what happens to partially completed work or whether termination is graceful.

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?

A single twelve-word sentence that front-loads the destructive action and then the two affected resource classes. No filler, nothing that repeats the title or annotations.

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

Completeness3/5

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

An output schema exists, so return-shape explanation is correctly omitted, and annotations carry safety semantics. What is missing for a destructive, hard-to-undo-adjacent operation is the outcome contract: whether cancellation is partial vs all-or-nothing, what happens to output already produced, and what state the batch ends in.

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 0% and there is one required parameter (batch_id) that the description never mentions, so nothing clarifies accepted id formats, behavior on unknown/expired ids, or whether the id must refer to a batch still active. The parameter is self-evident from its name, which limits the practical cost, but the description adds no meaning here.

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?

A specific verb ('Cancel') plus the affected resources ('queued tasks', 'running shell process groups') makes the effect concrete and distinguishable from execute/execute_batch/get_batch. It never explicitly ties this to the batch identified by batch_id, but the name and siblings make the scope inferable.

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

Usage Guidelines2/5

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

No statement of when to call this versus checking status with get_batch first, nor any prerequisite or caveat about cancelling an already-finished batch. The agent must infer timing (presumably only on queued/running batches) from the effect description alone.

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

Deploy Server

Other Tools