Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

cancel_job

Cancel a queued or running backtest job, or retrieve its existing status when already finished. Provides a safe, idempotent way to stop jobs without data loss.

Instructions

Cancel a job, or report its existing terminal state if already finished.

Not confirm-gated (ADR-0003's explicit non-gated list): reversible, no data loss. Idempotent: cancelling an already-terminal job just returns its existing status, never an error.

This milestone implements only the state-machine transitions that don't require calling OctoBot (no HTTP/Socket.IO call happens here, or anywhere else in this module):

  • queued (waiting on backtest_execution_lock, never started): cancelled directly.

  • running: only sets cancel_requested = True on the record. Milestone 8's watcher loop is what will actually notice the flag, tell OctoBot to stop, and transition the record to cancelled once that's confirmed -- this tool deliberately does NOT fabricate an immediate state="cancelled" for a running job, since nothing here is actually stopping it.

Raises JobNotFoundError for an unknown job_id (same as get_job_status).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully covers behavioral expectations: idempotency, no data loss, not confirm-gated, no HTTP/Socket.IO call, and the important limitation that a running job only gets cancel_requested set rather than an immediate cancelled state. It also discloses the JobNotFoundError behavior.

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?

The description is long but every sentence earns its place; it is front-loaded with purpose and safety and uses bullets for state-specific behavior. The structure makes complex milestone-specific behavior easy to parse.

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?

Given no annotations and no output schema, the description is remarkably complete: it covers purpose, idempotence, side effects, state transitions, async behavior, and error conditions. Nothing needed for correct invocation or expectation-setting 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?

The schema only defines job_id as a string with zero description coverage, so the description must carry the burden. It adds meaning by explaining how unknown job_id values are handled and referencing get_job_status for the same error behavior, though it could further clarify where valid job IDs come from.

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 opens with a clear verb and resource: 'Cancel a job, or report its existing terminal state if already finished.' It distinguishes the tool's behavior across job states and separates it from siblings like get_job_status and cancel_order by describing its state-transition scope.

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 states this tool is for canceling jobs and describes what happens for queued vs running jobs, giving an agent a solid basis for when to invoke it. It does not explicitly enumerate alternatives or exclusions, but the intended context is unambiguous.

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

Install Server

Other Tools