duplicacy-mcp

by SeraphimSerapis

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource (storage, repository, schedule, job) and a unique action (create, delete, get, set, list). The two status tools are clearly separated by their focus: schedule status vs backup status.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in lower_snake_case (e.g., create_storage, get_filters, delete_job). Verbs are specific and predictable, making the naming uniform and easy to anticipate.
Tool Count5/5
15 tools is well-scoped for a backup management server, covering the core resources without unnecessary bloat. Each tool has a clear role in the lifecycle of storages, repositories, schedules, and jobs.
Completeness5/5
The tool set provides comprehensive CRUD-like coverage for storages and repositories, full schedule and job lifecycle management, plus filter configuration and status monitoring. No critical operations are missing; any workaround is only for convenience, not necessity.
Average 4/5 across 15 of 15 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Remove a job from a schedule' without specifying side effects, reversibility, index-shifting behavior, permission requirements, or error handling. This is insufficient for a mutation tool.
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?
The description is brief and front-loaded with a one-sentence purpose, followed by a concise argument list. There is no wasted text, though the argument list duplicates schema information. It is appropriately sized for the tool's simplicity.
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?
The tool is simple (two integer params, no enums, output schema present), so the description covers the basic purpose and parameter semantics. However, it lacks any explanation of behavior after deletion, such as index shifting, error conditions, or whether deletion is permanent. This leaves gaps for an agent using the tool in a real workflow.
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 input schema provides only titles ('Schedule Index', 'Job Index') with no descriptions, so the 0% coverage means the description must compensate. It does add meaning by clarifying that both indexes are 0-based and that job_index refers to a position within the schedule, which maps well to the schema. However, it could add more context about valid ranges or preconditions.
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 clearly states the tool's function with a specific verb ('Remove') and resource ('a job from a schedule'), which distinguishes it from siblings like delete_schedule (removes an entire schedule) and add_job (adds a job). The purpose is immediately understandable.
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 is provided on when to use this tool compared to alternatives such as delete_schedule or add_job. There are no explicit prerequisites, exclusions, or usage context, leaving the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral transparency. The phrase 'List backup repository IDs' implies a read-only operation, but there is no disclosure of permissions, error conditions, return format, or pagination behavior. This is minimal behavioral context.
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 extremely terse: one sentence plus an Args line. It avoids redundancy and gets straight to the point, with no filler or unnecessary elaboration.
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?
The tool is simple (one parameter, output schema exists), but the description lacks usage guidance and behavioral details, such as how to interpret results or what errors might occur. Given the presence of sibling tools and no annotations, the description is minimally sufficient but leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'storage' parameter, and the description only adds 'Storage name.' This barely adds meaning beyond the parameter's title and does not clarify what a valid storage name refers to or how it affects the listing. With 0% schema coverage, the description fails to compensate adequately.
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 clearly states the tool's function: 'List backup repository IDs that exist in a storage.' This is a specific verb (List) with a concrete resource (backup repository IDs) and scope (in a storage), making it easy to distinguish from sibling tools like create_repository or delete_repository.
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?
The description implies usage through the mandatory 'storage' parameter but does not explicitly discuss when to choose this tool over alternatives such as get_schedule_status or lookup_storage. No 'when to use' or 'when not to use' guidance is provided, leaving the context implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds useful context like id uniqueness and path being inside the container, but does not disclose failure behaviors, permissions, or side effects beyond the basic creation intent.
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?
The description is concise and front-loaded with a clear purpose statement followed by a well-structured argument list. Each line earns its place, though the arg examples could be considered slightly redundant given the simple parameter names.
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?
For a simple three-param creation tool, the description covers the purpose, parameters, and key context. The presence of an output schema means return values are covered elsewhere. But it would benefit from more explicit usage guidelines and behavioral transparency, so it's not a perfect 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions, so the description fully compensates by explaining each parameter's meaning and providing concrete examples (e.g., id: 'Plex-media'). This is essential for correct usage.
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 clearly states the tool's function with a specific verb and resource: 'Create a backup repository'. It further clarifies the relationship 'one source directory backed up to one storage', distinguishing it from sibling tools like create_storage or create_schedule.
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?
The description implies the tool is for creating repositories and provides context about the source/storage relationship, but it does not explicitly state when to use this tool versus alternatives or any exclusions. No reference to sibling tools is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does provide meaningful details such as the bitmask semantics for days and the meaning of max_time, which are not obvious. However, it omits side effects like what happens if a schedule with the same name already exists, whether the operation is idempotent, or any required permissions. The description is informative but not fully transparent about the creation's consequences.
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?
The description is front-loaded with the purpose statement, followed by a structured argument list. While the parameter explanations are detailed, they are all necessary given the schema's gaps. The format is scannable and each line earns its place. It is slightly verbose due to the examples, but these are valuable for clarity, so it remains appropriately concise.
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?
For a create tool with 5 parameters, no schema descriptions, and no annotations, the description covers every parameter with useful domain-specific semantics. It also explains that a schedule is a container for jobs, providing important context for the tool ecosystem. It does not detail return values or error scenarios, but the presence of an output schema mitigates the need for return-value explanation. Overall, it is highly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate, and it does. Each parameter is explained with concrete examples: start_time format (HH:MMAM/PM), frequency in seconds with daily example, days bitmask construction with '1111111' and '0000000' cases, and max_time semantics with '00:00' meaning no limit. This adds significant value beyond the bare schema, making the parameter usage clear and unambiguous.
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 clearly states the tool's function: 'Create a backup schedule (container for one or more jobs).' It uses a specific verb (create) and resource (backup schedule), and clarifies that a schedule is a container, distinguishing it from the sibling tool add_job which adds jobs to a schedule. This is unambiguous and properly scoped.
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?
The description implies usage by explaining that a schedule is a container for jobs, which suggests using this tool before add_job, but it does not explicitly state when to use this instead of alternatives or exclude cases. There is no direct 'use this for X, use add_job for Y' guidance, so it relies on the user inferring the relationship from the container mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It notably mentions 'Existing backups remain in storage,' which is a key side effect. However, it does not mention other potential consequences such as whether dependent jobs/schedules are affected, irreversibility, or required permissions.
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 compact, front-loaded with the core action, and includes a brief Args section. Every sentence provides useful information without redundancy, making it highly efficient.
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?
For a simple one-parameter delete tool, the description adequately covers the action, parameter, and a key behavioral consequence. The presence of an output schema reduces the need to explain return values, and the description seems sufficiently complete for its complexity.
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 description adds significant meaning to the lone 'index' parameter: it specifies the index is 0-based and explains how to obtain it via get_backup_status. This goes well beyond the schema's minimal 'type: integer' and compensates for the 0% schema_description_coverage.
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 clearly states 'Delete a repository configuration' with a specific verb and resource. This distinguishes it from sibling tools like delete_storage, delete_schedule, and delete_job, which target different resources.
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?
The description implies when to use it—when you need to delete a repository configuration—and even adds a hint about getting the index from get_backup_status. However, it does not explicitly contrast with alternatives or state when not to use it, leaving usage context mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal. It indicates a read operation via 'Return', but does not explicitly state that no changes are made, nor does it mention error behavior when an invalid index is provided. With no annotations, more behavioral disclosure would be valuable, though the getter nature is fairly clear.
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 extremely concise: one sentence for the main purpose and a clear args section. There is no wasted text, and the structure makes the parameter definition easy to parse.
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?
For a simple getter with one parameter and an existing output schema, the description provides sufficient context. It explains the parameter and the purpose, and the output schema presumably covers return format details. A slight gap is not mentioning what exactly constitutes 'include/exclude filter patterns' or any edge-case behavior.
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 schema only provides a title 'Index' and type 'integer' with no description. The description adds essential meaning by explaining that 'index' is the repository index (0-based), which is critical for correctly invoking the tool.
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 uses a specific verb 'Return' and clearly identifies the resource: include/exclude filter patterns of a repository. It distinguishes itself from sibling tools like set_filters, which likely modifies those patterns.
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?
The intended use is implied by the verb 'Return' and the parameter 'index', but no explicit guidance is given about when to use this tool versus alternatives. There are no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns existence and details, which is useful, but it does not mention error behavior, permissions, or side effects. For a read-only lookup, this is minimal but not insufficient.
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 very concise: one purpose sentence followed by a single parameter definition. It is well-structured, front-loaded, and every sentence earns its place.
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?
For a simple single-parameter lookup tool, the description covers the core purpose and parameter semantics. The existence of an output schema means return values do not need to be explained further. It could mention when to use, but that is not critical here.
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 input schema has only a bare 'name' string, but the description adds meaning: 'Storage name as configured in duplicacy-web.' This contextualizes the parameter beyond the schema, compensating for 0% schema description coverage.
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 verb and resource: 'Look up a storage by name; returns whether it exists and its details.' This clearly distinguishes it from sibling tools like create_storage and delete_storage.
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?
The intended usage is implied through the verb 'look up,' but the description does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. It is clear enough for a simple lookup operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses important aspects like encryption with the password and the dedupe seeding behavior of copy_from, but it does not mention error handling, permissions, or side effects beyond creation.
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 well-structured with a clear one-line purpose followed by an Args block. Each parameter description earns its place with concrete examples and practical guidance, and there is no redundant fluff.
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?
With an output schema present and all parameters thoroughly explained, the description is largely complete. The only gap is the lack of explicit usage guidance relative to sibling tools, but that is a marginal omission given the rich parameter documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: uniqueness of name, URL format examples, password/encryption role, compression choices with guidance, and copy_from semantics. This adds substantial meaning beyond the raw schema.
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 opens with 'Create a new backup storage (destination)', clearly stating the specific verb+resource and distinguishing it from repository creation. The parenthetical '(destination)' disambiguates from the sibling tool create_repository.
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?
The description explains the tool's function ('Create a new backup storage') and provides detailed parameter context, but it does not explicitly state when to use this tool versus alternatives like create_repository. Usage is implied through the tool name and sibling context, not directly articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the cascading effect of deleting the schedule and its jobs, which is a key behavioral trait. It also specifies the index is 0-based. Since no annotations are provided, this carries the full burden, but it does not mention irreversibility or permission requirements.
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 concise and front-loaded with the action, followed by a clear Args section. Every word earns its place; no wasted sentences.
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?
For a simple deletion tool with one parameter, the description adequately covers the action, the parameter, and how to obtain the index. An output schema exists, so return values need not be explained. Minor omissions like behavior on non-existent schedules don't significantly detract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only lists schedule_index as an integer with no description. The description adds crucial meaning by explaining it is 0-based and references get_schedule_status for the correct value, fully compensating for the schema's lack of information.
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 clearly states the action: 'Delete a schedule and its jobs.' This uses a specific verb and resource, and distinguishes from sibling tools like delete_job and delete_repository.
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?
The description implies usage but does not explicitly state when to prefer this over alternatives like delete_job or when not to use it. It provides helpful context by referencing get_schedule_status for the index, but lacks explicit exclusion or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself. It explicitly states that existing backups are NOT deleted, which is a critical side-effect beyond the obvious deletion. This adds meaningful context about the operation's impact, though it does not mention reversibility or permission requirements.
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?
The description is concise and front-loaded, with the core action in the first sentence. The 'Args:' block is somewhat redundant with the schema but still adds a human-readable clarification. Overall, every part earns its place with no unnecessary verbosity.
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?
This is a simple tool with one parameter and an output schema present. The description covers the action, the parameter meaning, and the most important contextual detail (backups are preserved). It does not explain error handling or return values, but the output schema likely covers those, so the description is sufficiently complete.
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 input schema provides only 'name' with a generic title, and description coverage is 0%. The description compensates by explaining that 'name' is the 'Storage name to remove,' giving clear meaning to the only parameter. This is exactly what the agent needs to invoke the tool correctly.
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 clearly states the action ('Delete a storage configuration') and the resource (storage configuration), which is specific and unambiguous. It also adds a clarifying note about existing backups not being deleted, further distinguishing the tool's behavior from a more destructive delete.
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?
The usage is implied by the tool name and description, but there is no explicit guidance on when to use it versus alternatives like delete_repository or create_storage. The note about backups is a caution rather than a usage rule, so it does not fully clarify when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the response contents but does not explicitly state that the operation is read-only or describe potential side effects, limitations, or permission requirements. 'Return' implies a read but lacks explicit safety disclosure.
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 a single sentence that front-loads the core purpose and provides specific details without any wasted words. Every word earns its place.
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?
Given that the tool has no parameters and an output schema exists (so return format need not be described), the description sufficiently covers the tool's purpose and the main data it returns. It is complete for its simplicity.
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 has zero parameters, so schema coverage is 100% and there are no parameter semantics to explain. The baseline for 0 parameters is 4. The description adds useful context by specifying that the status is per-repository.
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 uses a specific verb ('Return') and resource ('per-repository backup status') while enumerating key fields (last run outcome, timestamps, sizes). This clearly distinguishes it from sibling tools like get_schedule_status, which focuses on schedule status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose statement implicitly indicates when to use the tool (when you need backup status), but it does not explicitly mention alternatives or when-not-to-use conditions. This provides clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'Return' and 'get', but does not explicitly state that it has no side effects, nor does it describe any permissions or edge cases. Acceptable for a simple status query, but not rich in behavioral detail.
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 two concise sentences. The first explains what it returns, the second gives a use case. No unnecessary words, and key information is front-loaded.
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?
For a read-only tool with no parameters and an output schema present, the description provides sufficient context. It names the exact data points returned and a common use case. No additional explanation of return values is needed due to the output schema.
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 has zero parameters, so the baseline is 4. The description adds nothing about parameters because there are none, and the schema already covers everything.
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 clearly states the tool's purpose: 'Return schedule status' with specific details about what's included (next run, pause state, running jobs). This distinguishes it from siblings like get_backup_status by focusing on schedule-level information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers explicit usage context: 'Use this to see whether a backup is running or when the next one is due.' It does not mention alternatives or when not to use, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the pattern rules ('first match wins') and gives an example, but it does not disclose that the operation overwrites existing filters or mention any side effects. This is a notable gap for a mutation tool.
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 concise and well-structured: two introductory sentences, an illustrative example, then a brief args list. Every sentence contributes to understanding, and the most important purpose is front-loaded.
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?
With an output schema present, return values need no description. The description covers the pattern syntax, example, and parameters well. It lacks an explicit statement about replacing all existing filters and possible error cases, but overall it is sufficiently complete for a setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does so by explaining both parameters: 'index' is 0-based, and 'patterns' are filter rules with order semantics, plus a concrete example. This adds significant meaning beyond the bare schema.
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 clearly states the tool's function with a specific verb ('Set') and resource ('include/exclude filter patterns of a repository'). It distinguishes itself from the sibling get_filters by implying the opposite operation and provides a concrete example of use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this tool is used to set repository filter patterns, with an example showing a typical use case. It does not explicitly mention when not to use it or name alternatives, but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core effect (enable/disable) but does not mention potential side effects, permission requirements, or reversibility. This is adequate for a simple toggle but leaves some gaps.
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 concise and front-loaded, with the core action stated first, followed by a minimal but clear Args block. No wasted words.
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?
For a simple toggle tool with an output schema present, the description covers the essential purpose and parameters. It could be more complete by addressing error conditions or prerequisites, but given the low complexity, it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: schedule_index is 0-based, and is_start is true for enable, false for disable. This is essential and clearly adds meaning beyond the raw schema.
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 clearly states the action: 'Start (enable) or stop (disable) a schedule.' This specifies the verb and resource, and distinguishes it from sibling tools like create_schedule, delete_schedule, and get_schedule_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear that the tool toggles a schedule between enabled and disabled states. It does not explicitly name alternatives or exclusion criteria, but the context is unambiguous relative to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It explains parameter-level behavior (e.g., destination reads from for prune/check, options are extra duplicacy CLI flags, parallel controls concurrency). It does not disclose error handling, idempotency, or return values, but the output schema covers some of that.
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 purpose is front-loaded, followed by a clean Args list where each parameter gets one line. Every sentence adds value, and the length is justified by the need to document 7 parameters with practical examples.
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?
The description fully covers all parameters, required vs optional fields, and provides enough context to invoke the tool correctly. With an output schema present, return values are handled separately, and the description leaves no meaningful ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description thoroughly compensates. Every parameter is explained with types, defaults, semantics, and concrete examples (e.g., '-threads 4', '-keep 0:30 -a', '-fossils'), including clarifications like source being empty for prune/check.
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 opens with 'Add a job (backup, prune, or check) to a schedule' — a clear, specific verb and resource. It also lists valid job types, and the sibling tool delete_job makes the add-vs-delete distinction obvious.
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?
Usage is implied by the verb 'Add' and the context of schedules, but there is no explicit guidance on when to use this tool over alternatives (e.g., delete_job, start_stop_schedule). No when-not-to-use or alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![duplicacy_mcp MCP server](https://glama.ai/mcp/servers/SeraphimSerapis/duplicacy_mcp/badges/card.svg)](https://glama.ai/mcp/servers/SeraphimSerapis/duplicacy_mcp)

Score Badge

Copy to your README.md:

[![duplicacy_mcp MCP server](https://glama.ai/mcp/servers/SeraphimSerapis/duplicacy_mcp/badges/score.svg)](https://glama.ai/mcp/servers/SeraphimSerapis/duplicacy_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/SeraphimSerapis/duplicacy_mcp'

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