The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Longhorn MCP listing page.
An MCP server for the Longhorn distributed storage manager API. Full read/write coverage of Longhorn's REST API (volumes, snapshots, backups, backing images, nodes, settings, engine images, recurring jobs, and more), a --read-only mode, both stdio and Streamable HTTP transports, and an official Helm chart.
AI-assisted development. The majority of this codebase — implementation, tests, and this documentation — was written with AI assistance (Claude). Review accordingly, especially before running write-mode tools against a production Longhorn cluster.
Longhorn's manager API is unauthenticated — reachability is the only access control. If you're not running this against an in-cluster Longhorn (see Connecting popular MCP clients → Remote/HTTP), you'll need a VPN, SSH tunnel, or kubectl port-forward svc/longhorn-backend 9500:9500 to reach it safely. Never expose Longhorn's manager API directly to an untrusted network.
| Flag | Default | Description |
|---|---|---|
--http | off (stdio) | Serve Streamable HTTP instead of stdio. |
--port | 3000 | HTTP listen port (with --http). |
--host | 0.0.0.0 | HTTP listen address (with --http). |
--read-only | off | Register only read tools; the client also refuses any non-GET request. |
--longhorn-url | http://longhorn-backend.longhorn-system.svc.cluster.local:9500 | Base URL of the Longhorn manager API. Standard Kubernetes cluster-local DNS by default — a cluster with a custom cluster domain overrides this via --longhorn-url in its own Deployment rather than changing this package's default. |
--allowed-hosts | localhost,127.0.0.1 | Comma-separated Host/Origin allowlist for --http mode. Must include every hostname/IP:port the server will actually be reached on — see MCP spec DNS rebinding guidance. |
An official chart is published alongside every release:
Key values:
| Value | Default | Notes |
|---|---|---|
image.repository / image.tag | ghcr.io/rafaelgaspar/longhorn-mcp / chart appVersion | |
args | ["--http"] | Append --read-only, --longhorn-url, --allowed-hosts, etc. — see CLI reference. |
service.enabled / .type / .port | true / ClusterIP / 3000 | |
route.enabled | false | Optional, vendor-neutral core Gateway API HTTPRoute (gateway.networking.k8s.io/v1) — no Envoy Gateway-specific resources. Bring your own Gateway and set route.parentRefs/route.hostnames. |
serviceAccount.create | true |
Full schema: chart/values.yaml / chart/values.schema.json.
The chart is also attached as an OCI referrer directly on the image manifest, for tooling that discovers charts via the OCI Referrers API instead of pulling a separately tagged artifact:
Each client's exact config file path/key can drift between versions — check the client's own docs if these don't work. All of them accept the same underlying command/args shape for a local stdio server.
Edit claude_desktop_config.json:
Edit .cursor/mcp.json (project-scoped) or ~/.cursor/mcp.json (global):
.vscode/mcp.json uses a servers key (not mcpServers):
To point a client at an already-running Streamable HTTP instance (e.g. this server deployed in-cluster, see Deploying with Helm) instead of spawning a local npx process, use that client's remote-MCP configuration with the server's /mcp URL. Clients without native remote-HTTP MCP support can bridge via mcp-remote.
Longhorn's manager API — and by extension this server — has no authentication of its own; reachability is the access control (see Quick start). For a multi-tenant or externally-reachable deployment, fronting --http mode with an MCP-aware gateway (e.g. Envoy AI Gateway or similar) for auth, rate limiting, and routing is a good idea. It's not required, though — a private network boundary (VPN, SSH tunnel, cluster-internal only) is a perfectly reasonable standalone posture too, and is exactly what the Helm chart defaults to (route.enabled: false, no external exposure).
--read-only is an enforced, structural guarantee (see below); the following is a softer, model-facing one — it shapes what a well-behaved LLM should do, not what the server can refuse.
Every tool whose action is destructive or hard to reverse (deletes, force-detaches, reverts, restores cluster-wide state, evicts a node, deploys an arbitrary engine image, redirects a backup target, etc.) has its description suffixed with an explicit instruction not to call it unless the user has explicitly authorized that specific action in the current conversation, and never proactively, speculatively, or as a side effect of an unrelated task. The server's MCP instructions field (surfaced by clients that support it, in addition to each tool's own description) repeats the same guidance at the server level as a backstop for tools called without reading their full description closely.
This is advisory, not enforced — a client or model can ignore it. It reduces the chance of an LLM calling volume_delete or systemrestore_create as an unprompted "helpful" side effect; it is not a substitute for --read-only where that's the guarantee you actually need.
Most tool descriptions end with a Longhorn docs: <url> link to the relevant page in Longhorn's official documentation, pinned to the Longhorn version this server's default --longhorn-url target runs (currently 1.12.1) rather than "latest," so the linked content matches the API version actually in use. A handful of tools with no clearly corresponding doc page (instancemanager_*, volumeattachment_*, longhorn_events, volume_job_list, the longhorn_raw_request/longhorn_list_resource_types/longhorn_describe_resource_type introspection tools) don't have one.
Every Longhorn resource returned by this server (a volume, node, backing image, ...) embeds an actions map of the RPC actions currently valid for it, e.g. a volume's actions.attach. Longhorn's own API returns these as URLs pointing at the manager's in-cluster address — useless to an MCP client, which can only call tools, not arbitrary HTTP endpoints. This server rewrites each one into the MCP tool that performs it instead, alongside that tool's parameter shape (name -> compact type, ? suffix for optional) so a client can call it without a separate schema lookup, e.g.:
args (as above on updateReplicaCount) appears when the action already pins down one of the tool's parameters — Longhorn's ~19 single-field volume update* actions all route through the one volume_update_setting tool, distinguished only by which setting value to pass. shape always lists every parameter the tool takes, including ones already pinned via args, so a pinned value can always be resolved against shape without a separate lookup.
Every action every resource type's schema currently declares maps to a named tool this way — including volume's undocumented jobList, via volume_job_list (Longhorn publishes no input/output schema for it, so that tool accepts an open-ended extra object; see longhorn_describe_resource_type('volume') to check the deployed version's exact shape). Any action a future Longhorn version adds that this server hasn't caught up to yet falls back to longhorn_raw_request instead, with args.method/args.path pre-filled from the original URL. Since Longhorn only lists actions currently valid for a resource's state (e.g. salvage only appears on a faulted volume), this reflects what's actually callable right now, not just what the tool schema allows.
--read-only enforces itself two ways:
tools/list, so a read-only instance's tool set is a strict subset of the read-write one.LonghornClient refuses any non-GET request regardless of which tool triggered it. This is what protects longhorn_raw_request, the one escape-hatch tool that stays registered in both modes (its write-ness isn't known until it's actually called).Run both a read-write and a read-only instance under different names in the same client config if you want an LLM session to default to read-only but have an explicit, differently-named write-capable tool set available:
scripts/introspect-schema.ts dumps a live Longhorn manager's self-described /v1/schemas — useful for cross-checking this package's hand-written tool coverage against whatever Longhorn version you're actually running:
Contributions are welcome — see CONTRIBUTING.md for dev setup, coding conventions, and how releases work.
MIT — see LICENSE.