Provides full access to OpenMediaVault NAS storage management, including system statistics, disk and filesystem monitoring, RAID management, shared folder configuration (SMB, NFS, FTP), and user/group administration.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-openmediavault Check the health of my disks and show current storage usage."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for OpenMediaVault (OMV), providing AI assistants with full access to NAS storage, shares, users, and system management through the OMV JSON-RPC API.
Compatible with OMV 5 and OMV 6.
33 tools across five categories:
Tool | Description |
| Hostname, version, CPU model, uptime, memory |
| CPU usage, memory usage, load averages |
| CPU temperature readings |
| Network interfaces with IP, netmask, gateway, speed |
| Syslog entries |
| Scheduled shutdown, wake-on-LAN settings |
Tool | Description |
| Physical disks with model, vendor, size, serial, temperature, SMART status |
| Filesystems with type, label, size, usage, mount status |
| Currently mounted filesystems with usage stats |
| SMART attributes for a disk |
| Extended SMART info including self-test results |
| SMART monitoring settings per disk |
| Scheduled SMART self-test jobs |
| Software RAID (mdadm) devices |
Tool | Description |
| Shared folders with filesystem references and privileges |
| User/group access privileges for a shared folder |
| SMB/CIFS (Samba/Windows) shares |
| Global SMB service settings |
| NFS shares with client and export options |
| Global NFS service settings |
| FTP shares |
| Global FTP service settings |
Tool | Description |
| Local user accounts with UID, GID, groups |
| Detailed info about a specific user |
| Local groups with GID, comment, members |
| Detailed info about a specific group |
| All system users including system accounts |
| All system groups |
| Shared folder privileges for a user |
Tool | Description |
| Status of all services (SMB, NFS, SSH, FTP, rsync, etc.) |
| Scheduled cron jobs with command and schedule |
| SSH service settings |
| Rsync backup/sync jobs |
| Rsync daemon modules |
| Global rsync settings |
| Email notification settings |
| Available software updates |
| Installed OMV plugins |
| Hardware watchdog timer settings |
Related MCP server: mcp-redfish
git clone git@github.com:fredriksknese/mcp-openmediavault.git
cd mcp-openmediavault
npm install
npm run buildThe server is configured via environment variables:
Variable | Required | Default | Description |
| Yes | — | OMV server hostname or IP address |
| No |
| OMV admin username |
| Yes | — | OMV admin password |
| No |
| Accept self-signed SSL certificates |
The server connects to the JSON-RPC endpoint at https://{host}/rpc.php, which is the standard endpoint for both OMV 5 and OMV 6.
Session management follows the OMV protocol:
Login via POST /rpc.php with Session.login
Extract the session cookie (PHPSESSID) from the Set-Cookie response header
Send both the Cookie header and X-OPENMEDIAVAULT-SESSIONID header on all subsequent requests
If the session expires (HTTP 401), the client automatically re-authenticates and retries.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"openmediavault": {
"command": "node",
"args": ["/absolute/path/to/mcp-openmediavault/dist/index.js"],
"env": {
"OMV_HOST": "192.168.1.100",
"OMV_USERNAME": "admin",
"OMV_PASSWORD": "your-password"
}
}
}
}claude mcp add openmediavault -- node /absolute/path/to/mcp-openmediavault/dist/index.jsSet environment variables before running, or configure them in your MCP settings.
Once connected, you can ask your AI assistant things like:
"What is the current disk usage and which filesystems are mounted?"
"Show me the SMART health status for all disks"
"List all SMB shares and their enabled status"
"What services are currently running on the NAS?"
"Show me all users and their group memberships"
"Are there any software updates available for OMV?"
"What cron jobs are scheduled and when do they run?"
"Show me the NFS export configuration"
"What is the CPU temperature and system load?"
npm run dev # Run with tsx (auto-reloads)
npm run build # Compile TypeScript to dist/
npm start # Run compiled outputsrc/
├── index.ts # Entry point — creates MCP server + STDIO transport
├── omv-client.ts # JSON-RPC client with session management and auto-retry
└── tools/
├── system.ts # System info, stats, network interfaces (6 tools)
├── storage.ts # Disks, filesystems, SMART, RAID (8 tools)
├── shares.ts # Shared folders, SMB, NFS, FTP (8 tools)
├── users.ts # Users and groups (7 tools)
└── services.ts # Services status, cron, SSH, rsync, plugins (10 tools)Node.js 18+
OpenMediaVault 5 or 6 with admin credentials
Admin account with API access (the default admin account works)
SEE LICENSE IN LICENSE
Enumerate all system groups including system groups
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool enumerates groups, but does not mention whether it is read-only, requires permissions, or any side effects. This is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is appropriate given no parameters, but it is not well-structured and contains redundancy ('including system groups'). It could be more concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should explain the nature of the output (e.g., what is returned) and how it differs from similar tools like 'list_groups'. The current description is insufficient for an agent to understand the tool's role in the broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description does not need to add parametric information. The description does not add value beyond the schema, but this is acceptable given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Enumerate all system groups including system groups', which clarifies the tool's function but is somewhat redundant and fails to distinguish from the sibling tool 'list_groups'. It does not specify whether it returns detailed information or just names, leaving purpose slightly unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_groups' or 'get_group'. The agent receives no decision framework, reducing utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enumerate all system users including system accounts (broader than list_users which may only show OMV-managed accounts)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. While the description implies a read operation ('enumerate'), it does not mention safety, permissions, or any behavioral traits such as whether it triggers side effects, requires authentication, or has rate limits. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the main action ('Enumerate all system users'), and includes the critical differentiation from list_users. Every word serves a purpose, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a clear comparison with a sibling tool (list_users), the description is largely complete for this simple enumeration tool. It could optionally note the output format or behavior, but the core purpose and distinction are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (0 params) and the input schema provides 100% coverage. According to the scoring guidelines, with 0 parameters the baseline is 4. The description does not need to add parameter semantics, so this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool enumerates all system users including system accounts, and explicitly distinguishes from list_users by noting it is broader and includes accounts list_users may omit. This provides a specific verb and resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool versus list_users: when you need all users including system accounts, as opposed to only OMV-managed accounts. This clear alternative usage guidance helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get CPU temperature readings from OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool requires special permissions, has rate limits, or is read-only. For a tool with no annotations, the description should explicitly state such traits; it does not.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains no superfluous words. It efficiently communicates the tool's purpose without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is minimally adequate. However, it lacks context about the format or units of the temperature readings, and does not mention if the tool can fail or what to expect from the response. Slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has 100% coverage (empty object). The description adds no additional parameter information, but since no parameters exist, the baseline is 4. The description does not mislead or omit necessary param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and resource ('CPU temperature readings') and specifies the system ('OpenMediaVault'). It is distinct from sibling tools like get_system_info or get_system_stats which cover broader metrics, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., get_system_stats might also include temperature). A user must infer usage from the name alone. While the purpose is clear, explicit context about prerequisites or comparative advantages is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global FTP service settings including port, max connections, and enabled status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It correctly implies a read-only retrieval, but doesn't mention error conditions (e.g., FTP service disabled) or any side effects. This is adequate for a simple getter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that conveys the necessary information without redundancy. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers the key information: what settings are returned. It could mention authentication requirements or the behavior when FTP is disabled, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (empty schema). The description adds no parameter-level detail, but the baseline for zero parameters is 4. No additional value is expected here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('global FTP service settings'), and lists specific fields returned (port, max connections, enabled status). It effectively distinguishes from sibling tools like 'get_smb_settings' or 'get_ssh_settings'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it indicate any prerequisites or contexts. It merely describes the tool's function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific group
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Group name to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states 'get detailed information' but fails to disclose what constitutes 'detailed information' (e.g., properties, members). No behavioral traits like read-only nature are explicitly stated, though implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate but lacks detail on what 'detailed information' includes. It could be improved but is not incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the parameter 'name' with 'Group name to look up', achieving 100% coverage. The description adds no additional meaning beyond 'specific group', so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific group', which specifies the verb (get) and the resource (specific group). It effectively distinguishes from sibling tools like 'enumerate_groups' and 'list_groups' which likely list groups rather than retrieve one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_groups' or 'enumerate_groups'. No explicit context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all currently mounted filesystems with their usage statistics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation ('Get') with no destructive hints, which is appropriate. However, it does not detail any potential delays, data freshness, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundant words. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and no output schema, the description minimally covers what the tool does. It could specify which statistics are returned (e.g., total size, used space) to be more complete, but for a simple read operation it suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%). Per guidelines, baseline is 4. Description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get'), the resource ('mounted filesystems'), and the specific scope ('currently mounted ... with their usage statistics'). This distinguishes it from siblings like 'list_filesystems' which likely lists all filesystems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives (e.g., 'list_filesystems', 'get_system_stats'). The description implies it is for mounted filesystems with usage stats, but does not state when not to use it or which sibling to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all network interfaces on the OpenMediaVault system with IP, netmask, gateway, and speed
| Name | Required | Description | Default |
|---|---|---|---|
| enumerate | No | If true, enumerate all detected devices. If false, list configured interfaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions what is returned but does not state whether it's read-only, permission requirements, or behavior for empty results. Lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with action and result, no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one boolean parameter and no output schema. Description lists return fields adequately but lacks usage context and behavioral details. Minimal but acceptable for low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains the 'enumerate' parameter. Description does not add extra meaning beyond the schema, hence baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'network interfaces', clearly stating the output includes IP, netmask, gateway, and speed. It distinguishes from sibling tools that list users, disks, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The 'enumerate' parameter is described in the schema but not highlighted in the description. Missing context like prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global NFS service settings and enabled status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies read-only, but no mention of authentication, side effects, or rate limits. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, description only mentions 'settings and enabled status' generically. Lacks detail on what specific settings are returned, but acceptable for a simple global settings getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters with 100% coverage, so description adds no parameter info. Baseline for no parameters is 4; description does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Get', specific resource 'global NFS service settings', and output 'enabled status'. It distinguishes from sibling tools like get_smb_settings or get_ftp_settings by specifying NFS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for retrieving NFS settings, but no explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get email notification settings configured in OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose whether the settings may be empty, what error conditions exist (e.g., no notification system configured), or if any prerequisites are needed. Merely stating 'Get email notification settings' is insufficient for a safe read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. It is concise and front-loaded with the key action and target. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should offer more context about return values or error handling. It does not, but the simplicity of the tool partially compensates. A score of 3 reflects adequate but not complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (trivially). The description repeats what is already obvious from the schema, but adds no additional value. Baseline 4 is appropriate given the parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves email notification settings in OpenMediaVault. It uses a specific verb ('Get') and resource ('notification settings'), distinguishing it from sibling tools like get_system_info or list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. With many sibling get_* tools, the description should indicate that this is for email notification settings specifically, and perhaps that it is a safe read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get power management settings (scheduled shutdown, wake-on-LAN, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only mentions 'Get', implying a read operation. It fails to disclose any behavioral traits such as authentication needs, performance, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, and provides concrete examples. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read tool, the description is fairly complete. It explains the purpose and gives examples of the settings included. However, it lacks details on output format or any side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description adds examples of returned settings, which provides context beyond the empty schema, but this relates to output rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves power management settings, with specific examples like scheduled shutdown and wake-on-LAN. This distinguishes it from sibling get_* tools that focus on other resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or any prerequisites. The description only states what it does, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global rsync daemon settings
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 does not disclose any behavioral traits such as read-only nature, permissions required, or what the returned settings include.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimal but functional. However, it does not clarify what 'settings' entails, which could be ambiguous among siblings like list_rsync_modules.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (trivially). The description adds no parameter information, but none is needed. Base score is 4 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves global rsync daemon settings, using a specific verb and resource. It distinguishes from sibling tools that get other settings or list rsync-specific items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_ssh_settings or list_rsync_modules. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the status of all OpenMediaVault services (SMB, NFS, SSH, FTP, rsync, etc.) showing which are enabled and running
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It clearly indicates a read-only operation (status retrieval) without side effects. It doesn't explicitly state 'read-only', but the context makes it obvious. The description adds detail on the scope (all services) and output fields (enabled/running).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the tool's purpose, scope, and output. No unnecessary words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully covers what the tool does. It lists example services and states the output characteristics (enabled/running status), providing enough context for an agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (zero param count) and 100% schema description coverage, meaning no additional parameter details are needed. The description implicitly confirms no inputs required, which is sufficient for an agent to invoke correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves status of all OpenMediaVault services, listing examples (SMB, NFS, SSH, etc.), and specifies what information is shown (enabled and running). This distinguishes it from sibling tools that focus on specific service settings or configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates use for a broad service status overview. Sibling tools like get_smb_settings or get_ssh_settings are more specific, so an agent can infer when to use this tool. However, explicit guidance on alternatives or when not to use is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SMART monitoring settings for a specific disk
| Name | Required | Description | Default |
|---|---|---|---|
| devicefile | Yes | Device file path of the disk (e.g., /dev/sda) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. The description implies a read-only operation ('Get') but fails to mention any behavioral traits such as authentication requirements, potential failure modes, or the nature of the settings returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose. It is concise and front-loaded, though it lacks structural elements like bullet points or additional context that would enhance readability for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate but does not fully achieve completeness. It does not explain what the settings encompass or the format of the response, which could be helpful for an agent to anticipate results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema, which already provides a clear explanation for 'devicefile' with an example. Since schema description coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'SMART monitoring settings for a specific disk'. It effectively conveys the tool's purpose, but unlike the high-scoring calibration example, it does not explicitly distinguish from sibling tools like get_smart_info or get_smart_extended_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 get_smart_info or get_smart_extended_info. The description lacks context about prerequisites or appropriate scenarios, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get extended SMART information for a specific disk including self-test results
| Name | Required | Description | Default |
|---|---|---|---|
| devicefile | Yes | Device file path of the disk (e.g., /dev/sda) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states the action and output type, but does not disclose read-only nature, permission requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, front-loaded with verb and key output. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with one parameter, but lacks explanation of what 'extended' means, what self-test results contain, or any notes on response structure (no output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description. The tool description adds no additional parameter details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' and resource 'extended SMART information including self-test results' for a specific disk. It clearly distinguishes from sibling tools like get_smart_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not to use or alternatives. The description implies use when extended info with self-test is needed, but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SMART attributes for a specific disk device to assess disk health
| Name | Required | Description | Default |
|---|---|---|---|
| devicefile | Yes | Device file path of the disk (e.g., /dev/sda, /dev/sdb). Use list_disks to find device files. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It does not disclose behavioral traits such as read-only nature, required permissions, or side effects beyond implying it retrieves data. Significant gap for a health assessment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear, the description lacks context on output format, behavioral expectations, and selection guidance among siblings. Given the tool's simplicity and no output schema, it is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema already describes devicefile fully. The tool description adds no additional parameter-level information, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'SMART attributes' with the context 'assess disk health'. It distinguishes from siblings like get_smart_extended_info by focusing on basic health assessment, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., get_smart_extended_info, list_smart_jobs). The parameter description mentions using list_disks to find device files, which aids in prerequisite handling but not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global SMB/CIFS service settings including workgroup, description, and enabled status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses it retrieves global settings but does not explicitly state it is read-only, nor does it mention auth or side effects. Basic behavioral context is inferred from the verb 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words, front-loaded with verb and resource. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description should convey return structure. It mentions included fields but does not specify format (e.g., JSON object) or full set of settings. Partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters with 100% schema coverage. Description adds value by listing example settings (workgroup, description, enabled status), providing context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('Get'), resource ('global SMB/CIFS service settings'), and provides examples (workgroup, description, enabled status). It distinguishes from sibling tools like list_smb_shares which are share-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for retrieving global SMB settings but provides no explicit when-to-use or when-not-to-use guidance. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SSH service settings including port, password authentication, and enabled status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose if the operation is read-only, requires permissions, or has side effects. The description only states what it retrieves, not 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that is front-loaded and directly states the tool's action. No wasted words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description lists example fields but does not specify the return structure (e.g., single object). For a getter, more detail on what is returned would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Description adds no parameter info beyond the schema, which is acceptable as there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets SSH service settings and lists specific fields (port, password authentication, enabled status), making the purpose distinct from sibling tools like get_ftp_settings or get_nfs_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool, but the name and context (sibling tools for other services) imply it's for retrieving SSH settings. Lacks explicit alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenMediaVault system information including hostname, version, CPU model, uptime, and memory
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only lists example output fields without stating side effects, permissions, or whether the operation is read-only. The tool likely reads system state, but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, followed by a list of included fields. No redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description lists key attributes (hostname, version, CPU model, uptime, memory), which provides a reasonable understanding of what the tool returns. However, it could hint at the response structure or additional optional fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (empty schema). The description does not need to add parameter details. It appropriately lacks parameter information, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves OpenMediaVault system information and lists specific fields (hostname, version, CPU model, uptime, memory). It distinguishes itself from sibling tools that focus on other resources (e.g., get_cpu_temp, get_system_stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_system_stats or get_cpu_temp. The description implies a general purpose but does not explicitly state 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.
Retrieve system log entries from OpenMediaVault (syslog)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of log lines to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states 'retrieve' but does not disclose whether the operation is read-only, potential performance impacts, rate limits, or log rotation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no wasted words. Could benefit from slight structure (e.g., bullet points) but is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description sufficiently explains the tool's purpose. However, it lacks context on the log source format or default behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add further meaning to the single parameter beyond what the schema already provides. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('system log entries from OpenMediaVault (syslog)'), distinguishing it from sibling tools that list or get other system entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, or any prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get OpenMediaVault system statistics including CPU usage, memory usage, and load averages
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'get' but does not explicitly confirm it is read-only, mention auth requirements, or describe any side effects. Minimal behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. Every word contributes meaning, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the types of statistics returned but does not detail structure or units. Without an output schema, more description could help the agent understand the return format. However, it covers the main data points adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema already indicates no inputs required. The description adds value by listing the returned statistics, compensating for the lack of an output schema. Base score of 4 is appropriate given the no-parameter case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves system statistics with specific examples (CPU, memory, load averages), establishing a clear verb-resource relationship. It is distinguishable from siblings like 'get_system_info' which may focus on broader system details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 'get_cpu_temp' or 'get_system_info'. The description does not include any when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for available software updates in OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states 'check' which implies a read-only operation, but does not disclose potential behaviors like network calls, caching, or safety concerns. The minimal detail leaves uncertainty 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (no parameters, no output schema), the description fails to describe the return value or behavior beyond the bare action. An agent would not know what the tool returns (e.g., list, boolean) or if it requires any preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% description coverage. According to guidelines, a baseline of 4 applies as no parameter information is needed. The description adds no parameter details, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Check for available software updates in OpenMediaVault' clearly states a specific verb ('check') and resource ('available software updates') within a defined scope. It is distinct from all sibling tools, none of which mention updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as whether it should be called before upgrading or if there are prerequisites. It lacks explicit usage or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific user account
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Username to look up |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It only mentions 'detailed information' without specifying the structure or scope of the output, potential side effects, or required permissions. This is insufficient for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundancy. However, it could be slightly more structured by listing the type of information returned, but it avoids fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description omits key details: what fields are in the response, how it differs from similar tools like enumerate_users, and any prerequisites. An agent would need to guess or test.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' is described in the schema as 'Username to look up', and the description adds 'a specific user account'. Since schema coverage is 100%, the description adds no meaningful extra semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed information about a specific user account'), clearly distinguishing it from sibling tools like list_users (which lists all users) and get_group (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like enumerate_users or get_group. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all shared folder privileges assigned to a specific user
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Username to get privileges for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation with no side effects, but does not disclose any potential limitations or prerequisites. Basic transparency, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no extraneous information. It is efficiently front-loaded, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description lacks details about the output format, types of privileges returned, or any constraints. It is complete only for a very basic understanding, leaving significant gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'name' with a clear description. The tool description adds no additional parameter context, but the schema sufficiently covers it, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all shared folder privileges assigned to a specific user' clearly specifies the verb 'get', the resource 'shared folder privileges', and the target 'specific user'. It distinguishes from siblings like 'get_shared_folder_privileges' which likely target folders rather than users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving privileges per user but provides no explicit guidance on when to use this tool versus alternatives like 'get_shared_folder_privileges' or other user-related tools. Lacks when-not-to-use or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hardware watchdog timer settings for system health monitoring
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It labels the operation as 'Get' implying read-only, but provides no details on return format, side effects, or any system impacts. Basic 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded with purpose. Efficiently communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is adequate for a simple getter. However, additional context about the settings structure or typical values could enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% by default. Baseline for 0 parameters is 4. Description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'hardware watchdog timer settings', with added context 'for system health monitoring'. It effectively distinguishes from sibling get_ tools which target different settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. However, as a simple getter with no parameters, usage is implicitly clear. Missing explicit when-not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all scheduled cron jobs configured in OpenMediaVault with command, schedule expression, and enabled status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like idempotency, performance, or side effects. For a simple list operation, the lack of transparency is acceptable but not helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a parameterless list tool. Mentions key output fields, but could be improved by noting expected return format (e.g., array) or behavior when no jobs exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema coverage is 100%. The description adds no parameter information but is unnecessary given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists cron jobs and specifies included fields (command, schedule expression, enabled status). However, it does not explicitly differentiate from sibling list_* tools, which all perform similar listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only states what it does, without context for selection or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all physical disks detected by OpenMediaVault including model, vendor, size, serial number, temperature, and SMART status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. The description indicates a read-only listing operation through the verb 'List', which is transparent. However, it does not disclose potential side effects, permissions required, or real-time nature, missing an opportunity to add depth beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of 20 words that front-loads the key action and resource. Every word contributes meaning without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with no output schema, the description is fairly complete: it lists the resource and the specific data fields returned. It could be slightly improved by mentioning whether results are sorted, require administrative privileges, or are real-time, but overall it provides sufficient context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the parameter semantics dimension is inherently well-covered. The description adds value by detailing the fields returned (model, vendor, etc.), which is helpful despite the schema being empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all physical disks detected by OpenMediaVault and specifies the information included (model, vendor, size, serial number, temperature, SMART status). It effectively distinguishes from sibling tools like list_raid_devices, list_filesystems, or get_smart_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource but does not explicitly state when to use it versus alternatives. For example, it includes SMART status which overlaps with get_smart_info, but no guidance is provided on distinction. Usage is implied only through the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all filesystems on the OpenMediaVault system including type, label, size, usage, and mount status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by listing attributes, but does not disclose any behavioral traits such as performance, authentication requirements, or response format when no filesystems exist. Since no annotations are provided, the description carries the full burden, but it is only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence that is front-loaded with the action and resource, followed by the attributes. Every word is meaningful and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is sufficient. It tells the agent what it returns. However, it could mention that an empty list is returned if no filesystems exist, but given the simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema covers 100% of parameters (none). The description adds value by specifying the output fields (type, label, size, usage, mount status), which provides context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all filesystems on the OpenMediaVault system, specifying the included attributes (type, label, size, usage, mount status). This distinguishes it from sibling tools like 'get_mounted_filesystems' (which likely lists only mounted ones) and 'list_disks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. For example, there is a sibling 'get_mounted_filesystems' that may be more appropriate for mounted filesystems, but no indication of when to choose one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all local groups in OpenMediaVault with GID, comment, and member list
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of groups to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions listing, which implies a read operation, but does not explicitly state safety (e.g., read-only, no side effects), permissions required, or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that conveys the core purpose and output details without any extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially explains the return (fields listed) but lacks details on format, ordering, pagination, or errors. For a simple list tool, it is moderately complete but could be more precise.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter ('limit') with a description. The tool description adds no additional meaning beyond the schema, and schema coverage is 100%, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all local groups in OpenMediaVault and specifies the returned fields (GID, comment, member list). It is not a tautology and provides specific context, though it does not explicitly differentiate from the sibling tool 'enumerate_groups'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all installed OpenMediaVault plugins
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits like permissions needed, side effects (e.g., read-only), or return format. The burden falls entirely on the description, which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is appropriately front-loaded and concise, though it could be structured to include more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description provides the essential purpose. For a simple list operation, it is reasonably complete, though it lacks any details on return format or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%, so the description does not need to add parameter semantics. The baseline for 0 parameters is 4, and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'plugins', and specifies 'all installed OpenMediaVault plugins', making it distinct from sibling tools like list_disks or list_users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 when listing all plugins is appropriate versus filtering. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all software RAID (mdadm) devices configured in OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies a read-only list operation but does not specify if there are any side effects, permissions needed, or error conditions (e.g., no RAID devices configured). The behavior is basic and not contradicted, but lacks detail beyond the listing aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary information. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters or output schema and low complexity, the description covers the essential purpose. However, it could mention that no arguments are required or that it returns a list of RAID device details, but this is not critical for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (trivially). The description does not need to add parameter meanings, and the baseline for no-parameter tools is 4. The description adequately explains the tool's function without requiring parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'software RAID (mdadm) devices', and the scope 'configured in OpenMediaVault'. It distinguishes from sibling list tools like list_disks or list_filesystems by specifying RAID, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as list_disks or list_filesystems. The context implies usage for RAID devices, but no when-not 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.
List all rsync backup/sync jobs configured in OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states it lists jobs, but no details on ordering, filtering, or permissions. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no redundant information. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, description is sufficient. Could mention empty list behavior or scope, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, baseline is 4. Description adds nothing about parameters, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it lists rsync backup/sync jobs, distinguishing it from sibling tools like get_rsync_settings and list_rsync_modules. Verb+resource is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives like list_rsync_modules or get_rsync_settings. Usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List rsync daemon modules (server-side rsync shares) configured in OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose read-only nature, permissions, output format, or any other behavioral traits beyond stating it lists modules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous information, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description is adequate but could be improved by mentioning output format or typical usage scenario. It lacks completeness regarding return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description's clarification that it lists rsync modules in OMV adds minimal but sufficient meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool lists rsync daemon modules (server-side rsync shares) configured in OpenMediaVault, providing a specific verb ('List'), resource ('rsync daemon modules'), and context ('OpenMediaVault'), distinguishing it from sibling list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as other list tools or get_rsync_settings. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all scheduled SMART self-test jobs configured in OpenMediaVault
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action without disclosing side effects, permissions, or output behavior. For a read operation, this is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, front-loads the action. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description is adequate but could hint at return format or typical use cases. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no parameter info because none is needed; baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'scheduled SMART self-test jobs configured in OpenMediaVault', distinguishing it from other list tools (e.g., list_cron_jobs, list_disks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to siblings like list_cron_jobs or get_smart_info. The description is purely declarative, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all local user accounts in OpenMediaVault with UID, GID, groups, and account details
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of users to return |
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 states it lists all local user accounts, implying a read-only operation, but does not explicitly declare safety, permissions, or side effects. The behavior is predictable but not richly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that immediately conveys the core purpose. Every word is necessary, with no redundancy or filler. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 what and the output fields (UID, GID, groups, account details). It lacks mention of ordering, pagination, or differentiation from similar siblings, but is mostly complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the 'limit' parameter has a clear description and default. The tool description adds no extra meaning about the parameter beyond what the schema provides, so it meets the baseline without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('all local user accounts in OpenMediaVault'), and the returned details ('UID, GID, groups, and account details'). It distinguishes from sibling 'enumerate_users' by specifying that it returns account details, but does not explicitly differentiate itself, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'enumerate_users' or 'get_user'. No contexts, prerequisites, or exclusions are mentioned, leaving the agent to guess when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0enumerate_groupsenumerate_usersget_cpu_tempget_ftp_settingsget_groupget_mounted_filesystemsget_network_interfacesget_nfs_settingsget_notification_settingsget_power_managementget_rsync_settingsget_services_statusget_shared_folder_privilegesget_smart_device_settingsget_smart_extended_infoget_smart_infoget_smb_settingsget_ssh_settingsget_system_infoget_system_logget_system_statsget_updatesget_userget_user_privilegesget_watchdog_settingslist_cron_jobslist_diskslist_filesystemslist_ftp_shareslist_groupslist_nfs_shareslist_pluginslist_raid_deviceslist_rsync_jobslist_rsync_moduleslist_shared_folderslist_smart_jobslist_smb_shareslist_usersScored across 39 tools
Most tools target distinct resources (disks, users, shares, services), but some overlap exists between 'enumerate_' and 'list_' variants (e.g., enumerate_groups vs list_groups). Descriptions clarify differences, so ambiguity is minor.
Tool names mix 'get_', 'list_', and 'enumerate_' prefixes with no strict pattern. For example, 'get_system_info' uses 'get' while 'list_disks' uses 'list'. Some tools use 'get_xxx_settings' vs 'get_xxx_info'. The pattern is inconsistent but still readable.
39 tools is slightly high for a single server, but the domain of NAS management involves many read-only queries. Each tool serves a specific sub-resource, so the count is justified, though it could be reduced by combining some settings endpoints.
The server only provides read operations; there are no create, update, or delete tools for any resource. This is a major gap for management tasks like adding users, configuring shares, or enabling services. The surface is severely incomplete for its apparent purpose.
Set up and run an in-product AI assistant from your AI client: create and tune assistants, connect knowledge sources, host an MCP server on an existing API, and read usage. Every tool is annotated read-only or destructive, so writes ask before they act.
Manage HepCloud (Turkish cloud) servers and managed PostgreSQL from your AI assistant. OAuth 2.1.
Inspect and control your Northflank projects, services, jobs, and builds from your AI assistant.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
