TrueNAS SCALE MCP server

truenas-mcp

An MCP server for TrueNAS SCALE. Read-first, deployable as a TrueNAS app, and authenticated with each user's own API key.

Status: working, young. Every capability in the design is implemented and

verified against a live TrueNAS 26 box. Expect rough edges rather than gaps.

Why this exists

iX ship an official truenas/truenas-mcp, and if it fits your needs you should use it. This one exists for three things it does not do:

and reached from elsewhere.

• It only speaks stdio, so it cannot be deployed as a container on the NAS

reach no matter how they authenticate.

• It holds a single server-wide API key, so every caller gets identical

way to pull new images and redeploy an app you already run.

• Its app coverage is catalog-shaped — install, uninstall, browse — with no

Design

Three ideas do most of the work.

The credential is the authorization. Callers supply their own TrueNAS API key; this server stores none. A session reaches exactly what that user's key permits, revocation happens in the TrueNAS UI, and there is no shared secret to leak. Authentication and authorization stop being two systems that can disagree. Served over stdio the key arrives from the environment instead, because there is no request to carry it — but the client spawns one process per user, so it is still that user's own key. What the design rules out is one key standing in for many callers, not configuration as such.

Reads and writes get different tool shapes. Reads are grouped into concern-level tools with an op enum, because they share most of their arguments and 815 middleware methods cannot each become a tool. Writes are individual tools — MCP annotations are per-tool, so bundling a safe operation with a destructive one behind one op parameter would put both behind a single consent gate, and a user who tires of confirming list_pools will allowlist the tool that can also export a pool.

Read-only by default. Mutating tools appear only when explicitly enabled. Separately, a denylist of unrecoverable operations is not reachable under any configuration, and it constrains argument values rather than just method names — deleting an app is recoverable, deleting it along with its volumes is not, and those are the same method.

Each of these was measured against a live box rather than reasoned about in the abstract, and several were overturned by what that measurement found.

Requirements

server speaks only the versioned JSON-RPC 2.0 WebSocket API.

• TrueNAS SCALE 25.04 or later. The REST API is removed in TrueNAS 26; this

• A TrueNAS API key per user. Create them under Credentials → API Keys.

Deploying as a TrueNAS app

Copy deploy/truenas-custom-app.yaml, adjust TRUENASMCPTARGET, and paste it into Apps → Discover → Install via YAML.

It mounts no host socket and requests no privileged access. The server reaches the middleware over the network even when running on the same box, so that every connection carries a user identity rather than root-equivalent socket access.

Running it elsewhere

Nothing requires the server to run on the machine it manages, and there is a good reason not to: installed as a TrueNAS app, it is unavailable exactly when the box is unhealthy — which is when you most want to ask it what is wrong.

docker run -p 8080:8080 \
  -e TRUENAS_MCP_TARGET=nas.local \
  -e TRUENAS_MCP_TLS_CERT=/tls/cert.pem \
  -e TRUENAS_MCP_TLS_KEY=/tls/key.pem \
  ghcr.io/cedricziel/truenas-mcp:main

Running the binary

Each GitHub release attaches binaries for Linux, macOS, and Windows on amd64 and arm64, alongside a checksums.txt. Configuration is environment variables only — there is no config file, and the only flags are --stdio and --healthcheck.

Shortened. The full README is on GitHub.