duplicacy-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DUPLICACY_EXPORTER_URL | Yes | Duplicacy Prometheus exporter URL |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_backup_historyA | Details of the last completed run of one Duplicacy snapshot: duration in seconds, files total and new, bytes uploaded and new, new chunks, revision, exit_code (0 = success, null = unknown). The exporter keeps only the last run, so this is not a list of past runs. Get valid IDs from list_snapshots. |
| get_backup_overviewA | 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. |
| get_backup_statusA | Current state and last-run details of one Duplicacy snapshot: running, exit_code (0 = success, null = unknown), last_success (RFC 3339, UTC), duration in seconds, files and bytes. A snapshot backed up to several storage targets or from several machines returns one row each. Get valid IDs from list_snapshots. For a health check across all backups use get_backup_overview instead. |
| get_prune_statusA | Whether a prune is running and when the last one succeeded (RFC 3339, UTC), per storage target and machine. An unknown storage_target is an error that lists the known ones. |
| get_storage_usageA | Size in bytes and chunk count of each storage, and how many revisions each snapshot keeps, as the exporter's storage poller last saw them. Empty, with a note, when the poller is off. |
| list_snapshotsA | Every snapshot ID, storage target and machine the exporter reports, sorted. backups lists each snapshot_id, storage_target and machine combination. Call this first to get valid values for the snapshot_id, storage_target and machine arguments of the other tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| All backup statuses | Every backup the exporter reports, one entry per snapshot_id, storage_target and machine, sorted: running, exit_code (0 = success, null = unknown), last success (RFC 3339, UTC) and last-run sizes. |
| Backup progress | Live progress of every backup: running, speed in bytes per second, progress_ratio from 0 to 1, progress_percent from 0 to 100, chunks uploaded and skipped. |
| Exporter health | Whether the duplicacy-exporter answers: status ok, degraded or unreachable, with the endpoint and HTTP code. |
TDQS
Scored across 6 tools
The tools mostly have clearly distinct monitoring purposes: overview is an aggregate health check, status is one snapshot, and history is the last completed run. The main ambiguity is between get_backup_status and get_backup_history, since both return last-run details, but the descriptions explicitly distinguish current state versus completed-run history.
All tool names follow a consistent snake_case verb_noun pattern: get_backup_history, get_backup_overview, get_backup_status, get_prune_status, get_storage_usage, and list_snapshots. The use of list_snapshots instead of get_snapshots is still a conventional verb_noun choice and does not break readability.
Six tools is well-scoped for a read-only Duplicacy backup monitoring server. Each tool maps to a distinct monitoring concern: discovery, per-snapshot status/history, aggregate health, prune status, and storage usage.
The surface covers the core monitoring workflows: discovering snapshots, checking backup health, inspecting a snapshot, reviewing last-run history, prune status, and storage usage. Minor gaps exist, such as no explicit standalone tool for listing storage targets or machines, but list_snapshots exposes those values and agents can work around this.