duplicacy-mcp

Overview Schema Source Related Servers Discussions Admin

Backup health overview

get_backup_overview

Read-onlyIdempotent

Check the health of all Duplicacy backups in one call, returning a status verdict for each snapshot, storage target, and machine to show whether backups are OK, running, stale, or failed.

Instructions

Health of every backup in one call. Each snapshot, storage target and machine gets a verdict: ok, running, stale (last success older than max_age_hours), never (no successful run) or failed (last exit code not 0), with a reason and the age of the last success. status is ok, attention or no_data. Use this to answer "are my backups OK?"; use get_backup_status for the details of one snapshot.

Input Schema

Name	Required	Description
`machine`	No	Only this machine, exactly as list_snapshots returns it in machines, for example "nas". Omit for all.
`snapshot_id`	No	Duplicacy snapshot ID, exactly as list_snapshots returns it, for example "photos".
`max_age_hours`	No	A backup whose last success is older than this many hours is stale. Default 26, which suits daily backups.
`storage_target`	No	Only this storage target, exactly as list_snapshots returns it in storage_targets, for example "b2". Omit for all.

Output Schema

Name	Required	Description
`counts`	Yes
`status`	Yes	ok when every backup is ok or running, attention when any is stale, never ran or failed, no_data when the exporter reports no backups
`backups`	Yes
`summary`	Yes
`exporter`	Yes
`checked_at`	Yes	When the overview was computed, RFC 3339 in UTC
`max_age_hours`	Yes	A backup whose last success is older than this is stale

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.1Oct 29, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare the tool as read-only, idempotent and non-destructive. The description adds meaningful behavioral context: the verdict categories (ok, running, stale, never, failed), what stale means in relation to max_age_hours, and the overall status values (ok, attention, no_data). It does not discuss cost or latency, but the added output semantics are substantive.

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 description is dense and front-loaded: the main purpose is stated first, followed by verdict semantics, status values, and the sibling routing. Every sentence carries information useful to an agent.

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?

With an output schema, fully documented parameters and annotation coverage, the description only needs to supply purpose, usage and verdict meaning. It does so completely, including a clear alternative for a different use case.

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 description coverage is 100%, so all four parameters are already documented in the schema, including max_age_hours and its default. The description states the stale rule but does not add syntax or format details beyond what the schema provides, so the baseline of 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 description states a specific resource and scope: it returns the health of every backup in one call, covering each snapshot, storage target and machine. It also distinguishes itself from get_backup_status, so an agent can identify it without opening the schema.

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 explicitly names the question this tool answers ("are my backups OK?") and directs the agent to get_backup_status for details about a single snapshot. That is explicit when-to-use and alternative routing.

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

Deploy Server