MCP-TrueNAS

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct TrueNAS resource (pools, datasets, alerts, disks, services, jobs, snapshots, VMs, etc.), with clear separation between existing resources and their scheduled task configurations (e.g., snapshots vs snapshot_tasks, jobs vs replication_tasks/cloudsync_tasks/scrub_tasks). The descriptions explicitly clarify potentially confusing pairs.
Naming Consistency5/5
All tool names follow the same 'truenas_' prefix plus a verb_noun pattern (list_*, get_system_info, check_updates, connection_status). Naming is uniformly lowercase snake_case with consistent verbs, making it easy to predict tool names for new resources.
Tool Count4/5
With 18 tools, the server is on the heavier side but justifiable for a comprehensive TrueNAS monitoring surface. Each tool covers a unique functional area, so none feel redundant. The count is slightly high but well within acceptable bounds for a full-featured NAS monitoring server.
Completeness4/5
As a read-only monitoring server, it covers all major TrueNAS operational areas: storage health (pools, datasets, snapshots, disks), services, networking, system info, alerts, jobs, VMs, apps, updates, and backup task configurations. Minor gaps exist (e.g., no single-item detail retrieval, no performance metrics), but these are workarounds via filters and pagination.
Average 4.3/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no additional behavioral traits beyond the fields returned, which is useful but not rich behavioral context. There is no contradiction with annotations.
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 description is a single sentence that front-loads the action and resource, then lists the specific data fields. Every part is informative and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only system info tool with one optional parameter and an output schema, the description is sufficiently complete. It covers all key data points and relies on the schema for response_format details. It could mention error behavior, but that is beyond the expected scope for a simple getter.
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?
There is one parameter (response_format) with 100% schema coverage, including an enum and descriptions for 'markdown' and 'json'. The description does not mention the parameter or add any semantics beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and a clear resource 'system information from TrueNAS', and enumerates the exact data fields returned (product version, hostname, uptime, CPU, memory, load, boot time, timezone). This distinguishes it from sibling tools that target specific subsystems like pools or datasets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by listing the system-wide metrics covered, implicitly indicating that this tool is for holistic system info rather than component-specific lists. It does not explicitly name alternatives or exclusion criteria, but the field list makes the intended usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds a valuable behavioral guarantee: 'Credentials, tokens, and secrets are deliberately never included.' This goes beyond annotations by assuring users about sensitive data handling. It does not cover all behaviors (e.g., pagination) but provides useful context.
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 description is two sentences, front-loaded with the action and resource, and every clause adds value (field list, provider examples, credential exclusion). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, an output schema, and read-only annotations, the description sufficiently covers what the tool does and important caveats (no secrets). It doesn't need to explain return values because an output schema exists.
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 coverage is 100% with the response_format parameter fully described in the schema, including enum values and default. The description itself adds no extra parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('configured cloud sync tasks'), and elaborates with concrete field details (local path, direction, provider, schedule, last-run state) and provider examples (S3, Google Drive, Backblaze). This clearly distinguishes it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (whenever cloud sync task info is needed) but does not explicitly mention alternatives or exclusions. It lacks guidance on when not to use it or how it differs from other list tools beyond the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is safe. The description adds that it returns running state and boot-start status, which is useful but does not disclose deeper behaviors like filtering or pagination; this matches the baseline for annotation-covered tools.
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 description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose and key output fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with good annotations, an output schema, and fully documented parameters, the description is sufficient. It conveys the domain and output, while schema and annotations cover the remaining details.
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?
The input schema already provides 100% coverage with descriptions for both parameters (state and response_format), including enums and defaults. The description adds no extra meaning about parameters, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'TrueNAS services' with examples (SMB, NFS, SSH, iSCSI), clearly distinguishing it from sibling list tools. It also states the output includes running state and boot-start status, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for listing services, and the examples indicate which kind of services, but it does not explicitly mention alternatives or when-not-to-use it. Since the scope is self-evident and no exclusions are stated, it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares it a safe read operation, and the description adds useful context by noting the exact output fields (name/path, enabled state) and the 'all configured' scope. However, it does not disclose any potential limits (pagination, performance) or clarify what 'enabled state' means. This is on par with the calibration example where annotations carry the safety profile.
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 description is two concise sentences. The first sentence front-loads the action and specific output, while the second provides a user-oriented summary ('what is this NAS actually serving?'). No redundant words or phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a read-only listing operation with a single optional parameter and an output schema present. The description sufficiently covers the scope, returned fields, and purpose without needing to detail return structures since an output schema exists. It is complete for the complexity level.
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?
The input schema is fully covered (100% coverage) with a clear description of the single response_format parameter, including enum values and default. The tool description does not add parameter-level detail, but the schema already provides complete information, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and explicitly names the target resources: 'SMB shares, NFS exports, and iSCSI targets'. It also states the scope ('all configured') and the useful output ('each with their name/path and enabled state'). This clearly distinguishes it from sibling tools that list pools, datasets, alerts, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The title and description make it obvious this is the tool for listing file and block shares across all three protocols. It does not explicitly mention when not to use it or suggest alternatives, but the context signals and sibling list clearly delineate it as the sole share-listing tool. The phrase 'in one call' hints at the consolidated use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable context by deliberately noting that device details, including VNC display passwords, are omitted—an important behavior for security and expectation setting.
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?
Two sentences front-load the action and provide a complete summary of included fields and the deliberate omission. No redundant words or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and a read-only list operation, the description covers the key return fields and notes the omitted sensitive details. This is sufficient for an agent to decide to call the tool and interpret results.
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?
The only parameter (response_format) is fully described in the schema with enum values and default; description coverage is 100%. The tool description adds no extra parameter meaning, matching the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists virtual machines and enumerates the specific attributes returned (run state, autostart, vCPU/memory, bootloader, device summary). This distinguishes it from sibling list_* tools that target other resources like pools or disks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool name and description; it is evident this is for enumerating VMs. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives for obtaining full device details, which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds useful behavioral context by specifying that the tool reports the current version, candidate version, release notes, and reboot waiting status. It also clarifies scope limitations (no app updates). No contradictions with annotations exist.
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 description is three sentences, front-loading the primary action, followed by output details and a scope note. Every sentence contributes meaningful information with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional parameter, output schema exists, annotations present), the description is complete: it states what is checked (update availability, reboot pending), what is reported (versions, release notes), and what is excluded (app updates). This is sufficient for an agent to correctly select and invoke the tool.
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 coverage is 100%. The single parameter 'response_format' is fully documented in the schema with enum values and descriptions. The tool description adds no additional parameter semantics, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check whether a TrueNAS base-OS (system) update is available, and whether the system is waiting on a reboot.' It specifies the resource (TrueNAS OS) and distinguishes itself from app/catalog updates, making it distinct from sibling tools like truenas_list_apps. It also enumerates the key outputs (current version, candidate version, release notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit exclusion: 'this covers the TrueNAS OS only — it does NOT check for app/catalog updates,' which constitutes a clear when-not-to-use. The context for when to use is implied by 'Check whether... update is available.' However, it does not name an alternative tool, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds valuable behavioral context about the default hiding of dismissed alerts and the 'current' nature of the listing, which goes beyond the structured annotations. No contradiction found.
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 description consists of two efficient sentences: the first defines the tool's purpose with examples, the second covers default behavior and parameter usage. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with full parameter documentation, an output schema, and annotations declaring read-only safety, the description is complete. It covers the essential behavior and filtering guidance without unnecessary detail.
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?
The input schema has 100% coverage of all three parameters with detailed descriptions and defaults. The description's mention of min_level and dismissed alerts only reinforces schema information without adding new semantic meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists current TrueNAS alerts with specific examples (warnings, errors, hardware problems, update notices). This distinguishes it from sibling list tools that target other resources, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (when current alerts are needed) and even suggests using min_level to filter for serious alerts. It does not explicitly mention alternatives or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds context by listing the specific data fields returned and noting pagination. No contradictions with annotations, and no need to disclose destructive behavior.
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?
Two sentences are front-loaded with the action and resource, followed by compact details on output fields and usage. No waste; every clause adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description is complete given the presence of an output schema and annotation. It covers both dataset types, key output attributes, and usage hints. No critical gaps.
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%, with each parameter (pool, limit, offset, response_format) already documented in the input schema. The description merely echoes 'filter by pool' and 'paginate' without adding new parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource 'ZFS datasets (filesystems and zvols)' and enumerates the returned attributes (space, snapshot usage, quota, compression, mountpoint). This makes it distinct from siblings like list_pools and list_snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical context: 'Filter by pool and paginate for large systems.' This indicates when to use the tool but does not explicitly mention alternatives or when-not-to-use it relative to other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable context about temperature readings being cached ~5 minutes by TrueNAS, which is a behavioral trait beyond the annotation. This helps the agent understand potential staleness of temperature data.
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 description is a single, well-structured sentence that front-loads the action and resource, then details the returned fields and optional temperature. No wasted words; every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the presence of an output schema, and the readOnlyHint annotation, the description is sufficient for the agent to select and invoke the tool correctly. It covers output contents, optional parameters, and the caching caveat, making it complete for this context.
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?
The input schema fully describes both parameters (response_format and include_temperatures) with descriptions and defaults, achieving 100% schema coverage. The description does not add any additional parameter semantics beyond what the schema already provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'physical disks' and enumerates the exact attributes returned (model, serial number, size, type, pool, optional temperature). This clearly distinguishes it from sibling tools like truenas_list_pools, which list pools rather than disks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving physical disk inventory, including optional temperature readings. It does not explicitly state when to use this over alternatives or exclude any scenarios, but the context is clear from the tool name and description. Score 4 for clear implied usage without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the tool is known to be safe. The description adds behavioral context by specifying the exact data returned (e.g., per-interface type, link state, MAC, addresses, MTU) and calls it a 'compact health view.' It does not reveal potential edge cases or rate limits, but with strong annotations and output schema, this is sufficient for a read-only listing tool.
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 description is two sentences, front-loaded with the core concept 'Compact network health view,' and includes a concise enumeration of data fields. The final sentence provides actionable use cases without any filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, one optional parameter, and an existing output schema, the description is complete enough. It covers the tool's scope, return content, and intended use case. The output schema handles detailed return structure, so the description doesn't need to elaborate further.
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?
The input schema covers 100% of the single parameter (response_format) with a clear enum, default, and explicit description. The tool description itself does not mention the parameter, but per the rubric, baseline is 3 when schema coverage is high. No additional semantic value is needed from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it provides a 'compact network health view' with a specific list of data (IP addresses per interface, default routes, DNS nameservers, per-interface type, link state, MAC, addresses, MTU). It also distinguishes itself from siblings by positioning as 'the first stop' for network health queries and NIC diagnostics, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: 'The first stop for 'is the NAS's networking okay?' or diagnosing a down NIC.' It does not explicitly name alternatives or exclusion criteria, but it establishes a clear primary use case. Sibling tools like truenas_connection_status exist, but no direct comparison is provided, so this is a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds contextual detail about the output content (health, capacity, fragmentation, running scrub/resilver). This goes beyond the structured annotations by describing what the tool reveals about system state, without contradicting the read-only nature.
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?
Two sentences, front-loaded with the action and resource, followed by data details and usage pointer. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with one optional parameter, full schema coverage, and an output schema, the description provides ample context: what data is included, the usage scenario, and the fact it's a first-stop overview. No significant gaps remain.
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?
The single parameter (response_format) is fully described in the schema with enum and default, giving 100% schema coverage. The description does not add extra parameter semantics, but with complete schema documentation the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List') and resource ('all ZFS storage pools'), and enumerates the exact data returned (health status, capacity, fragmentation, scrub/resilver). This distinguishes it from sibling tools like list_datasets or list_disks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context with 'The first stop for how are my pools? or how full is my NAS?', indicating when to reach for this tool. It does not explicitly exclude alternatives or name sibling tools, but the purpose is specific enough that usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, so the bar is lower. The description adds valuable context: it clarifies that it lists scheduled tasks (not currently running ones) and enumerates the returned fields. This goes beyond what annotations state, though it doesn't cover potential edge cases like empty results.
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?
Two tight sentences: the first gives the primary purpose and key output details, the second provides a useful distinction from a sibling tool. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description covers its scope, the relationship to a sibling, and the read-only nature is already in annotations. No significant gaps remain.
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?
The only parameter, response_format, is fully described in the schema with enum, default, and description, achieving 100% schema coverage. The tool description itself does not add additional parameter details, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what it does: 'List scheduled pool scrub tasks' and specifies the attributes returned (pool, schedule, threshold, enabled state). It also differentiates it from truenas_list_pools by noting that the sibling only shows a scrub while running.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the sibling tool truenas_list_pools and its behavior, implying this tool is for viewing scheduled scrub configurations rather than active scrub activity. It could be more direct about when to choose this tool, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds valuable behavioral context by noting that the tool 'Works across TrueNAS versions (the underlying API differs; this tool picks the right one automatically),' which is beyond the annotations and helps the agent trust the tool's compatibility.
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 description is three sentences, front-loaded with the core purpose, and every sentence earns its place: what it lists, how to handle scale, and cross-version compatibility. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for a list tool: purpose, usage guidance, and compatibility note. With a full output schema and read-only annotations, nothing critical is missing for the agent to invoke it correctly.
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?
The input schema has 100% coverage with descriptive parameter definitions (e.g., 'Maximum snapshots to return' for limit, 'Only snapshots of this dataset' for dataset). The description only reinforces the dataset filter and pagination advice without adding new syntax or format information, so it meets the schema-driven baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a resource ('ZFS snapshots') and adds detail about the returned fields ('creation time and space used'), clearly distinguishing it from sibling tools that list other TrueNAS resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool ('Systems often have thousands of snapshots') and instructs to 'filter by dataset and paginate,' which serves as usage guidance. It does not explicitly exclude alternatives, but the sibling tools are distinct resources, so no exclusion is necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds clarity about what the tool reports (policy status, not existing snapshots), but does not disclose additional behavioral traits like pagination, ordering, or performance. This is adequate but not rich, matching the baseline for well-annotated read-only tools.
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?
Two well-structured sentences: the first states the exact scope and fields, the second differentiates from a sibling tool. Every sentence earns its place, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list operation with an optional format parameter. The output schema exists, so return values are already documented. The description fully explains what the tool does and how it differs from a similar tool, making it complete for the agent's selection and invocation needs.
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 coverage is 100% (the only parameter, response_format, has a clear description). The description does not add anything beyond what the schema already provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('configured periodic snapshot tasks'), and enumerates the key fields returned (dataset, retention policy, schedule, enabled). It also explicitly distinguishes this tool from the sibling truenas_list_snapshots, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool versus the alternative: 'truenas_list_snapshots shows the snapshots that EXIST; this shows whether an automatic snapshot POLICY is actually running.' This provides explicit guidance on tool selection and excludes the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds critical behavioral details: it never reveals the API key itself, and it reports API generation detection and authentication success. This gives agents a fuller understanding of what the tool returns and its privacy safeguards. It does not contradict annotations.
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 description is two sentences, front-loaded with the tool's purpose, followed by a concise list of returned information and an explicit usage directive. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero required parameters), the presence of an output schema, and the description covering purpose, usage timing, and expected outputs, the description is fully sufficient for an agent to select and correctly invoke this tool.
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?
The input schema already fully describes the only parameter (response_format) with enum values and their meaning. The description doesn't add anything about the parameter, and with 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description delivers a specific verb+resource combination: 'Diagnose the connection to TrueNAS' and enumerates exactly what is shown (configured URL, API key presence, API generation, authentication success). This clearly distinguishes it from sibling data-access tools like truenas_get_system_info or truenas_list_pools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Call this first when any other truenas_ tool fails,' providing an unambiguous usage scenario and prioritizing it as a diagnostic entry point. This contrasts with siblings, which are for specific resource queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds valuable context: it specifies the version scope (24.10+), discloses that it also reports Docker backend status, and highlights the update availability fields. This goes beyond the annotations without contradicting them.
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 description is two sentences, front-loaded with the core purpose, and every clause adds value. The 'key part' emphasis is a helpful structural cue, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 optional param, read-only, output schema present), the description covers all essential aspects: what is listed (apps, state, version, update status), the version requirement, and the distinction from the closest sibling. The output schema handles return structure, so no further return details are needed.
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?
The only parameter (response_format) is fully described in the input schema, covering 100% of schema description coverage. The description itself does not add parameter-specific details, but the schema already provides full context, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: installed TrueNAS apps. It distinguishes from the closely related sibling tool truenas_check_updates by explicitly stating it is the app-level counterpart, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly tells the agent when to use this tool versus truenas_check_updates: this covers apps, while check_updates only covers the base OS. This explicit comparison provides clear usage guidance and an alternative, fulfilling the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it is a safe read. The description adds meaningful behavioral context: results are 'most recent first' and include state, progress percent, and errors. This goes beyond the basic read-only hint, though it doesn't discuss pagination or rate limits.
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 description is two sentences, concise and front-loaded with the verb and resource. The first sentence covers what it lists and the output details; the second sentence provides actionable usage examples. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with three optional parameters, an output schema, and a readOnlyHint annotation, the description fully covers the purpose, output, and practical usage. There is no missing critical information; the output schema handles return formats, and the annotations cover safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter comments. The description adds extra guidance for the 'state' parameter by giving concrete use cases (RUNNING for current activity, FAILED for failures). While limit and response_format are not further explained, the baseline 3 is elevated to 4 because of this added practical parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a specific resource ('TrueNAS background jobs') and provides concrete examples (scrubs, replications, updates). It clearly distinguishes itself from sibling tools like list_replication_tasks or list_scrub_tasks by covering all background jobs, not just one type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit practical guidance: 'Use state=RUNNING to see what the NAS is doing right now, state=FAILED to find recent failures.' This clearly indicates when to use the tool with which parameter. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full exclusions/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and the description reinforces this with 'List'. It adds valuable context beyond annotations: it reveals that configurations are shown even when nothing is running, and that enabled status and last-run state are included. No contradiction with annotations.
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?
Two sentences: the first is front-loaded with the core action and scope, the second provides a useful contrast with a sibling tool. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema present, read-only annotation), the description covers purpose, scope, and the key distinction from a sibling. Nothing essential is missing for an AI agent to select and invoke it correctly.
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?
The input schema covers the single parameter response_format with 100% coverage, including an enum and default. The description adds nothing about this parameter, so the baseline of 3 applies — the schema does the heavy lifting and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists configured ZFS replication tasks, explains what these are in parentheses, and specifies the returned fields (direction, transport, enabled state, last-run state). It explicitly distinguishes from truenas_list_jobs, so it's specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not: 'Unlike truenas_list_jobs, this shows the task CONFIGURATION even when nothing is running.' This tells the agent when to choose this tool over a related alternative, which is exactly the kind of guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-TrueNAS MCP server](https://glama.ai/mcp/servers/PainInTheNic/MCP-TrueNAS/badges/card.svg)](https://glama.ai/mcp/servers/PainInTheNic/MCP-TrueNAS)

Score Badge

Copy to your README.md:

[![MCP-TrueNAS MCP server](https://glama.ai/mcp/servers/PainInTheNic/MCP-TrueNAS/badges/score.svg)](https://glama.ai/mcp/servers/PainInTheNic/MCP-TrueNAS)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PainInTheNic/MCP-TrueNAS'

If you have feedback or need assistance with the MCP directory API, please join our Discord server