Hiberden

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 whatverify_copyrecords: 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. Seedocs/Hiberden_MCP_Command_Surface_and_Permission_Model.md(which supersedesdocs/mcp/write-gate-design.md).

verify_copyis the differentiator: it is proof from the actual medium, not a stored flag. Identify the copy byarchive_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:
- TheHIBERDEN_DBenvironment variable, if set.
- Otherwise%LOCALAPPDATA%\Hiberden\catalog.dbon Windows, or~/.hiberden/catalog.dbon 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 samecatalog.dbat 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.

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 --version

hiberden-mcp-linux-x86_64is 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:

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 usage

installwrites (or updates) anmcpServers.hiberdenentry pointing at this executable. It is zero-config for the catalog: the entry only pinsHIBERDEN_DBwhen you already have it set in your environment, otherwise it relies on the default%LOCALAPPDATA%\Hiberden\catalog.dbpath.

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 samemcpServersshape).commandis the path to the executable.envis optional: includeHIBERDEN_DBonly 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-mcp

- Local-only and closed-domain. The server is read + verify only and performs zero network I/O; the only state it writes is the copy statusverify_copystamps 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_copygives 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.

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: setHIBERDEN_TAPE_FAKE=1(and optionallyHIBERDEN_TAPE_FAKE_ROOT=<dir>to point at a directory standing in for the mounted volume).

Parses various file formats using the 302.AI API, requiring a 302AI_API_KEY.

A local server that allows AI to execute Windows CMD commands, read/write files, and manage directories within a specified path.

Filesystem agent memory working with consolidation Daemon on your machine

An AI-powered MCP server for advanced file system operations, including search, comparison, and security analysis.

Securely browse and read files within an Android project, with built-in validation and access controls for sensitive directories.

Build a persistent, local knowledge base in Markdown files through conversations with LLMs.

A read-only MCP server for querying live FTP data using the CData JDBC Driver.

An MCP server for viewing, editing, and creating text files, based on the Claude built-in text editor tool.

Convert PDF, Word, Excel, PowerPoint, EPUB, HEIC and images from Claude or Cursor, with 35 converters exposed through just two MCP tools.