What can you do with this server?

Based on the provided schema, you can query Duplicacy backup metadata from the exporter through an MCP client. * Get the last backup run details for a specific snapshot: files, bytes, duration, exit code. * Get the current backup status for a specific snapshot. * Get prune operation status, optionally filtered by storage target. * List all unique snapshot IDs known to the exporter. * Caveat: the schema annotations mark these query tools as non-read-only, destructive, and open-world, conflicting with the README's read-only claim; README tools like get_backup_overview and get_storage_usage are not present in this schema.

Which integrations are available for this server?

Integrates with a Prometheus exporter to monitor Duplicacy backup metrics, enabling the tracking of backup status, progress, health, history, and snapshot lists.

de en es ja ko ru zh

duplicacy-mcp

by GeiserX

Overview Schema Source Related Servers Discussions Admin

Remote

Features

Reads the metrics of duplicacy-exporter and serves them over MCP.
One call answers "are my backups OK?": get_backup_overview gives every backup a verdict (ok, running, stale, never, failed) with a reason.
Speaks MCP 2026-07-28 (server/discover, stateless requests) and every earlier revision down to 2024-11-05 (the initialize handshake) from the same binary, over stdio and Streamable HTTP. Clients that still use the old handshake keep working.
Read-only by design: every tool and resource only reads the exporter, so there is no read-only flag to set. Every tool carries readOnlyHint, a title, an output schema and structured results.
HTTP listens on 127.0.0.1:8080 by default. On any other address it refuses to start without a bearer token, rejects cross-origin browser requests and caps request bodies.
Ships as Go binaries for several platforms (GoReleaser), a Docker image and an npm wrapper.

Related MCP server: duplicati-mcp

Tools and resources

Tool	What it answers
`get_backup_overview`	Health of every backup in one call: verdict, reason, age of the last success. `max_age_hours` (default 26) sets when a backup is stale.
`list_snapshots`	Every snapshot ID, storage target and machine, for use as filter values.
`get_backup_status`	State and last-run details of one snapshot, per storage target and machine.
`get_backup_history`	The last completed run of one snapshot. The exporter keeps only the last run.
`get_prune_status`	Whether a prune is running and when the last one succeeded, per storage target.
`get_storage_usage`	Storage size and chunks, and revisions per snapshot, from the exporter's storage poller.

Resources: duplicacy://status, duplicacy://progress and duplicacy://health. Parameters and output fields are on Usage.

Install

The npm package runs the server over stdio; set DUPLICACY_EXPORTER_URL to your exporter.

Claude Code

claude mcp add --transport stdio --env DUPLICACY_EXPORTER_URL=http://localhost:9750 duplicacy -- npx -y duplicacy-mcp

Claude Desktop (claude_desktop_config.json) and Cursor (~/.cursor/mcp.json)

{
  "mcpServers": {
    "duplicacy": {
      "command": "npx",
      "args": ["-y", "duplicacy-mcp"],
      "env": { "DUPLICACY_EXPORTER_URL": "http://localhost:9750" }
    }
  }
}

VS Code (.vscode/mcp.json)

{
  "servers": {
    "duplicacy": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "duplicacy-mcp"],
      "env": { "DUPLICACY_EXPORTER_URL": "http://localhost:9750" }
    }
  }
}

Codex (~/.codex/config.toml)

[mcp_servers.duplicacy]
command = "npx"
args = ["-y", "duplicacy-mcp"]
env = { DUPLICACY_EXPORTER_URL = "http://localhost:9750" }

npm 12, pnpm and Bun skip install scripts, so the wrapper downloads and verifies the binary on first start. Versions up to 0.1.2 relied on the install script alone; with npm 12 run them as npx -y --allow-scripts=duplicacy-mcp duplicacy-mcp.

Docker (Streamable HTTP)

export MCP_AUTH_TOKEN=$(openssl rand -hex 32)
docker run -d -p 127.0.0.1:8080:8080 -e MCP_AUTH_TOKEN \
  -e DUPLICACY_EXPORTER_URL=http://duplicacy-exporter:9750 drumsergio/duplicacy-mcp:v0.1.2
