backrest-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct resource or action: config, health, snapshots, files, operations, logs, summary, and download URLs. There is no meaningful overlap between any pair, and descriptions clarify their specific roles.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern: get_ for single items or status, list_ for collections. The prefixes are uniform and predictable across the entire set.
Tool Count5/5
Eight tools is well-scoped for a backup/monitoring server, covering the key read-only operations without redundancy or excessive fragmentation.
Completeness2/5
The tool set is read-only and missing core lifecycle operations: there is no restore_snapshot tool even though get_download_url references it as a companion, and no tools to create, update, or delete repos/plans or trigger backups. This leaves obvious gaps and dead ends.
Average 3.8/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on August 30, 2026
- 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, the description carries the full burden of behavioral disclosure. It merely states the action with no mention of side effects, preconditions (like needing a valid ref), size limits, or edge cases. The tail behavior for max_bytes is only in the parameter description, not the main description.
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 a single, front-loaded sentence with no wasted words. It is concise but somewhat under-specified; one might expect a bit more context, yet it remains clear and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and well-described parameters, the description lacks essential context such as how the 'ref' is obtained, when this tool is appropriate, and its relationship to get_operations. It feels incomplete for a tool that clearly depends on prior operations.
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%, and the parameter descriptions for 'ref' and 'max_bytes' are informative, including the source of the ref and truncation behavior. The main description adds no parameter information, so the baseline of 3 is appropriate.
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?
The description 'Fetch the log output for an operation' clearly identifies the action (fetch) and the resource (log output), with the scope of an operation. It is specific enough to distinguish from siblings like get_config or get_health, though it does not explicitly differentiate from get_summary or get_operations.
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?
The description provides no guidance on when to use this tool or how it relates to siblings. The schema mentions that the 'ref' comes from get_operations, but this is in the parameter description, not the main description. No exclusions or alternatives are stated.
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, the description carries full responsibility for disclosing behavior. It fails to mention whether listing is recursive or just immediate children, whether both files and directories are returned, any pagination or sorting behavior, or any permissions required. This leaves the agent guessing about the tool's actual behavior.
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 a single, clear sentence that is efficiently written and front-loaded. It avoids unnecessary filler, though it may be too brief to convey essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and no annotations, the description is far too sparse. It does not explain the browsing behavior, how the path parameter affects results, or any relevant caveats. The presence of an output schema reduces the need to document return values, but the description still fails to provide a complete picture.
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?
The schema covers all three parameters with descriptive text (e.g., path defaults to '/', repo_id is resolved to a GUID). The description adds no additional parameter information, so a baseline score of 3 is appropriate given 100% schema coverage.
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?
The description 'Browse files within a specific snapshot' uses a clear verb ('browse') and resource ('snapshot'), and the tool name reinforces this. It is distinguished from sibling tools like list_snapshots and get_summary, but it doesn't explicitly mention that browsing can target subdirectories via the 'path' parameter.
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 versus alternatives, nor are there any exclusions or prerequisites. The description only states what the tool does, not when it should be called.
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 for behavioral disclosure. It only restates the list operation and filtering, omitting return format, pagination, or the merge behavior when repo_id is omitted (which appears only in the schema, not the description).
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?
One sentence with no redundancy, front-loaded with the verb and resource. It is appropriately sized for a simple listing tool.
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 and has an output schema, so return values need no explanation. However, the description lacks usage guidance and behavioral details like merge behavior, making it minimally adequate rather than complete.
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% with detailed parameter explanations. The description adds no parameter semantics beyond 'optionally filtered by repo or plan,' so it does not improve on what the schema already provides.
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?
The description uses a specific verb ('List') and resource ('snapshots in a Backrest repo') and notes optional filters. It does not explicitly differentiate from sibling 'list_snapshot_files', but the resource distinction is implied by the tool name.
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 versus alternatives like 'list_snapshot_files' or 'get_summary'. The description states only the basic functionality without exclusions or recommended use cases.
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. The verb 'List' implies a read-only operation, but the description does not explicitly state side effects, permissions, or behavior like ordering or pagination beyond 'recent'. It adds some context via filters but remains minimal.
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 concise sentence (11 words), front-loads the primary action and resource, and contains no fluff or repetition. Every word 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?
The tool is simple, has an output schema to cover return structure, and all parameters are documented in the schema. The description covers the core purpose and options. It could optionally mention that results are ordered by recency (implied by 'recent'), but this is a minor gap.
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 coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond the schema; it merely restates that filtering by plan or repo is possible, which the schema already documents.
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 the specific verb 'List', names the resource 'backup operations', and specifies scope ('recent') and optional filters (plan or repo). This clearly distinguishes it from sibling tools like get_logs or list_snapshots, which target different resource types.
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 the tool (when you need recent backup operations), but it does not explicitly state when not to use it or mention alternatives. The optional filters hint at use cases, but no exclusionary guidance is provided.
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 must carry the full burden. It discloses the basic behavior (getting a URL) and notes the URL is 'signed', but does not explain what signed means (e.g., expiration, permissions). It also lacks information on error cases or side effects. The description is not misleading, but there are clear gaps in explaining the signed URL behavior.
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 exactly two sentences, with the most important information first. Every word is purposeful, no redundancy or fluff. It is a model of concise, front-loaded description.
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 2-parameter get tool with an output schema, the description provides essential context: what it does, when to use it, and its relationship to restore_snapshot. It does not explain the signed URL's behavioral details or error handling, but given the tool's simplicity and the presence of an output schema, this is largely adequate. A small gap remains regarding signed URL semantics.
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?
The schema description provides 100% coverage for both parameters, so the baseline is 3. The description text reinforces that the tool fetches a 'specific restored file' but adds no substantial new meaning beyond the schema. The mention of restore operation context is useful but not a novel addition.
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+resource ('Get a signed download URL for a file') and clearly ties it to restore operations. It distinguishes itself from sibling tools by focusing on the restore output, and the mention 'Companion to restore_snapshot' further clarifies its unique role.
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 explicitly states when to use this tool: 'after a restore' and 'Companion to restore_snapshot', providing clear context. It does not explicitly mention when not to use it, but the sibling tool list (e.g., list_snapshot_files) implies alternatives for listing files. This is clear usage 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, the description carries the transparency burden. It discloses that the tool returns the full config as a dict and explicitly states it does not expose credentials, which is valuable safety-relevant behavior. It omits potential details like auth/error behavior, but for a simple read-only config getter this is adequate.
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?
Two short sentences with no fluff. The main purpose is front-loaded in the first sentence, and the second sentence adds an essential behavioral caveat. 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 the tool's simplicity (zero parameters, clear read purpose, and an output schema present), the description is complete. It identifies the target, output format, and a critical data-safety behavior, leaving no significant gaps for an agent to misuse the tool.
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, making schema coverage trivially 100% and the baseline 4. The description adds useful semantic context about the return value (a dict) and credential redaction, though no parameter descriptions are necessary.
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 ('Read') and clearly identifies the resource ('Backrest configuration'), listing its main components (repos, plans, global settings). This makes it easily distinguishable from sibling tools like get_health or list_snapshots.
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?
While it does not explicitly say 'use this when you need the config' or mention alternatives, the resource is uniquely named and unambiguous among the siblings. The context is clear enough that an agent would know when to select it over other 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 provided, the description carries the burden of behavioral disclosure. It clearly states the output (per-repo/per-plan counts, bytes, snapshots, next scheduled time) and the 30-day time range. As a 'Get' operation, it implies read-only behavior, and no side effects are mentioned. This adds useful context without being overly verbose.
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 sentences: the first front-loads the core purpose, and the second elaborates on the return details. There is no redundant information, and every word adds value.
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 the tool's simplicity, zero parameters, and presence of an output schema (which likely documents the return structure), the description is complete. It details the content of the summary (counts, bytes, snapshots, next scheduled time) and matches the expected dashboard use case. No critical information is missing.
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 description is not required to explain parameter semantics. The baseline for no-parameter tools is 4, and the description appropriately describes what the operation returns without any parameter-related gaps.
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 'Get' with a clear resource 'Backrest dashboard summary' and specifies the 30-day stats per repo and plan. This distinguishes it from sibling tools like list_snapshots and list_snapshot_files, which focus on listing individual snapshots rather than aggregated statistics.
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 provides clear context by indicating this returns a high-level dashboard summary, which implies use for overview and monitoring rather than granular inspection. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It explicitly states 'Read-only; safe to poll,' explains the underlying HTTP behavior (200 vs 401), and discloses the three possible return statuses plus additional data when healthy. This is thorough and goes beyond minimal expectations.
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, consisting of two sentences that front-load the purpose and then provide necessary behavioral details. Every sentence adds value without redundancy or fluff.
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 the tool's simplicity (no params), the presence of an output schema, and the detailed description of return statuses and safe polling, the description is complete. It covers purpose, behavior, and usage context without leaving significant gaps.
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 no parameter-specific information, but none is needed. It does clarify the output structure, which is useful, though the output schema likely covers that.
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: 'Check that Backrest is reachable and credentials are valid.' This is a specific verb+resource, and it distinguishes itself from sibling tools by focusing on health status rather than returning config, snapshots, or logs.
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 gives clear context for when to use the tool (health checks, polling) and mentions it wraps GetConfig, implying the alternative if full config is needed. However, it does not explicitly state exclusions or name alternative tools for specific scenarios, so it stops short of a 5.
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:

[![backrest-mcp MCP server](https://glama.ai/mcp/servers/TadMSTR/backrest-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TadMSTR/backrest-mcp)

Score Badge

Copy to your README.md:

[![backrest-mcp MCP server](https://glama.ai/mcp/servers/TadMSTR/backrest-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TadMSTR/backrest-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/TadMSTR/backrest-mcp'

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