TrueNAS MCP

Install App

install_app

Install an app from the TrueNAS catalog using a catalog app ID, unique app name, and JSON chart values; preview with dry-run by default before actual installation.

Instructions

Install an app from the TrueNAS catalog.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app_name": "<app_name>",
      "catalog_app": "<catalog_app>",
      "values": "<values>"
    },
    "name": "install_app"
  }
}

Input Schema

Name	Required	Description	Default
`train`	No	Catalog train, default "stable".	stable
`values`	Yes	JSON string of the app install values/config (the chart values).
`dry_run`	No	Preview only (default True); set False to actually install.
`version`	No	App version, default "latest".	latest
`app_name`	Yes	Unique name for the installed app instance (lowercase, no spaces).
`catalog_app`	Yes	Catalog app id, e.g. "jellyfin" or "custom-app".

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Oct 23, 2026

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, but it only says 'Install an app.' It omits critical behavior from the schema, notably that dry_run defaults to true and must be set false to actually install, and it does not mention mutation side effects, permissions, or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is a single front-loaded sentence with no wasted words. It is as concise as possible for the stated purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with six parameters and no annotations. Although an output schema exists and need not be described, the description fails to cover the dry-run default safety behavior or install prerequisites, leaving the agent without key context for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema documents all six parameters including dry_run, train, and app_name. The description adds no parameter-level meaning beyond the catalog source, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: install an app, sourced from the TrueNAS catalog. It clearly distinguishes installation from sibling operations like start_app, update_app, and upgrade_app, though it does not explicitly name those alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use install_app versus start_app or upgrade_app, nor any prerequisite such as the catalog app needing to exist. Usage is only implied by the verb 'install'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.