truenas-aiops

Server Quality Checklist

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

Latest release: v0.10.0
Disambiguation4/5
Most tools target distinct resource-action pairs (alert_list, dataset_get, pool_scrub_start, snapshot_delete). However, the two RCA tools (pool_health_rca and alert_and_capacity_rca) overlap in purpose, and pool_list/pool_capacity both report capacity, though descriptions are clear enough to tell them apart.
Naming Consistency3/5
Tool names follow a loose resource_action pattern (dataset_list, snapshot_create), but there are inconsistencies: scrub_status vs. pool_scrub_start, compound names like alert_and_capacity_rca, and generic names like overview and system_info. The mixture is readable but not uniform.
Tool Count4/5
At 25 tools, the server is on the heavy side but each tool addresses a distinct aspect of TrueNAS monitoring and operations (pools, datasets, snapshots, services, disks, replication, cloud sync, undo). A few reads could be consolidated, but the count is appropriate for the broad scope.
Completeness3/5
The surface covers core read/monitoring and several write actions (create dataset, snapshot, start scrub, restart service). Notable gaps remain: no dataset update/delete, no pool create/delete, no alert management, no snapshot rollback, and only list operations for replication/cloud sync. These are significant but partly intentional for an AIOps server.
Average 4.2/5 across 25 of 25 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on August 10, 2026
- 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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it's a [READ] operation and returns health/scan/topology status, but does not disclose behavior like error handling, required permissions, or whether results are cached. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the [READ] prefix. It uses a clear heading and lists arguments concisely. No waste, but could benefit from more structure.
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?
Lacks output schema, so return values are undefined. Does not explain what constitutes 'health' or 'scan/topology status', error scenarios, or prerequisites. Incomplete for a status tool with siblings providing richer 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?
Schema descriptions coverage is 0%, but the description explains both parameters: pool_id as 'TrueNAS pool id' and target as 'TrueNAS target name from config'. However, it lacks format details (e.g., integer vs string constraints). Adds basic meaning but not rich semantics.
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 clearly states this tool retrieves 'Health and scan/topology status' for a single pool, distinguishing it from sibling tools like pool_get (general pool info) or pool_capacity (capacity). However, it does not specify the exact output fields, leaving some ambiguity.
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?
No guidance on when to use this tool versus pool_get, pool_capacity, or others. The description implies it's for a single pool but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It declares a read operation, implying non-destructive behavior, but lacks details on permissions, error states, or what happens when target is null (default).
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 concise sentences: first states purpose with a front-loaded '[READ]' indicator, second describes the sole parameter. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single optional parameter and no output schema, the description covers the core purpose but omits details about the return format or structure. For a simple read tool, it is minimally adequate.
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?
With 0% schema description coverage, the description adds meaning by stating 'target: TrueNAS target name from config.' This clarifies the parameter's source and purpose, but it is brief and does not explain what a 'target' is or how to obtain valid values.
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?
Description specifies a read operation ('[READ]') and clearly states the resource ('capacity summary per pool') with breakdown (size/allocated/free and used percent). It distinguishes from sibling tools like pool_list and pool_get, which focus on listing or general details rather than capacity.
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?
No guidance is provided on when to use this tool versus alternatives (e.g., pool_list, pool_get). The description only includes an argument explanation, not usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It includes a '[READ]' tag but does not disclose idempotency, auth requirements, rate limits, or side effects beyond the read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief and structured, with a clear Args line. Slightly more could be trimmed, but it is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/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 and no output schema, the description covers purpose and parameter usage. However, it lacks detail on what constitutes 'active' and whether dismissed alerts are included, reducing completeness.
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 0%, but description adds meaning for the target parameter: it clarifies that the value comes from config and omission uses default. This compensates partially.
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?
Description clearly states the tool lists active TrueNAS alerts with specific fields (level, message, class, dismissed). It distinguishes from sibling list tools by specifying alerts and 'active' status.
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?
No guidance on when to use this tool versus alternatives like dataset_list or snapshot_list. The only usage note is about the target parameter, not contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description is the sole source. It mentions '[READ]' but does not disclose other behavioral traits such as performance, limitations, or side effects.
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 concise, front-loads the purpose, and includes a parameter section without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists some fields but does not explain output structure, pagination, or filtering. Adequate for a simple list tool.
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?
The description provides meaningful context for the 'target' parameter beyond the schema's default and type, explaining its role as a TrueNAS target name.
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 ZFS datasets with specific fields, using a read indicator '[READ]'. It distinguishes from siblings like dataset_create and dataset_get.
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?
No explicit guidance on when to use this tool versus alternatives like dataset_get or snapshot_list. The only hint is the 'target' parameter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says it's a read operation and returns three fields. Fails to disclose error handling (e.g., missing pool_id), auth requirements, or performance implications.
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: one-line summary with '[READ]' tag, then args list. Front-loaded, zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; mentions return fields but not full structure or possible errors. Adequate for a simple read tool but lacks detail on edge cases.
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 0%, but description adds domain meaning: 'pool_id: TrueNAS pool id' and 'target: TrueNAS target name from config'. Clarifies purpose of each parameter beyond just type.
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?
Description clearly states it reads scrub scan state for a pool, mentioning specific fields (function/state/percentage). It distinguishes from write sibling 'pool_scrub_start'.
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?
No explicit guidance on when to use vs alternatives (e.g., pool_scrub_start). Usage is implied but not stated.
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?
With no annotations, the description carries the burden. It indicates a read-only operation via '[READ]', which is positive, but does not disclose return format, error behavior, or potential side effects. The description is adequate but not rich.
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 concise, using a clear format with a [READ] prefix and bulleted args. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of return values (no output schema), error handling, or additional behavioral details. For a get tool, describing the output structure would improve completeness. However, the sibling tools and context provide some usage guidance.
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 0%, so the description compensates by explaining pool_id as 'TrueNAS pool id (see pool_list)' and target as 'TrueNAS target name from config.' This provides context beyond the schema's type definitions.
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 read operation with '[READ]' and specifies the action: 'Return detail for a single pool by id.' It distinguishes from sibling tools like pool_list (which returns all pools).
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?
Implies usage when needing details of one pool and suggests using pool_list to obtain the pool_id, but does not explicitly state when to choose this over other pool-related tools like pool_status or pool_capacity.
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?
No annotations are provided, so the description carries the burden. It includes the '[READ]' tag to indicate read-only and lists returned fields, but omits details like required permissions, error handling, or pagination 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?
The description is highly concise with two sentences: a clear purpose line and a parameter explanation. Every part earns its place, and the '[READ]' is front-loaded for quick comprehension.
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 and lack of output schema, the description covers the return fields and parameter usage. It could mention aspects like whether all disks are returned at once or if there is a limit, but overall it's adequate.
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 description coverage is 0%, so the description must compensate. It explains the 'target' parameter well: 'TrueNAS target name from config; omit to use the default.' This adds meaning beyond the schema's basic type definition.
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 physical disks with specific fields (name, serial, model, size, pool), and the '[READ]' prefix indicates read-only operation. This distinguishes it from sibling tools like pool_list or dataset_list.
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 explains the optional target parameter but lacks guidance on when to use this tool versus alternatives. Usage is implied as straightforward for listing physical disks, but no explicit when-not-to-use or alternative suggestions are given.
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?
No annotations are provided, so the description carries the burden. It discloses it's a read operation and returns status/description, but lacks details on behavior when target is null, error cases, or any side effects. Adequate but not thorough.
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?
Description is extremely concise: a single line with [READ] prefix and a one-line parameter explanation. Every sentence is necessary and front-loaded with the operation type.
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 simple tool with one optional parameter and no output schema, the description covers the key aspects. It could mention the output format or provide an example, but it is largely complete given the tool's complexity.
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 description coverage is 0%, but the description in the 'Args' section adds meaning: 'target: TrueNAS target name from config.' This clarifies the parameter's purpose beyond the schema's type definition.
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?
Description clearly states it is a READ operation for recent S.M.A.R.T. self-test results per disk, with status and description. This distinguishes it from sibling tools like disk_list (list disks) or pool_list (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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameter 'target' is a TrueNAS target name from config, implying usage context. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives or prerequisites.
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?
No annotations are provided, so the description carries the burden. It discloses the read-only nature via '[READ]', specifies filtering criteria (non-dismissed, WARNING+, 80%/90% thresholds), and describes the worst-first ordering and output content. It does not mention error handling or return format, but covers the main behavioral traits.
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 compact yet thorough, starting with a clear summary line, then explaining the data sources and reporting criteria in two sentences, followed by an args section. No wasted words; the structure is logical and front-loaded.
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 no output schema and no annotations, the description effectively explains what the tool returns (one finding per active alert and per near-full dataset, with level/percent) and the input parameter. It could specify the exact return format, but the described behavior is sufficient for an RCA diagnostic tool.
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?
With schema coverage at 0%, the description compensates by explaining the single parameter 'target' as 'TrueNAS target name from config; omit to use the default.' This adds meaning beyond the schema's bare 'target' field and clarifies default behavior.
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: 'Surface active TrueNAS alerts by level and datasets near full.' It specifies the resources (active alerts, dataset listing) and the combined purpose, distinguishing it from siblings like alert_list and dataset_list which handle each separately.
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 usage for a combined alert/capacity diagnostic but does not explicitly state when to use it versus alternatives or provide exclusions. The context from 'Collects the active alert list and the /pool/dataset listing' implies a combined view, but no direct guidance on selection is given.
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 description marks the operation as '[READ]', indicating no side effects, but lacks details on rate limits, authentication requirements, or any potential impacts. For a simple list tool, this is adequate but not thorough.
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 purpose, and no unnecessary words. Every line adds value.
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 has 1 optional parameter and no output schema, the description lists returned fields (id, name, status, health, capacity) and explains the parameter. It is complete for its simplicity, though could note the return format (list).
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?
With 0% schema coverage, the description explains the 'target' parameter well: 'TrueNAS target name from config; omit to use the default.' This adds essential context beyond the schema's type-only definition.
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 'List ZFS pools with id, name, status, health, capacity.' This specifies the verb (List) and resource (ZFS pools) and lists returned fields, clearly distinguishing from siblings like pool_get or pool_status.
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 explains the 'target' parameter and default behavior, but does not explicitly state when to use this tool versus alternatives like pool_get. Contextual clarity is high from sibling tool names.
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?
Description clearly marks the operation as [READ] and lists the data returned. Since no annotations are provided, the description carries the full burden; it adequately conveys that this is a read-only tool with no side effects.
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 extremely concise with exactly two sentences: first sentence states the purpose and data returned, second sentence explains the parameter. 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 read tool with one optional parameter and no output schema, the description provides a complete list of returned fields and parameter behavior. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds full meaning for the only parameter: 'target: TrueNAS target name from config; omit to use the default.' This provides context beyond the schema's type and default.
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?
Description clearly states the tool reads TrueNAS system summary and lists specific fields (version, hostname, memory, cores, uptime). It distinguishes from sibling tools like 'overview' which may provide a broader view.
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?
The description gives a usage note for the optional target parameter but does not provide explicit guidance on when to use this tool versus sibling tools like overview or pool_list. No context on 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?
The description explicitly marks the tool as a read operation with '[READ]', which is the primary behavioral trait. Without annotations, this is valuable transparency. It does not disclose error handling or authentication needs, but for a simple read, the key information is provided.
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 extremely concise: a one-line summary with a read flag and example, then brief parameter descriptions. Every sentence adds value, and the structure makes it easy to scan. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the parameters but does not describe the return value or behavior on failure (e.g., if dataset not found). For a simple get with no output schema, the description is moderately complete but could be improved by mentioning the response format.
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?
Despite 0% schema coverage, the description explains both parameters: dataset_id is a TrueNAS dataset id from dataset_list, and target is a TrueNAS target name from config. This adds meaning beyond the bare schema (type/required/default), helping the agent understand their origins.
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 returns detail for a single dataset by id, with a specific verb 'Read' and resource 'dataset detail'. The example 'tank/data' adds clarity. It distinguishes from sibling tools like dataset_list (list) and dataset_create (create).
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 a single dataset's details when you have its ID. It references dataset_list for getting the ID, providing context. However, it does not explicitly state when not to use or specify alternatives, though the sibling names make the differentiation clear.
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 description explicitly begins with '[READ]', disclosing read-only behavior, and lists the returned fields (name, state, enable). While it does not cover error handling or side effects, for a read-only list with no annotations, this is meaningful disclosure.
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 compact sentences: one for purpose and one for the argument. It is front-loaded with the READ marker and functional summary, with 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 low complexity (one optional param, no output schema, no annotations), the description sufficiently covers the tool's purpose, returned fields, and parameter semantics. It does not need to explain return value structure beyond what it already lists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'target' is explained as 'TrueNAS target name from config; omit to use the default', adding practical usage detail that the schema lacks. The schema only lists type and default, so the description fully compensates for the 0% 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 uses a specific verb ('List') with a clear resource ('system services') and states the output scope ('name, state (RUNNING/STOPPED), enable'). This clearly distinguishes it from siblings like service_restart and other 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?
No explicit when-to-use or alternative guidance is provided. The verb 'List' implies a read query, but the description does not mention when to prefer this over other tools or reference alternatives like service_restart.
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?
With no annotations, the description carries full behavioral transparency. It explicitly marks the operation as IRREVERSIBLE, mentions the dry_run preview, and notes that it captures prior state for audit while declaring no undo. This covers the key risks beyond basic mutation, though it omits permission requirements or detailed effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the critical WRITE and IRREVERSIBLE flags. The Args list is clear and each sentence serves a purpose, though the audit-record note is slightly extra and could be seen as tangential to basic usage.
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 delete tool with no output schema and no annotations, the description covers the essential operational details: irreversibility, dry-run preview, and snapshot_id sourcing. It could further explain expected return values or error behavior, but it sufficiently addresses the primary decision factors for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining each parameter: snapshot_id format ('dataset@name' with a reference to snapshot_list), dry_run behavior (preview without deleting), and target (TrueNAS target from config). This adds meaning far beyond the bare schema.
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 'Delete a ZFS snapshot by id' with a specific verb and resource. It distinguishes from siblings like snapshot_create and snapshot_list by specifying deletion semantics and id format.
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?
Provides clear context: dry_run=True to preview, and snapshot_id references snapshot_list for lookup. It also states 'declares no undo', which warns against using this tool when rollback is expected, though it doesn't explicitly name alternative tools like undo_apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It goes beyond a simple 'list' by explaining that 'state' reflects the last run's job status (SUCCESS/FAILED/RUNNING), is null until the task runs, and unlike replication tasks, cloud-sync tasks have no inherent state. The '[READ]' prefix also signals non-mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the action, then gives behavioral nuance in a separate paragraph. The state clarification is necessary and earns its place, though the 'Args' line could be integrated more smoothly. Overall it is well-structured without redundancy.
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 simple list tool with one optional parameter and no output schema, the description covers the essential fields, the semantics of 'state', and the target argument. It does not describe the return structure, but that is not expected here. The explanation of the state quirk makes it sufficiently complete for an agent to use.
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?
The schema provides only the target parameter with a null default and no description, so the description's 'Args: target: TrueNAS target name from config' adds essential context about where the value comes from. It does not explicitly state that the parameter is optional or how omitting it behaves, but it compensates for the absent schema 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 opens with '[READ] List cloud-sync tasks' and specifies the resource and fields (description, direction, path, state). It clearly distinguishes this from replication_list by noting cloud-sync records carry no state of their own, making it unambiguous what this tool does.
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 tool name and '[READ]' establish it as the list operation for cloud-sync tasks, and the contrast with replication provides implicit usage guidance. However, it does not explicitly state when to use this over a sibling like 'replication_list' or give direct alternative names, so it stops short of 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?
With no annotations, the description carries the transparency burden. It includes a '[WRITE]' tag, states the side effect (creates a snapshot), and notes that dry_run avoids creation and 'without an undo token', implying normal runs may produce an undo token. It does not mention permissions or error handling, but the provided context is meaningful.
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 compact and well-structured. It starts with a one-line purpose, then an inverse note, a usage hint, and a clear parameter list. Every sentence earns its place with no fluff or repetition.
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?
The description covers all parameters and gives essential behavioral context (dry_run, undo token, inverse). It does not describe return values, but no output schema exists, so that is not required. It also omits prerequisites like dataset existence, but the overall guidance is sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains each parameter with examples (dataset: 'tank/data', name: 'manual-2026-06-28'), clarifies dry_run behavior, and specifies target as 'TrueNAS target name from config'. This adds significant meaning beyond the schema.
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 'Create a ZFS snapshot' with the exact naming format 'dataset@name'. It is a specific verb+resource and distinguishes itself from sibling tools by naming the inverse operation (snapshot_delete).
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 explicitly names the inverse tool and gives usage guidance for dry_run ('Pass dry_run=True to preview'). It does not list alternative tools for other scenarios, but the create/delete relationship is clear and adequate for the tool's purpose.
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?
With no annotations, the description carries the full burden. It discloses that the operation is non-destructive, supports a dry-run mode, and has no undo. This is solid transparency for a create tool, though it omits permission requirements 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 description is well-structured and front-loaded: it starts with the core purpose, then key behavioral notes, then a clean parameter list. Every sentence earns its place, with no fluff or repetition.
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 (4 params, no output schema) and lack of annotations, the description covers all essential aspects: what it does, safety profile, dry-run usage, scope boundaries, and parameter semantics. It is complete enough for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the 'Args' section compensates fully by explaining each parameter's meaning, including an example for 'name', the optional 'pool' purpose, 'dry_run' behavior, and 'target' source. This adds significant value beyond the raw schema.
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 'Create a ZFS dataset' with a specific verb and resource. The '[WRITE]' prefix and the explanation that it's non-destructive further clarify its role, distinguishing it from read-only siblings like dataset_list and dataset_get.
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 practical usage guidance: 'Pass dry_run=True to preview' and explicitly says 'dataset deletion is intentionally out of scope,' which helps an agent decide when to use or avoid this tool. However, it doesn't explicitly compare to alternatives, though siblings are mostly read/list tools, so the context is clear.
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?
No annotations are provided, so the description carries the full burden. It discloses important behavioral details: state values (PENDING/RUNNING/FINISHED/ERROR/HOLD), the meaning of PENDING, the presence of an 'error' field with actionable sentences, and returned fields (lastSnapshot, lastRun). This goes beyond a simple list operation and helps the agent anticipate response content.
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 concise, front-loaded with a [READ] tag and a clear statement of purpose. It then provides just enough detail about state semantics and parameters without redundancy. Every sentence 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?
With no output schema, the description covers all return fields (name, direction, transport, state, error, lastSnapshot, lastRun). It also explains the target parameter fully. For a list operation with one optional parameter, the description is complete and leaves no major gaps in understanding what the tool does and returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'target' with a default of null and no description. The description fully compensates by explaining that 'target' is a TrueNAS target name from config and that omitting it uses the default. This adds complete semantic meaning for the only parameter.
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 ('replication tasks'), enumerating the key fields (name, direction, transport, state). It clearly distinguishes itself from sibling tools like alert_list or dataset_list by focusing on replication tasks. The [READ] prefix also signals the operation 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 implies when to use this tool: to list replication tasks and inspect their state/error information. It does not explicitly name alternatives or exclusions, but the context is clear given the specialized resource. No direct sibling alternative exists, so the guidance is adequate though not exhaustive.
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?
With no annotations, the description carries full responsibility. It explicitly marks the operation as [READ], discloses the return structure including the 'truncated' flag, and explains what to do if truncation occurs. This goes beyond a simple 'list' by informing the agent about safety and pagination-like 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?
The description is well-structured and concise: a one-line summary, then a return format explanation, then an organized Args block. Every sentence adds value, and there is no fluff or repetition.
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 there is no output schema and no annotations, the description completely covers what the tool returns, how to interpret truncation, and what each parameter does. It even advises on next steps for a common edge case, making it fully sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage), but the description's Args section explains each parameter clearly: dataset with an example, limit with its default, and target as a config-based name. This fully compensates for the schema's silence.
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 'List ZFS snapshots, optionally filtered to one dataset' with a specific verb and resource. It distinguishes this from sibling tools like snapshot_create and snapshot_delete by being a read-only listing operation.
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 context on when to use the tool (to list snapshots) and offers practical guidance on handling truncation by increasing the limit or filtering to one dataset. However, it does not explicitly mention when not to use it or name alternative tools for other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It openly marks the operation as '[WRITE][risk=medium]', explains that the inverse tool runs under its own governance and risk tier, warns that a token can only be applied once, and mentions dry_run to preview without executing. This goes beyond a simple 'apply' and discloses key behavioral traits.
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 well-structured with a clear summary line, a brief paragraph of important caveats, and an Args list. Every sentence adds value, and it is appropriately front-loaded with the [WRITE] and risk indicator.
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?
The description covers purpose, parameters, and behavior comprehensively. However, it does not mention what the tool returns (e.g., the inverse tool's result or a success/failure status). With no output schema, a brief note on return value would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only titles with 0% description coverage, so the description must explain each parameter. It does: undo_id is sourced from undo_list or _undo_id, dry_run previews the inverse call, and target is passed through conditionally. This adds substantial meaning beyond the schema.
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 purpose: 'Apply a recorded undo by dispatching its inverse tool.' This distinguishes it from sibling tool undo_list, which lists recorded undos, and other write tools. The verb and resource are specific, leaving no ambiguity.
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 usage context by noting the undo_id source ('from undo_list or an _undo_id in a write result') and the dry_run preview option. It does not explicitly name alternatives or exclusions, but the context makes it clear when to use this tool versus listing undos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds: it explicitly marks the operation as read-only ([READ]), describes pulling the /pool listing with topology and scan, details the evaluated conditions, and explains the output format (worst-first, with measured values and actions).
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 compact and front-loaded, starting with the purpose and read-only hint, followed by specific detection criteria and an Args section. Every sentence contributes useful information with no 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 fully covers input, process, thresholds, ordering, and output contents. Even without an output schema, an agent can understand what the tool returns and how to interpret it, making the description complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, 'target', is thoroughly explained as a TrueNAS target name from config, with the behavior when omitted clearly stated. This adds significant meaning beyond the bare schema of string/null/default null.
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 opens with a specific verb ('Flag'), names the resource ('ZFS pools'), and specifies exact criteria (state, error counters, capacity). It clearly differentiates this tool from simple listing/status siblings by describing a diagnostic flagging behavior with ordering and output content.
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 makes the use case clear: run this to get a health-focused RCA of ZFS pools based on degradation, errors, and capacity thresholds. It does not explicitly state when not to use it or name alternative tools, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this exceptionally well: discloses the read-only nature, most-recent-first ordering, exact return shape, truncation behavior (with the extra-row fetch making truncation measured), the effectVerified caveat and its implications, and the host-local nature of undo state.
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 detailed yet well-structured, with clear sections for purpose, return values, truncation semantics, and parameter explanations. Every sentence adds practical value, and the most important information is front-loaded, making it efficient despite its length.
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?
Even without an output schema, the description fully specifies the return format, pagination semantics, and the crucial effectVerified caveat. It also contextualizes the tool within the undo workflow by referencing undo_apply. For a tool of this complexity, the description is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions and 0% coverage, but the description's Args section fully compensates. It explains limit's default and hard cap, and explicitly states that target is unused and accepted only for CLI uniformity, which prevents an agent from misusing the parameter.
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 opens with a clear verb and resource: 'List recorded, not-yet-applied undo tokens (most recent first).' It explicitly distinguishes this tool from sibling list tools by focusing on undo tokens and directly mentions the companion tool undo_apply, making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it says to use the returned undoId with undo_apply, emphasizes that only not-yet-applied tokens are shown, and notes that target is unused and accepted only for CLI uniformity. While it doesn't explicitly enumerate alternative tools or when not to use this one, the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The '[READ]' prefix explicitly indicates a read-only operation, and the description explains the tool provides a health summary without side effects. No annotations exist to contradict this.
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 concise with two sentences and an Args section, front-loading key purpose and usage guidance without unnecessary details.
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?
Despite no output schema, the description fully covers the tool's behavior, input, and usage context, making it complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains the single optional parameter 'target' as a TrueNAS target name from config with omit-to-use-default behavior, compensating for 0% 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's purpose as a 'One-shot health summary' covering pools, alerts, and services, distinguishing it from sibling tools like pool_list, alert_list, and service_list.
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?
Explicit guidance to call this first for triaging a TrueNAS system before drilling into specific components, providing clear when-to-use and implying alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It declares '[WRITE]' and 'Non-destructive,' notes the absence of an undo descriptor, and implies asynchronous behavior via 'Poll progress.' This is transparent and honest about side effects.
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 concise and front-loaded: purpose first, then behavioral notes, then args. Every sentence adds value with no wasted words or repetition of schema defaults.
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?
Despite no output schema, the description covers the operation's outcome, next steps (scrub_status), and all parameter details. It also mentions the non-reversible nature, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the inline Args section is essential. It fully explains each parameter: pool_name format with example, dry_run semantics, and target's role. This compensates completely for the schema's lack of descriptions.
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 'Start a scrub (integrity check) on a pool,' identifying the specific action and resource. It distinguishes the tool from siblings like scrub_status (monitoring) and pool_list/pool_get (listing).
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 explicitly instructs to 'Poll progress with scrub_status; do not re-issue,' providing both an alternative and a when-not. It also mentions dry_run preview, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job. It discloses that the tool captures the prior service state for an audit record, declares no undo, and describes the refusal behavior under dry_run. This goes beyond basic side effects and informs the agent of important behavioral traits such as safety checks and audit 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?
The description is well-structured and front-loaded with the main purpose. Each sentence provides necessary information: the action, examples, dry_run, behavioral notes, refusals, and parameter explanations. No filler or redundancy is present. The Args section is formatted clearly, making it easy to scan.
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 4-parameter tool with no output schema and no annotations, the description is remarkably complete. It covers all parameters, explains side effects, gives specific safety constraints, and references service_list for valid names. The agent receives enough context to invoke the tool correctly and understand its consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: service (TrueNAS service name), confirm (required for 'ssh'), dry_run (preview), and target (from config). It adds context beyond the schema, such as defaults and refusal conditions, making parameter use clear and meaningful.
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 opens with 'Restart a system service', a specific verb+resource statement. It further specifies examples ('smb', 'nfs') and distinguishes itself from sibling tools like service_list by naming the exact action. There is no ambiguity about what the tool does.
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 explicitly states when to use the tool (to restart a service) and when refusals occur: invalid service names and 'ssh' without confirm=True. It warns that SSH is the out-of-band recovery path, explaining why the confirm is required. This gives clear context and exclusions, satisfying the criteria for explicit usage guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/AIops-tools/TrueNAS-AIops'

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