Skip to main content
Glama
Archiware MCP

Archiware MCP

by mnott

job_cancel

Cancel a running or waiting backup job and verify its resulting state. Set confirm:true to send the cancellation; otherwise preview the requests without executing.

Instructions

Cancels a running OR waiting job via the REST API (falls back to nsdchat if the job stays active) and reports the job state afterwards. Requires confirm:true; without it only the requests that WOULD be sent are returned.

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": "job_cancel"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesJob id
confirmNoMust be true to actually run

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and discloses meaningful behavior: the primary REST path, a fallback to nsdchat if the job stays active, and a state report afterwards. The dry-run-without-confirm semantics are also spelled out, though it doesn't say what happens on cancellation failure or whether the action is reversible.

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 tight sentences with zero filler, front-loading the action and scope, then the execution mechanism, then the confirm precondition. Every clause contributes information an agent needs.

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 mutation tool with no output schema, the description covers the mechanism, the fallback, the safety gate, and the post-action reporting. Remaining gaps are minor: failure modes and the shape of the returned job state are unspecified.

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 coverage is 100% and both parameters are already documented in the schema (id and confirm with "Must be true to actually run"). The description reinforces the confirm behavior and its consequence (preview only) but adds no new format or constraint detail beyond the schema.

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 and resource ("Cancels a ... job") and narrows scope to running OR waiting jobs, which tells an agent exactly which job states it applies to. It does not differentiate itself from the sibling stop_job, so the agent must guess which of the two to call for a running job.

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

Usage Guidelines3/5

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

Gives a clear precondition for execution (requires confirm:true, otherwise a dry-run preview is returned), which is real when-to-use guidance. However, it offers no comparison to stop_job or job_history, leaving the choice among sibling job-control tools to inference.

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