Backrest MCP is an MCP server that lets you monitor and interact with a Backrest/restic backup system through a read-only-by-default set of tools, with optional opt-in tools for triggering and managing backups.
Check Backrest health and credential validity (get_health)
Read the full Backrest configuration (get_config)
List snapshots across repos or filtered by repo/plan (list_snapshots)
Browse files inside a snapshot (list_snapshot_files)
Get 30-day dashboard stats per repo/plan (get_summary)
View recent backup operations with filters (get_operations)
Read operation logs (get_logs)
Get signed download URLs for restored files (get_download_url)
If write mode is enabled: trigger backups, run repo maintenance (prune/check/stats/unlock/index), and cancel running operations
If destructive mode is enabled: permanently forget snapshots (with confirmation token) and restore snapshots to a guarded staging path
Provides optional InfluxDB metrics integration, emitting tool call metrics (measurement 'backrest_tool' with 'tool' tag and 'duration_ms' field) to InfluxDB for monitoring.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@backrest-mcp list my recent snapshots"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Backrest — a web UI and orchestrator for restic backups.
Python/FastMCP rewrite of backrest-mcp-server. Covers the full useful surface of the Backrest REST API with layered safety controls to protect backup data.
Tool | Description | Requires |
| Check reachability + credential health (poll-safe) | — |
| Read Backrest configuration (repos, plans) | — |
| List snapshots; no args → all repos merged | — |
| Browse files within a snapshot (by | — |
| 30-day dashboard stats per repo and plan | — |
| Recent operation history with status icons + log refs | — |
| Read an operation's log output (ref from | — |
| Signed download URL for a restored file | — |
| Trigger a backup plan (dry_run supported) |
|
| Run maintenance: prune/check/stats/unlock/index |
|
| Cancel a running operation |
|
| Permanently forget a snapshot (confirm token required) |
|
| Restore snapshot to a staging path |
|
Default state: read-only — only the 8 read tools are registered. No write calls are
possible without explicit opt-in. RunCommand, SetConfig, AddRepo, RemoveRepo, and
ClearHistory are intentionally never exposed.
API field names target the deployed Backrest v1.13.0 connect-rpc API, which upstream
mainhas since diverged from. SeeCHANGELOG.md(0.3.0) for the reconciliation notes.
Related MCP server: Keepit MCP
Backups are critical data. Four controls gate write and destructive operations:
1. Read-only mode (default: on)
BACKREST_READONLY=true # no write tools registered (default)
BACKREST_READONLY=false # enables trigger_backup, do_repo_task, cancel_operation2. Destructive gate (default: off)
BACKREST_ALLOW_DESTRUCTIVE=false # forget/restore never registered (default)
BACKREST_ALLOW_DESTRUCTIVE=true # enables forget_snapshot, restore_snapshot
# requires BACKREST_READONLY=false3. Forget confirmation token
forget_snapshot requires confirm=f"FORGET:{snapshot_id}". The caller must name the exact snapshot being deleted.
4. Restore path guard
restore_snapshot validates the target path against BACKREST_RESTORE_ALLOWED_PREFIX (default: /tmp/backrest-restore/) using os.path.realpath(). Path traversal attempts are blocked. After verifying restored files, move them manually.
5. Audit log
Set BACKREST_AUDIT_LOG=/path/to/audit.jsonl to log all write operations. Credential values are never included.
Env var | Default | Purpose |
|
| Backrest base URL |
| — | Basic Auth username (optional) |
| — | Basic Auth password |
|
| Disable all write tools |
|
| Enable forget/restore (requires READONLY=false) |
|
| Restore target path guard |
| — | JSONL audit log for write ops |
|
|
|
|
| Bind host for http mode (non-loopback refused) |
|
| Bind port for http mode |
| — | Bearer token, required in http mode (≥16 chars) |
|
| Logging verbosity |
| stderr | Log file path |
| — | Optional InfluxDB metrics |
python3 -m venv .venv
source .venv/bin/activate
pip install -e .For development/testing:
pip install -e ".[dev]"
pytestAn ecosystem.config.js is included for PM2-managed deployment. Credentials are injected
via --env-file to avoid storing them in the config file:
cd /path/to/backrest-mcp
pm2 start ecosystem.config.js --env-file /path/to/secrets.envThe secrets file must contain BACKREST_USERNAME, BACKREST_PASSWORD, and (for http mode)
BACKREST_MCP_AUTH_TOKEN. All other settings default safely in ecosystem.config.js
(BACKREST_READONLY=true, BACKREST_ALLOW_DESTRUCTIVE=false).
ecosystem.config.js defaults to BACKREST_MCP_TRANSPORT=http, running a long-lived
streamable-http service on 127.0.0.1:8626/mcp. HTTP mode fails closed:
binds loopback only (non-loopback bind refused unless BACKREST_MCP_ALLOW_NONLOOPBACK=1);
requires a BACKREST_MCP_AUTH_TOKEN bearer token of ≥16 chars (generate with
python3 -c "import secrets; print(secrets.token_hex(32))").
Clients authenticate with Authorization: Bearer <token>. Set BACKREST_MCP_TRANSPORT=stdio
(or unset it) to fall back to per-turn stdio via the backrest-mcp entry point.
{
"mcpServers": {
"backrest": {
"command": "/path/to/backrest-mcp/.venv/bin/python",
"args": ["-m", "backrest_mcp.server"],
"env": {
"BACKREST_URL": "http://localhost:9898",
"BACKREST_USERNAME": "your-username",
"BACKREST_PASSWORD": "your-password",
"BACKREST_READONLY": "true"
}
}
}
}Omit BACKREST_USERNAME and BACKREST_PASSWORD if Backrest auth is disabled.
If connecting to an HTTPS endpoint with a private or self-signed CA:
REQUESTS_CA_BUNDLE=/path/to/ca.crthttpx respects this env var. Do not disable TLS verification.
Structured JSON logs via structlog. LOG_LEVEL controls verbosity (default: INFO). Set
LOG_FILE to write to a file instead of stderr — exactly one sink is attached, so under
PM2 the same line is not also duplicated into error_file. If LOG_FILE cannot be created
the server falls back to stderr and says so on stderr rather than failing to start.
LOG_LEVEL applies to this server's own loggers. httpx, httpcore, mcp and nats are
held at WARNING regardless, so their wire trace cannot drown the server's own lines.
Optional InfluxDB metrics via pip install -e ".[influxdb]":
Env var | Purpose |
| InfluxDB write URL |
| Auth token |
| Bucket/database (default: |
Optional NATS publishing via pip install -e ".[nats]":
Env var | Purpose |
| NATS server URL. Unset = disabled. |
| Subject prefix (default: |
Each tool call emits a backrest_tool measurement with tool tag and duration_ms field.
Telemetry is best-effort and never fails a tool call, but it is not silent. An unset env var is the intended disabled state and logs nothing. A backend that is configured and failing warns exactly once per process and is then not retried:
Event | Meaning |
|
|
| The client built but a write failed — the usual symptom of a wrong or unreachable URL, since |
|
|
| First NATS transport error, in place of nats-py's per-attempt ERROR reporting. |
| The connection succeeded but a publish failed. Publishes keep being attempted. |
Every one of these carries the exception class only, never the URL or token — a NATS URL embeds its credentials.
NATS connects fail fast (allow_reconnect=False, two attempts, 2 s connect timeout, 5 s
overall deadline) so an unreachable broker delays a tool call by well under a second rather
than the ~120 s the library defaults produce.
Credentials flow: env vars → BackrestClient.__init__ → httpx Basic Auth tuple → Authorization header.
Credentials are never written to logs, audit entries, or MCP tool responses.
Read the Backrest configuration (repos, plans, global settings).
Returns the full Backrest config as a dict. Does not expose credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Get a signed download URL for a file produced by a restore operation.
Companion to restore_snapshot: after a restore, fetch a URL to download a specific restored file.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path of the file within the restored output to download. | |
| operation_id | Yes | The restore operation's ID (from get_operations). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Check that Backrest is reachable and credentials are valid.
Wraps GetConfig — the call that returns 200 with valid credentials and 401 when they drift. Returns status "ok", "auth_failed", or "unreachable", plus the configured URL and a repo/plan count when healthy. Read-only; safe to poll.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Fetch the log output for an operation.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | The operation's log reference — the "log:" value surfaced by get_operations. | |
| max_bytes | No | Cap on returned text size; when the log is larger, the tail is kept (errors are usually at the end). Default 100000. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
List recent backup operations, optionally filtered by plan or repo.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of operations to return (default 20). | |
| plan_id | No | Filter operations by plan ID. | |
| repo_id | No | Filter operations by repo ID (resolved to the repo GUID that the operation selector matches on). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Get the Backrest dashboard summary — 30-day stats per repo and plan.
Returns per-repo and per-plan success/warning/failed backup counts, bytes scanned/added, total snapshots, and the next scheduled backup time.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Browse files within a specific snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Directory path within the snapshot to list. Defaults to root "/". | / |
| repo_id | Yes | The repository ID (as shown by list_snapshots / get_config). It is resolved to the repo GUID that the Backrest ListSnapshotFiles API expects. | |
| snapshot_id | Yes | Snapshot ID to browse. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
List snapshots in a Backrest repo, optionally filtered by repo or plan.
| Name | Required | Description | Default |
|---|---|---|---|
| plan_id | No | Plan ID to filter snapshots. Can be combined with repo_id. | |
| repo_id | No | Backrest repository ID to list snapshots for. When omitted, all configured repos are enumerated and their snapshots merged (each snapshot is tagged with its repoId). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
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.
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.
Eight tools is well-scoped for a backup/monitoring server, covering the key read-only operations without redundancy or excessive fragmentation.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
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
