instabox-mcp

Start, stop, pause or resume a machine

instabox_machine_power

Change a machine's power state by starting, stopping, suspending, or resuming it; supports clean shutdown and resuming paused workloads.

Instructions

Change a machine's power state. start: boot a stopped machine (resumes a paused one). stop: shut down; processes end, files kept (a paused machine cannot be stopped: resume or delete it). suspend: pause, keeping memory and running processes. resume: continue a paused machine where it left off. A machine runs one operation at a time (409 operation_conflict otherwise). Commands, files and SSH wake an idle-paused machine automatically, but a machine you paused or stopped stays off until you start/resume it.

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>",
      "action": "<action>"
    },
    "name": "instabox_machine_power"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Machine ID (m_...) or its unique name
`wait`	No	Wait for the operation to finish before returning (default true)
`action`	Yes
`stopTimeoutSeconds`	No	stop only: seconds to wait for clean shutdown before forcing off (default 60)
`waitTimeoutSeconds`	No	Max seconds to wait (default 300)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: processes end on stop but files persist, suspend retains memory and running processes, and only one operation may run per machine (409 operation_conflict otherwise). The one gap is that stop terminating processes sits in mild tension with destructiveHint=false, so an agent gets no explicit confirmation about whether in-flight work is lost permanently.

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?

Front-loaded with the one-line purpose, then structured as per-action clauses, followed by the conflict rule and the auto-wake caveat. Dense but waste-free; the single long paragraph costs a little scannability for an agent parsing the action list.

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 state-machine tool with no output schema, it covers every decision an agent must make: which action to pick, what each action preserves or destroys, the blocked transition, and the 409 conflict condition. The wait semantics are handled by the schema, so nothing essential 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 80% and the schema already documents id, wait, and both timeout parameters. The description's real contribution is defining the four action enum values semantically, which the schema leaves as bare strings — a meaningful addition. It says nothing about wait/stopTimeoutSeconds/waitTimeoutSeconds, but those are already covered in the schema.

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 ('Change a machine's power state') and then enumerates all four actions with their individual effects. It is clearly separable from siblings like instabox_create_machine, instabox_delete_machine, and instabox_update_machine, which touch lifecycle rather than runtime state.

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?

Gives explicit when-to-use for each action and names the correct alternative when one is blocked: a paused machine 'cannot be stopped: resume or delete it', routing the agent to instabox_delete_machine. It also explains the auto-wake boundary — implicit wake for idle-paused machines versus explicit start/resume for user-paused or stopped ones.

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