Exposes the Hiberden archive engine (hiberden-core) as Model Context
Protocol tools over the stdio transport
(newline-delimited JSON-RPC 2.0).
MCP is an open, vendor-neutral standard, so this one server is drivable from any MCP client: Claude Desktop / Claude Code, OpenAI's Agents SDK and ChatGPT desktop, Gemini, Cursor, Windsurf, and others. There is no model and no API key in this process. The client brings the LLM; this binary only answers tool calls against the local catalog. In its default mode it performs no network I/O.
The server advertises and answers the read/verify tools below by default, and
nothing mutates configuration. The only state any default tool ever writes
is what verify_copy records: the copy's status, its verify-pass provenance
(which algorithm ran, when the last full pass succeeded), and an audit-log
row for each completed verify — and it only does that after a genuine
read-back from the medium.
Write and delete tools (catalog management, destinations, policies) ARE
implemented, but behind a catalog-persisted permission tier that defaults to
read-only and is only changeable in the Hiberden desktop app's settings; a
tool above the active tier is neither advertised nor accepted. See
docs/Hiberden_MCP_Command_Surface_and_Permission_Model.md (which supersedes
docs/mcp/write-gate-design.md).
Related MCP server: Copick MCP Server
Tool | Args | What it does |
| none | Top-level projects (containers). For each: name, policy, archive count, and a roll-up of how many of its archives sit in each coverage state. |
|
| The archives (leaves actually written to media). For each: project, size, SHA-256, 3-2-1 coverage, and per-copy status (destination + kind + status). Narrow by project, Collection, and/or a case-insensitive name substring. |
|
| The Collections inside one project (catalog-only organizational nodes): id, name, parent, archive count. |
| none | Library-wide 3-2-1 roll-up: total archives plus counts in unconfigured, unprotected, in_progress, at_risk, and fully_covered. |
|
| Full detail for one archive: project, size, SHA-256, legacy MD5 (if imported), coverage, and every copy with its destination, kind, status, address, and written/verified timestamps. |
| none | Configured destinations (Tape, LocalFs, NAS, Cloud) with id, slot, kind, name, and enabled/retired state. |
| none | Tapes: serial, volume label, uuid, capacity, used bytes, last verified time, and copy count. |
|
| One cartridge by barcode: label, capacity, used bytes, last verified, and the archives stored on it. |
|
| Recent copy activity, newest first (default 20): each copy's archive, destination, status, and write/verify timestamps. |
|
| Find a file by name/path fragment across every archive, with the archive and every destination it is stored in. |
|
| The file manifest of one archive from the catalog index (path, size, per-file SHA-256), paginated. The report enabler: client-ready deliverable lists and checksum manifests from the index (a one-time backfill may read a local copy of a pre-index archive). Archives with no buildable index (legacy tape-only imports) report |
|
| Recent background jobs (saves, verifies, restores), newest first: verb, state, archive, destination, bytes, timestamps, and the recorded failure reason on failed/interrupted rows. |
| none | One-call inventory + capacity roll-up: counts, total archived bytes, copies by status, destinations by kind, tape capacity vs. use. |
|
| Re-reads the copy off its medium and compares it to what was recorded. Default |
verify_copy is the differentiator: it is proof from the actual medium, not a
stored flag. Identify the copy by archive_id + destination_id. It works for
disk and NAS copies and for tape copies (the cartridge is mounted and read
back). Cloud (S3) read-back verify runs in the Hiberden desktop app, not here:
for a cloud copy the tool returns a clear message that the copy was checked in
the desktop, not here, so it has not passed or failed. That message is a
not-attempted result, not a verification failure.
Adding archives (writing bytes), save, and restore are not exposed here. Catalog, destination, and policy configuration tools exist behind the permission tier described above; at the default read-only tier they are neither advertised nor accepted.
The server reads the single catalog shared by the desktop app, the CLI, and this server. Path resolution:
The HIBERDEN_DB environment variable, if set.
Otherwise %LOCALAPPDATA%\Hiberden\catalog.db on Windows, or
~/.hiberden/catalog.db on Linux.
The catalog is opened fresh per tool call (sub-millisecond) rather than held for
the process lifetime. With WAL mode and a busy timeout, the desktop app and this
server can run against the same catalog.db at the same time without a
multi-process locking hazard.
All diagnostics go to stderr. stdout carries the JSON-RPC channel; anything written to stdout that is not a JSON-RPC message corrupts the stream.
Linux binaries are published on the releases page and at
cdn.hiberden.app. They are built on Ubuntu 22.04, so they run on Ubuntu
22.04+, Debian 12+, and equivalents; verified on debian:bookworm-slim and
ubuntu:22.04.
curl -fsSLO https://cdn.hiberden.app/downloads/hiberden-cli-linux-x86_64
curl -fsSLO https://cdn.hiberden.app/downloads/hiberden-cli-linux-x86_64.sha256
sha256sum -c hiberden-cli-linux-x86_64.sha256 # verify before running it
chmod +x hiberden-cli-linux-x86_64
./hiberden-cli-linux-x86_64 --versionhiberden-mcp-linux-x86_64 is the same connector as the Windows build. The
CLI (hiberden) catalogs and archives with no display server and no network —
the whole point of the kit is that an air-gapped or headless machine can run
it.
Linux reached general availability on 2026-08-11 at version 1.3.1, alongside Windows. What that does and does not cover, precisely:
Writing a new archive needs a license. Reading your data back never does, license or not. Kits published before GA are ungated and stay that way; entitlement applies from the first post-GA kit onward. Nothing you archive now becomes unreadable later: the format and catalog are identical across platforms.
The desktop app runs on Linux too, as a signed .deb and .AppImage
from hiberden.app/linux. A macOS beta for
Apple Silicon is at hiberden.app/download.
Tape on Linux is unproven on hardware. The backend targets the
open-source LTFS implementation and has never run against a drive on any
platform. Use HIBERDEN_TAPE_FAKE=1 to exercise the flows without one.
Archives are signed by a per-install Ed25519 identity stored under
~/.hiberden/keys/ (owner-only). It is the same custody model as the OS
keyrings on other platforms, and no stronger: it is not hardware-backed.
The binary self-installs into known MCP clients:
hiberden-mcp install # auto-detect Claude Desktop / Cursor / Windsurf and write their config
hiberden-mcp install --print # print a paste-ready snippet instead of touching anything
hiberden-mcp uninstall # remove the hiberden entry from detected clients
hiberden-mcp help # show usageinstall writes (or updates) an mcpServers.hiberden entry pointing at this
executable. It is zero-config for the catalog: the entry only pins HIBERDEN_DB
when you already have it set in your environment, otherwise it relies on the
default %LOCALAPPDATA%\Hiberden\catalog.db path.
To wire it up by hand, add this to your client's config (Claude Desktop:
claude_desktop_config.json; Claude Code: .mcp.json; Cursor / Windsurf use the
same mcpServers shape). command is the path to the executable. env is
optional: include HIBERDEN_DB only if your catalog lives somewhere other than
the default path.
{
"mcpServers": {
"hiberden": {
"command": "C:/path/to/hiberden-mcp.exe",
"env": { "HIBERDEN_DB": "C:/path/to/catalog.db" }
}
}
}This pipes three requests (initialize, list tools, read coverage) straight into the binary:
printf '%s\n' \
'{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{}}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list"}' \
'{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"coverage_status","arguments":{}}}' \
| HIBERDEN_DB=path/to/catalog.db hiberden-mcpLocal-only and closed-domain. The server is read + verify only and performs
zero network I/O; the only state it writes is the copy status verify_copy
stamps after a read-back. It never sends data to Hiberden or any third party.
No API key and no LLM are stored in the binary, so there is nothing to steal there.
verify_copy gives ground-truth physical state: it re-reads and re-hashes the
actual medium, so even a manipulated assistant cannot fabricate a "Verified".
Tool annotations (readOnlyHint, destructiveHint, and so on) are hints, not
guarantees. Prompt injection is an unsolved industry-wide problem. The
architecture here is conservative by design; that is not a claim of immunity.
The server runs entirely on your own machine, holds no account or API key, and
in its default read-and-verify mode performs zero network I/O — it never sends
your catalog or your files to Hiberden or any third party. The only state any
default tool writes is the copy status verify_copy stamps after a genuine
read-back. Full details (what the server reads, what it never does, the role of
the separate AI client, and credential handling) are in
PRIVACY.md, hosted at https://hiberden.app/mcp/privacy.
Tape support is in beta and has not been validated on physical tape hardware in this implementation. The design never speaks SCSI directly and treats tape as a filesystem via LTFS tooling, so any tape the LTFS tooling can mount should work by construction. That is an architectural property, not a tested hardware matrix. Do not read these notes as a guarantee for any specific drive or generation.
For testing without a drive, the tape backend can run against a fake backend:
set HIBERDEN_TAPE_FAKE=1 (and optionally HIBERDEN_TAPE_FAKE_ROOT=<dir> to
point at a directory standing in for the mounted volume).
Full detail for one archive: its project, size, SHA-256, legacy MD5 (if imported), coverage, and where it is stored, with each Destination's kind, status, path, and verification timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| archive_id | Yes | The archive's id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false. The description adds value by detailing exact return fields including destinations and timestamps, going beyond what annotations offer.
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?
Single sentence with front-loaded purpose. Lists many fields, making it informative but slightly long. Could be split for readability.
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 one-parameter read-only tool with no output schema, the description adequately covers what data is returned (archive fields and destination details). Missing output schema is compensated by textual description.
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?
Only parameter archive_id is described in schema with 'The archive's id.' The description does not add further meaning, and schema coverage is 100%, so baseline 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 clearly states 'Full detail for one archive' and enumerates specific fields (project, size, SHA-256, etc.), distinguishing it from siblings like list_tapes or coverage_status.
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 use for comprehensive single-archive info but does not explicitly state when to use or not use this tool over alternatives. No sibling differentiation is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call inventory and capacity roll-up for the whole library: project/archive/tape/job counts, total archived bytes, stored copies by status, destinations by kind, and tape capacity vs. use. The fast starting point for utilization reports and health summaries; for the 3-2-1 protection view use coverage_status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, indicating a safe, closed-world read operation. The description adds behavioral context: it is a 'fast' aggregation returning 'inventory and capacity roll-up' data. This goes beyond annotations by describing performance and scope, though it does not contradict them.
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 extremely concise with two sentences. The first sentence lists the tool's output, and the second provides usage guidance. No extraneous information.
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 parameters, no output schema), the description adequately covers what it returns (counts, bytes, capacity, etc.) and when to use it. It is complete for its purpose.
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 and 100% schema description coverage. According to guidelines, absence of parameters warrants a baseline score of 4. The description does not need to elaborate on parameter semantics.
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 as a 'one-call inventory and capacity roll-up for the whole library' listing specific metrics (counts, bytes, etc.). It distinguishes itself from the sibling tool 'coverage_status' by noting that for the 3-2-1 protection view, that alternative should be used.
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 says it is 'the fast starting point for utilization reports and health summaries' and directs users to 'coverage_status' for the 3-2-1 protection view. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The headline 3-2-1 coverage roll-up across the whole library: the total archive count and how many archives are unconfigured, unprotected, in progress, at risk, or fully covered.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates safe read-only behavior. The description adds that this is a roll-up of archive counts, which provides further context about the output being a summary rather than raw data. No contradictions.
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, well-structured sentence that clearly communicates the tool's output without any fluff. 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 zero parameters and no output schema, the description is sufficiently complete by listing the exact counts returned. It could optionally mention the scope ('across the whole library') more explicitly, but it is already stated.
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 input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter-specific information. It appropriately describes the tool as requiring no inputs.
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 provides a '3-2-1 coverage roll-up across the whole library' with specific metrics: total archive count and counts of unconfigured, unprotected, in progress, at risk, and fully covered archives. This is a specific verb-resource combination that distinguishes it from sibling tools like archive_detail or tape_detail.
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 explicit guidance on when to use this tool vs alternatives. However, the description implies it is for a high-level overview of coverage across the entire library, which helps differentiate from more specific tools. It could benefit from stating that it is not for individual archive details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a file by name or path fragment across EVERY archive at once, and report which archive it is in and every Destination it is stored in (local folder, NAS, tape, cloud) with each Destination's status. Answers "is saved, and where?". Case-insensitive substring match on the file path; pass a filename or a path fragment.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max matches to return (default 50). | |
| query | Yes | A filename or path fragment, e.g. "20250906-234643-UI.md" or "logs/". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. The description adds context: searches across all archives, reports destinations with status, and specifies substring matching. No contradictions, and the description enhances understanding of behavior beyond annotations.
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 three sentences with no wasted words. It front-loads the main purpose and scope, then elaborates on the use case and matching behavior. Well-structured and concise.
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 no output schema, the description explains return value: the archive and destination details with status. Parameters are well-documented. Missing details like pagination or error handling, but sufficient for a simple find 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?
Input schema has 100% coverage. Description adds meaning by explaining the query parameter is a filename or path fragment and that matching is case-insensitive substring. This clarifies usage beyond the schema descriptions.
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 verb 'Find', the resource 'file', and the scope 'across EVERY archive'. It explains what is reported: archive name and destination details with status. This sufficiently distinguishes it from siblings like list_archive_files or archive_detail.
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 explains the tool answers 'is <filename> saved, and where?' and describes the matching behavior (case-insensitive substring). It does not explicitly list when not to use it or compare to alternatives, but the purpose is clear and context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The file manifest of one archive from the catalog index: each file's relative path, size, and SHA-256 (sha256 is null for entries indexed before per-file capture). Paginated for very large archives. Combine with archive_detail to produce client-ready deliverable lists and per-file checksum manifests. Answers come from the catalog index, not by re-reading the archive; a one-time index backfill may read a LOCAL copy of an archive that pre-dates the index. If the archive has data but no index could be built (e.g. a legacy tape-only import), the response says indexed: false with a note — that is "manifest unavailable", NEVER "the archive is empty".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max files to return (default 500, max 2000). | |
| offset | No | Skip this many files (default 0). | |
| archive_id | Yes | The archive's id (see list_archives / find_file). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining that SHA-256 is null for older records, that pagination is supported, and the nuanced case of 'indexed: false' versus empty archive. Annotations already declare readOnlyHint=true, and the description adds critical behavioral details without contradiction.
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 relatively long but each sentence adds important nuance. It front-loads the main purpose and then supplies details. Could be slightly more concise, but overall well-structured and free of 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 has no output schema, the description adequately describes the returned data (path, size, SHA-256) and potential edge cases (null SHA, indexed false). It covers all needed context for an agent to understand behavior and output format.
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 parameters are well-documented in the schema. The description adds minimal extra semantics (e.g., mentions pagination for very large archives), but does not provide significant new meaning beyond what the schema already offers.
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 returns a file manifest for one archive, listing relative path, size, and SHA-256. It distinguishes from siblings like list_archives and archive_detail, making the purpose unmistakable.
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 explains when to use this tool (combine with archive_detail, for client-ready lists) and provides context about the data source (catalog index vs re-reading). However, it lacks explicit when-not-to-use conditions or alternatives beyond the combination hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the archives (the leaves actually written to media). Each archive's project, size, SHA-256, 3-2-1 coverage, and every Destination it is stored at (Destination + kind + status) are included. Optionally narrow with project_id (one container), collection_id (one Collection within a project), and/or name (case-insensitive substring, e.g. "johnson" to find the Johnson family album).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Case-insensitive substring filter on the archive name. | |
| project_id | No | Only archives in this project (container) id. | |
| collection_id | No | Only archives filed in this Collection id (see list_collections). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, so the description correctly does not repeat that. The description adds value by detailing the output fields (project, size, SHA-256, 3-2-1 coverage, destinations) and the filtering behavior, which goes beyond what annotations convey. It does not contradict any annotation, and it clearly indicates a safe, read-only operation.
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, front-loaded with the core action ('List the archives'), and every phrase adds value. The first sentence defines the scope and output content; the second sentence covers optional filters with an example. No wasted words, and the structure is easy to parse quickly.
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 3 optional parameters, no output schema, and readOnlyHint=true, the description completely covers what the tool does: it lists archives with specific fields, and it explains each filter. The agent knows what to expect in the response and how to narrow results. The sibling tools (e.g., list_archive_files, archive_detail) are clearly distinct, and the context makes the tool's role in the workspace understandable.
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%, so the baseline is 3. The description adds meaning beyond the schema by clarifying the name filter as 'case-insensitive substring' with an illustrative example ('johnson' to find the Johnson family album), and by explaining that project_id is 'one container' and collection_id is 'one Collection within a project'. This provides contextual richness that helps an agent understand the exact filtering behavior.
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 ('archives'), and immediately clarifies it means 'the leaves actually written to media'. It lists exactly what information is included (project, size, SHA-256, 3-2-1 coverage, destination details), which clearly distinguishes it from sibling tools like list_projects, list_collections, and archive_detail. The purpose is unambiguous and well-scoped.
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 that the tool can be narrowed with optional filters (project_id, collection_id, name) and provides an example for the name filter. It also implies the tool lists all archives with summary info, which guides the agent to prefer this for broad queries versus archive_detail for deeper detail. However, it does not explicitly name alternatives or state when not to use this tool, which would be ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Collections inside one project. Collections are the middle tier of the Project > Collection > Archive model: catalog-only organizational nodes (never written to media). Each entry has the Collection's id, name, parent_collection_id (null at the top level), and the count of archives filed directly in it. Pass a Collection's id to list_archives (collection_id) to see its contents.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | The project (container) id whose Collections to list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description complements this by noting collections are 'catalog-only organizational nodes (never written to media),' which adds behavioral context beyond the annotations. It does not detail aspects like pagination or error handling, but this is a simple listing tool with one parameter.
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 compact—3 sentences total—each adding essential information: the location in the hierarchy, the nature of collections (catalog-only), and the return content. No wasted words, and the critical usage guidance is front-loaded.
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?
With one required parameter, a schema with 100% coverage, and no output schema needed (return fields are summarized in the description), this is complete. The description covers purpose, structure, content, and next steps, making it fully adequate for agent use.
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 description adds value by explaining the role of project_id in the context of the hierarchy. It does not repeat the existing schema description verbatim but reinforces it with business logic context.
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 states clearly that the tool lists collections inside one project, distinguishes it from siblings like list_projects and list_archives by explaining the hierarchical model (Project > Collection > Archive), and specifies what each entry contains (id, name, parent_collection_id, count of archives).
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 tells when to use this tool (when exploring the middle tier of the hierarchy) and guides the next step: 'Pass a Collection's id to list_archives (collection_id) to see its contents.' This differentiates it from sibling tools and provides a clear workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every configured Destination: id, slot, kind (tape, localfs, nas, cloud), display name, enabled and retired flags. Retired and disabled Destinations are included; the list is unfiltered. The stored config blob (path or credential reference) is not returned. Source of the destination_id taken by verify_copy and by the policy and destination write tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only (readOnlyHint=true). The description adds that the list is unfiltered (including retired/disabled) and explicitly states that the stored config blob is not returned. This provides behavioral context beyond what annotations alone convey.
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 just three sentences, each serving a distinct purpose: listing fields, clarifying inclusion/exclusion, and noting usage context. No wasted words.
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 parameterless list tool with no output schema, the description fully explains what is returned, what is not, and how it relates to other tools. It is self-contained and informative.
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?
There are no parameters, so schema coverage is 100%. The description adds meaning by detailing the output fields and exclusion of config blob, which compensates for the lack of parameters.
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 it lists Destinations and enumerates the exact fields returned (id, slot, kind, display name, enabled/retired flags). It distinguishes from sibling list tools by focusing on the Destination resource and specifying what is not returned (config blob).
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 indicates that the list is unfiltered (includes retired/disabled), which clarifies when to use it. It also mentions it serves as the source for destination_id used by other tools, providing context for usage. However, it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent background jobs (saves, verifies, restores), newest first: verb, state, archive, destination, bytes done/total, timestamps, and — for failed or interrupted jobs — the recorded failure reason. Answers "did last night's backup finish?" and "why did the upload fail?" without opening the app.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max jobs to return (default 25, max 200). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation, such as ordering by newest first, inclusion of failure reasons for failed jobs, and the specific fields returned. This helps the agent understand what to expect.
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, two sentences, with the core purpose front-loaded. Every word adds value: it defines scope, details fields, and gives concrete examples. No unnecessary repetition.
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?
Despite lacking an output schema, the description thoroughly explains what the tool returns (verb, state, archive, destination, bytes, timestamps, failure reason) and its use cases. For a simple read-only tool with one parameter, this is 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?
The schema already describes the limit parameter with 100% coverage, so the description does not need to add much. It does not mention the parameter, but that's acceptable as the schema is sufficient. Score is baseline 3.
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 lists recent background jobs (saves, verifies, restores) with specific fields and example questions, making its purpose unmistakable. It distinguishes itself from sibling tools like list_tapes or archive_detail by focusing on jobs.
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 explicit use cases, such as checking if a backup finished or why an upload failed. However, it does not explicitly state when not to use this tool or suggest alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the top-level projects (containers). Each project owns a protection policy and holds archives; this returns the project's name, policy, archive count, and a roll-up of how many of its archives sit in each coverage state. For the individual archives, use list_archives.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds context about the return fields (name, policy, archive count, coverage state roll-up), exceeding what annotations provide.
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 concise sentences with the purpose front-loaded and no wasted words.
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?
Despite no output schema, the description fully explains what is returned and how it relates to sibling tools, making it complete for the tool's simplicity.
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?
No parameters exist, so schema coverage is 100%. Baseline score of 4 is appropriate; no additional parameter info needed.
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 lists top-level projects and explains what information each project contains, distinguishing it from the sibling tool list_archives.
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?
Explicitly tells when not to use this tool and directs to list_archives for individual archives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List known tapes with serial, volume label, uuid, capacity, used bytes, last verified time, and how many archives are stored on each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description safely adds the specific fields returned. Provides additional behavioral context beyond annotations.
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?
Single sentence, front-loaded with action and resource, no unnecessary words. Every word earned 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?
For a zero-parameter list tool, description covers the action and lists all returned fields. No output schema needed; annotations cover safety. 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?
No parameters exist, so schema coverage is 100% by default. Description adds no parameter info since none are needed; baseline 4 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 clearly states the tool lists known tapes and enumerates the fields returned (serial, volume label, etc.), distinguishing it from siblings like tape_detail or list_projects.
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 explicit when-to-use or when-not-to-use guidance, but given no parameters and sibling tools like tape_detail, usage context is implied. Adequate but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent storage activity across the library, newest first: for each event, the archive, its Destination, status, and when it was written and last verified. This is copy-level storage history; for background job runs and recorded failure reasons use list_jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows to return (default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so description need not reiterate safety. Description adds context about the nature of entries (copy-level storage history) but does not disclose any further behavioral traits beyond what annotations and schema imply.
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 sentences front-loaded with key purpose and content details. Every word is informative with no redundancy.
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 (one optional param, no output schema, good annotations), the description provides sufficient context: what is returned, ordering, and when to use an alternative 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?
Schema coverage is 100% for the single parameter 'limit', with a clear description. The tool description does not add additional meaning beyond the schema, so baseline score 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?
Description uses specific verb 'list' with resource 'Recent storage activity' and includes key fields (archive, Destination, status, write time, verify time). Distinguishes from sibling tool 'list_jobs' by stating this is 'copy-level storage history' versus 'background job runs and recorded failure reasons'.
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?
Clearly states when to use (for storage activity) and explicitly points to 'list_jobs' for job failures. Does not mention other exclusions or prerequisites, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything about one tape, identified by its serial (the barcode operators read off the cartridge): the tape's label, capacity, used bytes, last verified time, the number of archives stored on it, and the list of archives that are stored on this cartridge (id, name, project_id, size). Answers "what is on tape HIB001L9?".
| Name | Required | Description | Default |
|---|---|---|---|
| serial | Yes | The tape serial / barcode, e.g. HIB001L9. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds context beyond annotations by specifying exact fields returned and giving example. Confirms read-only behavior. No contradictions.
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 concise sentences front-loading purpose and return fields. No wasted words.
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 one-parameter tool with no output schema, description fully covers purpose, parameter, and return data. Complete for agent to use correctly.
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 already describes 'serial' as the tape barcode. Description adds real-world context: 'barcode operators read off the cartridge' and example value, enhancing understanding beyond schema.
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?
Description clearly states the tool returns all details of a single tape by serial, lists specific data fields, and includes an example. Differentiates from sibling tools like list_tapes which returns all tapes.
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?
Implicitly clear when to use: when you need details of a specific tape. No explicit exclusion criteria or contrast with siblings but context from sibling names helps. Missing explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Re-read an archive from one of its destinations and compare it to what was recorded. Default mode "full": re-hash SHA-256 plus the recorded BLAKE3 and the stored signature when present, then mark the copy Verified on a match (Failed on a mismatch, Missing if the file is gone) — the only pass that can promote, and the citable one. Optional mode "fast": a BLAKE3-only re-read that refreshes an already-Verified copy or exposes a mismatch but NEVER promotes (a matching fast pass on an unverified copy returns passed_unpromoted; an archive with no recorded fast hash falls back to a full pass with the reason surfaced). Results and audit rows name the algorithm that ran. Identify which stored archive to check by archive_id + destination_id. Works for disk and NAS destinations, and tape destinations (the cartridge is mounted and read back); cloud read-back runs in the desktop app, not here. NOTE: this is the only always-on tool that writes, and it only ever does so after a genuine read-back.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Verify mode. Default "full" (SHA-256 + recorded BLAKE3 + signature — the promoting, citable pass). "fast" is a BLAKE3-only sustain/demote check that never promotes. | |
| archive_id | Yes | The archive's id. | |
| destination_id | Yes | The Destination the archive is stored at. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool writes after a genuine read-back, which annotations don't fully capture. Details behaviors like promotion, demotion, statuses (Verified, Failed, Missing, passed_unpromoted). Aligns with annotations (readOnlyHint=false, destructiveHint=false). No contradictions.
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 moderately long but front-loaded with purpose. Every sentence adds value, though some details (e.g., algorithm names) could be condensed. Overall, well-structured and informative.
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 no output schema, the description fully explains return statuses (Verified, Failed, passed_unpromoted) and mode dependencies. Covers constraints for disk/NAS, tape, and cloud. Unambiguous about writing behavior. Complete for a complex 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?
Schema coverage is 100% (3 parameters), so baseline is 3. Description adds meaning by explaining the mode difference (fast vs full) and the role of archive_id/destination_id. Provides context that fast mode never promotes and full mode is citable.
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 starts with a clear verb and resource: 'Re-read an archive from one of its destinations and compare it to what was recorded.' It distinguishes itself from sibling tools (e.g., list_tapes, coverage_status) by focusing on verification and promotion. The two modes (full and fast) are clearly defined.
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?
Explicitly states when to use: 'the only always-on tool that writes' and 'the only pass that can promote.' Provides exclusion criteria: 'cloud read-back runs in the desktop app, not here.' Distinguishes full vs fast mode usage, including when each is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose. For example, list_tapes lists tapes, tape_detail gives details on one tape, coverage_status provides overall coverage, while catalog_stats gives inventory and capacity. There is no overlap between tools; each serves a unique function.
Tool names follow a mostly consistent pattern with underscores and descriptive terms. While some use verb_noun (list_tapes, find_file, verify_copy), others are noun_noun (coverage_status, archive_detail, tape_detail). The mix is understandable but not perfectly uniform, which could confuse an agent expecting all verbs.
With 12 tools, the server is well-scoped for managing and monitoring a backup/archive library. The count covers listing, detail views, status, verification, file search, job history, and overall stats—neither too few nor too many for its domain.
The server misses a tool to list all archives, despite list_projects referencing list_archives. This is a notable gap that could hinder agents from getting an overview of archives. Otherwise, it covers key read operations and one write/verify tool, but the missing list_archives reduces completeness.
Read-only access to your Brickway LEGO and alt-brick collection: sets, builds, figures, catalog.
Read-only game, setup, place, evidence and travel decision tools with explicit provenance.
Browse, query, and administer your managed WaveHouse + ClickHouse projects (schema, pipes, policy).
Read-only verifier for 25 ProofRelay MCP tools and non-confidential evidence bundles.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Agaveis/hiberden-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