claude mcp add --transport http duplicacy http://127.0.0.1:8080/mcp --header "Authorization: Bearer $MCP_AUTH_TOKEN"

The image listens on 0.0.0.0:8080 inside the container, so it will not start without MCP_AUTH_TOKEN (or MCP_ALLOW_UNAUTHENTICATED=true behind a reverse proxy that authenticates). Compose, a global npm install and a local build are in Getting started; every variable is in Configuration.

Documentation

Getting started: Docker Compose, npm, local build, first run
Configuration: environment variables, HTTP security, client config for stdio and HTTP
Usage: tools, parameters, output fields and resources
Development: testing with Inspector, credits, contributing
Related projects: the Duplicacy family, other MCP servers, registry listings

Part of the Duplicacy family: duplicacy-exporter, duplicacy-cli-cron, duplicacy-ha, duplicacy-container.

License

GPL-3.0-or-later

Available Tools

4 tools

get_backup_historyC

Destructive

Get the last backup details for a specific Duplicacy snapshot (files, bytes, duration, exit code)

Name	Required	Description	Default
`snapshot_id`	Yes	The snapshot ID to query history for

TDQS

C2.8/5.0

Behavior1/5

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

Annotation Contradiction: Description uses 'Get' implying read-only operation, but annotations mark destructiveHint=true without any warning about side effects or destructive behavior in the text.

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?

Appropriately concise, front-loaded with action verb, and parenthetically lists return fields efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Compensates for missing output schema by listing return fields, but fails to address the destructive annotation or explain what 'last backup' means versus current status.

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?

With 100% schema description coverage, meets baseline; description implies the snapshot parameter by mentioning 'specific Duplicacy snapshot' but adds no additional semantic context beyond schema.

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?

Clearly states it retrieves last backup details with specific fields (files, bytes, duration, exit code) for Duplicacy snapshots, though doesn't differentiate from sibling get_backup_status.

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

Usage Guidelines2/5

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

Provides no guidance on when to use versus alternatives or when not to use.

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

get_backup_statusB

Destructive

Get the current backup status for a specific Duplicacy snapshot

Name	Required	Description	Default
`snapshot_id`	Yes	The snapshot ID to query status for

TDQS

B3.1/5.0

Behavior2/5

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

Mentions 'Duplicacy' for domain context but critically fails to explain why a 'get' operation has destructiveHint=true, which is highly unexpected and risky.

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?

Single sentence, front-loaded with action and target, no redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a single-parameter tool but gaps remain around the destructive behavior and whether status refers to active operations or snapshot metadata.

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?

Baseline score since schema has 100% coverage; description adds no parameter-specific semantics beyond the schema.

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?

Clear verb 'Get' and resource 'backup status', with 'current' distinguishing it from sibling get_backup_history, though 'status' semantics (running vs completed) remain ambiguous.

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

Usage Guidelines2/5

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

No guidance on when to use vs list_snapshots (which also retrieves snapshot info) or get_backup_history; lacks when-not exclusions.

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

get_prune_statusC

Destructive

Get the prune operation status, optionally filtered by storage target

Name	Required	Description	Default
`storage_target`	No	(optional) Filter prune status to a specific storage target

TDQS

C2.8/5.0

Behavior1/5

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

Annotation Contradiction: Description implies read-only operation ('Get'), but annotations indicate destructiveHint=true and readOnlyHint=false without explanation for this discrepancy.

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?

Single sentence is appropriately front-loaded and concise, though extreme brevity contributes to missing behavioral transparency and output details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks description of return values (critical given no output schema exists), but adequately covers the single parameter and low complexity of the operation.

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?

With 100% schema description coverage, baseline is met; description mentions 'optionally filtered' but adds no semantic depth beyond schema's '(optional) Filter' text.

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?

States specific action (get prune operation status) and filtering capability, distinguishing from backup/snapshot siblings, though assumes user knows what 'prune' entails.

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

