Skip to main content
Glama
mandalacomputer

Mandala Computer

Official
by mandalacomputer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Restore a snapshot

restore_snapshot
Destructive

Revert a computer's disk to a saved snapshot, overwriting current data and discarding changes made since it was captured. Check restore availability before use.

Instructions

Put a snapshot back onto the computer it came from, discarding everything on that disk since. Check restore_available in list_snapshots first: where it is false, the snapshot's usable copy is on a host its computer has left, and a restore is refused while clone_snapshot still works. Refused on an orphaned snapshot — clone_snapshot is what works there. It leaves the computer RUNNING whatever state it was in: restoring a stopped one boots it, which is a start like any other and is charged. A disk snapshot comes back to a fresh boot, a memory one to the captured session, and either way a suspended session the computer was holding is discarded with the disk it was saved against.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmYesMust be true. This overwrites the source computer's current disk.
snapshot_idYes
idempotency_keyNoOptional. Omit it on a first attempt: a fresh key is sent for you, and an answer that is lost names it. Pass the key such an answer named to send the SAME call again without it being done twice — the platform answers with the first call's result, or says it is still running. After a 5xx that names no operation_id, send the same call again with the same key: nothing may have been done, and the platform either carries it out (the key was released) or answers idempotency_outcome_unknown. After idempotency_outcome_unknown, or a 5xx that names an operation_id, the key is spent (resending with it answers idempotency_outcome_unknown), and the call may still be under way: read its operation first (get_operation with the operation_id the error named, or list_operations with the key), wait while it is pending or running and do not resend meanwhile, and send the call with a new key (or none) only once the operation is final as failed or not found AND get_computer shows the step did not happen. Keys last 24 hours; the same key with different arguments is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations provide only destructiveHint=true, and the description goes well beyond it: it discloses refusal semantics, that the computer is left RUNNING with a startup charge for a stopped one, the differing restore behavior of disk vs memory snapshots (fresh boot vs captured session), and that a suspended session is discarded. This is exactly the kind of side-effect and billing context an agent needs before a destructive call.

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-loads the core action and its destructive consequence, then handles refusals, alternatives, and post-restore state in a tight sequence. Dense but every sentence adds a distinct fact; slightly long, which keeps it from a 5.

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 mutation tool with no output schema, the description covers the preconditions, refusal paths, alternatives, resulting power/session state, and billing implication. An agent has enough to decide correctly and anticipate outcomes.

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

Parameters3/5

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

Schema description coverage is 67%: confirm is self-documented and idempotency_key carries an extremely detailed inline explanation. snapshot_id has no schema description, and the prose only implies the source-computer relationship rather than defining the parameter. With most parameter meaning already in structured fields, this is a baseline 3.

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 ('Put a snapshot back onto the computer it came from') and immediately scopes it with the destructive consequence ('discarding everything on that disk since'). It clearly distinguishes the operation from clone_snapshot, which it names as the copy-preserving alternative.

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 preconditions ('Check `restore_available` in list_snapshots first'), the refusal conditions (usable copy on a host the computer left; orphaned snapshot), and routes the agent to clone_snapshot as the working alternative in those cases. Nothing is left to inference.

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

Deploy Server

Other Tools