Skip to main content
Glama
Archiware MCP

Archiware MCP

by mnott

container_backup

Backs up the P5 container cold: commits a pre-update image, saves it, stops the container, archives the compose directory, and verifies checksums. Requires confirm:true; restart:true restarts it.

Instructions

Cold backup of the P5 container (docker inspect/diff, commit to -pre-update, docker save, STOP the container, tar the compose dir, SHA256SUMS, verify). Leaves the container stopped unless restart:true. Refused while a job runs unless force. Requires confirm:true; without it the steps are listed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "container_backup"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNo
confirmNoMust be true to actually run
restartNoStart the container again afterwards

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full behavioral burden. It clearly discloses the side effects: the container is stopped, a pre-update image commit is made, files are tarred, checksummed, verified, and the container remains stopped unless restart:true. It omits details such as backup destination, required permissions, and failure behavior, but the major operational risks are surfaced.

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?

The definition is front-loaded and compact: a single purpose statement with a parenthetical execution sequence, followed by the stop/restart and safety constraints. It is dense but every clause carries operational meaning, so it stays efficient.

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 tool with no annotations or output schema, the description covers the important invocation behavior and side effects. It still does not say where the backup is written or what a successful result returns, which are meaningful gaps for a backup operation.

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

Parameters5/5

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

All three parameters are given operational meaning: confirm gates execution and causes a dry-run listing when absent, restart reverses the stopped state, and force overrides the job-lock refusal. The description adds force semantics not present in the schema and clarifies the effects of the other two.

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 opens with a specific verb and resource, "Cold backup of the P5 container," and enumerates the concrete operations (docker inspect/diff, commit, save, stop, tar, checksum, verify). This is enough to separate it from container lifecycle siblings such as container_start or container_update; an agent can tell this is the backup operation.

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 important invocation conditions: confirm:true is required, force overrides the running-job refusal, and restart controls whether the container is left stopped or started again. It does not explicitly route the agent to p5_config_backup or other alternatives, so it stops short of full when-to-use guidance.

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