Skip to main content
Glama
Sign In
Archiware MCP

Archiware MCP

by mnott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

restore

Preview recovering a single backed-up path at a chosen backup version, including destination, conflicts, and exact P5 GUI steps; confirmation creates only the destination folder.

Instructions

Restore plan for ONE path at a chosen BACKUP version (at = a version start from restore_options). P5's CLI and REST cannot select a single path of a backup version (RestoreSelection addentry takes only archive handles; addfromvolume restores a whole volume), so this tool never starts a P5 job: it returns the full preview (source version, volume(s) with barcode and location, destination, bytes, free space, bounded tree, existing destination files, conflict policy, planId) and the exact P5 GUI steps (Restore > Backup > client > path > backup date > restore to the destination folder). confirm:true with the planId only creates the destination folder. Data comes from the catalogue copy of the backup index when the client is indexed, else P5's SQLite index. For archive entries use restore_archive; a whole volume is restore_volume.

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": {
      "at": "<at>",
      "path": "<path>"
    },
    "name": "restore"
  }
}

Input Schema

NameRequiredDescriptionDefault
atYesVersion chosen from restore_options (its `start`, YYYY-MM-DD HH:MM)
toNoAbsolute directory in the P5 container; the original path is placed below it. Default: <restoreRoot>/<YYYYMMDD-HHMMSS>
pathYesOriginal absolute path (file or folder) as backed up
clientNoP5 client (default localhost)
planIdNoplanId printed by the preview; required with confirm:true. A changed destination or new conflicts make the call refuse and show the new plan
confirmNoWith planId: prepare the destination folder
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.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it states this never starts a P5 job, that confirm:true with a planId only creates the destination folder, that the call refuses and re-plans if the destination changes or new conflicts appear, and where the index data comes from. That is exactly the behavioral context an agent needs for a mutation-adjacent planning 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?

It is front-loaded with the core purpose and the alternative-routing sentence is well placed. The parenthetical about RestoreSelection addentry and addfromvolume is internal justification that could be shortened, but it does explain why no job is started, so the length is mostly earned.

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 an 8-parameter tool with no output schema, the description enumerates the full preview payload (source version, volumes, destination, bytes, conflicts, planId) and the GUI steps, covering what would otherwise be unknown. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so every parameter including enum values is already documented in the schema. The description reinforces `at`, planId, and confirm, but adds no syntax, format, or constraint detail beyond what the schema already states, so the baseline 3 applies.

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 gives a specific verb, resource, and scope: build a restore plan for ONE path at a chosen backup version. It explicitly differentiates itself from restore_archive and restore_volume in the final sentence, so an agent can route correctly without opening other schemas.

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?

It names the alternatives and the conditions that select them ('For archive entries use restore_archive; a whole volume is restore_volume') and points to restore_options for choosing `at`. It also clarifies when confirm should be used and what changes force a re-plan.

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