Skip to main content
Glama
Archiware MCP

Archiware MCP

by mnott

governance_report

Generates a read-only per-plan report of an Archiware P5 backup server, covering events, tasks, retention and last-run results, and flags unused or risky items with reasons, recommendations and apply actions.

Instructions

Read-only. P5 explained in plain words, per backup plan: enabled, events (pool, level, frequency in words, next run), tasks and folders, last run per task with result, retention; flags with a one-line reason and a recommendation (keep / merge / disable / delete): never ran or only failed, disabled for long, folders in several plans, tasks on folders that do not exist, pools without (appendable) volumes, events whose pool has no tape in the library; plus server-wide settings (maintenance restart window and what it waits for, plan stop/cancel times, mail). Each deletable/disable-able flag carries an apply item for governance_apply.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it does declare 'Read-only' up front so the agent knows there are no side effects. It also discloses the analytical behavior — it flags problems with a one-line reason and a keep/merge/disable/delete recommendation — which goes well beyond a simple read. It does not mention cost or latency for what is likely a full inventory scan, which is the main remaining gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The safety qualifier 'Read-only.' is correctly front-loaded, but the remainder is a single run-on sentence with semicolon-chained lists that is hard to parse at a glance. Every listed item is substantive content, so nothing is padding, yet the density and unexplained 'P5' token hurt scannability.

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?

There is no output schema, so the description must describe return values itself, and it does so thoroughly: contents, flag categories, per-flag reasons and recommendations, and the `apply` linkage to governance_apply. For a zero-parameter report tool this is close to complete, with the undefined 'P5' term and absent output format/structure as the only shortfalls.

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?

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool is 4. The description's 'per backup plan' phrasing clarifies that plan granularity is inherent in the output grouping rather than a filter the caller supplies, which prevents a false expectation of a plan argument.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Read-only' and then enumerates exactly what the report contains: per-plan enabled status, events, tasks and folders, last run results, retention, plus server-wide settings. That is far more specific than the bare name 'governance_report'. It loses a point because the core label 'P5' is never defined, so an agent unfamiliar with the domain cannot fully anchor the tool's subject.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit 'use this when' statement and no comparison against siblings like plans, pools, or volumes. The one routing signal is implicit: flags carry an `apply` item for governance_apply, which tells the agent this is the read/preview side and that mutations belong elsewhere. Useful but indirect guidance.

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