From truenas-mcp
Capture the state of a TrueNAS NAS (pools, networks, deployed apps, inferred naming and path conventions) BEFORE any architecture decision is made. Use at the very start of any "deploy / install / set up X on the NAS" request, or whenever the agent needs a fresh picture of what exists on the NAS. Read-only; produces a structured NAS profile that downstream skills consume. Hands off to truenas-deployment-planning.
How this skill is triggered — by the user, by Claude, or both
Slash command
/truenas-mcp:truenas-discoveryThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill builds the **NAS profile** that every subsequent skill in
This skill builds the NAS profile that every subsequent skill in this plugin consumes. It is read-only: it reads the NAS state via the MCP server's tool surface and presents what it found to you. It never modifies anything on the NAS.
The MCP server is mechanism. Discovery is the eye: it tells the rest of the pipeline what is actually there, so planning and deployment do not have to guess.
Run this skill at the start of:
Do not run discovery if it has already produced a profile earlier in this conversation AND the user has not asked for a refresh — the profile is in-session state. If in doubt, run it again; it is read-only.
Every claim Discovery makes falls into one of three buckets:
| Bucket | Source | How it's presented |
|---|---|---|
| Fact | A TrueNAS API call returned it | Stated plainly |
| Assumption | Derived from observed patterns (e.g. naming inference from existing apps) | Marked "assumption" with confidence; user confirms or corrects |
| Unknown | Not retrievable with current tools | Stated explicitly as "unknown" with reason |
An inference is never silently adopted. The output schema (below) keeps the three buckets separate.
Call test_connection.
connected == false: stop. Show the error and recovery hint.
Discovery cannot proceed without a session.app.create schema and the auth flow this plugin targets are 25.04+.Call get_system_info.
Capture as facts:
These are exact API answers. Do not invent pool names; use only the ones the API returned.
Call list_apps. For every app in the result, call
get_app_details in batches of up to 3 in parallel — wait for each
batch to complete before starting the next. This caps concurrent
API load without dropping coverage on installations with many apps.
From the collected app data, derive:
Naming convention (assumption, confidence-rated)
^[a-z][a-z0-9-]+$ matches all → "kebab-case"-prod|-test|-staging recurs → record suffix<prefix>- recurs → record prefixhigh if all samples fit one pattern, ≥5 samplesmedium if all samples fit, 3–4 sampleslow if mixed or only barely consistentPath convention (assumption, confidence-rated)
volumes (bind mounts under
/mnt/)./mnt/<pool>/<app>/... vs
/mnt/<pool>/apps/<app>/... vs /mnt/<pool>/<other-segment>/<app>/.Pool workload assignment (assumption)
<fast-pool>, <bulk-pool>) — record the hint, ask
the user to confirm.Call get_docker_networks.
Capture as facts:
Derive (assumption):
Reverse-proxy / app network candidate
proxy|traefik|caddymacvlan AND ≥2 apps share it (requires
the app detail data collected in Phase 3 — run Phase 3 first)Present the profile to the user in this exact shape:
NAS profile — <hostname> (TrueNAS Scale <version>)
═══════════════════════════════════════════════════
Facts (from API):
TrueNAS version: <version>
Hostname: <hostname>
Uptime: <uptime>
Storage pools:
<name> <status> <healthy>
...
Docker networks:
<name> <driver> <subnet>
...
Apps deployed: <N>
<name> (<status>) → pool <inferred-pool>
...
Assumptions (please confirm):
Naming convention: <pattern> confidence: <low|medium|high>
sample size: <N>
Path convention: /mnt/<pool>/<app>/ confidence: <…>
Pool workloads:
<pool>: <N apps> — likely <inferred role>
...
App network candidate: <name or "none detected">
Unknown (please clarify when relevant):
- Vdev topology per pool (no MCP tool yet)
- Pool hardware type (NVMe / HDD / SSD)
- External-facing network identity (which network is LAN-routable)
Wait for the user to confirm or correct the assumptions before handing off.
Once the user confirms (or corrects), say so explicitly and pass the confirmed profile forward. From here:
truenas-deployment-planning takes over for architecture decisions.The MCP server does not expose tools for:
Mark these as "unknown" in the profile and ask the user when the answer matters. Adding these tools is a separate future spec.
npx claudepluginhub svnstfns/claude-marketplace --plugin truenas-mcpProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.