TrueNAS Core MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific TrueNAS resources like datasets, pools, shares, and users, with clear separation between creation, listing, and modification operations. However, some potential overlap exists between 'modify_dataset_permissions' and 'update_dataset_acl' as both handle dataset access control, though their descriptions differentiate Unix permissions versus ACLs.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as 'create_dataset', 'list_datasets', 'get_dataset_properties', and 'modify_dataset_permissions'. All tools use snake_case without deviation, making them predictable and readable for an agent.
Tool Count4/5
With 20 tools, the count is slightly high but reasonable for a TrueNAS server covering storage management, sharing protocols, and user administration. It includes core operations for datasets, pools, shares, snapshots, and users, though it might benefit from consolidation in areas like debugging tools.
Completeness4/5
The tool set provides comprehensive coverage for dataset lifecycle (create, list, get, modify, snapshot), storage pools, and sharing protocols (NFS, SMB, iSCSI), with user management included. Minor gaps exist, such as missing update/delete operations for shares or targets, but agents can likely work around these for core workflows.
Average 3.1/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 6 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states this is a creation operation, implying it's a write/mutation tool, but doesn't disclose behavioral traits like permissions required, whether it's idempotent, error conditions, or what happens on success/failure. The description adds minimal context beyond the basic action.
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 appropriately sized and front-loaded with the main purpose in the first sentence. The parameter list is structured but could be more integrated. No wasted sentences, though it lacks completeness for a mutation tool.
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?
Given this is a mutation tool with no annotations, 4 parameters (2 required), 0% schema coverage, and no output schema, the description is incomplete. It covers the basic action and parameters but misses critical context like behavioral traits, error handling, and output expectations, which are essential for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all 4 parameters with brief explanations (e.g., 'Path to share', 'Optional comment'), adding basic semantics beyond schema titles. However, it doesn't provide format details (e.g., path syntax), constraints, or examples, leaving significant gaps.
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 the action ('Create a new SMB share') and specifies the resource type (SMB share). It distinguishes from siblings like create_dataset or create_nfs_export by specifying SMB shares specifically. However, it doesn't explicitly differentiate from list_smb_shares or other share-related tools beyond the creation action.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing path), when not to use it, or refer to sibling tools like list_smb_shares for context. The agent must infer usage from the tool name alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'gets' information, implying a read-only operation, but doesn't specify if it requires authentication, has rate limits, returns structured data, or handles errors. This leaves significant gaps in understanding how the tool behaves.
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 concise, with a clear purpose statement followed by parameter details in a separate section. It avoids unnecessary words, though the parameter explanation could be slightly more detailed without losing efficiency.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., permission details format), error conditions, or dependencies, making it insufficient for an agent to fully understand the tool's context and usage.
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 description adds value by explaining the 'dataset' parameter as a 'Dataset path (e.g., "tank/data")', which clarifies its format beyond the schema's basic string type. However, with only 1 parameter and 0% schema description coverage, this minimal explanation is adequate but not comprehensive, meeting the baseline for a single-parameter tool.
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 the tool's purpose with a specific verb ('Get') and resource ('current permissions and ACL information for a dataset'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_dataset_properties' or 'modify_dataset_permissions', which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'get_dataset_properties' for general dataset info or 'modify_dataset_permissions' for permission changes, leaving the agent without context for tool selection.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'detailed status' but doesn't specify what that includes (e.g., health metrics, capacity, performance), whether it's a read-only operation, or any constraints like authentication needs or rate limits. This leaves significant gaps for an agent to understand the tool's 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 front-loaded with the core purpose in the first sentence, followed by a concise 'Args' section. Every sentence earns its place with no wasted words, making it efficient and well-structured for quick understanding.
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?
Given the complexity of a status-checking tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed status' entails, the return format, or any behavioral traits like error handling. This makes it inadequate for an agent to fully leverage the tool without additional 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 schema description coverage is 0%, but the description includes an 'Args' section that documents the single parameter 'pool_name' with a brief explanation. This adds value beyond the bare schema, though it's minimal and doesn't cover format or examples. With one parameter, the baseline is 4, but the limited detail reduces it to 3.
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 the verb 'Get' and the resource 'detailed status of a specific pool', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_pools' or 'get_system_info', which might also provide pool-related information, so it doesn't reach the highest score.
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 such as 'list_pools' for a broader view or 'get_system_info' for general system status. The description only states what it does without context for selection among siblings.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves information but doesn't mention permissions required, rate limits, error handling, or the format of returned data. This leaves significant gaps for an agent to understand operational constraints.
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 brief and front-loaded with the core purpose, followed by a simple parameter explanation. It avoids unnecessary verbosity, though the structure could be slightly improved by integrating the parameter note more seamlessly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs or response format, and with 0% schema coverage, it fails to fully compensate for the missing structured data, leaving the agent under-informed.
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 schema description coverage is 0%, but the description adds basic semantics by explaining that 'username' is used to look up a user. However, it doesn't specify format constraints, examples, or whether it's case-sensitive, which limits its usefulness beyond the bare schema.
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 the tool's purpose with a specific verb ('Get') and resource ('detailed information about a specific user'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'list_users', which might cause confusion about when to use each.
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 provides no guidance on when to use this tool versus alternatives like 'list_users'. It mentions looking up a specific user but doesn't clarify if this is for single-user queries versus bulk listing, leaving usage context implied rather than explicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't mention whether this requires specific permissions, whether snapshots are immutable, what happens if a snapshot with the same name exists, or any rate limits. The description lacks essential behavioral context for a mutation tool.
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 appropriately sized with a clear purpose statement followed by parameter explanations. The 'Args' section is well-structured. However, the first sentence could be more front-loaded with additional context about snapshot behavior or usage scenarios.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a snapshot actually is in this context, what the tool returns, whether the operation is synchronous, or error conditions. The agent lacks crucial information to use this tool effectively.
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 parameter semantics in the 'Args' section, explaining what each parameter represents. With 0% schema description coverage, this compensates well by documenting all three parameters. However, it doesn't elaborate on format constraints (e.g., valid snapshot name patterns) or the implications of the recursive option.
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 the verb ('Create') and resource ('snapshot of a dataset'), making the purpose immediately understandable. It distinguishes from siblings like 'create_dataset' by specifying the snapshot operation rather than dataset creation. However, it doesn't explicitly differentiate from 'create_snapshot_policy' which might be a closer sibling.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, when snapshots are appropriate, or how this differs from other snapshot-related tools like 'create_snapshot_policy'. The agent must infer usage from the tool name alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the action of updating ACLs, which implies a mutation, but doesn't mention critical aspects like required permissions, whether changes are reversible, potential side effects (e.g., data access impacts), or error conditions. This leaves significant gaps for safe tool invocation.
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 appropriately sized and front-loaded with the core purpose, followed by a bullet-point-like list of parameters with brief explanations. There's minimal waste, though the formatting with 'Args:' could be slightly more polished for clarity.
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?
Given the complexity of updating ACLs (a mutation with security implications), no annotations, no output schema, and 4 parameters, the description is incomplete. It lacks information on behavioral traits (e.g., permissions needed, effects), output format, and error handling, making it inadequate for safe and effective use by an agent.
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 adds meaningful context for all parameters beyond the schema, which has 0% coverage. It explains 'dataset' as a path with an example, 'acl_entries' as a list with permissions, and clarifies the boolean flags 'recursive' and 'strip_acl'. This compensates well for the lack of schema descriptions, though it doesn't detail the structure of ACL entries.
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 the verb 'Update' and the resource 'dataset Access Control Lists (ACLs)', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'modify_dataset_permissions' or 'get_dataset_permissions', which likely handle related but different operations.
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 provides no guidance on when to use this tool versus alternatives like 'modify_dataset_permissions' or 'get_dataset_permissions'. It lists parameters but doesn't explain the context or prerequisites for updating ACLs, leaving the agent to infer usage scenarios.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this creates a new dataset but doesn't mention important behavioral aspects: whether this requires specific permissions, what happens if the dataset already exists, whether there are size/name constraints, or what the response contains. For a creation tool with zero annotation coverage, this leaves significant behavioral gaps.
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 efficiently structured with a clear purpose statement followed by parameter documentation. Each sentence earns its place by providing essential information. The formatting with 'Args:' and bullet-like parameter explanations makes it scannable, though the lack of complete sentences for parameters slightly affects readability.
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 this is a creation tool with no annotations and no output schema, the description does an adequate job covering the basic purpose and parameters. However, it lacks important context about behavioral aspects (permissions, error conditions, response format) and usage guidelines relative to sibling tools. The parameter documentation is strong, but other contextual elements are incomplete.
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 parameter documentation for all 4 parameters, adding meaningful context beyond the schema's 0% description coverage. It explains what each parameter represents ('Pool name where dataset will be created', 'Dataset name', 'Compression algorithm', 'Optional quota in bytes') and notes the default for compression. This fully compensates 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('dataset'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'create_snapshot' or 'create_snapshot_policy' which also create resources, missing the opportunity to clarify this creates a storage dataset rather than a snapshot or policy.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing pool), when not to use it (e.g., for modifying existing datasets), or refer to sibling tools like 'modify_dataset_properties' for updates. The only implied context is dataset creation, but no explicit usage boundaries are provided.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates an NFS export, implying a write operation, but doesn't cover critical aspects like required permissions, whether the export is persistent, potential side effects, error conditions, or response format. This leaves significant gaps for a creation tool.
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 appropriately sized and front-loaded, with a clear purpose statement followed by a parameter list. Every sentence earns its place by adding necessary information, though the parameter section could be slightly more integrated into the flow rather than a separate list.
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 tool's complexity (5 parameters, no annotations, no output schema), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral details like permissions, side effects, and return values. For a creation tool with no structured support, it should do more to fill these gaps.
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 adds substantial value beyond the input schema, which has 0% schema description coverage. It provides examples for 'dataset' and 'allowed_networks' parameters and clarifies the purpose of 'read_only', 'maproot_user', and 'maproot_group'. This compensates well for the schema's lack of descriptions, though it doesn't cover defaults or all nuances.
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 the action ('Create an NFS export') and the resource ('for Kubernetes persistent volumes'), which is specific and informative. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_smb_share' or 'create_iscsi_target', which would require mentioning NFS-specific context or contrasting with other sharing protocols.
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 provides no guidance on when to use this tool versus alternatives like 'create_smb_share' or 'create_iscsi_target', nor does it mention prerequisites or typical scenarios. It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.
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 provided, so the description carries the full burden of behavioral disclosure. It states the tool 'debugs' but doesn't clarify what this entails—e.g., whether it's a read-only diagnostic, modifies settings, requires specific permissions, or has side effects like logging or alerts. This is a significant gap for a tool with potential system interactions.
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, efficient sentence: 'Debug connection settings and environment variables.' It is front-loaded with the core action and target, with zero wasted words, making it highly concise and well-structured for quick understanding.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'debugging' involves—e.g., whether it returns diagnostic data, logs errors, or requires specific system states. For a tool that might interact with system connections, more context on behavior and outputs is needed to guide the agent effectively.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids unnecessary details. A baseline of 4 is applied since no parameters exist, and the description doesn't mislead about inputs.
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 the tool's purpose: 'Debug connection settings and environment variables.' It specifies the action ('debug') and the target resources ('connection settings and environment variables'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'reset_connection', which might be a related operation.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as when to choose 'debug_connection' over 'reset_connection' or other diagnostic tools. This leaves the agent without clear usage instructions.
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 provided, so the description carries the full burden of behavioral disclosure. It states 'Get all properties' but doesn't clarify what 'properties' include (e.g., metadata, settings), whether it's a read-only operation, or any constraints like permissions required. This leaves significant gaps in understanding the tool's 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 and well-structured, with a clear purpose statement followed by a parameter explanation in a bullet-like format. Every sentence adds value without redundancy, making it easy to parse quickly.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'properties' are returned or any behavioral traits like error handling. For a tool with no structured metadata, more detail is needed to fully understand its use and output.
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 adds meaningful context for the single parameter 'dataset' by providing an example ('tank/data'), which clarifies the expected format. Since schema description coverage is 0%, this compensates well, though it could be more detailed about path conventions or restrictions.
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 the tool's purpose with a specific verb ('Get') and resource ('properties of a dataset'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_dataset_permissions' or 'modify_dataset_properties', which would require more specificity about what 'properties' encompasses.
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 provides no guidance on when to use this tool versus alternatives. With siblings like 'list_datasets' (for listing datasets) and 'get_dataset_permissions' (for permissions), there's no indication of when this tool is appropriate, such as for retrieving metadata versus other dataset-related operations.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but it doesn't specify what 'system information' includes (e.g., hardware details, software version, configuration), whether it requires authentication, or how the data is returned. This leaves significant gaps for a tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately clear what the tool does without unnecessary elaboration.
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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'system information' entails or how it's structured, which is critical for an agent to understand the return value. For a read-only tool with no structured output documentation, more detail about the response format would be helpful.
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 tool has zero parameters, and schema description coverage is 100% (since there are no parameters to describe). The description appropriately doesn't mention parameters, which aligns with the input schema. No additional parameter semantics are needed, so this meets the baseline for a parameterless tool.
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 the verb ('Get') and resource ('TrueNAS system information'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings (like 'get_pool_status' or 'get_dataset_properties'), but it's specific enough to indicate this retrieves general system-level data rather than component-specific information.
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 provides no guidance on when to use this tool versus alternatives like 'get_pool_status' or 'get_dataset_properties'. While the name implies it's for system-wide information, there's no explicit context about when this is appropriate versus more specific sibling tools, leaving the agent to infer usage patterns.
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 provided, so the description carries full burden for behavioral disclosure. 'List all storage pools' implies a read-only operation but doesn't specify whether this returns all pools at once or uses pagination, what format the results are in, or any authentication requirements. For a tool with zero annotation coverage, this is inadequate.
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, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple list operation and is front-loaded with the essential information.
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?
Given no annotations and no output schema, the description is insufficient for a complete understanding. While the purpose is clear, there's no information about what the tool returns (e.g., pool names, IDs, statuses) or behavioral aspects like pagination or error conditions. For a tool in a storage management context, more context is needed.
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 tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description doesn't need to compensate for missing parameter documentation since there are no parameters to document.
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 'List all storage pools' clearly states the verb ('List') and resource ('storage pools'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_datasets' or 'list_smb_shares' beyond the resource name, which prevents a perfect score.
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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_pool_status' that might provide more detailed information about pools, there's no indication of when a simple list is sufficient versus when status details are needed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but only states the action without details on permissions, rate limits, pagination, or output format. It lacks critical information like whether this requires admin access or returns all users at once.
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, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core purpose without any fluff or redundancy.
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?
For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the output looks like (e.g., list format, user attributes) or behavioral aspects like permissions, making it inadequate for an agent to use confidently without additional context.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for not adding unnecessary information.
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 the verb ('List') and resource ('all users in TrueNAS'), making the purpose unambiguous. However, it doesn't distinguish itself from sibling tools like 'get_user' (which likely retrieves a single user), leaving room for minor improvement.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_user' for retrieving specific users or clarify if this is the primary method for user enumeration, leaving the agent without contextual usage cues.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('Modify') but doesn't specify permissions required, whether changes are reversible, potential side effects (e.g., quota enforcement), or error handling. The example adds some context but lacks critical details like rate limits or authentication needs for a mutation tool.
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 appropriately sized and front-loaded, starting with the core purpose. The two-sentence structure is efficient, with the second sentence providing essential parameter details and examples. There's minimal waste, though it could be slightly more structured with bullet points for clarity.
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 complexity (mutation tool with nested objects, no output schema, and no annotations), the description is moderately complete. It covers the purpose and parameters well but lacks behavioral context, usage guidelines, and output details. For a tool that modifies system properties, more information on safety and prerequisites would improve completeness.
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 description coverage is 0%, so the description must compensate. It clearly explains both parameters: 'dataset' as a path with an example, and 'properties' as a dictionary with example key-value pairs. This adds significant meaning beyond the bare schema, though it doesn't detail all possible property types or constraints beyond the examples.
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 the verb ('Modify') and resource ('ZFS dataset properties'), making the purpose unambiguous. It distinguishes itself from siblings like 'create_dataset' or 'get_dataset_properties' by focusing on property updates rather than creation or retrieval. However, it doesn't explicitly differentiate from 'modify_dataset_permissions' or 'update_dataset_acl', which are also modification tools.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., dataset must exist), compare with similar tools like 'modify_dataset_permissions', or specify when not to use it (e.g., for creating datasets). The example hints at usage but lacks explicit 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a creation operation but doesn't mention whether it requires specific permissions, what happens if the target already exists, whether it's idempotent, or what side effects might occur. The description is minimal beyond the basic action.
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 efficiently structured with a clear purpose statement followed by parameter explanations in a bullet-like format. Every sentence adds value, with no redundant or unnecessary information. The formatting makes it easy to scan and understand.
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 creation tool with 4 parameters, no annotations, and no output schema, the description provides adequate basic information about what the tool does and what parameters it accepts. However, it lacks important context about behavioral aspects, error conditions, and what the tool returns upon success.
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 explanations for all 4 parameters (name, dataset, size, portal_id) with examples for name and size, adding substantial value beyond the schema which has 0% description coverage. It clarifies what each parameter represents in the context of iSCSI target creation.
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 the verb 'Create' and the resource 'iSCSI target for Kubernetes block storage', making the purpose immediately understandable. It distinguishes this tool from siblings like create_dataset or create_nfs_export by specifying it's for iSCSI storage, though it doesn't explicitly contrast with them.
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 provides no guidance on when to use this tool versus alternatives like create_dataset or create_smb_share. It doesn't mention prerequisites, dependencies, or typical scenarios for iSCSI target creation in Kubernetes storage contexts.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'List all datasets' but doesn't reveal if this is a read-only operation, how results are returned (e.g., pagination, format), or any rate limits. This leaves gaps in understanding the tool's behavior beyond the basic action.
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, efficient sentence ('List all datasets') with zero waste. It's front-loaded and appropriately sized for a simple tool with no parameters, making it easy to scan and understand quickly.
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 tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks context on usage, behavior, or output format. For a list operation, more details on result handling would improve completeness, but it's not entirely incomplete for such a simple case.
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 input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description adds no parameter details, which is acceptable here since there are no parameters to explain. A baseline of 4 is appropriate as the description doesn't need to compensate for any gaps.
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 'List all datasets' clearly states the verb ('List') and resource ('datasets'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_pools' or 'list_smb_shares' beyond the resource name, nor does it specify scope (e.g., all datasets in a system vs. filtered).
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 provides no guidance on when to use this tool versus alternatives like 'get_dataset_properties' for detailed info or 'list_pools' for related resources. It lacks context about prerequisites, such as whether authentication is needed or if it's for browsing vs. detailed queries.
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 provided, so the description carries the full burden of behavioral disclosure. It states 'List all SMB shares' but doesn't clarify if this is a read-only operation, what the output format might be, or any limitations (e.g., pagination, rate limits). For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 a single, efficient sentence: 'List all SMB shares.' It is front-loaded with the core action and resource, with zero wasted words. This is appropriately sized for a simple list tool.
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 tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, usage context, or output. For a simple list operation, this might suffice, but it doesn't fully compensate for the absence of annotations or output schema.
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 tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter details, so it meets the baseline for tools with no parameters. No additional semantic value is required or provided.
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 'List all SMB shares' clearly states the verb ('List') and resource ('SMB shares'), making the tool's purpose immediately understandable. It doesn't differentiate from siblings like 'list_datasets' or 'list_pools', but the resource specificity is adequate. No tautology with the name 'list_smb_shares' since it adds the resource type.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it requires specific permissions or differs from other list tools. With siblings like 'list_datasets' and 'list_pools', some differentiation would be helpful.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool forces re-initialization, which implies a state-changing operation, but doesn't clarify if this is destructive (e.g., drops connections), has side effects, or requires specific conditions. More context on behavior is needed.
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, efficient sentence that front-loads the key action and outcome without unnecessary words. It's appropriately sized for a zero-parameter tool.
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 tool's complexity (simple reset operation) and lack of annotations/output schema, the description is minimally adequate. It explains what the tool does but lacks details on behavioral traits, usage context, or output, leaving gaps for an agent to infer.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a high baseline score for this dimension.
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 the action ('reset') and resource ('HTTP client') with the specific outcome ('force re-initialization'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'debug_connection', which might have overlapping troubleshooting purposes.
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. The description implies it's for re-initialization but doesn't specify scenarios (e.g., after errors, for troubleshooting) or mention sibling tools like 'debug_connection' that might be related.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'create' implying a write operation, but doesn't mention permissions needed, whether policies are editable/deletable, rate limits, or what happens on success/failure. The description adds basic context about automation and recursion, but lacks critical behavioral details for a creation tool.
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?
Well-structured with clear heading 'Args:' and bullet-like parameter explanations. Each parameter description is efficient and adds value. Could be slightly more front-loaded with a clearer purpose statement before parameter details, but overall very concise with zero waste.
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 creation tool with 5 parameters, nested objects, no annotations, and no output schema, the description does well on parameters but lacks behavioral context. It explains what each parameter means but doesn't cover what happens after creation, error conditions, or system implications. Adequate but with clear gaps given the 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 description must fully compensate. It provides detailed semantic explanations for all 5 parameters: clarifies 'dataset' target, 'name' purpose, 'schedule' as cron-like with example format, 'retention' settings with structure, and 'recursive' meaning. This adds substantial value beyond the bare schema.
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 the verb 'create' and resource 'automated snapshot policy', which is specific and distinct from sibling tools like 'create_snapshot' (which creates individual snapshots) or 'create_dataset'. However, it doesn't explicitly differentiate from all siblings, just implies policy vs. snapshot creation.
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 'create_snapshot' for one-off snapshots or other policy-related tools. The description only states what it does, not when it's appropriate or what prerequisites might be needed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it implies a mutation operation ('modify'), it doesn't specify critical behavioral traits such as required permissions, whether changes are reversible, potential side effects, or error conditions. The chmod/chown analogy provides some context but lacks operational details.
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 appropriately sized. The purpose statement is front-loaded, followed by a clear parameter breakdown. Every sentence adds value, though the chmod/chown analogy could be slightly more explicit about its limitations in this context.
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 mutation nature of the tool, no annotations, and no output schema, the description is moderately complete. It excels at parameter documentation but lacks behavioral context about permissions requirements, side effects, and return values. For a permission-modification tool with 5 parameters, more operational guidance would be beneficial.
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 provides excellent parameter semantics beyond the schema. With 0% schema description coverage, the description fully compensates by explaining all 5 parameters: dataset path format, mode format and examples, owner/group identifiers, and recursive behavior. Each parameter's purpose and format is clearly documented.
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 the tool's purpose: 'Modify dataset permissions (chmod/chown equivalent)'. It specifies the verb ('modify') and resource ('dataset permissions'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'modify_dataset_properties' or 'update_dataset_acl', which also modify dataset attributes.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'modify_dataset_properties' or 'update_dataset_acl', nor does it specify prerequisites, exclusions, or appropriate contexts for permission modification versus other dataset operations.
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:

[![TrueNasCoreMCP MCP server](https://glama.ai/mcp/servers/vespo92/TrueNasCoreMCP/badges/card.svg)](https://glama.ai/mcp/servers/vespo92/TrueNasCoreMCP)

Score Badge

Copy to your README.md:

[![TrueNasCoreMCP MCP server](https://glama.ai/mcp/servers/vespo92/TrueNasCoreMCP/badges/score.svg)](https://glama.ai/mcp/servers/vespo92/TrueNasCoreMCP)

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/vespo92/TrueNasCoreMCP'

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