nasbridge
Provides tools to manage TrueNAS systems, including ZFS pools and datasets, SMB/NFS/iSCSI shares, snapshots, replication, VMs, alerts, and network configuration.
Click on "Deploy 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., "@nasbridgeCreate a dataset on tank with lz4 and daily snapshot task"
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.
nasbridge — control TrueNAS from Claude
An MCP server for TrueNAS that lets Claude Desktop, Claude Code, Cursor or any other MCP client manage your NAS — ZFS pools and datasets, SMB and NFS shares, snapshots, replication, VMs, alerts and network config. 278 actions in all.
Ask for "a dataset on tank with lz4 and a daily snapshot task", or "which pools are degraded", and it happens over the wire rather than through the web UI.
TrueNAS 26 drops the REST API in favour of JSON-RPC 2.0 over WebSocket, so this server speaks that transport directly.
One tool, not 278
The design decision worth stealing: this exposes a single hierarchical
truenas tool rather than one tool per action.
Most MCP servers register a flat tool per operation. At 278 actions that consumes a large share of the context window before the model has done any work, and degrades tool selection as the list grows. Here the model discovers categories, lists the actions in one, then executes with parameters — three cheap round trips instead of a permanently expensive tool manifest.
Related MCP server: truenas-ws-mcp
How it works
This started as a fork of the truenas-mcp package, which targets the REST API
that TrueNAS 26 removed. The tool handlers are largely unchanged — they still call
a REST-style client (client.get/post/put/delete). What was rewritten is
everything beneath: a path-translator maps each REST path to its JSON-RPC method
(GET /pool becomes pool.query, PUT /pool/id/1 becomes pool.update), and a
ws client sends those calls over a single authenticated WebSocket connection.
Keeping the REST-shaped seam meant the 278 handlers did not have to be rewritten to change transport.
Authentication is auth.login_with_api_key on connect. The connection keeps itself alive with a 30s core.ping. Long-running operations are tracked via core.get_jobs.
Tools
The truenas tool takes category, action and params:
No args or
category="help"— list all categories with action countscategoryonly — list the actions in that category and their parameterscategory+action+params— execute
278 actions are wired across these categories:
Category | Covers |
| System info, services, mail, API keys, power, NTP |
| Pools, datasets, snapshots, periodic snapshot tasks |
| SMB, NFS and iSCSI (targets, extents, portals, initiators) |
| Interfaces, global config, static routes, staged changes |
| Virtual machines and VM devices |
| System alerts and alert notification services |
| Replication, cloud sync/backup, cron, rsync, SSH credentials |
| stat, listdir, mkdir, permissions, ACLs, ownership |
Destructive actions (reboot, shutdown and similar) require an explicit confirm: true parameter.
Resources
Read-only resources surface common state without a tool call: truenas://system/info, truenas://storage/pools, truenas://storage/datasets, truenas://services, truenas://alerts, truenas://network/summary, truenas://sharing, truenas://vms, truenas://apps, truenas://disks, truenas://boot/environments and truenas://system/update.
Configuration
Variable | Required | Default | Notes |
| yes | — | TrueNAS host or URL. |
| yes | — | Generate in TrueNAS: Credentials → API Keys → Add |
| no |
| Set |
The client connects with wss:// by default. A self-signed cert needs TRUENAS_VERIFY_SSL=false.
Don't pass a
ws://URL.http://andhttps://are rewritten towss://, but an explicitws://is left alone — and TrueNAS auto-revokes any API key it sees used over an insecure transport. You get an authentication failure that looks like a bad key, and the key really is dead. Regenerate it and connect overwss://.
Requirements
TrueNAS 26 or later (earlier versions expose a different WebSocket shape)
Node.js 18+ (CI proves the built server imports on 18 and 22)
A TrueNAS API key — Credentials → API Keys → Add
An MCP client: Claude Desktop, Claude Code, Cursor, or anything else speaking MCP
Install and run
git clone https://github.com/maverick0628/nasbridge.git
cd nasbridge
npm install
npm run build
TRUENAS_URL=https://truenas.local TRUENAS_API_KEY=1-yourkey node dist/cli.jsCreate the API key in the TrueNAS UI under Credentials → Local Users → API Keys.
Keep it in your MCP client config or a local .env, never in the repo — .env is
gitignored for that reason.
The server speaks MCP over stdio. Add it to your MCP client config — for Claude
Desktop that is claude_desktop_config.json, for Claude Code .mcp.json:
{
"command": "node",
"args": ["/path/to/nasbridge/dist/cli.js"],
"env": {
"TRUENAS_URL": "https://truenas.local",
"TRUENAS_API_KEY": "1-yourkey",
"TRUENAS_VERIFY_SSL": "false"
}
}Tests
npm testUnit tests cover the REST-to-WebSocket path translator and the client against a mock WebSocket server. test/e2e-live.mjs runs the dataset create/get flow against a real TrueNAS instance.
Notes
TrueNAS 26 tightened dataset validation: atime, compression and sync must be uppercase string literals (ON, OFF, LZ4, STANDARD). The storage tools normalise these before create/update, so the model can pass natural values.
Built against TrueNAS 26. Earlier versions expose a different WebSocket API shape and are not supported.
License
MIT — see LICENSE.
Available Tools
1 tooltruenasA
Manage your TrueNAS system. 278 actions organized in categories.
Usage:
No args or category="help" → list all categories
category only → list available actions in that category with parameters
category + action → execute (pass action-specific params in 'params')
Categories: system, storage, sharing, network, vm, alert, replication, filesystem
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action name within the category (e.g. 'pool_list', 'dataset_create'). Omit to discover available actions. | |
| params | No | Action-specific parameters as key-value pairs. Discover required params by calling with just category. | |
| category | No | Category name: system, storage, sharing, network, vm, alert, replication, filesystem |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully reveals the two-step discovery workflow and that the third step executes an action. However, it does not mention whether actions may be destructive, require authentication, or what the return/response looks like. The described behavior is accurate but lacks safety/state-change context.
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, well-structured, and front-loaded with the core purpose. The bulleted usage modes are efficient and each sentence contributes either to purpose or to the invocation protocol. The category list is compact and complete.
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 meta-tool exposing 278 actions, the description provides a complete discovery protocol and lists all top-level categories, making the tool usable in practice. The absence of an output schema means return values are not documented, but the stepwise discovery mechanism compensates by letting the agent learn on the fly. Slight gap: no mention of error handling or authentication expectations, though these are per-action details.
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 provides descriptions for all parameters (100% coverage), so the description adds little beyond what is already structured. It reiterates that omitting action discovers actions and that params are discovered by calling with category only. This repetition confirms the discovery flow but does not add new field-level insight such as value formats or examples.
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 manages TrueNAS and enumerates 278 actions across specific categories (system, storage, sharing, etc.), which grounds its purpose. The verb 'manage' is broad, but the category list and usage modes make the tool's role as a gateway/dispatcher apparent. It does not need sibling differentiation because no siblings are listed.
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?
Usage is explicitly and clearly specified with three distinct invocation patterns: no args or category='help' lists categories, category alone lists available actions, and category+action executes with params. This is directly actionable guidance with no ambiguity, and it even explains how to discover required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
truenas
TDQS
Scored across 1 tool
There is only one tool in the set, so there can be no confusion between tools. The single tool's purpose and usage are clearly described, making it unambiguous to an agent.
With only one tool named 'truenas', there is no inconsistency in naming conventions. The name is a clear, lowercase identifier, even though it does not follow a verb_noun pattern.
A single tool is far too few for the broad scope of managing a TrueNAS system. This forces agents to use a hierarchical dispatcher with 278 actions, which is inefficient and difficult to navigate compared to a proper tool set.
The tool lists categories covering many core NAS areas, but user management is notably absent from the listed categories. While 278 actions likely provide extensive coverage, the single-dispatch design obscures the true completeness and creates potential gaps.
Maintenance
Related MCP Connectors
- mcpOAuthcom.gibsonai
GibsonAI MCP server: manage your databases with natural language
- ZapierOAuthcom.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for Gainium — manage trading bots, deals, and balances via AI assistants
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Related MCP Servers
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables Claude Desktop and other MCP clients to interact with TrueNAS Core systems through the TrueNAS API, supporting user management, storage operations, sharing, and snapshot creation.2059,702 PyPI31MIT
- AlicenseBqualityDmaintenanceMCP server for TrueNAS Scale that enables AI assistants to manage storage pools, datasets, apps, VMs, snapshots, and more via the native WebSocket API.59MIT
- AlicenseAqualityAmaintenanceAI-powered MCP server for TrueNAS SCALE storage operations with governance and safety features, enabling management of pools, datasets, snapshots, disks, alerts, and services.25MIT
- AlicenseNot gradedqualityAmaintenanceAn MCP server for TrueNAS SCALE that enables read-first management of storage, system, sharing, and virtualization resources with per-user API key authentication, and optional write operations.1MIT