Skip to main content
Glama
Sign In
Archiware MCP

Archiware MCP

by mnott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

ensure_done

Verifies scheduled backup runs since a given date, lists failed, stopped, missing or waiting tasks, and optionally re-runs only failed/stopped/missing tasks once with confirmation.

Instructions

Checks that every scheduled run since since (YYYY-MM-DD or YYYY-MM-DDTHH:MM, default 24 h) produced a successful job for every enabled task of its plan; lists failed, stopped, missing and still-waiting tasks. rerun:true with confirm:true re-runs exactly the failed/stopped/missing tasks once (run_tasks_once, same pool); never cancels anything. mail:true sends the report to operatorMail through the host MTA (independent of P5's own mail). Call it after the nightly window.

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": "ensure_done"
  }
}

Input Schema

NameRequiredDescriptionDefault
mailNo
rerunNo
sinceNo
confirmNoMust be true to actually run; without it only the plan/commands are returned

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4.4/5.0
Behavior4/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 substantial work: reruns are limited to exactly the failed/stopped/missing tasks, run once, and nothing is cancelled. It also discloses that mail goes to operatorMail via the host MTA independently of P5's own mail. Permissions required and idempotency of repeated reruns are not stated.

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-loaded with the check semantics, then the rerun and mail modes, then the timing hint. Sentences are densely packed with param-tagged clauses (`rerun:true`, `mail:true`) that read efficiently, though the single long paragraph is heavier than necessary.

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 four-parameter tool with no annotations and no output schema, the description covers what is checked, what is reported, what the mutating path does, and mail routing. Return shape details (report format, field names) are unspecified, which is the main remaining gap.

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?

Schema coverage is only 25% (just `confirm`), so the description must compensate, and it does: it documents the `since` format and default (24 h), the rerun/confirm pairing, and the mail delivery target. All four parameters gain meaning beyond their bare boolean/string types.

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?

Uses a specific verb and resource: verifies that every scheduled run since `since` produced a successful job for every enabled task, and enumerates the failure categories it surfaces (failed, stopped, missing, still-waiting). It also implicitly differentiates from sibling `run_tasks_once` by saying reruns use that same pool, so an agent can distinguish check from action.

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 explicit timing guidance ("Call it after the nightly window") and gates the mutating path behind rerun:true + confirm:true, plus a clear exclusion ("never cancels anything"). It does not compare against `health`, `job`, or `dryrun_plan`, so the agent must infer which diagnostic to pick, keeping it below 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