instabox-mcp

Delete a snapshot

instabox_delete_snapshot

Destructive

Permanently delete a snapshot by providing its ID and exact ID or name as confirmation; machines already created from it remain unaffected.

Instructions

PERMANENTLY delete a snapshot. Machines already created from it are not affected. confirm must be the snapshot's exact ID or name (server-checked). Needs images:delete.

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>",
      "confirm": "<confirm>"
    },
    "name": "instabox_delete_snapshot"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Snapshot ID (sn_..., or im_... for older ones)
`confirm`	Yes	The snapshot's exact ID or name, repeated to confirm

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and non-idempotent, so the baseline is met; the description adds genuinely useful context beyond them: permanence, the fact that derived machines survive, the server-enforced confirm check, and the required images:delete permission. It does not address retry-after-partial-failure or what happens if the snapshot is in use, which would round out a mutation tool.

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?

Three short sentences, zero filler, with the most consequential fact (permanent deletion) in the first position. Every sentence carries distinct information: danger, blast radius, confirmation rule, permission.

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 destructive tool with strong annotations and no output schema, this covers nearly everything an agent needs: intent, danger, side effects, confirmation protocol, and authorization. It omits only edge-case behavior such as in-use snapshots or confirm-mismatch errors.

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 100%, so the baseline is 3, but the description adds that `confirm` is server-checked against the snapshot's exact ID or name—an enforcement detail the schema only weakly conveys with 'repeated to confirm'. It adds minor value on top of an already well-documented 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 ('PERMANENTLY delete a snapshot'), with the destructive adverb front-loaded. The resource name makes it trivially distinguishable from instabox_delete_machine and instabox_create_snapshot without inspecting schemas.

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?

Gives a clear precondition ('Needs images:delete') and a side-effect scope that matters for decision-making ('Machines already created from it are not affected'), which tells the agent this is safe with respect to existing machines. It never explicitly names an alternative or states when not to use it, so it stops short of the top score.

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