Skip to main content
Glama
deenesjakoruzh
GeiserX

duplicacy-mcp

by GeiserX
OverviewSchemaRelated ServersScoreDiscussions
Go
Remote

제공 기능

유형

용도

MCP URI / 도구 ID

리소스

백업 상태, 진행률 및 상태 읽기 전용 조회

duplicacy://statusduplicacy://progressduplicacy://health

도구

백업 기록 쿼리, 스냅샷 나열, 정리(prune) 상태 확인

get_backup_statusget_backup_historylist_snapshotsget_prune_status

모든 기능은 단일 JSON-RPC 엔드포인트(/mcp)를 통해 노출됩니다. LLM / 에이전트는 initialize -> readResource -> listTools -> callTool 등의 순서로 작업할 수 있습니다.

Related MCP server: duplicati-mcp

빠른 시작 (Docker Compose)

services:
  duplicacy-mcp:
    image: drumsergio/duplicacy-mcp:0.1.0
    ports:
      - "127.0.0.1:8080:8080"
    environment:
      - DUPLICACY_EXPORTER_URL=http://duplicacy-exporter:9750

보안 참고: HTTP 전송은 기본적으로 127.0.0.1:8080에서 수신 대기합니다. 네트워크에 노출해야 하는 경우 인증이 포함된 리버스 프록시 뒤에 배치하십시오.

npm을 통한 설치 (stdio 전송)

npx duplicacy-mcp

또는 전역으로 설치:

npm install -g duplicacy-mcp
duplicacy-mcp

이 명령은 플랫폼에 맞는 사전 빌드된 Go 바이너리를 GitHub 릴리스에서 다운로드하고 stdio 전송을 사용하여 실행합니다. 최소 하나 이상의 공개된 릴리스가 필요합니다.

로컬 빌드

git clone https://github.com/GeiserX/duplicacy-mcp
cd duplicacy-mcp

# (optional) create .env from the sample
cp .env.example .env && $EDITOR .env

go run ./cmd/server

구성

변수

기본값

설명

DUPLICACY_EXPORTER_URL

http://localhost:9750

Duplicacy Prometheus 익스포터 URL (끝에 / 제외)

LISTEN_ADDR

127.0.0.1:8080

HTTP 수신 대기 주소 (Docker는 0.0.0.0:8080으로 설정)

TRANSPORT

(비어 있음 = HTTP)

stdio 전송을 사용하려면 stdio로 설정

.env 파일( .env.example에서 생성)에 넣거나 환경 변수로 설정하십시오.

테스트

Inspector로 테스트했으며 현재 완전히 작동합니다. PR을 만들기 전에 이 MCP 서버가 해당 환경에서 잘 작동하는지 확인하십시오.

클라이언트 LLM을 위한 구성 예시

{
  "schema_version": "v1",
  "name_for_human": "Duplicacy-MCP",
  "name_for_model": "duplicacy_mcp",
  "description_for_human": "Monitor Duplicacy backup status, progress, and health via Prometheus metrics.",
  "description_for_model": "Interact with a Duplicacy backup monitoring server that reads metrics from a Prometheus exporter. First call initialize, then reuse the returned session id in header \"Mcp-Session-Id\" for every other call. Use readResource to fetch URIs that begin with duplicacy://. Use listTools to discover available actions and callTool to execute them.",
  "auth": { "type": "none" },
  "api": {
    "type": "jsonrpc-mcp",
    "url":  "http://localhost:8080/mcp",
    "init_method": "initialize",
    "session_header": "Mcp-Session-Id"
  },
  "contact_email": "acsdesk@protonmail.com",
  "legal_info_url": "https://github.com/GeiserX/duplicacy-mcp/blob/main/LICENSE"
}

크레딧

Duplicacy -- 잠금 없는 중복 제거 클라우드 백업

duplicacy-exporter -- Duplicacy용 Prometheus 익스포터

MCP-GO -- 최신 MCP 구현

GoReleaser -- 간편한 멀티 아키텍처 릴리스

관리자

@GeiserX.

기여

언제든 참여해 주세요! 이슈를 열거나 PR을 제출해 주십시오.

Duplicacy-MCP는 Contributor Covenant 행동 강령을 따릅니다.

GeiserX의 다른 MCP 서버

관련 프로젝트

프로젝트

설명

duplicacy-cli-cron

Duplicacy CLI를 사용하는 Docker 기반 암호화 이중 저장소 백업 자동화

duplicacy-exporter

Duplicacy 백업을 위한 실시간 Prometheus 익스포터

duplicacy-ha

Duplicacy 백업 모니터링을 위한 Home Assistant 커스텀 통합

duplicacy-container

Kubernetes에서 Duplicacy를 실행하기 위한 컨테이너 이미지 및 Helm 차트

Available Tools

4 tools
get_backup_historyC
Destructive

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

ParametersJSON Schema
NameRequiredDescriptionDefault
snapshot_idYesThe 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

ParametersJSON Schema
NameRequiredDescriptionDefault
snapshot_idYesThe 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

ParametersJSON Schema
NameRequiredDescriptionDefault
storage_targetNo(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

ParametersJSON Schema
NameRequiredDescriptionDefault

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. Dates show when Glama detected each change.

  1. 4 tool updatesv0.1.0
    • First observedget_backup_history
    • First observedget_backup_status
    • First observedget_prune_status
    • First observedlist_snapshots
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Prometheus MCP Server

    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.
    34
    MIT

  • Proms MCP Server

    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.
    4
    GPL 2.0

  • duplicacy-mcp

    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.
    15
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GeiserX/duplicacy-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server