Usage Guidelines2/5

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

No guidance on when to use versus get_backup_status or other status tools; lacks 'when-not' or alternative recommendations.

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

list_snapshotsB

Destructive

List all unique Duplicacy snapshot IDs known to the exporter

Name	Required	Description	Default
No parameters

TDQS

B3/5.0

Behavior1/5

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

Annotation Contradiction: Description implies read-only operation ('List'), but annotations indicate destructiveHint: true and readOnlyHint: false without explanation.

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?

Single, front-loaded sentence that immediately conveys action and target; no extraneous text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks output schema description (return values undefined) and fails to explain the destructive behavior flagged in annotations.

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?

Zero parameters present, meeting baseline requirement; no additional parameter context needed.

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?

Clear verb (List) and resource (snapshot IDs), mentions 'Duplicacy' to distinguish domain, and functionally differentiates from sibling status/history getters.

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

Usage Guidelines2/5

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

No guidance on when to use versus get_backup_history or other retrieval tools; no exclusion criteria provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Apr 3, 2026
- First observedget_backup_history
- First observedget_backup_status
- First observedget_prune_status
- First observedlist_snapshots

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-04-04 02:31 across 4 tools

Disambiguation4/5

Tools have clearly distinct purposes, though get_backup_history and get_backup_status both target specific snapshots with similar naming patterns (historical vs current status). The descriptions adequately clarify the distinction between completed backup details and ongoing operations.

Naming Consistency5/5

All four tools follow a strict verb_noun pattern using snake_case (get_backup_history, get_backup_status, get_prune_status, list_snapshots). The naming convention is uniform and predictable throughout the set.

Tool Count4/5

Four tools is reasonable for a focused observability server interfacing with a Duplicacy exporter, providing essential monitoring capabilities without excessive scope. However, the read-only nature limits the server's overall utility for backup operations.

Completeness3/5

As a monitoring-specific server, it covers basic backup status, history, and prune operations, but lacks storage metrics, verification/check status, and error log access. For general Duplicacy management, the absence of backup execution, restore, or configuration tools represents notable functional gaps.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Related MCP Connectors

jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
https://mcp.jumpcloud.com/v1
mcp-openaiOAuth
io.github.AceDataCloud
MCP server for OpenAI API (chat completions, image generation, embeddings) via AceDataCloud
AI & Machine Learning Image & Video Processing
11
https://openai.mcp.acedata.cloud/mcp
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
https://aichat.mcp.acedata.cloud/mcp
Backtest360 A
com.backtest360
MCP server exposing the Backtest360 engine API as tools for AI agents.
Finance Research & Data
202
https://mcp.backtest360.com/mcp

Related MCP Servers

Prometheus MCP Server
Monitoring Databases
CaesarYangs
A
license
Not graded
quality
F
maintenance
An MCP server that enables Large Language Models to retrieve, analyze, and query metric data from Prometheus databases through pre-defined routes.
Updated 2 years ago (2025-04-05 06:16 UTC)
33
MIT
duplicati-mcp
Monitoring Databases
kcofoni
A
license
A
quality
D
maintenance
MCP server for managing Duplicati backups from an LLM.
Updated 5 months ago (2026-05-14 16:58 UTC)
17
MIT
Proms MCP Server
Monitoring Observability
app-sre
A
license
Not graded
quality
D
maintenance
A lean MCP server that provides LLM agents with transparent access to multiple Prometheus instances for metrics analysis and SRE operations.
Updated 3 months ago (2026-07-27 04:18 UTC)
4
GPL 2.0
duplicacy-mcp
Cloud Storage Monitoring
SeraphimSerapis
A
license
A
quality
C
maintenance
MCP server for administering Duplicacy backups via the duplicacy-web API, enabling AI clients to inspect and manage storages, repositories, schedules, and jobs.
Updated 2 months ago (2026-09-08 22:23 UTC)
15
MIT

Features

Tools and resources

Install

Documentation

Related projects

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers