Skip to main content
Glama
roman-zaglauer

OctoBot MCP Server

by roman-zaglauer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

restart_octobot

Restart OctoBot safely for maintenance or recovery, with a confirmation gate and automatic refusal while jobs are active.

Instructions

Trigger a full OctoBot process restart. Confirm-gated (ADR-0003/ADR-0010).

This is the first tool in this project that can never be made fully safe or graceful (ADR-0010) -- stated plainly, not softened. OctoBot's own restart mechanism (GET /wait_reboot?reboot=true, confirmed against Drakkar-Software/OctoBot source) is an ABRUPT kill-and-re-exec, never the graceful OctoBot.stop() shutdown -- no task cancellation, no explicit order handling occurs before the kill. Exchange-side orders are reconciled from the exchange on reboot (OctoBot's own designed, changelog-hardened behavior, even for live trading), but the exact duration of the unmonitored window during the restart itself is UNVERIFIED (open question #14) and this tool cannot measure or bound it.

Check order (cheapest/safest first, ADR-0010 Decision 4), so a call that's about to be refused never makes an unnecessary live call:

  1. confirm flag. If not exactly true, no OctoBot call is made at all -- this scrapes the currently selected profile's profile_type (the same Tier-B scrape list_profiles/get_profile use) ONLY to build a risk-scaled reason string, then returns require_confirmation's structured refusal (a normal return, not an error). The reason string is more detailed/cautious when profile_type is LIVE -- or the scrape itself is inconclusive, which fails toward the MORE cautious message, never toward silently allowing (ADR-0010 Decision 3) -- than when it is SIMULATOR. This is the SAME confirm=true gate regardless of profile_type: never a hard, non-bypassable block for LIVE profiles (see ADR-0010 for why an earlier draft's hard refusal didn't hold up against OctoBot's own changelog/source evidence that restart-during-live-trading is a designed, hardened scenario).

  2. JobStore active-job check. Refuses outright -- a structured non-exception return, naming every job -- if any backtest/ data_collection job is queued/running (both of octobot_mcp.jobs.JobStore's independent locks checked, ADR-0007's "two independent locks" precedent). Never warns-and-proceeds or auto-cancels (ADR-0010 Decision 4 explicitly rejects both): the caller must cancel_job or wait for completion first.

  3. The one live call. GET /wait_reboot?reboot=true. HTTP 200 -> {"restart_triggered": true, "message": ...} (below). Anything else raises RestartFailedError -- never a false "triggered" result.

Residual risk, accepted (ADR-0010): a job could start in the narrow window between check 2 and the actual reboot call -- accepted given this project's single-MCP-client assumption (A3), not engineered away.

Output on success: {"restart_triggered": true, "message": "OctoBot restart scheduled (~2s delay); the server will be briefly unreachable. Call wait_for_octobot_ready() next, then re-confirm the active profile via get_profile()/list_profiles() before starting a backtest."}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNo

Schema Changelog

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

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and fully discharges it: it discloses abrupt kill-and-re-exec, lack of graceful shutdown, the unverified downtime window, exchange-side order reconciliation, refusal behavior, and residual race risk. This goes well beyond a generic 'restarts the bot' statement.

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

Conciseness4/5

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

The description is front-loaded with the core purpose and is well structured with a numbered check order. It is verbose, and some internal references (ADR-0010, open question #14, A3) are tangential for tool invocation, but the length is largely justified by the risk of an abrupt restart.

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?

Despite no output schema, it documents the success response, error path, refusal return, and recommended follow-up (wait_for_octobot_ready, then re-confirm profile). It also covers edge cases such as inconclusive profile scrapes and the job-start race, making the definition complete for correct invocation.

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

Parameters5/5

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

Schema coverage is 0%, but the description fully compensates by explaining that confirm is a strict boolean gate: if not exactly true, no OctoBot call is made and a structured refusal is returned. It also clarifies that the same confirm=true gate applies for LIVE and SIMULATOR profiles, adding behavioral meaning far beyond the schema's bare boolean field.

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 opening sentence states the exact action and resource: 'Trigger a full OctoBot process restart.' This is distinguished from safety-related siblings like wait_for_octobot_ready by explicitly framing itself as the restart trigger and referencing the subsequent readiness check, so an agent can tell it apart.

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

Usage Guidelines5/5

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

The description gives an explicit ordered check: confirm must be exactly true, active jobs must not be queued/running, and only then is the live call made. It states hard refusals instead of warn-and-proceed, and explicitly requires the caller to cancel_job or wait before restarting, providing clear when-to-use and when-not-to-use conditions.

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