Unraid MCP

by lemanjo

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation1/5
Numerous tools directly overlap, such as unraid_get_array vs unraid_v4371_query_array, unraid_list_vms vs unraid_v4371_query_vms, and unraid_get_docker_logs vs unraid_v4371_query_docker_logs. The query_, get_, and list_ variants often describe essentially the same resource, making reliable tool selection very difficult.
Naming Consistency2/5
Naming mixes unraid_get_*, unraid_list_*, unraid_read_*, unraid_v4371_query_*, and unraid_v4371_next_* with no consistent verb convention. The arbitrary v4371 version segment on some tools but not others further breaks any predictable pattern.
Tool Count1/5
With 88 tools, the server is far beyond the 16-25 heavy range and well into extreme bloat. Many tools appear to be redundant query wrappers, and the count would be more manageable with around 20-30 consolidated operations.
Completeness2/5
Read and query coverage is broad, spanning system info, Docker, VMs, UPS, notifications, logs, and settings. However, there are no mutation or control tools for starting/stopping containers or VMs, changing shares, managing the array, or creating API keys, leaving significant management gaps.
Average 3.8/5 across 75 of 88 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on August 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is established. The phrase 'bounded section' adds useful behavioral context about limiting reads, but the description does not mention response format, path validity behavior, or any other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant wording. It is efficient, though extremely terse; brevity is a strength, but it borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no parameter descriptions, the description leaves significant gaps: how bounds are expressed, what content is returned, and how this differs from unraid_read_system_log or unraid_query_log_files. An agent can guess, but the definition does not fully support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the roles of path, lines, or startLine. The phrase 'bounded section' weakly hints at line-based reading, but the agent is left to infer which parameters define the bounds and how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), a clear resource ('server log file'), and a scope ('bounded section'), so an agent understands the core function. It does not explicitly differentiate from log-related siblings such as unraid_read_system_log or unraid_query_log_files, but the action and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like unraid_read_system_log or unraid_get_docker_logs. The description gives no context about which log file types it applies to or what distinguishes it from the many log-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the bar for additional disclosure is lower. The description adds value by noting that the response includes overview counts and active warnings/alerts, but it omits behavioral details like pagination ordering or how importance filtering affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence with no filler, redundant phrasing, or restatement of the tool name. The primary action and scope are front-loaded before the additional output details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and zero schema-level descriptions, the description is not complete enough for reliable invocation. It fails to explain pagination via limit/offset or the role of the importance filter, and the many sibling notification tools make the lack of routing guidance more costly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only partially maps to the 'type' parameter via 'unread or archived'. The limit, offset, and importance parameters have no semantic explanation in either the schema or the description, leaving the agent to guess their effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('List'), a resource ('Unraid notifications'), and scopes it to 'unread or archived' notifications, plus overview counts and active warnings/alerts. It does not explicitly name or contrast any sibling tool such as unraid_v4371_query_notifications, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over sibling notification tools like unraid_v4371_query_notifications or the various unraid_v4371_next_notifications_* subscriptions. The description implies a use case but provides no exclusions, prerequisites, or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear and there is no contradiction. The description does not add behavioral detail beyond those annotations, such as return format or role-validation behavior, but it is consistent with them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repeated title content. It is efficient, though slightly under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only query with strong annotations, the description is adequate but minimal. There is no output schema and the description does not clarify what the resolved permission output looks like, nor does it differentiate this from closely related role/permission tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for the undocumented roles parameter. It only restates 'a set of roles' and adds no meaning beyond the schema's array type and enum values, leaving the burden on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('resolve') and a clear resource ('permissions granted by a set of roles'), so an agent can tell this is a permission-lookup query. It does not explicitly contrast with closely related sibling tools such as query_preview_effective_permissions or query_api_key_possible_permissions, which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description never states when to use this tool instead of query_preview_effective_permissions, query_api_key_possible_permissions, or query_available_auth_actions, leaving tool selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description is consistent with those. The description adds modest context by saying the response includes counts, a page, and current warnings/alerts, but it does not disclose operational details like auth needs, rate limits, or pagination behavior beyond what the schema already provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence with no filler. It front-loads the verb and lists the three result components economically, making every word meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with annotations covering safety, the description provides a reasonable high-level summary of the return payload. However, with no output schema and no explanation of filter semantics or how this differs from sibling notification tools, an agent could still struggle to choose and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter documentation, but it does not. The phrase 'bounded filtered page' vaguely hints at the filter's role, yet it never explains the nested filter object, the UNREAD/ARCHIVE type enum, offset, limit, or importance. The schema's property names carry most of the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource: notification counts, a filtered page, and current warnings/alerts. It is unambiguous about what the tool returns, though it does not explicitly distinguish itself from sibling tools like unraid_list_notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling alternatives such as unraid_list_notifications or the next_* subscription tools. The description implies this is a direct query rather than a subscription, but it never states exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. 'Preview' is consistent with these hints and adds the notion of computing/combining effective grants, but the description discloses no further behavior — for example, whether roles and permissions are combined, whether they are alternatives, or what happens when no parameters are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One eight-word sentence with no filler; the operative verb 'Preview' is front-loaded and every word contributes meaning. It is appropriately sized for a simple read-only tool, though it leans toward under-specification rather than polished completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, zero parameter descriptions, and multiple similar auth/permission siblings, a single sentence cannot adequately equip an agent to call this tool correctly. Missing pieces include the shape of the preview result, how roles and permissions combine, and how this tool differs from unraid_v4371_query_permissions_for_roles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the burden falls on the description. It does add interpretative value by mapping 'role' to the roles parameter and 'explicit permission grants' to the permissions parameter, and the inline enums (ADMIN/VIEWER roles, READ_ANY/CREATE_ANY actions) are self-descriptive. However, it does not explain how the two parameters interact, their optionality, or any default behavior, leaving the agent to guess at combination semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Preview effective role and explicit permission grants') with a clear verb and resource: it computes effective permissions from roles and explicit grants. However, it does not differentiate itself from the highly similar sibling 'unraid_v4371_query_permissions_for_roles', so an agent cannot tell which tool answers a given permissions question without opening both schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when not to use it, or which alternatives apply. Given the near-sibling 'unraid_v4371_query_permissions_for_roles' and related auth-query tools (query_api_key_possible_roles, query_api_key_possible_permissions, query_available_auth_actions), the absence of any routing guidance is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds valuable behavioral details beyond these: it is a one-shot subscription call that waits for a single event, returns a bounded payload, and then disconnects. This gives the agent meaningful insight into blocking and lifecycle behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that front-loads the essential behavior: waiting for the next event, bounded payload, and disconnection. Every phrase earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and one required parameter at 0% schema coverage, the description needs to explain what operationId refers to and what the returned payload contains or how it is bounded. It does neither, so an agent cannot confidently invoke this tool correctly despite understanding its general lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or purpose of the required operationId parameter at all. Since there is no enum, default, or schema description, an agent has no basis for determining what value to supply. The description entirely fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Wait for the next event'), a specific resource ('this fixed GraphQL subscription'), and the action outcome ('return one bounded payload, then disconnect'). It is clear about what the tool does, though it does not explicitly differentiate itself from the many other next_* subscription sibling tools beyond the name and title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when you need the next plugin installation update event from a fixed subscription, but it does not state when to choose this instead of alternatives like query_plugin_install_operations or other next_* subscription tools. There is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds modest behavioral context with 'bounded timestamped', indicating that results are limited and time-filtered, but it does not disclose return format, pagination, or rate limits. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler words. The core action and scope are front-loaded, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three straightforward parameters, no output schema, and strong annotations, the definition is largely adequate for a safe read operation. However, the existence of near-duplicate sibling tools like 'unraid_get_docker_logs' creates potential selection ambiguity that the description does not resolve, and no usage guidance is provided. These gaps make it adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only indirectly hints at parameter semantics through 'bounded' (tail) and 'timestamped' (since). It does not explain that 'id' identifies the Docker container or define how tail and since behave beyond what parameter names imply. Given the schema's clear constraints and self-explanatory param names, this is partial but not full compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') with a clear resource ('bounded timestamped logs from one Docker container'), making the tool's core function easily identifiable. It also distinguishes itself from list/system-log siblings by emphasizing single-container scoping and timestamp bounds. However, it does not explicitly differentiate itself from the similarly named sibling 'unraid_get_docker_logs', which keeps it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as 'unraid_get_docker_logs' or 'unraid_v4371_query_docker_container'. There are no exclusions, prerequisites, or selection criteria provided, leaving the agent to infer usage solely from the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile: read-only, idempotent, non-destructive. The description adds the 'current' snapshot framing and the list of metric types, which is useful but does not disclose response structure, units, or edge cases such as missing temperature sensors. With strong annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Get current') and then enumerates the metric families. It contains no fluff or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and strong annotations, the definition is mostly sufficient, but the lack of an output schema makes the missing return-format information more meaningful. It also does not note how this tool differs from the many query_metrics and next_system_metrics siblings, so an agent has enough to call it but not enough to confidently choose it over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the baseline for parameter semantics is 4. No parameter documentation is needed, and the description's metric list adds useful context about the expected return content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource: current CPU, memory, network, swap, and temperature metrics from Unraid. It is easy to understand what the tool returns, but it does not explicitly distinguish itself from similarly scoped siblings like unraid_v4371_query_metrics or the unraid_v4371_next_system_metrics_* tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description simply restates the operation, and the sibling list contains several closely related metric tools (unraid_v4371_query_metrics, unraid_v4371_next_system_metrics_cpu, etc.) with no exclusions or selection criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by naming the returned fields, but it does not disclose output shape, pagination, or any ordering/filtering behavior. This is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or redundancy. Every part of the description adds information about the tool's scope or output fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, annotated read-only tool, the core call contract is mostly complete. However, the existence of a closely named sibling, unraid_v4371_query_shares, creates ambiguity about which share-listing tool to invoke, and the description does not resolve it. A short comparison or exclusion would make the description contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter documentation burden on the description. The field list in the description compensates for the absent output schema by indicating what the returned data will contain, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('user shares') and enumerates the fields returned: capacity, allocation, cache, disk inclusion, and LUKS status. This makes the tool's purpose clear, though it does not explicitly distinguish it from the sibling tool unraid_v4371_query_shares, which likely covers a similar share-listing use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus unraid_v4371_query_shares or other sibling list/query tools. There are no conditions, prerequisites, or exclusions. The agent must infer usage from the title and field list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the operation's safety profile. The description adds that the tool enumerates log files available through the Unraid API, which clarifies the action, but it does not disclose return shape, ordering, or empty-list behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One clean, front-loaded sentence with no filler. The verb and resource are presented immediately, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent list operation, the description plus annotations are minimally sufficient. However, there is no output schema and the description does not indicate what a returned list contains or how this tool differs from the similarly named unraid_v4371_query_log_files.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. No additional parameter explanation is needed from the description, earning the zero-parameter baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('system log files'), and it clarifies that the tool returns available log files rather than log contents. However, it does not differentiate itself from overlapping siblings like unraid_v4371_query_log_files or unraid_read_system_log.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives. The closest sibling, unraid_v4371_query_log_files, appears to overlap significantly, and unraid_read_system_log likely handles log contents, but the description does not mention either or provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already report readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds meaningful lifecycle information beyond those hints: it explicitly says the tool returns one bounded payload and then disconnects, which is important for an agent that might expect a continuous stream or multiple events. It does not mention timeout behavior or what happens if no event ever arrives, but the provided disclosure is still valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every phrase earns its place: the action ('wait'), the resource ('fixed GraphQL subscription'), the output shape ('one bounded payload'), and the termination ('then disconnect').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description is too thin to fully support correct invocation. It does not clarify what `path` should be, what kind of event is waited for, or how the bounded payload is structured. The blocking/wait behavior and whether a timeout exists are also unstated, which is significant for an agent deciding whether to call this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only declares a required string `path`, and the schema description coverage is 0%. The description does not explain what `path` means, what format or source it should come from, or how it relates to the subscription, leaving the agent to guess that it is a log file path. The tool name and sibling tools like unraid_v4371_query_log_files provide some inference, but the description itself adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for the next event from a fixed GraphQL subscription, returns one bounded payload, and disconnects. This differentiates it from the query_* siblings by emphasizing the 'next/event-subscription' nature, and the title names the logFile resource. It stops short of saying 'next log line' or 'new log entry', which would make the purpose even more concrete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: this is for obtaining the next event rather than querying current state, which helps distinguish it from unraid_v4371_query_log_file. However, there is no explicit 'use this when...' guidance, no mention of alternatives, and no statement about whether to call this repeatedly or combine it with query_log_files to discover valid paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds one useful behavioral detail beyond annotations: the base64 case image is deliberately excluded from the response. It does not describe response shape or auth needs, but that is less critical for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the action front-loaded and only one clarifying detail about the excluded base64 image. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple no-parameter read-only query, but with no output schema the agent learns only that it returns 'display preferences' minus the case image. More detail about the returned preference fields or the relationship to sibling theme/display tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is nothing for the description to add about parameters. The baseline of 4 for a zero-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get display preferences') and adds a scope-defining constraint about the base64 case image. It is clear, though it does not explicitly distinguish itself from similar query_* siblings like query_public_theme.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives, and no sibling or alternative is named. The 'without returning the base64 case image' clause narrows the output but does not help an agent decide when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds one useful behavioral detail beyond annotations: it excludes machine, hardware, OS, and DIMM serial identifiers. However, it does not describe auth expectations, response structure, or other call-time behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource, then states the key exclusion. Every word contributes meaning, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is mostly adequate, but there is no output schema and the description does not enumerate what 'detailed system inventory' contains. Given the presence of unraid_get_system_info, the lack of clarification about this tool's specific scope leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics that the description must explain. The baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a clear resource ('detailed system inventory') with an explicit exclusion detail. It is clear in isolation, but it does not explicitly distinguish itself from closely named siblings like unraid_get_system_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over alternatives such as unraid_get_system_info or the many other query_info siblings. No exclusions, prerequisites, or selection criteria are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds one behavioral constraint beyond annotations — bounded temperature history — but the phrasing 'without unbounded temperature history' is an awkward double negative that leaves the exact behavior (bounded vs. no history) ambiguous. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence with no filler. The verb and resource are front-loaded, and the caveat about temperature history is appended without bloat. Every word carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool, the description is adequate for selecting and invoking it. However, there is no output schema, and the description gives no hint of the response shape, units, or whether values are current snapshots versus time series. It also leaves the agent wondering what to use when full temperature history is actually needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline of 4 applies. There is nothing for the description to document about parameters, and it appropriately does not invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get CPU, memory, temperature, and network metrics'. It clearly enumerates the metric domains returned. However, it does not differentiate from the near-identically named sibling `unraid_get_metrics`, which plausibly serves the same purpose, so it falls short of full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given. The only hint is the caveat 'without unbounded temperature history', which vaguely implies another tool exists for full history, but it never names `unraid_v4371_next_system_metrics_temperature` or the streaming `next_*` variants. Given roughly 70 siblings including an overlapping `unraid_get_metrics`, the absence of routing guidance is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds the 'connected' scope, which is a small behavioral constraint, but it doesn't disclose what happens if no account is connected or what the returned profile contains. Given the strong annotation coverage, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded, unambiguous sentence with no wasted words. It communicates the core function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read query with annotations covering safety, the description is mostly sufficient. However, the sibling unraid_v4371_query_me creates ambiguity about what 'owner' means versus 'me,' and the description does not clarify the distinction or any expected output. This leaves a meaningful completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain beyond the schema. The baseline of 4 applies here because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the connected Unraid account profile.' This clearly describes what the tool does using active language. However, it does not differentiate from the sibling tool unraid_v4371_query_me, which could plausibly retrieve the same information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling query tools. It does not state exclusions, conditions, or alternatives, leaving the agent to guess the distinguishing use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds some scoping by naming what is returned, but it does not disclose any additional behavioral traits such as auth requirements, pagination, or response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. Each listed attribute ('capacity', 'placement', 'filesystem settings') is a meaningful, non-redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only query, the description is usable: an agent knows it will get share capacity, placement, and filesystem settings. However, there is no output schema and no indication of response structure, and the relationship to unraid_list_shares is left unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with additionalProperties false, so there are no parameter semantics for the description to clarify. This matches the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('shares') and names three concrete aspects of the returned data: capacity, placement, and filesystem settings. It does not explicitly mention or distinguish itself from the sibling 'unraid_list_shares', so the differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to prefer this tool over alternatives like unraid_list_shares, nor any stated exclusions or conditions. The description simply says what it lists, requiring the agent to infer usage context on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope of data returned but no further behavioral traits like authentication needs, response format, or rate limits. With annotations carrying the safety burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with a compact list of output categories. Every phrase contributes meaning, and there is no filler or redundant restating of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema read-only tool, the description adequately conveys what will be returned (versions, OS, hardware, memory, network interfaces). The absence of explicit sibling differentiation is a minor gap, but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there are no parameter semantics to document. The description reinforces that no input is needed by describing the output scope, matching the baseline of 4 for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('Unraid system information'), then enumerates concrete content areas: Unraid/API versions, host OS, hardware summary, memory modules, and network interfaces. This distinguishes it from focused siblings like unraid_get_metrics or unraid_get_array, though it does not explicitly differentiate it from similarly broad tools like unraid_v4371_query_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose this tool over any of the many sibling query/list tools. It does not mention alternatives, exclusions, or preferred use cases, leaving the agent to infer selection solely from the name and outcome list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what data is returned but does not disclose other behavioral traits such as response size, sorting, filtering, or any operational caveats. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the core action and resource, then lists the output content compactly. Every word contributes meaningful information and nothing is redundant with the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only listing tool with no output schema, the description adequately names the response categories: identity, SMART summary, temperature, and partitions. It could clarify what counts as 'assignable' or describe the output shape, but for this simple operation the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema description coverage, so there is no parameter meaning for the description to add. The baseline of 4 applies because there is no parameter semantics burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('detected and assignable physical disks'), and enumerates the included data (identity, SMART summary, temperature, partitions), making the purpose clear. It does not explicitly differentiate itself from sibling tools like unraid_v4371_query_disks or unraid_v4371_query_assignable_disks, but it identifies its scope sufficiently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to choose this tool over the many sibling query/list tools. There is no mention of alternatives, exclusions, or conditions, so an agent must infer usage solely from the name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds the output field scope (IDs, names, lifecycle states) but gives no further behavioral context such as ordering, filtering, or relationship to the query_vms sibling. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is specific and front-loaded with the action and resource. Every phrase adds value by enumerating the returned fields, with no affiliation or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list operation with safety annotations already provided, this description is nearly complete. It states the core output fields despite the absence of an output schema, but it would be slightly more complete if it distinguished itself from the similarly scoped unraid_v4371_query_vms sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the schema fully documents this with 100% coverage. The description's mention of IDs, names, and lifecycle states refers to output rather than parameters, so there is nothing missing for the agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific verb ('List'), a specific resource ('Unraid virtual machines'), and the exact output fields ('IDs, names, and lifecycle states'). It is clearly distinct from list tools for other resources like disks or Docker containers, though it does not differentiate itself from the similar sibling unraid_v4371_query_vms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to prefer this tool over alternatives, and the sibling list includes unraid_v4371_query_vms which may overlap significantly. There is no mention of when to use this tool versus query-style VM tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the data scope (capacity, parity, member disks), but it does not describe response format, pagination, or any limitations beyond that scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the resource and expected output, making it easy to read and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only state query with strong annotations, the description is largely complete. It does not mention the response format and does not disambiguate from the similarly named unraid_get_array, but those are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameter semantics to clarify; schema coverage is effectively 100%. The description's mention of what is queried is useful but not required for understanding parameters because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get array state') and lists concrete data dimensions: capacity, parity status, and member disks. It is clear and informative, but it does not distinguish itself from the sibling tool unraid_get_array, which appears to target the same resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as unraid_list_disks, unraid_v4371_query_disks, or unraid_get_array. The description only implies usage through its wording, but does not state exclusions, prerequisites, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which cover the safety profile. The description's 'List' phrasing is consistent with those annotations but adds no additional behavioral context, such as whether the returned list varies by caller or whether authentication is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the verb and object clearly and is appropriately sized for a parameterless read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only query, the description is mostly complete: the agent knows what will happen and needs no input. However, there is no output schema and no description of what the returned list contains, and the ambiguity about 'authentication actions' prevents a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics burden on the description. The schema is empty and fully covered, and the baseline of 4 applies because there is nothing for the description to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('authentication actions supported by the API'), so an agent can understand what the tool does. However, it does not explicitly distinguish this from closely related sibling tools like query_api_key_possible_permissions or query_permissions_for_roles, leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many similar query tools. There is no mention of alternatives, exclusions, or contextual prerequisites, so the agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds that the tool reports validation status and the current error, but it does not elaborate on return format or any auth/rate-limit context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no filler or repetition. Front-loads the action and object immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter read-only query, especially with rich annotations. Slightly vague about what 'core configuration' refers to and what shape the validity/error response takes, but an agent can invoke it without further input.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description does not need to explain inputs. The no-parameter baseline applies; nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), resource ('core configuration'), and outcome ('validity and its current error'), which separates it from many other query_* siblings. It is clear but does not explicitly differentiate from related tools like query_settings or query_vars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to call this tool versus any sibling, nor any context such as checking config before/after operations. The agent must infer use 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is fully covered. The description adds modest context by mentioning 'safe settings values' and 'without form schemas,' but it does not disclose return shape, error behavior, or what 'safe settings' excludes. This is adequate given the strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The main action and resource are front-loaded, and every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query with rich annotations, the description provides enough scope to know what will be returned: Unraid Connect status and safe settings values. It could be more precise about what 'safe settings values' includes, but no required invocation details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%, so the schema places no burden on the description. The description does not need to explain parameter behavior because none exist, making this a solid baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a concrete resource ('Unraid Connect status and safe settings values'), making the tool's purpose clear. It does not explicitly contrast with sibling tools, but the 'without form schemas' phrasing hints at a distinction from form-schema-related queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling query tools such as unraid_v4371_query_settings or unraid_v4371_query_config. The description implies a read-only status query, but it does not state when this specific tool is the right choice or when an alternative should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false). The description adds one piece of behavioral context beyond that: the tool will not return client secrets, which is useful for an agent deciding whether output is safe to expose. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the verb and resource, followed by the one qualifier that matters. No filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description plus annotations are largely sufficient: it states the operation, the key security caveat, and the safety profile. The main gap is not clarifying the relationship to the closely named siblings, but this is minor given how simple and safe the call is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing to document. Baseline for 0 params is 4; the description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('OIDC provider configuration'), and the qualifier 'without client secrets' adds meaningful scope. However, it does not explicitly differentiate from closely related siblings like query_oidc_provider, query_oidc_configuration, and especially query_public_oidc_providers, leaving some ambiguity about what 'providers' excludes or includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many OIDC-related siblings (query_oidc_provider, query_public_oidc_providers, query_oidc_configuration, query_is_sso_enabled). Neither alternatives nor exclusions are mentioned; only an implicit hint ('without client secrets') that this is the safe option when secrets are not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the resource scope 'loaded API plugins and module capabilities' but no further behavioral context such as auth needs, output volume, or operational caveats. This is adequate given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action and scope clearly and economically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list operation, the description conveys the essential purpose and high-level return content. However, because there is no output schema, the description could slightly expand on what 'module capabilities' includes or what shape the list takes, though this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to document. The baseline of 4 applies because the description does not need to compensate for any parameter coverage gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and a distinct resource ('loaded API plugins and module capabilities'), which separates it from sibling tools like unraid_v4371_query_installed_unraid_plugins. However, it stops short of explicitly differentiating itself from related plugin tools, and 'module capabilities' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool instead of related siblings such as unraid_v4371_query_installed_unraid_plugins or unraid_v4371_query_plugin_install_operations. The agent must infer intent purely from the short description and tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the specific data fields returned (status, uptime, version), but discloses no further behavioral traits such as output format or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states exactly what the tool does without filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only tool with rich safety annotations, the description is largely complete. However, there is no output schema and no elaboration on what 'services' means here, which could create minor ambiguity given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is needed from the description. The schema coverage is 100% and the description simply clarifies the subject matter, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names the resource ('service status, uptime, and version information'). It distinguishes the tool from most sibling query tools, but it does not explicitly contrast with unraid_get_system_info, which could also provide version/status data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. With over 100 sibling tools, the description does not state when service status is the right resource to query or mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds useful scope context by listing the four configuration areas covered. However, it discloses nothing about the response shape or whether the data is live or cached — gaps that matter since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single nine-word sentence that front-loads the verb and resource before enumerating scope categories. Every word earns its place; there is no fluff, repetition, or schema duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent query tool, the description is nearly sufficient: annotations cover safety, and the description covers what the tool returns. It falls short only by not clarifying how it differs from unraid_get_ups or query_ups_devices, which the sibling list shows are closely related.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 and there is nothing for the schema to document. The description adds value by previewing the payload scope (service, connection, network, shutdown configuration), which is the closest thing to semantic content a parameterless tool can offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource (UPS configuration) and enumerates the scope in concrete terms: 'service, connection, network, and shutdown configuration.' This differentiates it from sibling device-query tools (query_ups_devices, query_ups_device_by_id) and the status-oriented unraid_get_ups through the word 'configuration,' though it never explicitly names those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not state when to prefer this over unraid_get_ups, query_ups_devices, or query_ups_device_by_id, and offers no exclusions or prerequisites. An agent must infer usage solely from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the output scope ('their states') and does not disclose additional behavioral traits such as whether only running VMs are included or how state is represented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and directly states the action and subject. Every word earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless, read-only listing tool, the description is almost sufficient. It tells the agent what the action is and that the output includes virtual machines and their states, although an output schema would be needed for full return-structure clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is effectively complete. There are no parameter semantics for the description to clarify, so the baseline for a no-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('virtual machines') plus the key detail ('their states'). It is clear and unambiguous on its own, but it does not differentiate itself from the similarly named sibling tool unraid_list_vms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool rather than alternatives. The sibling list includes unraid_list_vms, which appears to overlap significantly, and the description does not explain any distinction or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior beyond this: 'return one bounded payload, then disconnect' discloses that the tool is a one-shot subscription, not a long-lived stream, and that the result is finite. This does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action ('Wait for the next event') and packs the key behavioral constraints—bounded payload, disconnect—into minimal, well-ordered prose with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the subscription lifecycle (wait, one payload, disconnect) but leaves unspecified what an arraySubscription event actually contains, how long the wait may be, or timeout behavior. Without an output schema, the vague 'bounded payload' does not fully inform the agent about the return value, though the tool's simplicity lowers the severity of this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to explain. A baseline of 4 is appropriate for a parameterless tool; the description correctly adds no parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Wait for the next event from this fixed GraphQL subscription' and clarifies the one-shot behavior with 'return one bounded payload, then disconnect.' It clearly differentiates from the many query siblings by naming it a subscription, though it relies on the tool name to specify it is the array subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives such as polling unraid_get_array or choosing another next_* subscription sibling. The imperative 'Wait for the next event' implies a real-time waiting use case, but no exclusions, alternatives, or decision criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=true), so the description's job is to add operational context. It does: 'Wait' discloses that the call blocks until an event arrives, 'one bounded payload' promises the response is size-limited, and 'then disconnect' reveals the subscription is self-terminating rather than streaming. These are meaningful behavioral traits the annotations do not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of about eighteen words that front-loads the core action ('Wait for the next event'), then specifies the two boundary conditions (bounded payload, disconnect). Every element — 'fixed', 'one', 'bounded', 'then' — earns its place, and there is zero redundancy with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 0-parameter tool with annotations covering safety, the operational flow is adequately described. But there is no output schema, and 'return one bounded payload' never hints at what the payload contains or what a displaySubscription event represents, leaving the agent to guess at return semantics. It also does not clarify whether the wait can block indefinitely or if a timeout applies. These gaps are moderate, not crippling, for such a simple invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema description coverage is 100%, so per the rubric the baseline is 4. The description's 'fixed' qualifier usefully reinforces that the subscription is pre-bound and takes no configuration, aligning with the empty input schema. Nothing more is needed for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Wait') and resource ('the next event from this fixed GraphQL subscription') and adds distinct behavioral specifics: one bounded payload, then disconnect. It is not a tautology, and the lifecycle (wait/return/disconnect) clearly separates it from the query-style siblings. However, the description never says what a 'displaySubscription' event actually is, so it relies on the tool name to carry the domain meaning and does not differentiate it from the other next_* subscription siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no exclusions, and no alternatives. There are roughly eighteen sibling subscription tools (next_notification_added, next_array_subscription, etc.), and nothing in the description helps an agent choose this one over them — the word 'fixed' only signals that no configuration is needed, not when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds valuable non-obvious behavior: it is a one-shot, blocking wait, returns a bounded payload, and disconnects rather than streaming. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the key action ('Wait for the next event') and adds the essential behavioral constraints. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter subscription the behavioral lifecycle is covered, but with no output schema the description does not explain what the notificationsOverview payload contains or what triggers it. An agent selecting among similarly named subscription tools gets only the title as semantic context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and 100% coverage, so the baseline is 4. The description reinforces this with 'fixed', and there are no parameter semantics left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific action—wait for the next event, return one payload, disconnect—and identifies the resource as a fixed GraphQL subscription, matching the notificationsOverview title. It is clear enough but does not differentiate this subscription from sibling next_* subscription tools such as next_notification_added or next_notifications_warnings_and_alerts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that query_notifications or list_notifications could be used for current state, nor any condition for choosing to wait for an event instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it is a one-shot subscription ('then disconnect'), fixed rather than configurable, and returns a bounded payload rather than a stream. It does not cover timeout or error behavior, but annotations already establish that the operation is read-only, idempotent, and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 18-word sentence with no filler. It front-loads the core action and includes every essential operational detail: wait, return one bounded payload, then disconnect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter subscription tool, the core lifecycle is covered: wait for an event, return a bounded payload, disconnect. However, there is no output schema, and the description does not describe what the payload actually contains or whether the wait can be indefinite. This leaves a meaningful gap for an agent trying to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and the schema confirms this with an empty properties object, so there is nothing for the description to clarify. The word 'fixed' reinforces that no selection or input is needed. Baseline for a zero-parameter tool is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete behavior: wait for the next event from a fixed GraphQL subscription, return one bounded payload, then disconnect. The title identifies the resource as the notificationsWarningsAndAlerts event. It does not explicitly distinguish sibling next_* subscriptions, but the one-shot subscription semantics are clear enough to separate it from query/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not explain when this should be chosen over sibling tools like unraid_v4371_next_notifications_overview or unraid_list_notifications, nor does it mention alternatives or prerequisites. Usage context is only implied by the verb 'wait'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it blocks waiting for the next event, returns a bounded payload, and disconnects automatically. These traits are not fully captured by readOnlyHint=true or idempotentHint=true. It does not disclose timeout behavior or what happens if no event arrives, but the core lifecycle is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one tight, front-loaded sentence. Every clause adds value: waiting, bounded payload, and disconnecting. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining the return value, but it only says 'one bounded payload' without describing the payload's structure or content. It also omits potential wait duration or cancellation behavior. For a simple zero-parameter subscription tool it is adequate, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty with 100% schema description coverage. The description's phrase 'fixed GraphQL subscription' reinforces that no arguments are needed. The baseline for zero-parameter tools is 4, and nothing here reduces that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: wait for the next event from a fixed GraphQL subscription, return one bounded payload, then disconnect. This conveys a specific one-shot behavior that matches the tool name. However, it does not explicitly distinguish this subscription from the many other next_* sibling subscriptions beyond relying on the tool name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the many sibling subscriptions such as next_display_subscription or next_array_subscription. The one-shot 'then disconnect' behavior implies a use case, but no conditions, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: this is a one-shot subscription that returns a bounded payload and disconnects, preventing the assumption that it is a persistent stream. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One tightly worded sentence conveys the entire behavioral contract: wait, return bounded payload, disconnect. Every phrase earns its place and the key behavioral information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool this covers the basic lifecycle well, and annotations cover the safety profile. However, there is no output schema and the description does not describe what the bounded payload contains, any timeout behavior, or possible error cases, leaving some uncertainty about what the caller receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% description coverage, so there are no parameter semantics for the description to clarify. Baseline 4 applies because there are no parameters requiring explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wait for the next event'), the resource ('this fixed GraphQL subscription'), and the termination behavior ('return one bounded payload, then disconnect'). However, it does not explicitly mention 'temperature' or differentiate itself from the many sibling next_* subscriptions; the title carries that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's operational mechanics but provides no guidance on when to use this subscription versus sibling alternatives like the CPU, memory, or network metrics subscriptions. No exclusions or selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the resource name and no extra behavioral context such as auth needs, rate limits, or side effects beyond those annotations. It is consistent with the read-only annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a no-parameter input, rich safety annotations, and a straightforward read operation, the description is complete: an agent knows what the tool returns and that it is safe. No output schema exists, but the return value is adequately described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so the description does not need to document any parameters. Baseline for zero-parameter tools is 4; nothing is missing here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Get the public WebGUI theme.' It is unambiguous about the operation, though it does not contrast against related query tools such as query_customization or query_display, so it does not explicitly differentiate among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives or any prerequisites. For a trivial no-parameter read this is a minor gap, but the description still provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond this: the returned projection is deliberately sanitized and excludes credentials and unique device IDs. This is valuable disclosure that annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about a dozen words, with the core behavior front-loaded and every word contributing meaning. It efficiently conveys both what the tool returns and what it omits, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and zero parameters, the description carries the burden of explaining what the agent should expect. It clearly states the exclusions but does not enumerate or characterize the included vars, and 'operational projection' is vague enough that an agent may not know what fields or categories to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics for the description to clarify. The baseline of 4 for zero-parameter tools applies, and the description does not need to compensate for any missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and identifies a specific resource ('Unraid vars'), and further clarifies that the result is a sanitized 'operational projection' with credentials and unique device IDs excluded. This distinguishes it from raw config or settings queries, though the term 'operational projection' is somewhat jargon-heavy and leaves the exact nature of 'vars' underdefined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to prefer this tool over the many sibling query tools, nor does it name any alternative or exclusion condition. The 'safe' wording implicitly suggests use when a redacted vars view is needed, but that is left to inference rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds the scope of returned data (array state, parity, disks), which is useful but not rich behavioral context. No side effects, permissions, or response format details are provided, but for a read-only getter this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Get array state') and lists the key data categories compactly. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and read-only annotations, the description provides enough high-level information about what is returned (array state, capacity, parity, disks) to determine relevance. It could be more detailed about the structure of each disk entry, but for a simple getter this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so there is nothing to explain. The baseline of 4 applies because no parameter documentation is needed; the description doesn't need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets array state, capacity, parity status, and the boot/parity/data/cache disks, using the verb 'Get' with a specific resource. However, it does not explicitly differentiate from the sibling unraid_v4371_query_array, which likely covers similar array data, so it is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when array status information is needed, but it provides no explicit guidance on when to use this tool instead of alternatives like unraid_list_disks or unraid_v4371_query_array. There are no stated exclusions or alternative tool names, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only, idempotent, and non-destructive, so the description does not need to restate safety. It adds useful behavioral context by emphasizing that the log section is bounded and that the path must come from the API's listing operation, not an arbitrary user-supplied path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately states the core operation and then gives the critical prerequisite. There is no filler or redundant repetition of the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the prerequisite and read-only intent are adequately conveyed, and the schema covers the required path. However, with no output schema and no explanation of what the returned log section looks like or how startLine and lines interact, an agent is left to infer part of the behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the path parameter is described in the schema, and schema coverage is low at 33%. The description reinforces that path must be API-provided, but it does not explain the semantics of lines or startLine beyond the vague phrase 'bounded section,' leaving two parameters with only numeric constraints and no meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Read a bounded section of a system log') and identifies the resource as a system log. It indicates the scope is bounded, which helps distinguish it from listing all system logs, though it does not explicitly contrast with sibling log-reading tools like unraid_get_docker_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit prerequisite: first obtain the API-provided path with unraid_list_system_logs. This gives clear context for how to prepare the required argument, though it does not state when to avoid this tool or name alternatives for reading other log types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it blocks until an event arrives, the subscription is fixed/pre-configured, the payload is bounded, and the connection self-terminates after one delivery. This is genuinely useful for an agent deciding whether to call a potentially blocking tool. No contradiction with readOnlyHint/idempotentHint; one minor gap is the lack of any timeout mention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 16-word sentence where every element earns its place: mechanism ('wait'), scope ('this fixed GraphQL subscription'), output contract ('one bounded payload'), and lifetime ('then disconnect'). Well-structured and front-loaded with the core waiting behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, one-shot subscription with strong safety annotations, the description covers the essential contract: what happens, what is returned, and that it terminates. Since there is no output schema, a slightly richer indication of payload contents would help, but the resource name (CPU metrics) and the bounded-payload statement provide adequate grounding for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them, so the baseline is 4. There is nothing for the description to add about parameter semantics, and it correctly attempts nothing. The 'one bounded payload' phrasing addresses output rather than inputs, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific behavior ('Wait for the next event... return one bounded payload, then disconnect') tied to a named resource (systemMetricsCpu in the name/title). It is clear what the tool does, and the one-shot disconnect semantics differentiate it from a continuous streaming subscription. However, the description is generic across all 'next_*' subscription siblings; resource differentiation relies on the name rather than the description itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The waiting/push semantics only loosely imply an event-driven use case versus polling query_metrics. With near-twin siblings like unraid_v4371_next_system_metrics_cpu_telemetry, the agent receives no help distinguishing which subscription to select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the domain context that the result is a list of explicit permissions, but does not disclose return format or further behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words; it states the exact action and target efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is adequate: it communicates the output concept and the scope. It does not describe return formatting, but no output schema exists and the tool is simple enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description needs to add no parameter-level meaning; the baseline with 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: lists explicit permissions accepted by API key operations. It is distinct from sibling tools like query_api_key_possible_roles, though it does not explicitly reference alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it—when you need the permission values an API key operation accepts—but it gives no explicit guidance about choosing it over related siblings such as query_permissions_for_roles or query_available_auth_actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'safe' and the content exclusions, which provide mild extra context, but it does not describe response format, failure modes, or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no wasted words. It communicates the resource, the safety characteristic, and what is excluded in a compact, scannable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter query tool with no output schema, the description sufficiently identifies the metadata category and its exclusions. It could be more complete by stating expected return shape or typical use cases, but the low complexity keeps the gap minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so there are no parameter semantics for the description to clarify. The baseline of 4 applies because the description does not need to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get safe customization and onboarding metadata.' It also narrows scope with 'without activation codes or embedded images,' which helps separate it from sibling query tools. However, 'customization' remains somewhat broad and no sibling names are mentioned, so it is not maximally distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving safe customization/onboarding metadata and not for data containing activation codes or images. It offers no explicit when-to-use guidance, exclusions, or alternatives among the extensive list of sibling query tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a bit of context with 'safe network metadata' and 'port conflicts,' but it does not explain return structure, pagination, or what 'update status' exactly refers to.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The deescription is one concise, front-loaded sentence. It states the primary action and resource immediately, then lists additional data categories without unnecessary words. Every phrase contributes meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a no-parameter, read-only query tool with strong annotations, the description provides enough category-level detail for an agent to select and invoke it. It lacks precise output structure, but the absence of parameters and safety annotations lower the burden; the missing specifics are not critical for a zero-argument inventory query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain parameter behavior. The input schema already covers everything; with 0 params, the baseline is 4 and no further compensation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb ('Get') and resource ('Docker inventory'), then expands with discernible output categories: network metadata, port conflicts, organization, and update status. This helps distinguish it from sibling tools like unraid_list_docker_containers, though the phrase 'safe network metadata' remains somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for Docker inventory and related status checks, but it does not explicitly state when to prefer this tool over overlapping siblings such as unraid_list_docker_containers or unraid_v4371_query_docker_container. No exclusions or alternative routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. The phrase 'capped output' adds useful behavioral context, but it does not explain what 'tracked' means, how output is capped, or any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every word contributes: the verb, the resource, and the distinguishing 'capped output' detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only operation with strong annotations and no output schema, the description conveys the core purpose and a key caveat. It would be slightly stronger if it pointed to the plural operation as the source of operationId values or clarified 'capped output,' but nothing essential is missing for making a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the operationId parameter beyond implying it identifies an installation. With one required parameter and no schema documentation, the description should compensate by clarifying the expected value or how to obtain it, which it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies a precise resource ('one tracked plugin installation'), and adds a distinguishing detail ('including its capped output'). This differentiates it from the plural sibling query_plugin_install_operations without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular 'one' implies this tool is the by-id counterpart to query_plugin_install_operations, but it never explicitly names the sibling or states when to choose this over the list operation. The usage context is inferable but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds only the schema-defined ID qualification and no additional behavioral context such as not-found behavior or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation and its input.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with strong annotations, the description and schema are largely sufficient. The only minor gap is not describing the expected output shape, but that is not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter semantics. It only restates that the ID is schema-defined and a string, without explaining what the ID refers to, how to obtain it, or any constraints beyond minLength 1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one UPS device') and pinpoints the selection criterion ('by its schema-defined string ID'). This clearly differentiates the tool from the plural sibling unraid_v4371_query_ups_devices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need a single UPS device by ID. However, it does not explicitly state when not to use it or point to alternatives such as query_ups_devices for listing all devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already fully cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds minor context by enumerating the reported metrics, but it does not disclose behavioral traits such as whether all UPS devices are aggregated into one snapshot or whether the call fails when no UPS is connected. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 13-word sentence that front-loads the verb and resource, then packs the full list of returned data into a compact enumeration. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with full annotation coverage, the description is largely complete: it names the resource and the output domains. The main gaps are the absence of a return-format description (no output schema exists) and no differentiation from the UPS-related sibling tools, but these are minor for a stateless read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing the description needs to document. Per the baseline for 0-param tools, the description is adequate; no parameter semantics are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') plus a clear resource ('connected UPS') and enumerates the exact data domains returned: status, battery, load, voltage, runtime, power, and configuration. This is specific and unambiguous, distinguishing it from general system-info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance. The sibling list contains several closely related UPS tools (unraid_v4371_query_ups_devices, unraid_v4371_query_ups_device_by_id, unraid_v4371_query_ups_configuration, unraid_v4371_next_ups_updates), and the description does not tell an agent how to choose among them, especially given the overlap on 'UPS configuration'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: it waits for the next event, returns exactly one bounded payload, and then disconnects, which is important for an agent to set expectations about blocking and subscription termination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence with the key action front-loaded. Every phrase earns its place: wait, fixed subscription, one bounded payload, and disconnect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter operation the lifecycle is well covered, and the annotation profile is already clear. Yet there is no output schema and the description does not describe what the docker container stats payload contains, so an agent only has the tool title to infer the return data shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so there is no parameter burden to explain. The description's use of 'fixed GraphQL subscription' reinforces that no user-supplied configuration or arguments are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear lifecycle for a subscription: wait for the next event, return one bounded payload, then disconnect. However, the data domain ('dockerContainerStats') is only present in the name/title, not in the description text itself, so a reader would need the title to know which subscription this is among many next_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool should be used when the agent needs the next docker container stats event. No explicit alternatives or exclusions are given, even though sibling tools such as unraid_v4371_query_docker_container and the various system metrics subscriptions cover adjacent use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the call as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds a meaningful behavioral disclosure: the response deliberately omits serial number and detailed geometry, which is not captured by annotations or the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with the verb and primary action first, followed by the output restriction. No filler and no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only query with annotations covering safety, the description is near-sufficient, but it lacks any note on response format, missing-disk behavior, or how the id maps to other disk endpoints. It also does not clarify what fields are actually returned beyond the two exclusions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the id parameter or explains how to obtain a valid disk id. The agent can only infer that id identifies the disk from the tool name and phrase 'Get one disk'; no relationship to query_disks/list_disks is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get'), a specific resource ('one disk'), and a sharp scoping constraint ('without returning its serial number or detailed geometry'). This clearly distinguishes it from the plural/list disk siblings and makes the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No alternative tools are named and there is no explicit when-to-use/when-not-to-use guidance. The singular 'one disk' and the omission clause imply a lightweight single-disk lookup, but the agent is not told to prefer this over unraid_v4371_query_disks or unraid_list_disks, or when those would be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds a meaningful behavioral detail by noting the auth URL is deliberately omitted, which helps the agent understand the response scope. However, it does not describe forceRefresh effects or other response behavior, so it adds only moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. The core action and the most important qualification are stated immediately, making it easy for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and annotations cover the safety profile, but there is no output schema and one parameter (forceRefresh) is unexplained. The description provides enough for basic invocation but not full self-sufficiency, since an agent cannot reason about the forceRefresh option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It identifies that 'one container' maps to the required id parameter, but it never explains the optional forceRefresh boolean. With two parameters and no schema descriptions, leaving one completely undocumented is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('Tailscale status for one container'), and adds a distinguishing detail ('without returning its authentication URL'). This separates it from siblings like query_docker_container, which likely returns the full container details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear context: it is for exactly one container and explicitly excludes the authentication URL. This implies when it should be used, but it does not name an alternative tool for cases where the URL is needed, so it stops short of explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description does not contradict them. The description adds that the tool returns authorization grants, which is useful, but it provides no additional behavioral context such as auth requirements or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The verb and object are front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument, read-only query tool, the description combined with the annotations is mostly sufficient for an agent to invoke it correctly. The only gap is that the structure or meaning of 'authorization grants' is not elaborated, and there is no output schema to clarify it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to add beyond what the schema already establishes. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('the authenticated account and its authorization grants'). This clearly distinguishes it from the many sibling query tools that target system info, arrays, disks, or API keys.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling query tools. It does not mention alternatives or exclusions, so the agent must infer usage from the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint, idempotentHint, and non-destructive behavior, so the description only needs to add substantive context. It does this by specifying that the tool returns interfaces, addresses, routes, and link state. It could go further by describing the response shape, but for a read-only simple list this is meaningful added detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or repetition. Every word adds meaning, and the primary action and payload are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only query with no output schema, this description is complete enough: it states what the tool lists and what categories of data are included. There is no invocation complexity left unexplained, and annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema coverage is 100%, so the description has no parameter documentation burden. With no parameters, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and names a clear resource ('network interfaces'), and goes further to enumerate what is included: addresses, routes, and link state. It is clear and informative, but it does not explicitly differentiate this tool from the sibling unraid_v4371_query_network, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as unraid_v4371_query_network or unraid_v4371_next_system_metrics_network. With a long list of similar query tools, the agent is left to infer the right selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (read-only, idempotent, non-destructive), the description adds important behavioral details: it waits for an event, returns a bounded payload, and disconnects after one result. This clarifies that the tool is a one-shot subscription rather than a continuous stream, which the annotations alone would not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the core action, and every phrase adds information. It is appropriately minimal without redundant schema or annotation repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only subscription tool, the description covers the essential call behavior: wait, return one bounded payload, disconnect. It does not detail the payload shape or timeout behavior, but with no output schema and a simple event subscription, the given information is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers input semantics and the description correctly notes this is a fixed subscription with no configurable options. The 0-parameter baseline of 4 applies, and no additional parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action—wait for the next event from a fixed GraphQL subscription, return one bounded payload, then disconnect—so an agent knows what the tool does. The event type is not repeated in the description text, but the title 'Next Unraid notificationAdded event' makes the resource clear and separates it from sibling subscription tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage: call it when you need the next notificationAdded event and want only one result before disconnecting. It does not name alternatives or explicitly say when not to use it, such as preferring unraid_list_notifications for historical notifications or other next_* subscriptions for different events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although readOnlyHint, idempotentHint, and destructiveHint already cover safety, the description adds important lifecycle behavior: it blocks waiting for an event, returns a single bounded payload, and disconnects. This is material for an AI agent because it prevents expecting a long-lived stream or repeated polling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence captures the entire lifecycle in order: wait, receive one bounded payload, disconnect. There is no filler or duplication of schema/annotation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only subscription event, the description covers the key invocation details: it waits for one event and then disconnects. It does not describe timeout/error behavior or the exact payload fields, but the tool name/title indicate the memory-metrics content and the operation is simple enough to call safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema fully documents this with 100% coverage, so there is little for the description to add. The phrase 'fixed GraphQL subscription' reinforces that no input customization is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (wait for the next event, return one bounded payload, disconnect) and the resource (this fixed GraphQL subscription), which distinguishes it from ordinary query tools. It does not explicitly name 'memory metrics' in the text, but the tool name and title supply that specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need one event from this specific subscription, then want to disconnect. It gives clear one-shot semantics but does not explicitly contrast it with query alternatives such as unraid_v4371_query_metrics or other next_system_metrics_* subscriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the basic safety profile. The description adds important behavioral context beyond the annotations: the operation deliberately avoids returning key material, which is a meaningful security-conscious trait an agent should know before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one tight, front-loaded sentence with no filler. It states the operation, the object, and the key security qualifier efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only query tool with rich annotations, the description covers the essential operational context: what is fetched, the scope, and the sensitive-data caveat. No output schema exists, but 'metadata and grants' gives a reasonable outline of the return content. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only minimally implies that 'id' identifies the API key. It does not explain where the id comes from, what format it should be in, or how it relates to other key-related tools. The semantic value added over the bare schema is thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the exact resource ('one API key's metadata and grants'), and clarifies the scope with 'one', distinguishing it from the sibling query_api_keys plural tool. It also adds a meaningful qualifier about not returning key material, which makes the purpose even more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'one' implies this tool is for retrieving a single API key by ID rather than listing all keys, but the description does not explicitly name the alternative or explain when to choose this tool over query_api_keys or other key-related siblings. Usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile with readOnlyHint, idempotentHint, and destructiveHint. The description adds the specific data returned, which is useful, but does not disclose any further behavioral details such as response format, error handling, or system dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the tool's purpose efficiently with no filler or redundancy. Every word contributes to comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query tool, the description is complete: it names all the value categories returned. The annotations handle the safety context, and no output schema is required to make the tool's purpose clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so there is nothing meaningful to add about parameters. The description still clarifies the output scope, satisfying the baseline expected for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') with a well-defined resource scope: system time, timezone, and configured NTP servers. This distinguishes it from sibling tools such as unraid_v4371_query_time_zone_options, which focuses on available timezone options rather than the current system state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. Given the large sibling list, especially similar query tools like unraid_v4371_query_time_zone_options and unraid_get_system_info, explicit routing or exclusions would help but are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds context beyond annotations by disclosing that the output is a 'non-JSON projection' rather than a raw API payload, which meaningfully shapes agent expectations. The term 'safe' is slightly vague, but the added value over annotations is real.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence of ten words, front-loaded with the action and resource, with the projection detail appended. Every word earns its place; no filler or repetition of schema/annotation content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-param, read-only, idempotent tool with annotations covering safety, the description is largely complete: it states what is fetched and the shape of the response (non-JSON projection). The main gap is the lack of guidance on valid id formats (full ID, short ID, name), and there is no output schema to fill that void, but this is minor for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears responsibility for clarifying the 'id' param. It implies that 'id' identifies the target container ('Get one Doker container'), but it never explicitly states what id refers to (containier ID vs. name), its format, or where the agent should obtain it. Minimal compensation for a single self-named parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get'), resource ('Docker container'), and singular scope ('one'), which clearly differentiates it from plural sibling tools like unraid_list_docker_containers and unraid_get_docker_logs. The qualifier 'with a safe, non-JSON projection' further defines the output contract beyond a bare fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'one' implies use for a single container rather than listing, but no explicit when-to-use guidance, exclusions, or named alternatives are provided. Among roughly 90 sibling tools, including unraid_list_docker_containers and unraid_v4371_query_docker, the routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description's 'Get' aligns with that. The description adds that the result is about identity and hardware identifiers, but it provides no additional behavioral context such as return shape or potential errors. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise 8-word sentence with no filler. The key resource and outcome are front-loaded, making the description efficient rather than under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool takes no parameters and has rich annotations, so the remaining burden is explaining what is returned; the description does so at a high level ('identity', 'hardware identifiers'). Since there is no output schema, a little more detail about the exact fields would have been useful, but the description is sufficient for a zero-input, read-only call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, the schema is an empty object, and schema description coverage is 100%. The description does not need to explain parameters, and it does not attempt to; the baseline 4 for a parameterless tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Get'), a distinct resource ('boot flash'), and the expected payload ('identity and hardware identifiers'), which separates it from the many disk/config/system sibling query tools. Even though the title is terse, the description fully states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent needing boot-flash identity or hardware identifiers would select this tool. However, no explicit guidance is given about when to prefer this over related queries such as unraid_v4371_query_internal_boot_context, and no alternatives 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is well covered. The description adds context by noting that destructive-operation warnings are part of the returned information, which is useful, but it does not describe any further behavioral traits such as response format or warning semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, then efficiently enumerates the four return facets. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters), the rich annotations, and the absence of an output schema, the description provides a reasonable orientation by naming the key output categories. It could be more detailed about how destructive-operation warnings are represented, but it is complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is no parameter documentation burden for the description to carry. Per the baseline for zero-parameter tools, the description need not explain parameters, though it still summarizes the returned content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and names a precise resource ('internal-boot context'), with a concrete list of what it returns: eligibility, names, disks, and destructive-operation warnings. This clearly distinguishes it from sibling query tools like query_flash or query_disks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when internal-boot information is needed, but it offers no explicit guidance about when to prefer this tool over related query tools, nor does it mention any exclusions or alternatives. The context is inferable from the name and content but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it readOnly, idempotent, and non-destructive, so no side effects need restating. The description adds the precise behavioral condition checked ('no license key') and implies a boolean outcome via 'Check whether'. It does not overpromise side effects or contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single declarative sentence that front-loads the query action and the condition; no filler or repeated title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only predicate, the description supplies the essential semantics and even defines the 'fresh install' condition. It does not explicitly state the return type, but 'Check whether' sufficiently implies a boolean; this is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema already covers 100%, so there is nothing for the description to add. Baseline of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Check whether') and states the exact resource condition ('server has no license key'), which maps directly to the tool name. This distinguishes it from other query siblings that check registration, info, or config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence indicates when to prefer this tool over alternatives such as unraid_v4371_query_registration or unraid_v4371_query_info, nor any exclusions. The only context is the purpose itself, so an agent must infer when the check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds a useful qualifier, 'readable', implying a permission filter, and clarifies that the response includes metadata, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler: 'List readable system log files and metadata.' Every word contributes meaning and the verb is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only listing tool, the description adequately states what is returned: log files and their metadata. It is slightly incomplete because it does not clarify how it differs from the singular query_log_file tool, but nothing needed for a correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the description carries no parameter documentation burden. The baseline of 4 applies because there are no parameter semantics to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List' + 'readable system log files and metadata'. The plural 'files' and the mention of metadata clearly distinguish it from the singular sibling query_log_file and from the subscription-style next_log_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as query_log_file, next_log_file, or docker_logs. The agent must infer the intended use from the name and sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context by disclosing that the client secret is deliberately excluded from the response, which is not visible from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no filler. The core action and the key exclusion are both communicated efficiently and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read operation with strong safety annotations, the description is largely sufficient. It does not describe error behavior or response shape, but the tool's simplicity and the clarity of 'configuration' make those gaps minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a required 'id' string with no description, and the tool description does not explicitly explain what the ID represents. The phrase 'Get one OIDC provider configuration' implies the ID selects the provider, but no additional meaning or format guidance is added for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('one OIDC provider configuration'), and adds a key qualifier ('without its client secret'). This clearly distinguishes it from the plural sibling tools and from secret-returning operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single provider configuration by ID, and the 'without its client secret' phrasing hints at a limitation. However, it never explicitly states when to prefer this tool over alternatives like unraid_v4371_query_oidc_providers or unraid_v4371_query_public_oidc_providers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds little beyond what is already provided. It does not contradict the annotations, but it also does not add meaningful behavioral context such as response format or network-failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. It is immediately scannable and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only, idempotent health-check tool, the description is almost complete. The only minor gap is that it does not describe the expected response payload, but the absence of an output schema and the trivial nature of a liveness check keep this from being a serious omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing further the description needs to explain. The baseline of 4 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check whether') and a clear resource ('Unraid API reports itself online'), making its purpose immediately obvious. It is distinguishable from the many resource-specific query siblings by being a general liveness/health check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for checking whether the Unraid API is online, which is a fairly clear usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention whether it should be called as a precondition to other API operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds that the tool lists parity-check history and outcomes, but does not disclose additional behavioral details such as ordering, limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, zero parameters, and strong safety annotations, the description is largely complete. It conveys what the tool returns, though a bit more detail about the output shape would be helpful since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('parity-check history and outcomes'), making the tool's function immediately clear. It also distinguishes itself from the many sibling query tools by targeting a unique data domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you need parity-check history. However, it does not explicitly mention when not to use it or point to alternatives such as subscription-based parity history tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the scope (public login-button metadata) but does not describe response structure, ordering, or whether the endpoint requires unauthenticated access. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler words. Every word earns its place, and the meaning is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list operation with strong safety annotations, the description is largely sufficient. The only gap is that the return payload is not described and no output schema exists, but the scope is well-defined enough for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics to document. With no parameters, the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a precise resource ('public OIDC login-button metadata'), which clearly distinguishes this from sibling tools like query_oidc_providers and query_oidc_configuration. It says exactly what the operation returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'public' and 'login-button' imply the scope, and the sibling names suggest broader OIDC queries, but the description does not explicitly say when to choose this over query_oidc_providers or query_oidc_configuration. Guidance is present only by inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to restate safety. The description does not add behavioral details such as authentication requirements, rate limits, or response shape, but it is consistent with the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant wording. Every phrase contributes meaning by narrowing the resource to remote-access exposure and port-forwarding configuration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only query, the description gives enough conceptual context for an agent to invoke the tool appropriately. It does not enumerate the exact fields in the response, and since there is no output schema, a slightly clearer statement of return content could improve completeness, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, and the empty schema fully documents that fact. With no inputs to explain, the description has no additional parameter semantics to provide, and the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and a specific resource ('remote-access exposure and port-forwarding configuration'), making the tool's purpose immediately clear. This resource scope is distinct from sibling tools like unraid_v4371_query_network, unraid_v4371_query_connect, or unraid_v4371_query_cloud, so an agent can select it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when remote-access exposure or port-forwarding configuration is needed, but it does not explicitly state when to use it versus alternatives or list any exclusions. Sibling tools such as query_network and query_connect are not mentioned, leaving the routing decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation read-only, idempotent, and non-destructive. The description adds specifics beyond annotations: it returns server records but redacts API keys and is scoped to 'connected' servers, which is useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that says exactly what it does and what it omits; no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description covers the core behavior and a critical data-exclusion. It does not describe the record fields, but the absence of parameters and the presence of annotations make the operation simple enough to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters and 100% coverage, so there is no parameter burden for the description to carry. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation ('List') and resource ('connected-server records'), and explicitly adds the limitation 'without returning their API keys.' This differentiates it from related siblings like unraid_v4371_query_server (singular) and the API-key query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage signal is the verb 'List,' which implies this is the tool to call when you need all server records. It does not mention alternatives such as unraid_v4371_query_server or exclusions, leaving when-to-use to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'selectable' nuance, indicating these are valid configuration options, but does not disclose additional behavioral details such as list ordering, formatting, or whether the result is a plain list or objects. For a trivial no-parameter query, this is adequate but not enriched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no wasted words. It is front-loaded with the verb and resource, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's extreme simplicity (no parameters, no output schema, clear read-only annotations), the description sufficiently conveys what the tool returns: a list of selectable system timezones. It doesn't specify the exact data shape, but for invocation purposes it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema covers this fully (100%). The baseline for a zero-parameter tool is 4. The description doesn't need to explain any parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('selectable system timezones'), making the operation unambiguous. It clearly distinguishes this from other sibling query tools like query_system_time or query_settings, which deal with different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: retrieve available timezone options for a system setting. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or conditions. The context is clear but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that: logs are timestamped and paginated via a returned cursor that becomes the next since value. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence defines the action and scope; the second delivers the essential pagination instruction. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only three-parameter log retrieval tool, the description covers purpose, scope, and pagination behavior. Since there is no output schema, it could be slightly more explicit about the response shape or where the cursor appears, but the missing detail is minor for this simple, well-annotated tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all three parameters. The description adds extra value by explicitly explaining the cursor-to-since pagination pattern, which clarifies the intended lifecycle of the since parameter beyond its static schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get') and resource ('timestamped logs for one UnraID Docker container'), clearly scoping to a single container. This distinguishes it from list-style siblings such as unraid_list_docker_containers, though it does not explicitly differentiate it from the similarly named unraid_v4371_query_docker_logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: retrieve logs for a specific Docker container, and advance pagination by reusing the returned cursor as since. It does not name alternatives or say when not to use the tool, but the one-container scope and cursor instruction give enough routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by listing the specific container details it returns, especially 'port conflicts,' which is not obvious from the tool name or schema. It could mention output shape or whether all containers are included, but the added detail is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource, then efficiently enumerates the returned fields. Every word earns its place and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with annotations covering safety and idempotency, the description is complete: it tells the agent exactly what data will be retrieved. No output schema is provided, but the listed result fields give sufficient expectation of the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially documents all inputs. With schema description coverage at 100%, the description correctly focuses on result contents rather than parameters, which is appropriate for a parameter-less read operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List'), a clear resource ('Docker containers'), and enumerates the returned aspects: state, image, ports, autostart, resource sizes, and port conflicts. This distinguishes it from sibling tools like unraid_get_docker_logs or unraid_v4371_query_docker_container, which target different data or a single container.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as unraid_v4371_query_docker_container or unraid_get_docker_logs. Usage context must be inferred entirely from the tool name and description, with no explicit exclusions or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a little behavioral context by specifying the scope ('installed') and the output granularity ('filenames'), but otherwise does not disclose additional behavior such as completeness, ordering, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It front-loads the action and resource, making it immediately understandable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description is complete: it states exactly what the tool returns (plugin filenames) and annotations cover the behavioral safety profile. An agent can select and invoke this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so the schema carries no burden. The baseline for zero-parameter tools is 4, and the description does not need to explain parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and a specific resource (installed Unraid OS plugin filenames), which clearly states what the tool does. It distinguishes itself from siblings like query_plugins and plugin_install_operation by emphasizing 'installed' and 'filenames'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: call it when you need a list of installed plugin filenames. However, it does not explicitly say when not to use it or direct users to a more detailed alternative such as unraid_v4371_query_plugins for richer plugin information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds only the predicate framing ('whether'), implying a boolean outcome; it doesn't disclose additional behavioral details like auth requirements or response shape, though little else is needed for such a simple query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no filler; the verb and object are front-loaded. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only boolean check, the description is sufficient for an agent to invoke it correctly. The 'whether' phrasing conveys the boolean return even without an output schema, and sibling distinctions are clear from the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema closes additionalProperties, so there is nothing the description needs to add. The baseline of 4 for a parameterless tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and a precise resource ('whether SSO is enabled'), making the operation unmistakable. Among many query_* siblings, this is clearly distinct from OIDC/authentication configuration queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: call when you need to know whether SSO is enabled. It does not name alternatives or say when not to use it, but for a zero-parameter status predicate the context is reasonably self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds valuable extra context by promising the API key is not returned, which is an important behavioral guarantee beyond the annotations. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence: it states the action, the resource, and the key safety qualifier with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query, the description is mostly complete: it says what is checked and what is deliberately not returned. It does not describe the response shape, but the absence of parameters and presence of safety annotations lower that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so there is no parameter semantics burden for the description to carry. The baseline of 4 applies because no parameters exist and the description correctly adds no unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') plus distinct resource ('cloud connectivity and API-key validity') and adds a meaningful security qualifier ('without returning the key'). This clearly separates it from siblings like unraid_v4371_query_api_keys and unraid_v4371_query_api_key, so an agent can identify the tool without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for checking cloud connectivity and API-key validity safely without exposing the key, which hints it should be preferred over key-returning alternatives. However, it never explicitly names those alternatives or states when not to use this tool, so routing guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by disclosing that serial numbers and geometry details are intentionally omitted, which informs whether this tool fits a given request. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the action and resource. Every word earns its place, with no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with strong annotations, the description gives enough to understand the core operation and an important output constraint. It could say more about the exact shape of the returned list, but the low complexity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty with 100% coverage, so there is no parameter burden for the description to carry. Per the baseline for zero-parameter tools, this dimension is well satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('attached disks'), and adds the exclusion of serial numbers/geometry details, which makes the tool's purpose precise. This scope helps distinguish it from the numerous sibling query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when this tool is appropriate: when the agent needs attached-disk inventory and not serial numbers or geometry. However, it does not explicitly name alternatives or state when to prefer siblings like unraid_list_disks, unraid_v4371_query_disk, or unraid_v4371_query_assignable_disks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond the annotations by revealing that the result is a deliberately filtered 'safe projection' and specifying which sensitive/complex fields are omitted, which helps the agent set expectations about the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action ('safe settings projection') and adds two clarifying exclusion clauses without wasted words. Every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool, the description gives enough to invoke it correctly and understand what to expect. It could be slightly more explicit about which settings are included, but the exclusions plus the term 'settings projection' make the scope reasonably clear even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain about inputs. The baseline of 4 applies, and no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource — 'Get a safe settings projection' — and goes further by listing what is deliberately excluded (unified values, schemas, OIDC client secrets). This clearly distinguishes it from the many sibling query tools, especially unraid_v4371_query_config and unraid_v4371_query_oidc_configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when a sanitized settings view is needed without sensitive or verbose fields, but it does not explicitly state when to prefer it over alternatives or when to use another tool. The exclusion list provides context but no direct routing guidance among the many sibling settings-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, and the description is consistent with those. It adds value by naming the fields returned, which is especially helpful because there is no output schema, though it does not describe output structure or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the key action ('List') and resource ('UPS devices') appear immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and strong read-only annotations, the description is nearly complete for a simple list operation. However, since there is no output schema, a brief note about whether it returns an array of per-device objects or an aggregate summary would further help the agent interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and the schema coverage is 100%, so the baseline is 4. The description does not need to document parameters and correctly focuses on what the response will contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and identifies the resource ('UPS devices') plus the exact metrics returned: state, battery health, runtime, voltage, load, and power. This clearly separates it from siblings like query_ups_device_by_id (single device) and query_ups_configuration (configuration, not runtime state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is for retrieving UPS runtime/state information, especially since it is a read-only list. However, the description does not explicitly state when to use this tool over query_ups_device_by_id or query_ups_configuration, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds a valuable behavioral detail beyond annotations: current form values are deliberately excluded, preventing an agent from expecting prefilled data. This is consistent with the read-only, non-destructive nature of the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the operation and then adds one clarifying limitation. Every word contributes useful meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query with rich annotations, the description is complete enough. It clearly states what the tool returns and explicitly notes the exclusion of current form values, so an agent can invoke it without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, with zero parameters and 100% schema description coverage. There is no parameter semantics for the description to add, and the 0-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the API-key form schemas.' It also adds a distinguishing detail by noting that current form values are deliberately excluded, which differentiates it from sibling tools that query actual API keys or permission metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives like query_api_keys or query_api_key_possible_roles. The intended use is implied from the name and the phrase 'form schemas,' but the description does not provide clear routing or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, true, and destructiveHint false, so the safety profile is covered. The description adds mild domain scoping ('accepted by API key operations') but provides no further behavioral detail such as return format or whether it is a subset of all roles.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler words. Every word contributes to understanding what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only reference tool, the description fully conveys what the tool returns and carries no invocation ambiguity. An agent can select and call it correctly from the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameters. The no-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('List') and a clear resource ('roles accepted by API key operations'). It distinguishes itself from sibling tools like query_api_key_possible_permissions by explicitly focusing on roles rather than permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need the roles that API key operations accept. It does not explicitly name alternatives or exclusions, but the context is sufficient for a zero-parameter reference query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so no side-effect warning is needed. The description adds value by indicating what kind of data is returned (configured network access URLs), and it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler; every word contributes meaning. 'Get configured' immediately communicates the action, and the enumeration of URL types is compact and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, non-destructive read operation with no output schema, the description provides sufficient information to call the tool correctly. The annotations cover safety, and the description states what the agent will receive in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the result content rather than parameter behavior, as nothing else is needed to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('configured ... access URLs'), and enumerates concrete categories: LAN, WAN, WireGuard, mDNS. This clearly distinguishes it from sibling tools like query_network_interfaces, which target interfaces rather than access URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent should call this when it needs the system's configured access URLs. However, there is no explicit contrast with related siblings such as query_network_interfaces, query_cloud, or query_remote_access, so the agent must infer which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context by explicitly stating that client secrets are excluded, which is a valuable safety guarantee beyond what the annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that front-loads the core purpose and includes an important safety qualifier. There is no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read-only tool with strong annotations, the description sufficiently states what will be returned: OIDC configuration and redirect origins. It also addresses the key security concern by noting the absence of client secrets, making the tool fully understandable without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to clarify about parameter meanings. The description instead clarifies the scope of the returned data, which is appropriate for a parameterless endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource: safe OIDC configuration and redirect origins. It also includes a distinguishing qualifier, 'without client secrets,' which separates this from other OIDC-related siblings that might return more sensitive or provider-level details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving non-sensitive OIDC configuration data, but it does not explicitly state when to choose this over related siblings like query_oidc_providers or query_oidc_provider. No exclusions or alternative routing guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral nuance by clarifying that command output is excluded, which tells the agent this returns summaries rather than full command logs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise sentence with no filler. The action and key distinguishing detail ('without command output') are front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query with comprehensive annotations, the description is sufficiently complete. It names the resource, scopes the result to tracked entries, and tells the agent that command output is omitted. No output schema exists, but 'List' makes the return shape clear enough for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there are no parameter semantics to document. The baseline of 4 is appropriate because the description cannot add parameter meaning beyond what the schema already fully covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('tracked plugin installations'), and a distinctive qualifier ('without command output') that separates it from related tools such as the singular plugin_install_operation query. An agent can immediately understand what this tool returns and how it differs from sibling operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only, list-style usage and the 'without command output' phrasing hints at a lighter-weight alternative to fetching full operation details. However, it does not explicitly state when to use this instead of query_plugin_install_operation, query_plugins, or the plugin install update subscription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotations by promising the API key is excluded from the returned record, which is a privacy-relevant detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part contributes: the action, the resource, and a security-relevant exlusion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query with no output schema, the description fully explains what the agent gets: the current connected-server record, minus its API key. No missing information is needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema coverage is 100%, so there is no parameter documentation burden. The description correctly focuses on the result rather than inputs, which is appropriate for a parameterless query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), identifies the resource ('current connected-server record'), and adds a distinguishing scope ('current') that separates it from the plural sibling unraid_v4371_query_servers. The additional note about not returning the API key further sharpens the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: call this when the current connected-server record is needed. It does not explicitly name alternatives like unraid_v4371_query_servers or state when not to use this tool, so the guidance relies on inference rather than direct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, idempotent behavior. The description adds useful behavioral context beyond annotations by specifying that the tool waits, returns exactly one bounded payload, and disconnects after the event. It could say more about timeout behavior or payload contents, but it meaningfully supplements the annotation-only safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key behavior: waiting, receiving one bounded payload, and disconnecting. Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter subscription tool with safety annotations and no output schema, the description covers the essential operational contract: one bounded event, then disconnect. The main omitted detail is the internal structure or meaning of the payload, but the tool name and sibling context indicate parity history data, so the gap is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing for the description to explain beyond noting that no input is required. Baseline 4 is appropriate since schema coverage is complete and no semantic gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: wait for the next event from a fixed GraphQL subscription, return one bounded payload, then disconnect. This clearly distinguishes it from one-shot query siblings like unraid_v4371_query_parity_history and from other next-event subscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is a one-shot subscription consumer: wait for the next event, receive one payload, then disconnect. It does not explicitly name alternatives or exclusion conditions, but the fixed-subscription framing gives sufficient context for when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable one-shot subscription semantics: it waits, returns one bounded payload, and disconnects. It does not contradict annotations, though it omits timeout or no-event behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence with no filler. The core behavior is front-loaded ('Wait for the next event') and every remaining clause adds meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-input, one-shot subscription tool, the description is nearly complete. It covers the operation's lifecycle but does not describe the payload shape or what happens if no event arrives; with no output schema, a bit more detail about the return value would be ideal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%, so the empty input schema is fully self-explanatory. The description's mention of a 'fixed GraphQL subscription' reinforces that this tool has no configurable inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Wait'), a precise resource ('this fixed GraphQL subscription'), and a well-defined terminal behavior ('return one bounded payload, then disconnect'). This clearly identifies it as a one-shot telemetry event tool and distinguishes it from indefinite subscriptions or query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear this is for retrieving a single next CPU telemetry event and then closing the subscription. It does not explicitly name alternatives or state when not to use it, but the intended usage is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior, but the description adds critical subscription semantics: it blocks until the next event, returns exactly one bounded payload, and then disconnects. This is highly valuable behavioral context that annotations do not convey and prevents an agent from treating this as a simple query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the core action, then states the result and lifecycle. Every clause earns its place; there is no fluff or repetition of schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter subscription tool with safety annotations already present, the description is nearly complete. It does not describe the payload structure beyond 'bounded payload', which would be a gap in the absence of an output schema, but the name and 'upsUpdates event' provide enough contextual signal for an agent to know what kind of data is coming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to explain about inputs. The phrase 'fixed GraphQL subscription' usefully reinforces that no parameters are needed because the subscription is predetermined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('wait for'), identifies a fixed GraphQL subscription, and states the exact behavior: return one bounded payload then disconnect. This clearly distinguishes it from the many query_* sibling tools, which fetch current state rather than waiting for an event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies one-shot subscription use: wait for the next event, get one payload, then stop. However, it does not explicitly mention when not to use it or point to alternative tools such as unraid_get_ups or unraid_v4371_query_ups_devices for current state reads, leaving the routing partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that by stating it deliberately excludes sensitive license-key location and contents, which is valuable for an agent deciding what information is safe to retrieve.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It communicates the primary action and an important exclusion efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only query tool, the description is largely complete: it specifies what is returned at a conceptual level and what is intentionally omitted. It does not enumerate all possible fields of 'registration state', but the low complexity and absence of parameters make the current level of detail reasonably sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter detail for the description to add beyond the schema. The description correctly focuses on the result and the scope of the operation, which fully suffices for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get registration state'. It also distinguishes itself by explicitly noting it does not return license-key file location or contents, which separates it from other query tools that might expose sensitive registration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the tool's purpose clear: use it when you need registration state. The negative clause 'without returning license-key file location or contents' also implies when not to use it or what not to expect, though it does not explicitly name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it is a one-shot subscription that disconnects after returning a single bounded payload, and it has no configurable inputs ('fixed'). This is important lifecycle information the agent could not infer from readOnlyHint, idempotentHint, or destructiveHint alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action ('Wait for the next event') and includes only essential behavioral details: bounded payload and disconnect. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and safety annotations already cover read-only/idempotent behavior, the description provides a complete picture of how to invoke and what to expect: wait for one event, receive a bounded payload, then the connection ends. The purpose and lifecycle are fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and the schema coverage is 100%, so the description does not need to document inputs. The phrase 'fixed GraphQL subscription' reinforces that no parameters are accepted, which is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: wait for the next event from a fixed GraphQL subscription, return one bounded payload, then disconnect. The title identifies the specific resource, 'ownerSubscription event', and the subscription semantics distinguish it from the many query_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an implied usage: call when you need the next event from this subscription rather than a current-state query. However, it does not explicitly state when to use this tool versus the many other next_* subscription tools or query_* alternatives, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond those hints: it is a subscription that waits asynchronously, delivers exactly one bounded payload, and disconnects afterward. This clarifies the one-shot consumption model and resource cleanup expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence. Every clause earns its place: waiting, event source, bounded payload, and disconnection. It is front-loaded with the primary behavior and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations, and a simple one-shot subscription behavior, the description is complete enough for correct invocation. The title and tool name convey the network metrics content, and the description clarifies the one-event-then-disconnect lifecycle even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them trivially, so the description does not need to explain parameter semantics. A baseline score of 4 is appropriate because no parameter documentation burden exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: wait for the next event from a fixed GraphQL subscription, return one bounded payload, then disconnect. This clearly distinguishes it from the many query tools and from sibling subscription tools by identifying the network metrics event type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a one-shot subscription usage model through 'Wait for the next event' and 'then disconnect', but it does not explicitly say when to prefer this over query_metrics or over sibling subscription tools like next_system_metrics_cpu. The usage context is understandable but no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds security-relevant context beyond the annotations by explicitly stating that key material is not returned, which shapes agent expectations about the response contents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single well-structured sentence with no filler. It front-loads the action and resource, then adds the crucial security qualifier without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list operation, the description is complete: it states what is returned (metadata and grants) and what is excluded (key material). Even without an output schema, an agent has enough information to call the tool and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters and schema description coverage is 100%, so there are no parameters for the description to document. The baseline of 4 applies because nothing is missing on the parameter side.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('API key metadata and grants'), and adds the important qualifier 'without returning key material.' This distinguishes it from the singular query_api_key tool and from any tool that would expose secrets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use it: when the agent needs to enumerate API key metadata and grants rather than a single key or key material. It does not explicitly name alternatives or state exclusions, but the plural scope and sibling naming make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond those annotations by disclosing that the result intentionally excludes serial numbers and geometry details, which is valuable for agents interpreting the response.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tight sentence front-loads the action ('List disks eligible for assignment') and adds a precise exclusion clause. Every word earns its place with no filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list operation with no output schema, the description is sufficient. It states the exact data scope and the notable omission, so an agent can invoke the tool correctly and set expectations without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no input schema burden for the description to carry. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a distinct resource 'disks eligible for assignment', then further disambiguates from sibling disk tools by explicitly stating what the response omits (serial numbers and geometry details). This makes the tool's purpose immediately clear and distinguishable from unraid_list_disks, unraid_v4371_query_disks, and unraid_v4371_query_disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'eligible for assignment' clearly scopes this tool to assignment workflows, giving an agent a concrete context for when to select it. However, it does not explicitly name alternative disk-listing tools or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Unraid MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Unraid MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/lemanjo/unraid-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lemanjo/unraid-mcp)

Score Badge

Copy to your README.md:

[![Unraid MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/lemanjo/unraid-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lemanjo/unraid-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lemanjo/unraid-mcp'

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