Skip to main content
Glama

Cancel a job and tear down its machine

cancelJob
DestructiveIdempotent

Cancels the job and tears down its machine. Symbioza stops your workload and collects the files it has written to /workspace/artifacts/ before the machine is released, within a short bounded window; the copies Symbioza already took during the run are kept even if that last collection cannot finish, getArtifact returns them marked recovered, and a file that could not be collected is listed as not delivered. If we confirm the stop, you are charged for measured time up to then, and never for more than a minute past the moment you asked; if the machine cannot be reached, you are charged only up to the moment you asked. Never more than your spending limit. getStatus shows the request as cancelRequestedAtMs at once (cancelState requested), and the job reads cancelled only once the stop is CONFIRMED (cancelEnforcedAtMs set, cancelState enforced); if the stop cannot be proven the job reads lost with cancelState unconfirmed and the last evidence in cancelStopDetail. Pass an optional reason (short human-readable text, truncated at 500 chars) to record WHY; it is stored opaquely and returned by getStatus as cancelReason so a client can see why a job was cancelled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoOptional human-readable reason for the cancel, surfaced to the client via getStatus.cancelReason. Truncated at 500 chars; stored opaquely, never parsed.
authKeyNoUsually omit this. The customer door — the OAuth-signed-in HTTPS connector at https://symbioza.dev/mcp — authenticates the session itself, so no key is passed per call. Only a self-hosted or test transport passes a key here.
executionIdYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
reasonNo
statusNo
cancelledYes
executionIdYes
cancelReasonNo
deadlineAtMsNo
alreadyTerminalNo
workloadFinishedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the destructive/idempotent annotations by disclosing the cancellation state machine (cancelRequestedAtMs -> cancelEnforcedAtMs -> cancelled/lost), artifact collection guarantees, and precise billing semantics. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core action is front-loaded, which is good, but the remainder is a dense, unbroken wall of text mixing state transitions, billing, and artifact rules. The content is valuable, yet a list or sentence breaks would make it scannable without losing information.

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 destructive, open-world job-cancellation tool with an output schema, the description covers the lifecycle, timing, billing, and reason handling an agent needs before invoking it. Nothing material is missing.

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

Parameters4/5

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

Schema coverage is 67% and already documents reason and authKey, but the description reinforces reason's meaning by tying it to getStatus.cancelReason and its 500-char opaque storage. executionId remains undocumented in both places, keeping this just under a 5.

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?

States a specific verb and resource ('Cancels the job and tears down its machine') and names the sibling tools it interlocks with (getStatus, getArtifact). An agent can distinguish this from submitJob or getStatus without opening a 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 frames when this tool is the right action and points to getStatus and getArtifact as the ways to observe the outcome. It stops short of an explicit when-not or cost/benefit comparison against alternatives, so it is strong context rather than full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.