Skip to main content
Glama
Sign In
Archiware MCP

Archiware MCP

by mnott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

restore_version

Restore one file version found by find_file to a P5 host directory from the cheapest source or a specified location. Preview conflicts and confirm with planId to execute.

Instructions

Restores ONE version found by find_file into a directory on the P5 host, from the cheapest place automatically (disk-tar: extracted from the tar; tape-library: P5 restore; tar on tape in library: tar restored to scratch then extracted) or from the location id given as 'from'. A version that is only on offline tapes is refused with 'insert '. Without confirm only the PLAN: host, absolute destination, source location chosen (and alternatives), bytes, free space, tree preview and every destination file that already exists (size+mtime now vs restored), conflict policy and a planId. confirm:true must pass that planId; if the destination or conflicts changed it refuses and shows the new plan.

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": {
      "path": "<path>",
      "version": "<version>"
    },
    "name": "restore_version"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoDefault: restore folder <restoreRoot>/<YYYYMMDD-HHMMSS>/<original path>. 'original' = original location (explicit choice; refused inside a syncRoot without forceSync). Any other absolute directory gets the original path placed below it
fromNolocation id from find_file instead of the cheapest
pathYesfull path as find_file shows it
clientNo
planIdNoplanId printed by the preview; required with confirm:true. A changed destination or new conflicts make the call refuse and show the new plan
confirmNoMust be true to actually run; without it only the plan/commands are returned
versionYesversion key '<mtime>-<size>' from find_file
forceSyncNoAllow to:'original' inside a configured syncRoot
onConflictNoWhat to do when a destination file exists: refuse (default), rename (<name>.restored-YYYYMMDD; not for P5 volume restores) or overwrite

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and does so: it describes the source-selection ladder (disk-tar, tape-library, tar-on-tape via scratch), the dry-run default, the exact refusal cases (offline tape, stale planId, changed destination/conflicts), and what the plan contains. That is unusually rich behavioral disclosure for 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.

Conciseness4/5

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

The plan-vs-confirm contract is front-loaded in the first clause and the dense parenthetical enumerations earn their space by explaining source fallbacks. Some sentences are long run-ons (the final sentence chains three failure conditions), which slightly hurts scanability.

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 9-parameter mutation tool with no annotations and no output schema, the description covers the workflow, safety gates and failure modes thoroughly. It is a bit thin on what exactly a successful confirmed restore returns, but the preview contents are enumerated so an agent knows what to expect.

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 already 89%, yet the description still adds meaning: it clarifies that 'from' overrides the automatic cheapest choice, that 'confirm' must be paired with the planId printed by the preview, and that conflicts trigger a re-plan rather than a partial write. It does not elaborate on 'client' or 'forceSync' beyond the schema, so not a 5.

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 names a specific verb and resource ('Restores ONE version') and anchors it to a sibling ('found by find_file'), plus the destination target (a directory on the P5 host). An agent can distinguish this from `restore`, `restore_archive` or `restore_volume` without opening any schema.

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 gives clear conditional guidance: source is chosen automatically from the cheapest location unless a location id is passed as 'from', and offline-only versions are refused with an 'insert <barcode>' message. The two-phase flow (preview first, then confirm with planId) is spelled out. It does not explicitly compare itself to the similarly named sibling `restore`, so a 4 rather than a 5.

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