qui-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Many tools have similar purposes, such as qui_add_torrent vs qui_create_torrent, and multiple 'get ... status' variants. The templated descriptions only mention the endpoint, so distinguishing between similar tools requires careful URL parsing, though each tool does map to a unique endpoint.
Naming Consistency4/5
Tools follow a consistent qui_<verb>_<resource> pattern with snake_case. However, verb usage is inconsistent for similar actions (e.g., list vs get, create vs add, delete vs remove, patch vs update), which slightly reduces predictability.
Tool Count1/5
214 tools is far beyond the typical MCP server scope. This sheer number overwhelms agent tool selection and violates the principle of a well-scoped tool set, even for a large API.
Completeness5/5
The tool set provides comprehensive coverage of the qui API, including CRUD operations for instances, torrents, RSS, automations, backups, cross-seed, Torznab, and configuration. There are no obvious dead ends; every resource appears to have appropriate lifecycle operations.
Average 3.1/5 across 178 of 214 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on August 12, 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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of disclosing behavior. It only explains how to structure arguments (path vs query vs body) but says nothing about what the action does, whether it is destructive, what side effects occur, or how success/failure is indicated. The endpoint implies a rename but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is concise in word count, but it is under-specified and poorly structured. It fronts an API call instruction rather than a purpose statement, and it provides no hierarchical or semantic organization to aid comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is grossly incomplete for a tool that mutates a resource. It doesn't state what the rename actually does, what arguments are required, or any edge cases. An agent cannot reliably use this tool without external API knowledge, making it inadequate in context.
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 is generic with no specific properties, so the description must compensate. It does provide a useful distinction between path variables, query values, and request body, which helps an agent structure the arguments. However, it doesn't describe what these parameters are (e.g., instanceID, hash, newName) or their meaning, leaving 0% schema coverage largely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Call qui's PUT /instances/{instanceID}/torrents/{hash}/rename endpoint' which is essentially a restatement of the tool name, not a clear statement of what the tool does. It fails to explicitly say 'Renames a torrent' and does not distinguish itself from sibling tools like qui_rename_torrent_file or qui_rename_torrent_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 vs alternatives. Sibling tools exist for renaming torrent files and folders, but the description doesn't mention them or provide decision criteria. No use cases, prerequisites, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions POST (implying a possible mutation) but gives no details about side effects, permissions, rate limits, or response behavior. The output schema exists but is not referenced, leaving the agent blind to what this operation actually does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is compact and to the point, but it spends its words on HTTP mechanics rather than meaningful information. It is concise without being substantive, though it does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has a specific endpoint, path/query/body structure, and an output schema, yet the description provides no purpose, examples, parameter details, or usage guidance. It is severely under-specified relative to the tool's complexity.
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 schema offers no parameter definitions, so the description at least explains how to segment arguments into path, query, and body. However, it doesn't name any actual path variables, query keys, or required body fields, leaving the agent without concrete parameter semantics for this endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only references the endpoint path and HTTP method, which adds no functional understanding beyond the tool name. It fails to state what a cross-seed search is or what results it returns, and doesn't differentiate it from similar sibling tools like qui_search_torznab or qui_search_cross_seed_torrent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to choose this tool over alternatives. There is no context about prerequisites, typical scenarios, or how this search differs from other search-related tools. The description only explains argument placement, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, authentication requirements, rate limits, or whether existing values are overwritten. The word 'set' implies a mutating operation, but nothing is explained about what happens to the feed or its URL. Completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the endpoint, which is efficient. However, it is under-specified: it provides a generic call convention but lacks concrete details. It earns its place, but the level of conciseness comes at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description is incomplete for correct invocation. The agent does not know what arguments to supply, what constitutes a valid body, or what to expect in the response. Given the tool's name suggests a specific action, the total absence of parameter and effect information makes it inadequate.
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?
The input schema has a single generic 'arguments' property with 0% schema description coverage. The description only says to pass path variables, query values, and a body, but does not specify which path variables exist (e.g., instanceID), what query parameters are accepted, or what the JSON body should contain. This gives the agent no meaningful parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific endpoint (PUT /instances/{instanceID}/rss/feeds/url) and ties it to the tool name, so the action is somewhat clear. However, it does not explain the actual domain effect (e.g., updating the URL of an RSS feed) and relies on the name for meaning. It distinguishes from siblings via the endpoint but lacks a plain-language purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 qui_add_rss_feed or qui_set_rss_rule. No prerequisites, context, or exclusions are mentioned. The description simply instructs how to make the API call without any decision-support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only explains how to structure arguments as a generic wrapper. It does not disclose that this is a mutating operation, potential side effects, required permissions, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with clear structure, but it is under-specified, missing purpose and behavioral context. This is not conciseness; it is insufficient specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and a free-form schema, the description provides minimal context. It does not explain what backup settings are being updated, the request body shape, or the successful outcome, making it inadequate for reliable tool selection and 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?
The input schema is a free-form object with zero property documentation, and the description provides a generic pattern for placing path variables, query values, and a JSON body. However, it does not name the specific path variables (e.g., instanceID) or describe the expected body fields, so it only partially compensates for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the endpoint and HTTP method, which identifies the resource and action (updating backup settings), but it does not explicitly state the purpose, relying on the tool name for intent. It provides some sibling differentiation via the specific endpoint path, but lacks a clear action verb beyond 'Call.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as qui_get_backup_settings or qui_trigger_backup. There is no mention of prerequisites, conditions, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior, but it does not. It merely gives endpoint invocation details (path variables, query params, body) and implies a POST request, but never states what the tool does, its side effects, or the nature of the operation. This is a generic boilerplate description for any qui API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording, making it concise and free of fluff. However, it is under-specified and lacks front-loaded purposeful content, but the dimension focuses on structure and economy of language, which is acceptable here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool performs a specific duplicate-check operation and has a large sibling set, the description is severely incomplete. It fails to convey the tool's purpose, making it impossible to know when to use it. Even though an output schema exists, the missing definition of what the tool does means the description is not contextually complete.
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 schema has only an 'arguments' object with no meaningful properties, and schema coverage is 0%. The description offers a generic pattern: 'Pass path variables directly in arguments, query values in arguments.params, and a JSON request body in arguments.body.' This hints at how to structure arguments but does not specify which path variables, query parameters, or body fields are required for this particular endpoint. It does not compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only repeats the endpoint path and tool name, saying to call the POST /instances/{instanceID}/torrents/check-duplicates endpoint. It never explicitly states that the tool checks for duplicate torrents or what its actual function is, making it a near-tautology. No verb-resource description or differentiation from siblings is provided.
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 or how it differs from sibling tools like qui_list_torrents or qui_cross_seed_apply. The description solely focuses on how to call the endpoint without any contextual or exceptive information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds no additional context such as response shape, pagination, or potential latency. It simply repeats the HTTP method, which is consistent with the annotation but offers no new insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it lacks essential information. It is concise but under-specified, leaving the agent to infer the tool's purpose and parameters from the name and endpoint alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema provided, poor purpose clarity, and no parameter documentation, the description is incomplete for a tool that interacts with a health endpoint. It does not mention what 'health' means, what data is returned, or how to interpret results.
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 schema has 0% parameter coverage, and the description only gives a generic convention (path vars, query in arguments.params, body in arguments.body) without specifying which path/query/body fields this endpoint expects. This does little to help an agent construct correct parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says to call a GET endpoint but does not explain what the tool actually does (e.g., retrieves health status for all indexers). It is essentially a restatement of the endpoint, not a clear function description. It fails to distinguish from sibling qui_get_torznab_indexer_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., singular health check, error/stats endpoints). Only describes how to pass arguments generically, not the use case or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds no behavioral details such as pagination, ordering, or that it returns a list of runs. It redundantly restates the HTTP method (GET), adding no new context beyond the annotation.
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 concise sentence with no fluff, front-loading the key instruction. It is sufficiently brief, though the flow could be improved by stating the purpose first.
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 an output schema present, return values are covered, but the description lacks purpose, usage context, and parameter specifics. Given the large set of similarly named sibling tools, this description is insufficient to disambiguate the tool's role or 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 coverage is 0%, so the description must compensate. It gives a generic mapping (path vars in arguments, query in arguments.params, body in arguments.body) but does not enumerate any concrete parameters for this endpoint, such as run ID or filters. The agent cannot determine what to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely instructs the agent to call a specific HTTP endpoint ('Call qui's GET /cross-seed/runs endpoint') without stating what the tool does, e.g., 'List cross-seed runs.' It does not differentiate from sibling tools like list_cross_seed_search_runs or list_cross_seed_season_pack_runs and relies on the name for meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. It does not mention when to choose this tool over other cross-seed list tools or any alternatives. The only guidance is a generic parameter-passing convention, which addresses how, not when, to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention side effects, permissions, required authentication, or what happens on success or failure. The POST method implies mutation, but this is not explicitly stated, and there is no information about consequences or state changes.
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 sentence, concise and front-loaded with the endpoint information. It contains no wasted words, and the structure is direct. However, it is too terse to compensate for the lack of parameter and context details, but conciseness itself is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely requires an instance ID and feed details, the description is significantly incomplete. It does not explain the expected inputs, output, or any behavioral context. Although an output schema exists, its content is not shown, and the description does not help an agent understand what this tool does beyond a raw API 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?
The schema offers only a generic 'arguments' object with no property definitions, so schema coverage is 0%. The description explains how to structure arguments (path variables, query params, body) but does not enumerate the actual path variables, query parameters, or body fields. This is a partial structural hint but lacks the semantic detail needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific endpoint (POST /instances/{instanceID}/rss/feeds) and HTTP method, which implies adding an RSS feed, but it does not state the action in plain language. It lacks a specific verb like 'adds' and does not distinguish itself from sibling tools like qui_add_rss_folder or qui_set_rss_feed_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description only tells how to call the endpoint, not when to use this tool versus alternatives, nor any prerequisites or context. It is simply an API call instruction with no decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds only the endpoint and generic parameter-passing rules, not behavioral context like what data is returned, whether it includes subdirectories, or any side effects. It doesn't describe the operation's behavior in a way that goes beyond what the name and annotation already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and contains actionable instruction, but it is not front-loaded with a human-readable purpose and mixes endpoint identification with parameter-passing mechanics. It's adequate but not exemplary in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a generic schema, an output schema, and a huge sibling set, the description should clarify what files are being listed and how this differs from related tools. It fails to mention that a directoryID is required as a path variable or to explain 'scan directory files,' leaving the tool's role ambiguous.
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 provides zero parameter definitions, and the description only says to pass path variables, query values, and a body without specifying which ones exist or their meaning. The guidance is a helpful convention but leaves the actual parameters undocumented, failing to compensate for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely rephrases the tool name as an endpoint call ('Call qui's GET /dir-scan/directories/{directoryID}/files endpoint') without stating the actual function of listing files in a scan directory. It doesn't explain what 'scan directory files' are or distinguish it from sibling tools like qui_list_scan_directories or qui_get_directory_content.
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, no mention of prerequisites or typical use cases. The parameter-passing instructions are syntax rules, not usage guidelines for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only mentions 'PUT', implying mutation, but does not describe side effects, idempotency, permission requirements, or potential failure modes. The description is purely mechanical ('Call endpoint') and offers no behavior beyond the HTTP verb.
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 very concise (two sentences), front-loads the endpoint, and avoids fluff. It loses a point because the brevity comes at the expense of useful functional context, making it less effective than a slightly expanded version would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the opaque schema, lack of annotations, and no explanation of operation semantics, the description is insufficient. It does not mention what priorityes are, how to structure the body, or any constraints, leaving a significant knowledge gap for correct invocation. The presence of an output schema does not compensate for these missing behavioral and parameter details.
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 is a free-form object with no property descriptions, so the description's instruction to pass path variables directly in arguments, query values in arguments.params, and a JSON body in arguments.body is valuable and adds meaning beyond the schema. However, it does not specify the actual path variables, query parameters, or body fields, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP method and endpoint path, which essentially mirrors the tool name. It fails to explicitly explain that the tool sets the priority of files in a torrent, relying on the name to convey purpose. Consequently, it does not distinguish itself from other torrent file operations beyond naming the endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 qui_get_torrent_files or qui_rename_torrent_file. It provides no context about prerequisites, typical scenarios, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides no behavioral context. It does not disclose side effects, required permissions, whether the operation replaces existing trackers, or what the response contains. The description merely repeats the endpoint path without any additional behavioral detail.
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 concise sentence that directly states the calling convention. It is front-loaded and contains no unnecessary words, but it sacrifices semantic richness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, an unhelpful schema, and no detailed output schema, the description leaves critical information missing. It provides no context on the purpose, required fields, or expected response, making it inadequate for an agent to use the tool correctly without external knowledge of the API.
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 is an opaque free-form object, and description coverage is 0%. The description adds a generic structure (path variables, query in arguments.params, body in arguments.body) but does not enumerate or explain the specific path variables (instanceID, hash), query parameters, or required body fields. This is helpful but insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it calls a PUT endpoint for torrent trackers, which implies an edit operation, but it doesn't explicitly explain what 'edit' means (e.g., updating the tracker list or a specific tracker). The endpoint path is mentioned, distinguishing it from sibling get/add/remove tools, but the semantic purpose is vague.
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 like qui_add_torrent_trackers or qui_remove_torrent_trackers. The description only gives call syntax, with no use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose that this is a mutating operation for editing category settings. It only mentions it's a PUT request, omitting effects, prerequisites, or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is efficient, but it is under-specified. It lacks any semantic content about categories, making it less useful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a skeletal schema and no annotations, so the description must carry the entire burden. It fails to communicate the domain purpose, the specific parameters, or the response, making it nearly impossible for an agent to correctly invoke 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 schema is generic with no parameter details. The description does provide a convention for passing path variables, query values, and body, but it does not enumerate the actual path/query/body fields needed (e.g., instanceID, category ID, category fields). This leaves the agent without concrete parameter knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint and HTTP method (PUT /instances/{instanceID}/categories), but fails to state the functional purpose of the call (e.g., 'update a category'). It relies on the tool name for meaning, which is insufficient for distinguishing from create/remove sibling 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 guidance is provided on when to use this tool versus qui_create_category or qui_remove_categories. The description simply instructs how to call an endpoint without indicating the intended scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation. The description adds the HTTP method (GET) and argument structure, but it doesn't disclose success/failure behavior, prerequisites, or any side effects. With the annotation, a 2 is appropriate for the minimal additional context.
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, dense sentence with no fluff, front-loading the endpoint call and then detailing argument structure. It could be improved by adding a purpose clause, but as a concise instruction it is well structured.
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?
Even though an output schema exists and readOnlyHint is set, the description lacks a clear statement of what the tool does, which is critical for an agent to choose it among many sibling tools. The argument structure is covered, but the overall purpose and usage context 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 schema is a single generic 'arguments' object with 0% property description coverage, so the description must compensate. It does so effectively by specifying that path variables go directly in arguments, query values go in arguments.params, and the body in arguments.body. This is essential and goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely instructs to call a specific endpoint, restating the tool name without defining what getDirectoryContent does or returns. It lacks a clear functional verb+resource description and does not distinguish the tool from siblings like qui_get_instance_mediainfo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. It only explains how to pass arguments, not the context or conditions in which this endpoint is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true is consistent with the GET method, but the description adds no further behavioral traits. It does not disclose pagination, result aggregation, side effects, or other contextual behavior that an agent would need to know.
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 conveys the endpoint and argument structure with no redundant words. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent role as a listing endpoint, the description is incomplete. It does not explain what 'cross-instance torrents' means, when to use it, or what the response contains — the output schema may cover return values, but the description fails to provide the core context needed for tool selection.
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 is a generic 'arguments' object with 0% description coverage. The description compensates by explaining that path variables go in arguments directly, query values in arguments.params, and body in arguments.body. This provides a useful structural template, though it omits endpoint-specific parameter names and meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Call qui's GET /torrents/cross-instance endpoint,' which restates the tool name with an HTTP method and path. It lacks a clear domain action verb like 'list' or 'retrieve' and does not specify what the tool does or returns, relying entirely on the name for meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. There are no use-case descriptions, prerequisites, or exclusions mentioned. The only usage instruction is about argument structure, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not mention that this is a read-only listing operation, pagination, or any side effects. The generic argument conventions are not behavioral disclosure. It fails to explain what the tool actually returns or how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, easy to parse and front-loaded with the endpoint. It is concise, though it sacrifices substantive content for brevity. It could be improved by adding purpose in the same length, but it does not waste words.
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?
Despite having an output schema (not shown) and readOnlyHint, the description is incomplete. It does not explain what the tool returns, when to use it, or how it differs from sibling tools. An agent would not be able to decide between this and qui_list_cross_seed_runs without additional context.
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 schema has zero coverage (one generic 'arguments' object). The description explains how to structure arguments (path variables, query params, body) but this is generic across all tools and does not specify what actual path, query, or body parameters this endpoint accepts. It adds some meaning but does not compensate for the complete lack of endpoint-specific parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint (GET /cross-seed/search/runs) but does not explicitly state the tool's purpose (e.g., 'List cross-seed search runs'). The resource is clear from the endpoint name, but the intended action is implied rather than stated. It is not a pure tautology but lacks a specific verb like 'list' or 'retrieve'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. It does not distinguish it from similar tools like qui_list_cross_seed_runs or explain any prerequisites or context. The only instructions are about argument structure, which apply universally and do not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure, but it reveals no behavioral traits. It does not indicate whether the operation is destructive, requires specific permissions, or has side effects. It merely provides the HTTP method and argument-passing pattern.
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 concise sentence, which is appropriately brief. However, it front-loads the HTTP endpoint rather than the tool's purpose, so while it is efficient, it is not optimally structured for an agent to quickly understand what the tool does.
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 a generic schema, no annotations, and a direct mutation operation, this description is insufficient. An agent cannot determine what parameters to provide or what the endpoint actually accomplishes. The presence of an output schema does not compensate for the missing input and behavioral details.
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 description adds some structure to the generic 'arguments' parameter by explaining that path variables go directly in arguments, query values in arguments.params, and the body in arguments.body. However, it fails to name the specific path variables (e.g., instanceID, hash) or body fields needed for a rename-file operation, leaving critical parameter details ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the underlying endpoint but does not clearly state that the tool renames a file within a torrent. It uses the verb 'Call' which is generic, and the resource is only implied by the endpoint path. It does not distinguish from sibling tools like qui_rename_torrent or qui_rename_torrent_folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only explains how to structure arguments, not the intended use case, prerequisites, or exclusions. Sibling tools with similar names are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does not state whether the operation is destructive, what side effects occur, or whether it requires specific permissions. The term 'reset' suggests mutation but the description does not elaborate or warn.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences and no filler. It front-loads the endpoint and then explains the argument structure. However, it could be better structured by separating the functional purpose from the invocation 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?
The tool has a minimal schema and no annotations, so the description must provide full context. It lacks a functional summary, parameter specifics, and any guidance on the response or side effects. The argument structure is explained, but the absence of endpoint-specific details makes it incomplete for 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 coverage is 0% and the only parameter is a free-form arguments object. The description adds structural guidance (path variables at top level, query in .params, body in .body) but does not list the specific path variables, query parameters, or body fields. The endpoint path indicates a directoryID is required, but the description doesn't explicitly mention it as a required argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the endpoint but does not explain the tool's functional purpose. The name and endpoint imply it resets scan directory files, but the description only provides the API call pattern, making the purpose vague about the actual effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools. The description focuses entirely on how to invoke the endpoint, not on the use case or prerequisites. An agent would not know whether to choose this over qui_list_scan_directory_files or qui_scan_directory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It does not mention permissions, side effects, response format, rate limits, or whether the operation is safe/read-only. The only behavior described is the mechanics of argument placement, which is not behavioural transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that immediately names the endpoint and method, followed by compact argument-routing instructions. There is no redundancy or filler; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (path, query, and body components) and the lack of annotation support, this description is inadequate. An output schema exists but is not enough to guide invocation. Missing details include authentication, required query parameters, search semantics, and expected response handling.
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 provides only a generic 'arguments' object with no property descriptions, so schema coverage is 0%. The description adds useful structural guidance (path variables directly in arguments, query values in arguments.params, request body in arguments.body), but it does not enumerate the actual parameters, their meanings, or required values. An agent still cannot construct a correct request without external API knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint and HTTP method, giving a specific resource to call. However, it does not state the domain-level purpose (e.g., searching torznab indexers for releases) and does not distinguish this from sibling tools like qui_search_torznab_cross_seed. It is more of an implementation detail than a semantic purpose statement.
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 qui_search_torznab_cross_seed or qui_get_torznab_search_cache. The description only explains where to place path, query, and body values, but not the circumstances that warrant using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does explain the argument structure (path vars, query, body), which is a form of invocation behavior, but it does not disclose side effects, security requirements, overwriting semantics, or response behavior. For a mutation tool, this is a significant gap.
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 endpoint and concisely explains the argument mapping. Every part is necessary and there is no wasted text. It is appropriately concise for a straightforward REST wrapper.
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?
Despite the tool having an output schema, the description lacks critical context about what fields are updatable, whether the update is partial or full, and what the expected request body structure is. The generic instruction to put a JSON body in arguments.body is incomplete without knowing the schema of that body. The description is too minimal for a tool with a complex real-world use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no properties, and schema coverage is 0%. The description compensates by specifying that path variables go directly in arguments, query values go in arguments.params, and the JSON body goes in arguments.body. This is essential guidance, but it lacks the actual parameter names, required fields, and formats, so it only partially helps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name by saying 'Call qui's PUT /torznab/search/cache/settings endpoint.' It doesn't explain what updating the Torznab search cache settings actually does or what effect it has. While it adds the HTTP method and path, it provides no meaningful purpose beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 alternatives. Sibling tools like qui_get_torznab_search_cache clearly relate to reading vs. updating, but the description offers no context, prerequisites, or exclusions. The agent is left without any decision framework.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description provides no information about side effects, safety, authentication, or error behavior. It only gives the HTTP method and argument passing convention, leaving the agent blind to behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, efficiently conveying the HTTP method and argument passing convention. It earns its place without waste.
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?
Despite the output schema covering return values, the description fails to explain the tool's purpose, required inputs, or behavior. With a generic schema and no annotations, this leaves the agent with insufficient context to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies that path variables go directly under 'arguments', query parameters under 'arguments.params', and the body under 'arguments.body'. This adds useful structure beyond the generic 'additionalProperties' schema, but it doesn't enumerate specific body fields or query parameters for the regex validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only instructs to call a specific endpoint URL; it doesn't state what validating a regex means or what the tool accomplishes. It relies entirely on the tool name, making it close to tautological.
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 mention of when to use this validation, prerequisites, or alternatives among the many sibling automation tools. The description gives no contextual guidance for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It notes the call is a POST, implying a side-effecting creation, but it doesn't describe what happens on success, required permissions, error behaviors, or idempotency. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the endpoint and immediately followed by parameter-passing instructions. It avoids unnecessary wording and is well-structured for readability, though the brevity causes 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?
Given an empty schema, no annotations, and only a general parameter convention, the description is far from complete. An agent cannot determine what fields to send in the body or query to successfully create an RSS folder. The description provides structure but not enough content to invoke the tool correctly without external knowledge.
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 schema provides zero property definitions (only a free-form 'arguments' object), and the description adds a general convention for placing path variables, query values, and body. However, it fails to name the actual parameters (e.g., instanceID, folder name) or required fields, leaving the agent without concrete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact endpoint ('POST /instances/{instanceID}/rss/folders') and the tool's name implies adding an RSS folder, but it never explicitly states this action in functional terms. It distinguishes from siblings via the unique endpoint path, but reads more like an API call instruction than a purpose statement.
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 alternatives like qui_add_rss_feed. The only instruction is how to pass parameters (path variables, query values, and body), which addresses invocation mechanics, not selection context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true is not contradicted; the description adds that it's a GET request, which is consistent. However, it does not disclose what the analysis entails, expected inputs, or any other behavioral context beyond the annotation. Minimal added value for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences with no filler. The first sentence states the endpoint, and the second adds practical guidance on argument passing. Both sentences earn their place, though the content is minimal.
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?
This is a simple GET call with an output schema, but the description omits essential context: what 'analyze' does, when it makes sense to call it, and specific parameter expectations. The output schema may cover return values, but the tool's purpose and usage remains unclear, making it incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no property descriptions, so the description's instruction to place path variables in arguments, query values in arguments.params, and body in arguments.body provides useful structural guidance. However, it does not list the specific path variables (e.g., instanceID, hash) or any query/body fields, leaving the agent to infer from the endpoint or other sources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the HTTP method and full endpoint path, which clarifies the exact operation being performed. However, it does not explain what 'analyze' means or what the tool accomplishes beyond calling the endpoint, making it only slightly more informative than the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus any of its many siblings. There is no mention of prerequisites, alternative tools, or scenarios where analyzing a cross-seed torrent would be appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It only describes parameter passing and gives no information about side effects, permissions, reversibility, or what happens during import. This is a significant gap for a potentially destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the endpoint, then provides clear guidance on argument placement. It contains no filler and every sentence contributes to understanding the call mechanics.
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?
The presence of an output schema mitigates the need to describe return values, but with no annotations and an overly generic schema, the description is not complete enough. It omits behavioral context, usage conditions, and specific parameter details, making it difficult to invoke correctly without external knowledge.
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 is generic with a single 'arguments' object (0% description coverage), so the description's instruction to place path variables, query values, and body in separate properties adds useful structure. However, it does not specify which parameters are required or what the JSON body should contain, leaving the agent to infer details from the endpoint path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint (POST /instances/{instanceID}/backups/import) which implies an import operation, but it does not explicitly state what importing entails or how it differs from siblings like qui_execute_backup_restore. The purpose is clear from the name and endpoint, but the description itself is more of a call instruction than a functional explanation.
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 such as qui_get_backup_manifest or qui_execute_backup_restore. It only explains how to structure arguments, not the conditions or contexts in which the tool should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it does not state whether this operation is a dry-run preview, a destructive delete, or what side effects occur. The contradictory signals from the name ('delete') and endpoint ('preview') are left unresolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the endpoint, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has a single free-form parameter and no annotations, so the description must provide meaningful context. It only covers the API call envelope and leaves out the endpoint's purpose, safety profile, and interaction with the 'delete' operation, making it incomplete for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds useful structure to the otherwise free-form 'arguments' parameter by specifying that path variables go directly in arguments, query values in arguments.params, and body in arguments.body. However, it does not enumerate the specific fields for this endpoint, so it only partially compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says to call a specific endpoint without explaining what the tool does functionally. It does not clarify what 'delete' means in the tool name or what an automation preview entails, making it hard to distinguish from siblings like qui_delete_automation or qui_apply_automations.
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 guidance or alternatives are mentioned. The description focuses on how to pass parameters, not when to choose this tool over others like qui_delete_automation or qui_dry_run_automations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only says 'Call PUT endpoint' without describing effects, reversibility, permissions, or any side effects of reordering instances. This adds no behavioral transparency beyond the HTTP method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no fluff. It front-loads the endpoint and provides structured argument guidance efficiently. Slightly more explanatory content would improve it without sacrificing conciseness.
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?
The description is incomplete given the generic schema and lack of annotations. It does not explain what updating the instance order means, what the request body should contain, or what query parameters are accepted. The output schema exists but request semantics are missing.
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 only has a generic 'arguments' object with no parameter descriptions. The description adds structural information about how to pass path variables, query parameters, and body, which is helpful. However, it does not list the actual path, query, or body fields expected for this endpoint, so it only partially compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact HTTP endpoint, but does not explicitly state what 'update_instance_order' does. The purpose is implied by the tool name and endpoint path, not clearly explained. It doesn't distinguish this tool from siblings beyond its name.
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 or how it differs from other instance-related tools like qui_update_instance or qui_list_instances. The only instructions are low-level argument passing details, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only describes how to call the endpoint. It does not mention that this is a mutating operation, what the effects are, auth requirements, or response characteristics, which is a critical gap.
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 that efficiently communicates the endpoint and general argument structure. It wastes no words, though it omits necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty schema and missing annotations, the description is incomplete. It fails to specify mandatory path variables, the request body shape, or expected outputs, making it insufficient for a tool with such low schema coverage.
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 schema provides zero property coverage, so the description must compensate. It adds a useful structural pattern (path variables in arguments, query in params, body in body), but it does not specify required fields like instanceID or the body's content for the new order, leaving the agent unable to construct a correct request.
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 endpoint for reordering automations, which clearly distinguishes it from sibling tools like qui_update_automation or qui_list_automations. However, it frames the action as 'call the endpoint' rather than stating the semantic effect (reordering automations), so it is clear but not fully explicit.
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 or alternatives. It only gives invocation instructions, omitting context such as checking current order via qui_list_automations or prerequisites like an existing automation set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior, but it only describes the mechanics of argument passing. It does not mention side effects, asynchronous execution, authorization requirements, or any state changes caused by the endpoint.
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 endpoint and method, then quickly covers the parameter conventions. It is concise with no unnecessary words or repetition.
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?
The description lacks essential context: the actual purpose of the tool, expected input fields, behavior, and when to use it. While an output schema exists, it is not described, and the arbitrary 'arguments' schema leaves the agent with little understanding of what to pass. This is too incomplete for a complex endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description meaningfully explains how to structure the 'arguments' object: path variables at the top level, query values in 'arguments.params', and the request body in 'arguments.body'. This compensates for the completely undescriptive schema, though it omits specifics about actual path/query/body fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific endpoint (POST /cross-seed/search/run) and HTTP method, making the operational target clear. However, it does not state the semantic purpose (e.g., starting a cross-seed search) nor differentiate it from other cross-seed search tools. The verb is 'call', which is generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 related tools such as qui_run_cross_seed_automation or qui_apply_cross_seed_search. There are no prerequisites, alternative mentions, or situational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, and the description only gives the instruction to call the endpoint. It does not disclose whether the operation is read-only, whether it has side effects, what errors may occur, or any authentication requirements. The description carries the full burden and fails to address these.
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, direct sentence that wastes no words. It is appropriately front-loaded with the endpoint reference and follows with parameter passing instructions in a clear, logical order.
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 annotations, a generic schema, and a sparse description, the tool is insufficiently specified. The presence of an output schema helps but does not offset the lack of purpose, usage context, or behavioral detail. An agent would have difficulty selecting this tool among many similar 'test' endpoints without more information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no specific properties (0% coverage). The description compensates by defining a general convention: path variables in arguments, query values in arguments.params, and JSON body in arguments.body. However, it does not enumerate the expected path variable (e.g., 'id') or list query/body fields, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the HTTP method and endpoint path ('POST /arr/instances/{id}/test'), which adds specificity beyond the tool name. However, it does not explain what the endpoint does (e.g., tests connectivity or configuration of an ARR instance), leaving the semantic purpose largely to inference from the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as qui_test_arr_connection or qui_test_torznab_indexer. There are no prerequisites, exclusions, or context hints about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only mentions how to pass arguments (path, query, body) and the HTTP method. It does not disclose that this is a mutating operation, what side effects occur, whether authentication is required, or what happens on success/failure. The POST method hints at mutation, but this is implicit rather than explicit.
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 concise sentence that front-loads the endpoint and packs in the parameter-passing convention. It avoids fluff and is easy to parse, though it may be under-specified. It's appropriately sized for a technical wrapper description.
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?
The tool is a mutating operation with no annotations, a minimal schema, and an output schema that isn't described. The description doesn't explain what trackers are expected in the body, required fields, response format, or error conditions. For an agent to invoke this correctly, it would need more context about the request body and behavior. The endpoint URL provides some clues but is insufficient on its own.
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 is a free-form object with 0% description coverage, so the description compensates by explaining how to structure arguments: path variables directly, query values in arguments.params, and a JSON body in arguments.body. This adds meaning to the generic 'arguments' parameter, but it doesn't specify the actual path variable names (though the endpoint reveals instanceID and hash) or the expected body fields, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says to call the POST /instances/{instanceID}/torrents/{hash}/trackers endpoint, which implies adding trackers to a torrent but doesn't explicitly state the functional outcome. It's more of an HTTP call instruction than a plain-language description of what the tool does. It distinguishes the resource and verb but doesn't clearly say 'adds trackers to a torrent.'
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 vs alternatives like qui_edit_torrent_tracker or qui_remove_torrent_trackers. The description is purely about making the API call and offers no context on prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, required permissions, or response behavior. It only says 'Call ... endpoint,' which is an instruction rather than a behavior disclosure. The POST method implies creation, but the description doesn't state that a category will be created, whether it overwrites, what happens on duplicate, or any security considerations.
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 one concise sentence with no wasted words. It front-loads the endpoint and method. However, it's so minimal that it sacrifices substance for brevity, providing only a generic pattern applicable to all endpoints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a creation endpoint with an open schema and no annotations, the description is far from complete. It doesn't explain the purpose, required body payload, path parameters, expected response, or potential errors. An agent would not know how to use this tool correctly without external knowledge of the API.
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 schema has no property descriptions (0% coverage), so the description must explain the parameters. It explains the general pattern (path variables in arguments, query in arguments.params, body in arguments.body), but doesn't specify which path variables (e.g., instanceID) or what fields the body requires. This is a generic template, not adequate for constructing a valid create_category request.
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 the specific endpoint (POST /instances/{instanceID}/categories) and method, which clearly targets category creation. However, it expresses the purpose in HTTP terms rather than domain language ('create a category'), leaving some inference required. The name helps disambiguate from siblings like qui_get_categories and qui_edit_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this creates a new category, no prerequisites, no mention of using qui_edit_category for updates, or any scenario for choosing this tool. It's just an HTTP call instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It reveals the parameter-passing convention (path, query, body) but does not state whether the operation is read-only, what consequences it has, or what response format to expect. The POST method implies mutation, but the description neither confirms nor denies it.
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 concise sentence with no filler words, clearly front-loaded with the endpoint. Its brevity is efficient but comes at the cost of omitting substantive purpose and usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's position within a large family of similar API wrappers, the description lacks a functional summary, selection criteria, or behavioral details. The output schema exists, but the definition still does not equip an agent to decide when to invoke this tool versus others. It provides only a minimal invocation hint.
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 generic 'arguments' object with no property details (0% coverage). The description adds useful structure by specifying that path variables go directly in arguments, query values in arguments.params, and the JSON body in arguments.body. However, it does not enumerate the required fields for this specific endpoint, so the agent must infer them from the endpoint name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact REST endpoint (POST /instances/{instanceID}/torrents/field) and HTTP method, which gives some specificity. However, the verb 'Call' is generic and does not explain what 'field' means or what the operation accomplishes, leaving functional ambiguity. It distinguishes from siblings only by endpoint path, not by purpose.
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 offers no guidance on when to use this tool versus alternative torrent-related tools like qui_get_torrent_properties or qui_list_torrents. It only explains how to pass arguments, not the use-case context or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description adds no additional behavioral context such as auth requirements, rate limits, pagination, or side effects. It only repeats that it is a GET request, adding no value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the endpoint call and immediately provides the argument-passing convention. Every word earns its place.
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?
Despite having an output schema and readOnlyHint, the description lacks a purpose statement and usage context. It does not explain what a torznab search cache is, what parameters are typically needed, or how this tool differs from similar search/history tools. The generic invocation pattern is insufficient for an agent to select and use 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 input schema is a generic 'arguments' object with no property descriptions (0% coverage). The description compensates by clearly explaining the internal structure: path variables at the top level, query values in 'arguments.params', and a JSON body in 'arguments.body'. This is essential for correctly constructing the arguments object, though it does not enumerate specific path/query/body fields for this endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely says 'Call qui's GET /torznab/search/cache/ endpoint,' which restates the tool name and HTTP method without explaining what the tool actually does. It lacks a specific verb like 'retrieve' or 'fetch' and provides no indication of what a 'torznab search cache' is or what the endpoint returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as qui_search_torznab or qui_get_torznab_search_history. The description only covers how to pass arguments, not the context or prerequisites for using the 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?
The GET method aligns with the readOnlyHint annotation, and the description adds how arguments are structured (path, query, body). However, it does not disclose other behavioral aspects such as pagination, sorting, or error conditions, but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentence description is concise and front-loaded with the endpoint. No wasted words, though it could be expanded for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks functional details about what activity is listed, how to specify the instanceID, or what filters are supported. The endpoint path and sibling tools help but the description itself is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only has a generic 'arguments' object with no properties, so the description's explanation of passing path variables directly, query values in arguments.params, and body in arguments.body provides essential structure. Yet it does not enumerate specific parameter names like instanceID, leaving parameter semantics incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says to call the endpoint, not what the tool does functionally (e.g., 'list automation activity'). It provides the HTTP path but lacks a clear verb/resource statement, making it vague about the operation's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus related tools like qui_list_automations or qui_get_automation_activity_run. The description only covers how to invoke the endpoint, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does reveal that this is an HTTP POST (implying a mutation) and explains how to structure arguments, but it does not disclose the actual side effects, whether the operation is idempotent, required permissions, or the nature of the request body. Significant behavioral ambiguity remains.
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 endpoint and then succinctly explains the argument convention. Every word earns its place, and there is no redundant content or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a relatively complex endpoint call with path, query, and body components, and no annotations, the description is incomplete. It omits the actual path variables beyond {instanceID}, any query parameters, the expected request body shape, and the business context. The presence of an output schema mitigates the need to describe return values, but the lack of request guidance makes the tool hard to invoke correctly without external API knowledge.
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 nearly bare (only a generic 'arguments' property with no documented fields), so the description must compensate. It does provide meaningful structure: path variables go directly in arguments, query values in arguments.params, and the request body in arguments.body. This is genuinely useful for an agent facing an untyped schema, even though it does not enumerate the specific variables or body fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP operation and endpoint ('Call qui's POST /instances/{instanceID}/rss/rules endpoint') but fails to explain the semantic purpose of the tool—does it create, update, or configure an RSS rule? It reads as an implementation instruction rather than a clear statement of what the tool does, and it does not differentiate from related sibling tools like qui_rename_rss_rule or qui_get_rss_rules.
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 about when to use this tool versus alternatives. The description focuses solely on argument-passing mechanics and never mentions scenarios, prerequisites, or exclusions. An agent receives no contextual help in deciding between qui_set_rss_rule and other RSS rule operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only reveals that this is a POST call (mutation), but doesn't mention side effects, required permissions, whether it overwrites existing caps, or what the response contains. The word 'sync' hints at an update, but the consequences are not disclosed.
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 sentence and stays on-topic, with the endpoint mentioned first. It is concise and doesn't waste words. Slightly dense, but all content is relevant. The structure is acceptable, though breaking into separate sentences might improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (free-form schema, no annotations, related sibling tools), the description is incomplete. It doesn't mention required path variable {indexerID} explicitly, nor what the sync entails, what happens on success/failure, or any prerequisites like an existing indexer. The output schema exists but the description doesn't hint at what the response contains.
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 is nearly empty (only a free-form 'arguments' object with no property definitions), so the description's explanation of argument structure (path variables directly, query in arguments.params, body in arguments.body) adds value. However, it doesn't identify the required path variable (indexerID) by name or specify any expected query/body fields, leaving the agent partially blind.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific endpoint (POST /torznab/indexers/{indexerID}/caps/sync) and names the resource (caps sync), so it's more than a tautology. However, it only says 'call' the endpoint without explicitly stating what the operation does (e.g., 'Synchronize indexer capabilities from the remote service'). The purpose is implied from the endpoint path but not clearly spelled out.
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 alternatives like qui_get_torznab_indexer or qui_update_torznab_indexer. The only additional info is how to pass arguments (path, query, body), which is invocation mechanics rather than usage conditions. No context like prerequisites or when a sync is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only specifies the HTTP method and argument-passing conventions, but does not indicate whether the operation is read-only, requires authentication, or has side effects. The POST method implies a request but 'validate' suggests it may be non-mutating, yet this is not stated.
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 efficiently communicates the endpoint and the argument structure. It is front-loaded with the action ('Call ...') and follows with the parameter conventions. No wasted words.
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?
Despite having an output schema that may document the response, the description omits behavioral context such as what the validation result indicates, error conditions, or any required setup. For a validation tool with no annotations and an opaque schema, the description is barely functional and leaves the agent to infer key details.
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 completely generic (a single 'arguments' object with no defined properties), so the description's explanation of how to pass path variables, query values, and a request body is essential and compensates for the 0% schema coverage. It gives clear structural semantics that the schema lacks, though it does not enumerate specific fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially restates the tool name: 'Call qui's POST /license/validate endpoint' adds the HTTP method and path but does not explain what validating a license means or what outcome the caller can expect. It does not distinguish from siblings like qui_validate_session or qui_get_licensed_status in terms of purpose.
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 about when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusion criteria, so the agent gets no help in choosing between this and related license/session validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'POST' and the endpoint, but does not mention side effects, required permissions, or response behavior. This is a significant gap for a mutation-like operation.
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 conveys the endpoint, the argument structure, and the exact placement of different input types. It is front-loaded with the most critical information and avoids any 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?
The description is too terse given the tool's nature. It omits the functional purpose, what 'apply' means, any expected outcomes, and error conditions. The presence of an output schema does not relieve the description of explaining the operation's intent, making it incomplete for an agent to decide and use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is essentially an empty envelope (additionalProperties only). The description compensates by explaining that path variables, query values, and body must be placed in arguments, arguments.params, and arguments.body, respectively. It even reveals the path variable names via the URL template, but does not enumerate query or body fields, leaving some ambiguity.
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 tool as a call to a specific POST endpoint, including the HTTP method and path template. It distinguishes this tool from siblings by its unique endpoint resource, though it does not explain the domain-level purpose of 'apply' beyond what the endpoint name implies.
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, nor any contextual prerequisites. It simply instructs how to call the endpoint without stating what scenario triggers this operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral disclosure. It mentions the HTTP method (POST) but does not explain side effects, required permissions, or whether the operation is asynchronous. The tool likely creates a torrent creation task, but this is not stated.
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 sentence that contains the essential endpoint information and argument-passing convention. It is concise and structurally straightforward, though it could be improved by adding a purpose statement and parameter details without becoming verbose.
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?
The description lacks business context and prerequisites. Given that the tool performs a create operation, it should explain what it creates (a torrent creation task?), what inputs are required, and what the output represents. The existence of an output schema helps but is not shown to the agent, so the description must carry more weight.
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 schema is nearly empty (only an 'arguments' object with additionalProperties true), and schema coverage is 0%. The description explains the general structure (path variables in arguments, query values in arguments.params, body in arguments.body), but it does not specify the actual path variables, query parameters, or body fields needed for this endpoint. This is a generic pattern, not tool-specific 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 identifies the exact HTTP endpoint and method for the tool. Although it doesn't explicitly state 'creates a torrent,' the tool name and endpoint path clearly imply this, distinguishing it from sibling tools. It lacks a plain-language statement of the tool's purpose, but the technical directive is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as qui_get_torrent_creation_status or qui_delete_torrent_creation_task. The description only gives low-level invocation instructions, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only describes the HTTP call mechanics (path, query, body) but omits side effects, required permissions, success/failure indications, or any consequences of creation. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently communicates the endpoint and parameter passing convention. It is front-loaded with the essential action and avoids unnecessary words. However, it is somewhat telegraphic and could benefit from a clearer structure, but it remains appropriately sized.
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?
Despite the existence of an output schema, the input side is severely underspecified. The description only covers the generic gateway pattern, not the specific domain requirements for creating a tracker customization. It lacks any mention of required fields, payload structure, or examples, making it incomplete for a POST operation with a highly generic schema.
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 is a generic 'arguments' object with 0% field description coverage. The description adds a useful convention: path variables go directly in arguments, query values in arguments.params, and body in arguments.body. However, it fails to specify which path variables, query parameters, or body fields are expected for this endpoint, leaving the agent without critical detail for correct invocation.
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 explicitly names the endpoint 'POST /tracker-customizations/' which clearly indicates a create action for tracker customizations, distinguishing it from siblings like update or delete. However, it doesn't explicitly state 'create' in business terms, relying on the HTTP verb to convey 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when a create operation is appropriate, nor does it contrast with list/update/delete operations. The agent must infer usage purely from the tool name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It only states it's a POST request (implying mutation) but says nothing about side effects, required permissions, idempotency, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. The endpoint call and argument structure are front-loaded, making it easy to parse.
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?
Despite having an output schema, the description is severely under-specified for a complex cross-seed endpoint among many similar siblings. It lacks purpose, usage context, and specific parameter details, making it incomplete for effective tool selection.
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 is a generic 'arguments' object, and the description adds a routing convention (path vars vs query vs body). However, it doesn't specify the actual parameters or fields for this endpoint, so it only partially compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint ('POST /cross-seed/apply') but does not explain what 'apply' actually does. It is more of an API call instruction than a functional description, and it doesn't differentiate from siblings like qui_apply_cross_seed_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The sibling list includes similar apply tools, and the description offers no context, prerequisites, or exclusions—only invocation mechanics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals destructiveness, but the description adds no additional behavioral context beyond that. It does not mention permanence, side effects, or required permissions. The only extra info is about argument structure, which is not behavioral. With the annotation present, the bar is lower, but the description still lacks meaningful behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is easy to read and front-loads the endpoint. It avoids fluff, but it is under-specified, which is a different issue from conciseness. The structure is acceptable, though it could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of schema parameter details, the description is incomplete. It does not specify the license key parameter, prerequisites, or consequences. While an output schema exists, the description fails to adequately support input construction, making the tool risky to invoke correctly without additional context.
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?
With 0% schema description coverage, the description must compensate, but it only generically says to put path variables in arguments, query values in arguments.params, and body in arguments.body. It fails to explicitly mention that the licenseKey path variable is required or how it should be represented (e.g., arguments.licenseKey). This leaves the agent guessing about the exact parameter structure.
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 operation as calling the DELETE /license/{licenseKey} endpoint, which implies deletion of a license. It is specific about the resource and method, distinguishing it from sibling license tools like validate or activate. However, it doesn't explicitly state 'deletes the specified license' in plain functional terms, slightly reducing clarity.
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, such as when to delete a license versus listing or activating one. It also omits any prerequisites or conditions (e.g., license must exist, cannot delete active license). No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the endpoint and parameter layout, with no mention of side effects, return behavior, authentication requirements, or whether this is a read-only discovery operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence with no unnecessary words. It front-loads the endpoint and provides the essential calling convention. It is concise, though it sacrifices needed detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (many sibling tools, no annotations, generic schema, output schema present), the description is too thin. It doesn't explain the purpose of discovery, what triggers it, or any constraints. The output schema exists, so return values needn't be described, but the description still lacks sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no parameter details (coverage 0%), so the description must compensate. It clarifies the wrapper structure: path variables, query params, and a JSON body. However, it doesn't specify which path variables, query keys, or body fields are relevant for this endpoint, leaving substantial ambiguity.
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 endpoint (POST /torznab/indexers/discover) and uses the verb 'Call' to indicate it invokes that endpoint. 'Discover' distinguishes it from related tools like qui_list_torznab_indexers, though it doesn't explain what discovery entails.
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 only explains argument passing conventions, not the intended use case or situations where one might prefer a sibling like qui_list_torznab_indexers or qui_search_torznab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The read-only annotation already covers safety, but the description adds little behavioral context. It doesn't describe what the response contains, whether it lists all items, or any operational nuances. The mention of a JSON request body for a GET endpoint is also unexplained and could confuse an agent.
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 sentence that communicates the essential call structure efficiently. It is well-organized and easy to parse, though it lacks specificity in favor of a reusable template.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema and no visible output schema, the description is insufficient. It doesn't mention that instanceID is required, what the returned items are, or any limits/filters. An agent would lack the necessary context to correctly construct the request.
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?
With 0% schema coverage, the description must compensate but only provides a generic pattern (path vars in arguments, query in arguments.params, body in arguments.body). It doesn't specify the required instanceID or any query parameters, leaving the agent without concrete parameter 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 names the GET endpoint /instances/{instanceID}/rss/items, clearly indicating retrieval of RSS items and distinguishing it from sibling tools like qui_get_rss_rules and qui_add_rss_feed. However, it doesn't explicitly state what is returned or why one would use it beyond the endpoint name, so it's clear but not fully explicit.
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 only explains the mechanics of passing arguments (path/query/body), not the intended use case or how it compares to other RSS-related 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?
The annotation readOnlyHint=true already conveys that this is a read-only operation, and the description's 'GET' method is consistent with this. The description adds the parameter-passing convention (path/query/body) but does not disclose additional behavior such as authentication requirements, response structure, or potential side effects. Since annotations cover the core safety profile, a score of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action ('Call'), and contains no filler. It is concise, but its brevity limits the amount of useful information conveyed. It earns a high score for structure but not a 5 due to the lack of explicit purpose and parameter 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?
Given the generic schema and the presence of an output schema, the description is incomplete. It fails to specify what path variables or query parameters are relevant for this endpoint (e.g., pagination, filters), and the mention of 'path variables' may be misleading for a fixed path like /license/licenses. The description does not provide enough context for an agent to correctly construct the request beyond the generic argument structure.
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 is generic with no specific parameters defined (0% coverage), so the description must compensate. It explains that path variables go in 'arguments', query values in 'arguments.params', and body in 'arguments.body', but it does not list which path variables, query parameters, or body fields this specific endpoint accepts. The guidance is generic and does not provide tool-specific parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Call qui's GET /license/licenses endpoint' which identifies the resource and HTTP method but does not explicitly state that the tool lists licenses. The purpose is implied from the tool name and endpoint, but the description itself lacks a clear action verb like 'list' or 'retrieve'. It distinguishes from siblings by naming the endpoint, but not as strongly as a purpose statement would.
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 alternative license-related tools (e.g., qui_get_licensed_status, qui_activate_license). The description only explains how to call the endpoint, not the conditions under which this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks the tool as destructive, and the description merely restates the HTTP DELETE method without adding new behavioral context. It does not disclose what resources are removed, whether the action is reversible, or any side effects. The description adds no value beyond the annotation and the tool name.
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 sentence with no unnecessary words, and it front-loads the core instruction. It is efficiently structured, though the brevity comes at the cost of specificity. It earns its place by providing the key information about argument passing.
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?
The tool appears to be a generic API wrapper with dynamic arguments, yet the description omits critical details like the required instanceID and the format for identifying which categories to remove. While an output schema exists, the input side is deeply under-specified, making the description incomplete for practical use. The guidance on argument structure is a start but not sufficient.
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 provides zero meaningful detail (only a generic 'arguments' object), so the description must compensate. It does explain the general structure of arguments (path variables, params, body), but it fails to specify which path variables are required (e.g., instanceID) or what the request body should contain. This is insufficient for correctly invoking the 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 specifies the DELETE /instances/{instanceID}/categories endpoint, which clearly indicates a remove operation for categories. The HTTP method and path make the purpose unambiguous, and it distinguishes from sibling tools like qui_get_categories and qui_edit_category. However, it does not explicitly use the word 'remove' or 'delete categories,' leaving a slight indirectness.
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 only explains how to structure arguments (path variables, query values, body) but gives no guidance on when to use this tool versus alternatives like qui_edit_category or qui_delete_category. There is no mention of prerequisites, such as needing an instance ID or category ID, nor any indication of when this operation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It mentions the HTTP method (PUT), implying a write operation, but does not disclose side effects, permissions, idempotency, or error behavior. The generic argument-passing instructions add some invocation context but not sufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is relatively concise and front-loaded with the endpoint reference. It contains three instructional clauses packed together, which makes it dense but not overly wordy. Some clarification could improve readability, but it earns a good score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and the generic schema, the description is incomplete. It references the full API path, so the agent can infer required path variables, but it does not explain what those variables represent, what values are valid, or what the request body must contain. The existence of an output schema mitigates return-value explanation, but invocation details remain under-specified.
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 is a generic 'arguments' object with no specific fields, and schema description coverage is 0%. The description mentions three argument categories (path, query, body) but does not specify the names or meanings of path variables (instanceID, ruleName) or the request body structure. This leaves significant ambiguity for the agent.
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 explicitly names the PUT endpoint for renaming an RSS rule, which clearly distinguishes it from sibling tools like set_rss_rule and remove_rss_rule. However, it focuses on the endpoint mechanics rather than directly stating the functional outcome, making it slightly less direct than ideal.
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 such as set_rss_rule or remove_rss_rule. It only describes the call mechanics, leaving the agent without contextual cues for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation provides destructiveHint=true, but the description adds no behavioral context beyond that. It does not disclose which specific operations are supported, whether they are irreversible, or what side effects might occur (e.g., mass deletion). The description thus adds minimal value beyond the annotation and leaves the tool's behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the endpoint path and argument structure. It contains no filler, though the first sentence is somewhat redundant with the tool name and could be tightened. Still, it earns its place by providing endpoint context.
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?
Despite having an output schema and annotation, the description lacks essential functional context. It does not explain what the bulk action endpoint does, which operations are included, or when to choose this generic tool over specialized ones. An agent could not determine appropriate usage without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a single free-form 'arguments' object with 0% schema coverage, but the description explicitly specifies the argument structure: path variables directly in arguments, query values in arguments.params, and a JSON body in arguments.body. This directly compensates for the schema gap and gives the agent the exact mapping needed to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely states to call the endpoint, which is a restatement of the tool name and resource. It does not explain what a 'bulk action' does functionally (e.g., delete, pause, reannounce multiple torrents), so it fails to distinguish the tool's purpose from specialized siblings like qui_ban_peers or qui_rename_torrent.
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 alternative tools. It only explains argument passing mechanics (path vs query vs body) and does not discuss scenarios, exclusions, or trade-offs relative to individual torrent operation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose safety and side-effect behaviors. It merely states 'call the endpoint' without mentioning that this starts a backup job, whether it's synchronous/asynchronous, permission requirements, or potential consequences. For a mutation trigger, this is a significant transparency gap.
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, focused sentence that immediately names the endpoint and the parameter-passing convention. It avoids fluff, but its brevity is also a drawback because it omits crucial context. Still, it is appropriately sized for what it does say.
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?
Despite the existence of an output schema, the description is incomplete for a trigger operation. It does not explain prerequisites (e.g., instance must exist), whether the backup runs in the background, how to interpret the response, or error possibilities. Combined with the minimal schema, the agent lacks the context needed for safe and effective 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?
The schema provides only a generic 'arguments' object with no property descriptions, and coverage is 0%. The description adds a structural convention (path vars in arguments, query in arguments.params, body in arguments.body), but it doesn't specify which path variables (beyond the inferable instanceID), query parameters, or body fields are needed. This is insufficient to construct a correct request without external API knowledge.
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 explicitly names the endpoint POST /instances/{instanceID}/backups/run, which clearly indicates it triggers a backup. It distinguishes from sibling tools like qui_list_backup_runs by targeting the 'run' action. However, it doesn't explicitly state the effect ('starts a backup'), so it falls 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 provided on when to use this tool versus alternatives like qui_list_backup_runs or qui_delete_backup_run. The description only covers parameter passing mechanics, not the circumstances in which triggering a backup is appropriate or how it fits with other backup-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It fails to mention any side effects, whether the scan runs synchronously or asynchronously, required permissions, or what the response contains. The description is purely a low-level HTTP call instruction and gives no 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It does bundle multiple instructions, but each phrase is needed to convey the argument mapping. It is appropriately compact, though slightly technical and dense.
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?
Despite having an output schema (not shown), the description doesn't explain what the tool actually accomplishes or what a successful trigger looks like. It omits key details such as the need for an instanceID, whether the scan is immediate/queued, and how results are retrieved. For a trigger action, this is insufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (a generic 'arguments' object with no defined properties). The description adds some structure by explaining that path variables go directly in arguments, query values under arguments.params, and the request body under arguments.body. This is useful but still does not specify which path variables (e.g., instanceID) or query/body fields are required or optional, leaving much ambiguity.
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 endpoint ('POST /instances/{instanceID}/orphan-scan/scan') and the tool name 'trigger_orphan_scan' implies its action. It clearly distinguishes from siblings like 'cancel_orphan_scan' or 'list_orphan_scan_runs'. However, it does not explicitly state 'triggers an orphan scan', relying instead on the endpoint path and name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only explains how to construct the arguments for the API call, with no mention of prerequisites (e.g., a valid instance ID) or scenarios where this action is appropriate. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only reveals the HTTP method, the endpoint, and how to pass arguments. It does not mention that the operation modifies instance status, the required permissions, idempotency, or any side effects, leaving the agent without critical 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?
The description is only two sentences, front-loads the endpoint, and gives the key usage rule without any filler. Every phrase earns its place, though it assumes familiarity with API concepts like path variables and JSON bodies.
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?
The tool has an open-ended arguments object with no schema hints, and the description does not enumerate required fields, valid status values, or the expected request body shape. While an output schema exists, the input side is under-specified enough that an agent cannot reliably construct a correct invocation without external knowledge of the qui API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is extremely permissive with no property descriptions, but the description provides useful structural semantics: path variables go directly in arguments, query values in arguments.params, and a JSON body in arguments.body. However, it does not name the expected path variable, query parameters, or body fields, so the agent still lacks concrete parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific endpoint and HTTP method, which distinguishes it from sibling tools at a technical level, but it never states the effect of the operation beyond the name 'update instance status.' It is not a full tautology, but the purpose is heavily dependent on the tool name and endpoint path.
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 instead of alternatives among the many sibling tools. The only usage information is the argument-passing convention, which explains how to structure the call but not why or when to choose this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions it calls a PATCH endpoint, implying a mutation, but does not explain the effects, required permissions, reversibility, or response characteristics. The agent is left to infer what 'update' means, and the description adds no transparency beyond the HTTP method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the endpoint, avoiding unnecessary verbiage. It is only two sentences and conveys the core method of invocation. It could be more informative without becoming verbose, but it earns its place as a brief reference.
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?
The tool is a mutation operation with multiple parameter categories (path, query, body), but the description omits essential details such as the required directoryID, accepted body fields, and any side effects. There is an output schema, but return value documentation is not needed; however, the input contract is severely under-specified for an agent to invoke the tool 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?
The input schema has 0% coverage with a single generic 'arguments' object. The description attempts to compensate by stating that path variables, query values, and body go into specific sub-properties, but it does not list the actual parameter names (e.g., directoryID) or the body fields. This leaves the agent without the information needed to construct a valid request.
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 operation as a PATCH to a specific endpoint, which implies updating an existing scan directory. The resource is specific (dir-scan/directories/{directoryID}), and the name aligns with the action. However, it does not summarize the tool's purpose in plain language, relying on the endpoint definition to convey meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_create_scan_directory or qui_update_dir_scan_settings. It only explains how to pass arguments, which is more about parameter semantics than usage context. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals the operation is destructive, but the description adds no additional behavioral context. It does not state whether the deletion is permanent, whether it affects other instances, or any side effects. The description focuses only on request construction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and not wordy, but it conveys minimal substantive information. It reads more like a generic API-invocation template than a tool-specific explanation, making it under-specified rather than elegantly concise.
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 a generic schema and only a destructive annotation, the description is insufficient for an agent to fully understand required inputs and behavioral outcomes. The output schema is present but does not compensate for the lack of explicit parameter documentation and tool-specific context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is a free-form 'arguments' object with no parameter definitions, so the description helps by explaining where to put path variables, query values, and body. However, it does not explicitly list or describe the required instanceID and infohash parameters, leaving the agent to infer them from the endpoint path.
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 the HTTP endpoint and verb (DELETE /cross-seed/blocklist/{instanceID}/{infohash}), which clearly indicates the tool deletes a cross-seed blocklist entry. The resource is specific, but the description phrases it as 'call endpoint' rather than directly stating the action, and it does not explicitly distinguish from sibling blocklist tools (add/list).
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 alternatives like qui_add_cross_seed_blocklist_entry or qui_list_cross_seed_blocklist. There is no mention of prerequisites, required permissions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the existing destructiveHint annotation. It does not state that the notification target is permanently removed, nor any side effects or requirements (e.g., auth). The description merely gives an invocation pattern, providing no additional disclosure beyond what annotations already 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 sentence that front-loads the endpoint and conveys the call structure efficiently. There is no unnecessary text or repetition of information already in the schema or annotations.
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 simple delete operation, the description omits critical context: it does not explicitly state that the tool deletes a notification target, nor does it specify how to provide the ID parameter. The generic argument-passing instructions are not enough to construct a valid call without assuming documentation conventions.
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 schema is generic (a single 'arguments' object with no specific properties), and the description only provides a general rule for placing path variables, query parameters, and body. It never explicitly states that the notification target ID must be passed as arguments.id, and the endpoint path's '{id}' is the only hint. This is insufficient compensation for the 0% schema coverage.
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 the exact endpoint (DELETE /notifications/targets/{id}), which clearly implies it deletes a notification target by ID. However, it uses 'Call' instead of explicitly stating 'Delete', and it doesn't distinguish from sibling delete tools beyond the endpoint path.
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, no mention of alternatives such as qui_update_notification_target or qui_create_notification_target, and no clarifications about prerequisites or irreversible consequences. The only instruction is about how to structure the API call, not about usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks the tool as destructive, and the description adds no additional behavioral context such as what exactly gets deleted, irreversibility, authentication requirements, or rate limits. The generic call instructions do not disclose any behavior beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and therefore concise, but it is generic and does not lead with the tool's semantic purpose. It reads like a template for API wrappers, lacking specificity that would make it useful at a glance.
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?
The tool has a destructive annotation and an output schema, but the description does not explain what tags are, why one would delete them, or what response to expect. Given the large number of sibling tools, this minimal description is insufficient for an agent to confidently select and invoke it in the right context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description provides essential structure by explaining that path variables go directly in arguments, query values in arguments.params, and a JSON body in arguments.body. However, it does not specify the actual path variables (e.g., instanceID) or body fields needed, so it only partially compensates for the lack of schema 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 identifies a specific verb and resource ('DELETE /instances/{instanceID}/tags'), which clearly indicates the action of deleting tags for a given instance. This distinguishes it from sibling tools that target other resources, though it does not elaborate on the domain meaning of 'tags' or the consequences.
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 other tag-related or deletion tools. The description gives calling conventions but no contextual triggers, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says it's a POST request, implying mutability, but doesn't state effects, permissions, or reversibility. The parameter-passing convention is procedural, not behavioral.
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 fluff; efficiently conveys the HTTP method and argument structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an open-ended arguments object, the description is critically incomplete. It doesn't specify required keys, the meaning of 'move', or the expected request body, making it inadequate for 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?
The schema offers no parameter details (0% coverage), so the description's convention for separating path, query, and body is valuable. However, it fails to enumerate the required path variables (e.g., instanceID) or body fields, leaving the agent guessing.
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 the specific endpoint and HTTP method, making it clear this tool moves RSS items. However, it lacks a plain-language statement of what 'move' accomplishes, so it is clear but not fully explanatory.
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 alternative RSS tools like qui_remove_rss_item or qui_add_rss_feed. The description only explains parameter passing, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only reveals the HTTP method (POST) and endpoint, implying a mutation, but doesn't state what the operation does, whether it's idempotent, what errors may occur, or what response shape to expect.
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, focused sentence that front-loads the endpoint and then explains argument structure. It is concise and without fluff, though this brevity sacrifices semantic richness.
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?
Despite the presence of an output schema (which explains returns), the description lacks endpoint-specific details. It doesn't specify what data to include in the JSON body or query parameters, which is critical for an add operation. The generic parameter-passing explanation alone is insufficient to invoke this tool 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?
Schema coverage is 0%, so the description needs to compensate. It explains that arguments can contain path variables directly, a params object for query values, and a body object for JSON, which adds useful structural guidance. However, it doesn't list the specific path variables, query parameters, or body fields required for this endpoint, leaving the actual payload unspecified.
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 the exact endpoint and HTTP method (POST /cross-seed/blocklist/), and the tool name plus sibling context (list/delete) clearly indicate an 'add' operation. However, the description itself doesn't explicitly state the semantic action of adding an entry; it only says to call the endpoint, which is a minor gap.
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 guidance is provided. The description doesn't mention alternatives (e.g., list or delete), prerequisites, or specific scenarios where this tool should be used, leaving the agent to infer applicability solely from the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the endpoint call and does not mention that this adds a torrent, potential side effects, authentication requirements, or response behavior. The POST method implies mutation, but no further transparency is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence names the endpoint and HTTP method; the second details argument structure. It is front-loaded and efficient.
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?
The tool has no annotations, a sparse schema, and an output schema. The description is adequate for basic invocation but lacks context on behavior, usage scenarios, and parameter semantics beyond generic structure. It would not fully inform an AI agent when to choose this tool over siblings.
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 generic 'arguments' object with no documented properties (0% coverage). The description compensates by explaining how to structure arguments (path directly, query in arguments.params, body in arguments.body), which is useful. However, it does not enumerate specific query parameters or body schema, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a POST call to /instances/{instanceID}/torrents/, specifying a verb and resource. However, it does not explicitly state the action 'add torrent' beyond the tool name, nor does it differentiate from sibling tools like qui_create_torrent or qui_add_torrent_trackers.
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 parameter-passing instructions but no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description doesn't disclose side effects, required permissions, or whether the operation is destructive. It merely describes the HTTP call mechanism.
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 sentence, clearly structured, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output schema exists and reduces need to explain returns, the description lacks any context about the season pack apply process, prerequisites, or relationship to sibling tools. The generic schema and terse description leave significant gaps for an agent.
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 no property definitions (0% coverage), so the description's explanation that path variables go directly in arguments, query values in args.params, and body in args.body adds crucial structural meaning. However, it doesn't enumerate specific parameters expected by the endpoint.
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 explicitly names the POST endpoint '/cross-seed/season-pack/apply' and uses the verb 'call', indicating the exact action. It differentiates from sibling tools like qui_check_cross_seed_season_pack by specifying the apply operation, though it doesn't elaborate on what applying entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It only provides parameter-passing instructions, not usage context, preconditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is expected to disclose behavior. It only states it calls a POST endpoint without explaining the effect (e.g., peers are banned, possibly irreversibly), any security requirements, or rate limits. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that efficiently convey the endpoint and argument structure without redundant details. Every sentence earns its place.
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?
Although an output schema exists, the description is incomplete: it does not provide the required path variable names, the body structure, or the operational context. An agent would not be able to confidently construct a valid request from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single free-form 'arguments' property with no specific fields. The description adds value by explaining that path variables go in arguments directly, query values in arguments.params, and body in arguments.body. However, it does not enumerate the specific path variables (e.g., instanceID) or body fields, leaving the agent to guess.
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 the exact endpoint and HTTP method, and the resource 'ban-peers' clearly matches the tool name. It distinguishes from sibling 'qui_add_peers' by naming the specific endpoint, but does not explicitly describe the action of banning peers beyond the route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_add_peers or qui_remove_torrent_trackers. It only explains how to structure arguments, not the appropriate use case or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation provides destructiveHint=true, so the agent knows it is destructive, but the description adds no context about what the destruction entails. It does not explain whether the scan run is aborted, if the operation is reversible, or if any associated data is deleted. The description only explains how to structure the request, not the behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant wording. It efficiently states the endpoint and the argument-passing convention, and every sentence earns its place.
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 destructive mutation, the description is incomplete. It lacks an explicit statement of what the tool does (cancel orphan scan run), when it should be used, and what the expected outcome or side effects are. Although the output schema exists, the operational context 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 schema provides only a generic arguments object with no property definitions (0% coverage), so the description must compensate. It does so by explaining that path variables go directly in arguments, query values in arguments.params, and the request body in arguments.body. This gives the agent a concrete convention for invoking the endpoint, though it does not enumerate the specific path variables or their types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the endpoint as DELETE /instances/{instanceID}/orphan-scan/runs/{runID}, which implies cancellation of an orphan scan run, but it never explicitly states that the tool cancels an orphan scan. The tool name provides the primary semantic, while the description focuses on HTTP mechanics. This is clearer than a tautology but lacks a direct statement of function.
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 on when to use this tool versus alternatives. It does not mention that this is for canceling a running orphan scan, nor does it distinguish from related tools like qui_trigger_orphan_scan or qui_confirm_orphan_deletion. The sibling list shows context, but the description itself provides no selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only explains argument formatting. It does not state whether the operation is read-only or mutating, any side effects, authentication requirements, or expected response behavior. The POST method implies a server-side action, but the effect is unknown.
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 immediately states the endpoint and then provides the three-part argument structure. Every word is informative, with no redundancy or 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?
The description is too minimal for an API wrapper with a bare-bones schema and no annotations. It lacks any explanation of what the tool does, when to use it, or what the expected inputs are beyond the generic argument container. The output schema exists but is not described, and the description does not help an agent understand the tool's role among many cross-seed siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a free-form 'arguments' object with no internal structure. The description adds crucial semantics by specifying that path variables go in arguments directly, query values in arguments.params, and a JSON body in arguments.body. This significantly compensates for the schema's 0% coverage, though it does not enumerate the specific path/query/body fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool calls a specific POST endpoint, identifying the resource, but uses the generic verb 'call' and does not explain what checking a season pack accomplishes. It is not a tautology because it provides the endpoint path, but the actual purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention related tools like qui_apply_cross_seed_season_pack or qui_list_cross_seed_season_pack_runs, nor any exclusions or prerequisites. The only guidance is about argument structure, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the HTTP method and argument structure; it does not disclose side effects, permissions, error behavior, or what the response represents, leaving an agent unaware of the operational implications.
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 concise sentence with no redundancy, front-loading the endpoint information. It is appropriately brief but could benefit from more explicit resource-specific details without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic schema (0% coverage), no annotations, and the complexity of a create operation, the description is insufficiently complete. It does not explain what the endpoint does beyond the HTTP method, what path/body parameters are required, or any behavioral context, making it difficult for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an empty generic object, so the description adds value by explaining how to structure arguments: path variables directly, query values in arguments.params, and body in arguments.body. However, it fails to list specific parameters for this endpoint (e.g., instanceID, automation config), leaving significant ambiguity.
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 the exact endpoint (POST /instances/{instanceID}/automations/) and the tool name indicates creation, distinguishing it from sibling automation tools (list/update/delete). However, the verb 'Call' is generic and does not explicitly state 'create a new automation.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_update_automation or qui_delete_automation. It only gives a technical calling pattern, without context on prerequisites or preference over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only mentions the HTTP method and argument structure. It does not disclose side effects, authentication requirements, permission needs, rate limits, or response behavior, leaving the agent completely in the dark about the tool's impacts.
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 efficiently conveys the HTTP method, endpoint, and argument passing convention. It contains no redundant information and is appropriately sized for the minimal schema.
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?
The description provides only the REST call pattern. It does not explain what a client API key is, what the request body should contain, or what the response will be. Despite having an output schema available, the description remains incomplete for an agent to construct a valid request without external knowledge.
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 schema defines only an 'arguments' object with no specific properties (0% coverage), so the description must compensate. It does explain the general structure (path variables at top level, query in arguments.params, body in arguments.body), but it fails to enumerate the actual path variables, query parameters, or required body fields for creating a client API key, leaving critical parameters unspecified.
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 explicitly identifies the tool as calling the POST /client-api-keys/ endpoint, which clearly indicates a create operation. This distinguishes it from sibling tools like qui_list_client_api_keys and qui_delete_client_api_key, which have different verbs and resources.
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 offers no guidance on when to use this tool versus alternatives, such as qui_create_api_key (for regular API keys). It does not state prerequisites, use cases, or exclusions, leaving the agent without context on when this specific tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explains how to structure arguments (path variables, params, body) but does not state what the tool actually does, what side effects occur (e.g., creating a resource), any permission requirements, or response handling. The POST endpoint implies mutation, but the description lacks direct behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that front-loads the endpoint and immediately explains argument passing. Every word serves a purpose; no wasted text.
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?
Even though an output schema exists, the description is too thin for a create operation. It never explicitly says that this tool creates an external program, omits required body fields, and provides no information about validation, errors, or expected responses. The argument-passing convention is useful but insufficient for a complex POST endpoint.
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 a single 'arguments' object with no property descriptions (0% coverage). The description adds meaningful structure by specifying that path variables, query values, and request body are passed within arguments, which goes beyond the schema. However, it does not enumerate specific required fields or provide examples, so it only partially compensates for the lack of schema detail.
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 the specific endpoint 'POST /external-programs/' which clearly identifies the resource and operation. It distinguishes from sibling tools like list, update, delete, and execute by the HTTP method and path, though it does not explicitly state 'create a new external program' as 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 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. It does not mention that this is for creating external programs or contrast with update/delete/list tools. The endpoint name implies creation, but the description offers no explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states to call the POST endpoint, which implies a mutating operation, but does not describe side effects, authentication needs, error behavior, or the fact that it creates a new resource. The description is an instruction rather than a behavioral transparency statement.
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 well-structured and front-loaded with the endpoint information. Every element earns its place, and it is clear and crisp without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, an output schema (not shown), and a generic parameter object, the description is insufficient. It lacks the high-level purpose, what an 'instance' is, and any contextual details that would help an agent understand the operation's significance. The existence of an output schema handles return values, but other completeness aspects are missing.
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 a single free-form 'arguments' object with 0% description coverage, so the description must compensate. It explains the general structure for passing path variables, query values, and request body, which is useful. However, it does not specify the actual expected fields or format for creating an instance, leaving significant ambiguity.
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 the verb (POST) and resource (/instances/), which is specific and identifies the action of creating an instance. It distinguishes from siblings by pointing to a unique endpoint, but it does not explicitly state the semantic purpose of 'creating an instance'—it relies on the tool name and the HTTP verb to convey that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only gives low-level API call instructions and does not mention any context, prerequisites, or exclusions that would help an agent decide between qui_create_instance and similar tools like qui_create_arr_instance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It only states the HTTP method and argument placement, without revealing the tool's side effects, required permissions, or behavior on success/failure. The POST method implies mutation, but there is no explicit statement about creating a resource or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and front-loaded with the endpoint. It is concise and not bloated, but could be slightly expanded to include purpose or parameter specifics without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the operation's complexity (creation endpoint), the description is too minimal. It lacks domain context about what a notification target is, required fields, or any prerequisites. The output schema covers return values, but there is no explanation of the resource being manipulated, making the tool difficult to use 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?
The schema is a generic container with no specific properties (0% coverage), so the description must compensate. It explains the three categories of parameters (path, query, body) but does not enumerate the actual fields or their meanings. A caller still lacks the specifics needed to craft a valid request.
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 operation as calling the POST /notifications/targets endpoint, which implies creating a notification target. It distinguishes from sibling tools like qui_update_notification_target and qui_delete_notification_target by referencing the specific endpoint, though it does not explicitly state 'create' as the action.
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 guidance on how to structure arguments (path variables, query params, body) but does not explain when to use this tool versus the related list/update/delete/test notification target tools. The usage context is implied by the POST method and naming, but no explicit comparisons or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true, the annotation already flags destructive behavior, but the description adds no context about what specifically gets deleted (e.g., all activity for the instance or a single record), irreversibility, or side effects. It does not contradict annotations, but it misses the opportunity to clarify the scope of deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the endpoint in the first sentence and argument-passing convention in the second. No wasted words.
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 destructive operation, the description lacks essential context about the deletion scope, required path variables, and consequences. While an output schema exists, it does not cover the operational behavior. The minimal detail is insufficient for an agent to use this tool confidently.
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 is a generic 'arguments' container with 0% description coverage, so the description's guidance on passing path variables directly, query values in arguments.params, and body in arguments.body adds some structure. However, it does not specify the expected instanceID path variable, query parameter names, or request body schema, leaving the agent to infer 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 clearly identifies the tool as calling the DELETE /instances/{instanceID}/automations/activity endpoint, which distinguishes it from sibling list/get operations. However, it does not restate the purpose in plain language (e.g., 'Deletes automation activity for an instance'), relying on the endpoint path and tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_list_automation_activity or qui_get_automation_activity_run. It only explains how to call the endpoint, not the context or prerequisites for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals destructiveness, but the description adds no further behavioral context such as permanence, side effects on related data, or permission requirements. It merely restates the HTTP method.
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 concise sentence without wasted words. However, its brevity comes at the cost of omitting key tool-specific details, making it less useful than it could be.
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 destructive delete operation, the description lacks explicit identification of the resource ID and any side effects or prerequisites. While an output schema exists, the description itself is insufficient for safe and 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 coverage is 0%, so the description must compensate by naming parameters. It gives a generic pattern for path variables, query values, and body, but fails to explicitly mention the required indexerID path variable for this specific 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 explicitly identifies the DELETE endpoint for torznab indexers, making the action unambiguous. The verb 'DELETE' and resource path clearly distinguish it from sibling tools like qui_get_torznab_indexer or qui_update_torznab_indexer.
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 (e.g., whether to delete or disable an indexer). It only explains a generic argument-passing convention, which is not usage context.
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 set readOnlyHint=true, and the description confirms a GET request, which is consistent. Beyond that, no additional behavioral traits are disclosed, such as error behavior if the instance does not exist or authentication requirements. The description adds the endpoint template but does not enrich the safety profile beyond what annotations provide.
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 sentence that directly states the endpoint and the argument-passing format. It avoids unnecessary words, but it is somewhat telegraphic and could be expanded with a brief purpose statement without harming conciseness.
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 simple GET endpoint, the description is minimal. It fails to name the required path variable, explain the count's meaning, or mention any query parameters. While an output schema exists, it does not compensate for the lack of invocation details here, leaving the agent to infer correct usage from the endpoint template and tool name.
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 is a free-form object with 0% parameter coverage, so the description must compensate. It provides a generic convention for passing path variables, query params, and body, but does not specify which path variables are required (e.g., instanceID) or whether any query parameters are supported. This is a significant gap given the schema's emptiness.
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 names the specific endpoint and HTTP method ('GET /instances/{instanceID}/torrent-creator/count'), which conveys the tool's function of retrieving a count. The tool name adds semantic meaning about active torrent creations, but the description does not explicitly state 'get the count of active torrent creation tasks'. It is distinguishable from siblings like qui_get_torrent_creation_status due to the '/count' suffix.
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 or any prerequisites (e.g., needing a valid instanceID). The only instruction is about how to structure arguments, not about the tool's selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a read-only operation, and the GET method aligns with that. The description adds no additional behavioral context such as what data is returned, side effects, authentication needs, or required instance existence. It only restates the endpoint call pattern, adding minimal value beyond the annotation.
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 endpoint and then briefly explains the argument convention. There is no redundant or filler content; every part 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?
The presence of an output schema reduces the need to describe return values. However, the description does not explicitly state that the instance ID path variable is required or how to set it (e.g., arguments.instanceID), nor what transfer-info represents. Given the tool's simplicity and output schema, this is adequate but has clear gaps in complete invocation guidance.
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 is generic (arguments object with additionalProperties true) and has 0% coverage. The description explains the overall argument structure (path, params, body) but does not name the specific parameter for the {instanceID} path variable or any query/body parameters. It partially compensates for the schema gap but leaves the agent to infer the required instanceID key from the endpoint string.
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 calls the specific GET endpoint /instances/{instanceID}/transfer-info, which is a unique action and distinguishable from sibling tools by the endpoint path. However, it does not explicitly differentiate the purpose (e.g., 'retrieve transfer info for an instance') from other instance-related tools, so it is clear but not fully differentiated.
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 only how to pass arguments (path variables directly in arguments, query values in arguments.params, body in arguments.body) but no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or alternative tools for retrieving other instance information, so selection guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It mentions the HTTP method, which is consistent with read-only, but provides no additional details about error scenarios, return shape, or side effects. With annotations present, the description still fails to add meaningful 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?
Two tightly written sentences: the first states the endpoint, the second explains the argument-passing convention. No filler or redundancy; information is front-loaded.
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?
Even with an output schema present, the description is too thin. It does not state what a scan directory is, what the response contains, or that the directory ID must reference an existing scan directory. The tool name carries most of the semantic load, which is insufficient for an agent to correctly infer behavior in varied contexts.
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's single arguments property is completely undocumented (0% coverage), so the description's explanation of how to structure path variables, query values, and request body is valuable. However, it does not specify the actual directoryID path variable, required vs. optional parameters, or any concrete query parameters, leaving much to inference.
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 HTTP verb (GET) and resource path (/dir-scan/directories/{directoryID}), making the target resource unambiguous. However, it lacks a natural-language statement of what the endpoint returns, instead relying on the tool name and path for semantic meaning, which slightly weakens its distinctiveness from sibling 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 guidance is provided about when to use this tool versus alternatives like qui_list_scan_directories or qui_get_scan_directory_status. The only instruction is a generic parameter-passing rule that applies to all tools in this family, not specific usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no behavioral context beyond that (e.g., pagination, rate limits, authorization requirements), but it also doesn't contradict the annotation. Thus it meets the baseline for annotation-backed descriptions.
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 redundancy. It is efficient, but the content is generic boilerplate that could apply to any endpoint, so it lacks substantive value. Still, for what it contains, it is well-structured.
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?
Despite having an output schema, the description does not provide domain-specific context: it fails to explain what search history is, what parameters are available, or how this tool relates to siblings. The generic argument-passing note doesn't make the tool usable for an agent without additional external knowledge of the API.
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 is a generic object with 0% property documentation. The description explains the convention (path variables in arguments, query values in arguments.params, body in arguments.body), which adds structural meaning, but it doesn't identify the actual valid parameters for this specific endpoint. Thus it only partially compensates for the schema's lack of detail.
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 explicitly names the endpoint GET /torznab/search/history, making clear that the tool fetches Torznab search history. However, it doesn't explain what 'search history' contains or distinguish it from sibling tools like qui_get_torznab_search_cache or qui_list_recent_torznab_searches, so it falls 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 only explains how to pass arguments (path, query, body) but offers no context about suitable scenarios, prerequisites, or exclusions. Sibling tools with similar names intensify the ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers that this is a read-only operation. The description adds that it's a GET request but discloses no additional behavioral details (e.g., returns a list, no side effects, auth needs). With the annotation covering safety, the description adds minimal value, so a low score 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded with the endpoint. It packs three pieces of guidance without fluff. A bit dense but efficient. Could be split for readability, but it earns a high score.
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 relatively simple and an output schema exists, so return value explanation is not necessary. However, the description does not clarify what the blocklist contains, when to use it, or any request-specific details. It is minimally complete but leaves the agent without enough context to invoke it effectively beyond the endpoint itself.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is very open (arguments with additionalProperties true, 0% schema description coverage). The description compensates somewhat by explaining the generic argument structure: path variables directly, query values in arguments.params, and body in arguments.body. However, it does not provide endpoint-specific parameter details (e.g., pagination, filters, expected keys), leaving the agent to guess what to pass.
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 the specific endpoint (GET /cross-seed/blocklist/) and the HTTP verb, making it clear this tool retrieves the cross-seed blocklist. It does not explicitly say 'list' but the endpoint and tool name imply it. It distinguishes from add/delete blocklist entry tools by focusing on the GET endpoint.
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 how to pass arguments (path variables, query values, body) but provides no guidance on when to use this tool versus alternatives. No mention of typical use cases, exclusions, or related tools. This is essentially call syntax, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks this as a safe read operation. The description adds the HTTP method and the argument structure (path variables, query parameters, body), which is useful but does not go beyond that. It does not disclose response behavior or potential edge cases, though the output schema exists. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is packed with three clauses in a run-on style. It earns its place by explaining the argument-passing convention, though it could be broken into clearer parts.
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?
The description is inadequate for an agent to know exactly what arguments to pass or when to choose this tool. It does not state whether any parameters are required, and the generic advice about path/body may mislead. The output schema helps with return values, but the input side remains underspecified.
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 has a generic 'arguments' object with no documented properties (0% coverage). The description gives a generic pattern for passing path, query, and body values but does not specify which parameters this endpoint supports. For a list endpoint with a path like /dir-scan/directories/, the mention of path variables is confusing and likely inapplicable.
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 the exact endpoint (GET /dir-scan/directories/) and the tool name 'list_scan_directories' clarifies the intent. It is specific to this resource but does not explicitly state that it lists all scan directories, which would better differentiate it from qui_get_scan_directory (singular).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as qui_get_scan_directory or qui_list_scan_directory_runs. The description only covers invocation mechanics, not selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only explains how to structure arguments (top-level path variables, arguments.params for query, arguments.body for JSON body). It does not describe side effects, such as whether files are moved on disk, whether the torrent must be paused, or what API errors may occur. The PUT method implies mutation, but that's not explicit.
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, each with a clear purpose: the first names the endpoint, the second explains the argument mapping. No wasted words, front-loaded with the action. Perfectly sized for the information it provides.
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?
Despite the presence of an output schema, the description omits critical context: what the new folder path should be, whether the operation is reversible, side effects on trackers/peers, and when to use this tool relative to similar rename operations. With no annotations and a bare schema, this description is insufficient for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no defined properties (0% coverage), so the description's structural convention is valuable: path variables go at top level, query values under arguments.params, and the request body under arguments.body. However, it doesn't enumerate the actual parameters (instanceID, hash, body fields like newPath), leaving the agent with only a template, not a full specification.
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 the precise REST endpoint (PUT /instances/{instanceID}/torrents/{hash}/rename-folder), which clearly implies the action of renaming a torrent folder. This distinguishes it from sibling tools like qui_rename_torrent and qui_rename_torrent_file by resource type. However, it frames purpose as an API call rather than a plain-language functional description.
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 like qui_rename_torrent or qui_rename_torrent_file. It doesn't mention conditions, prerequisites, or exclusions, leaving the agent to infer the appropriate selection context from the endpoint name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects; it does not. Not mentioning whether reprocessing is destructive, asynchronous, re-runnable, or what is affected, though 'POST' hints at mutation. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences; no redundant filler. The front-loaded endpoint statement and parameter convention are each useful. Could be expanded with purpose, but as written it's concise.
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 POST action with no annotations and no output schema details, the description omits purpose, side effects, and required path/body parameters. It only covers the general request shape, leaving the agent under-equipped for correct 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?
Despite an empty schema (only `arguments` anyOf object), the description explains the three-part argument convention: path variables at top level, query in arguments.params, and body in arguments.body. This is essential for a generic proxy tool and goes far beyond the schema's `additionalProperties: true`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint and HTTP method, which maps to the tool's name, but it never explains what 'reprocess' does semantically (e.g., re-running RSS rules for matching). It is not a pure tautology because it gives the URL structure, but it remains vague for an agent deciding among related RSS 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 guidance on when to invoke reprocess versus siblings like qui_preview_rss_rule_matches or qui_refresh_rss_item. It only provides invocation mechanics. The agent must infer context from the endpoint name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It offers no information about side effects, mutability, permissions, reversibility, or error behavior. The only hint is the HTTP method 'POST' and the endpoint name 'requeue-no-match,' which vaguely implies a mutation, but this is far too thin for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence identifies the endpoint, and the second concisely explains the argument-passing convention. Every word earns its place, and the structure is appropriately front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and zero schema coverage, this description is incomplete. It fails to explain the operation's purpose, when to use it, what the request body should contain, or what the output represents—even though an output schema is said to exist. The description is a bare HTTP wrapper that leaves the agent with many unanswered questions.
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 a generic 'arguments' object with no property definitions (0% schema description coverage), so the description's instruction to pass path variables directly in arguments, query values in arguments.params, and a request body in arguments.body adds essential structural meaning. This clearly explains how to route parameters, even though it does not enumerate the specific endpoint parameters like {directoryID} or the expected body shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact HTTP endpoint but does not explain what the operation does in domain terms. It simply says 'Call qui's POST /dir-scan/directories/{directoryID}/requeue-no-match endpoint,' which is a technical instruction rather than a clear purpose statement. The endpoint is unique enough to distinguish it from siblings, but the agent is left guessing what 'requeue-no-match' actually accomplishes.
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 about when to use this tool versus alternatives. The description only explains how to structure arguments, not the context or scenario in which this operation should be invoked. Given the many sibling tools for directory scanning (e.g., qui_scan_directory, qui_reset_scan_directory_files), this lack of usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the HTTP method (POST) implying a mutation, and shows how to structure arguments, but it doesn't explain side effects, permissions, what actions the search triggers, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, no filler, and front-loaded with the endpoint. It is appropriately concise for the minimal information it conveys, though the terseness contributes to some gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single generic parameter, no annotations, and an unprovided output schema, the description is insufficient. It doesn't explain the purpose of the cross-seed search, what inputs are needed beyond generic placement, or what the tool returns, leaving critical context missing.
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 only has a generic 'arguments' object with no properties. The description adds structure by explaining that path variables, query values, and body are passed within arguments, but it doesn't name the specific path variables (instanceID, hash) or required fields. It partially compensates for the 0% schema coverage.
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 as calling a specific POST endpoint for cross-seed torrent searching, distinguishing it by the exact endpoint path. However, it lacks a domain-level explanation of what cross-seed search does, so it doesn't fully differentiate from sibling 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 guidance on when to use this tool versus the many sibling cross-seed tools, nor any preconditions or alternative tool references. It only provides request construction details, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the endpoint and HTTP method, without mentioning potential side effects (e.g., sending a test notification), required permissions, or whether the test is synchronous. This is a significant gap for a mutation-like action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that are direct and front-loaded with the endpoint. Every sentence contributes practical information about argument formatting, with no filler or redundant repetition of the schema.
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?
Despite having an output schema, the description lacks essential context for a test action: what triggers, how to interpret the response, prerequisites, or side effects. It is essentially a thin wrapper statement that leaves the agent guessing about the tool's behavior and return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a single free-form object with 0% description coverage, so the description must compensate. It adds a useful convention: path variables directly in arguments, query values in arguments.params, and body in arguments.body. However, it fails to enumerate specific parameters like 'id' or body fields, leaving the structure partially specified.
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 operation as calling the POST /notifications/targets/{id}/test endpoint, which tests a notification target. It distinguishes from sibling notification tools (create, update, delete, list) by the 'test' action, though the verb 'Call' is generic rather than descriptive of the outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only provides argument-passing instructions (path variables, query params, body) but omits context such as 'use after creating/updating a target to verify configuration' or references to sibling notification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the HTTP method and argument-passing conventions, but it does not mention side effects (e.g., partial vs. full updates), required permissions, reversibility, or error behavior. For a mutating operation, this is a significant transparency gap.
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 core action and immediately explains how to pass different parameter types. No redundant filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a generic REST wrapper with no schema details and a complex update operation, the description is incomplete. It lacks context about what an 'instance' is, what parts are updatable, whether a request body is mandatory, and what the response contains. The presence of an output schema lessens the need to describe returns, but the input side remains underspecified.
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 0% coverage and only an empty 'arguments' object, so the description adds necessary value by explaining the path/query/body structure. However, it does not specify the actual path variables, query parameters, or body fields for the endpoint, leaving the agent without concrete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific HTTP operation (PUT /instances/{instanceID}/) and the resource being acted on. It distinguishes this from sibling tools by referencing the endpoint path, and the tool name 'update_instance' reinforces the action. However, it does not explicitly state what 'updating' an instance entails in business terms, which would strengthen purpose clarity further.
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 scenarios, prerequisites, or contrast with tools like qui_update_arr_instance or qui_update_instance_status. The description only explains how to structure the request, not when the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool makes a PUT request and describes argument structure, but it does not state that this modifies log settings, what the effect is, or any side effects or permissions. This is insufficient transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant phrases. It efficiently conveys the endpoint and argument structure, though it could be expanded with more context without becoming bloated. It earns its place but is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, a minimal schema, and the existence of an output schema, the description is incomplete. It does not explain what settings can be updated, the expected body schema, the response format, or any prerequisites. An agent would need external documentation to safely invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic with a single 'arguments' object and 0% coverage, so the description's explanation of how to structure path variables, query values, and body adds value beyond the schema. However, it does not enumerate any actual parameters or fields for the log-settings endpoint, leaving significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the endpoint (PUT /log-settings), which clearly identifies the action as updating log settings. It distinguishes from the sibling tool qui_get_log_settings (GET) by using PUT. However, it does not use a natural-language verb like 'update,' so it is clear but slightly indirect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as qui_get_log_settings or other settings-update tools. The only contextual clue is the PUT method, which implies an update, but there is no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It reveals the HTTP method PATCH, implying a mutating operation, but doesn't mention required permissions, side effects, reversibility, or what happens to existing preferences. This is a significant gap for a write operation.
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 immediately names the endpoint and then concisely explains the argument structure. There is no fluff or redundancy; every word earns its place, and it's front-loaded with the core action.
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?
Despite an output schema being present (not shown), the input side is practically undocumented. The description fails to explain what 'preferences' means, which fields can be updated, or what a valid request body looks like. For a tool among many update_* siblings, this level of detail is insufficient for an agent to invoke it correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with zero documented properties, so the description's breakdown into path variables, query params, and a body is valuable structural guidance. However, it doesn't specify which path variables exist (beyond instanceID in the endpoint), what query parameters are accepted, or what the JSON body should contain, leaving much to inference.
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 as PATCHing the /instances/{instanceID}/preferences endpoint, which unambiguously signals an update to an instance's preferences. It distinguishes from the sibling qui_get_preferences by implying a write operation, though it doesn't explicitly say 'update preferences' or mention the GET alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_get_preferences or other update tools. It only explains how to structure the arguments (path, query, body) but doesn't state any prerequisites, exclusions, or scenarios where a different 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds nothing beyond the destructiveHint annotation. It does not mention what exactly will be cancelled, whether the operation is per-run or global, or any side effects or confirmation requirements. For a destructive operation, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant phrases. It front-loads the key instruction (call the endpoint) and adds only the necessary parameter routing details. 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?
An output schema exists, so return values are presumably covered. However, the description is minimal: it does not explain what 'cancel' means in this domain, whether the tool targets a specific run or all runs, or when it is appropriate to invoke. It is marginally complete for a simple endpoint wrapper.
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 a generic arguments object with no defined properties, but the description explains how to use it: path variables in arguments, query values in arguments.params, and JSON body in arguments.body. This provides structural guidance that compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the exact endpoint (POST /cross-seed/run/cancel) but does not explicitly state the domain action (cancelling a cross-seed automation run). The verb 'Call' is generic, and the effect of the operation is only implied by the endpoint path and tool name.
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 like qui_cancel_cross_seed_search or qui_cancel_directory_scan. The description lacks any context about prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool makes a POST request, implying it may commit an action or trigger a side effect, but it does not describe what that side effect is, whether it is safe, idempotent, or requires special permissions. The description is purely mechanical and lacks any statement about consequences or response 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, compact sentence that conveys the endpoint, HTTP method, and parameter-passing conventions without any fluff. Every clause serves a functional purpose, making it highly efficient and easy to parse.
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?
The tool likely interacts with a webhook check, but the description gives no context about its role, expected inputs/outputs, or relationship to other cross-seed tools. Even though an output schema exists, the description alone does not enable an agent to determine whether this is the right tool for a task or what the outcome will be. The brevity leaves significant gaps in understanding the tool's purpose and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema being an opaque permissive 'arguments' object (0% coverage), the description explicitly explains how to map path variables, query parameters, and the request body to the arguments structure. This is essential practical guidance that significantly reduces ambiguity and enables correct invocation. It fully compensates for the absent schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete action: 'Call qui's POST /cross-seed/webhook/check endpoint.' This identifies the exact HTTP method and resource, but it does not state what the endpoint does (e.g., check webhook configuration, trigger a test). The tool name hints at a cross-seed webhook check, but the description offers no semantic explanation, making it only nominally distinct from many other cross-seed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter-passing instructions: 'Pass path variables directly in arguments, query values in arguments.params, and a JSON request body in arguments.body.' This clarifies how to structure arguments, but it gives no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The 'when' is simply 'when you need to call this endpoint,' which is tautological and unhelpful for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the destructiveHint annotation, which already signals danger. It adds no further behavioral context, such as irreversibility, scope of deletion, or confirmation requirements. Given the annotation covers the main risk, a neutral score 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?
The description is a single sentence that is front-loaded with the endpoint and follows a clear structure for argument passing. No unnecessary words or repetition of schema 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?
For a destructive operation that deletes all backup runs, the description lacks important context such as impact on the instance, whether recovery is possible, or when this should be used. The generic argument structure further reduces completeness, leaving the agent to guess required inputs. The output schema covers return values, but the input side is underspecified.
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 schema is a generic 'arguments' object with 0% coverage, so the description must compensate. It explains how to structure path variables, query parameters, and body, but does not enumerate required fields such as instanceID, available query parameters, or body schema. The endpoint mentions {instanceID} but the description does not explicitly list it as a required argument.
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 names the DELETE endpoint for backup runs, which indicates the operation. The tool name includes 'all' to distinguish it from the singular qui_delete_backup_run. However, it relies on inference from the endpoint rather than explicitly stating 'delete all backup runs'.
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 like qui_delete_backup_run. There are no context cues, prerequisites, or exclusions. The tool name implies 'all' vs 'one', but the description does not explicitly address this distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation, so the description's burden is lower, but it adds no behavioral context beyond the argument structure. It does not describe what the tool returns, what 'active trackers' means, or any side effects, leaving the agent to infer 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 sentence that is extremely concise and front-loaded with the endpoint. Every part is necessary, and there is no redundant or verbose language.
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 presence of an output schema likely covers return values, but the description lacks domain context (what are active trackers?) and any usage guidance. For a simple read-only endpoint, it is minimally adequate but leaves gaps in understanding when and why to use this 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 a generic blob with zero coverage, so the description's explanation of how to pass path variables, query values, and body is essential and adds significant meaning. It provides a clear pattern for structuring arguments, even though it does not enumerate specific parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact HTTP endpoint (GET /instances/{instanceID}/trackers) and how to structure arguments, which is specific but does not clearly state the semantic purpose of retrieving active trackers. It is more of a low-level call instruction than a purpose statement, but it does distinguish the resource by endpoint path.
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 qui_get_torrent_trackers or qui_list_tracker_customizations. The description only explains how to invoke the endpoint, not the contexts in which it is 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 indicate readOnlyHint=true, so the read-only nature is covered. The description adds the important behavioral detail that path variables go directly in arguments, query values in arguments.params, and a body in arguments.body—which is essential for invocation. It does not disclose error behavior, auth requirements, or response size, but given the annotation coverage, 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, compact sentence that front-loads the endpoint and immediately gives the argument-passing convention. There is no wasted text, and the structure is clear and scannable.
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?
The tool is fairly complex with path variables and possibly query/body parameters, but the description only provides a generic template. It doesn't specify which parameters are required, whether a request body is actually expected for this GET endpoint, or what query options exist. The output schema exists, so return values are omitted, but request construction is under-specified.
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 schema provides zero description coverage (only a generic 'arguments' object), so the description must compensate. It mentions the existence of path variables, query values, and a body, and the endpoint path names instanceID and runID. However, it does not enumerate possible query parameters or body fields, leaving the agent to guess what is actually required or optional.
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 names the exact endpoint (GET /instances/{instanceID}/backups/runs/{runID}/manifest), which indicates the tool retrieves a backup manifest for a specific run. This distinguishes it from siblings like qui_list_backup_runs or qui_import_backup_manifest. However, it doesn't explicitly state the outcome in plain language, relying on the endpoint name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only explains how to pass arguments (path, query, body) but not the conditions under which this tool is appropriate. No exclusions or alternative references 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?
The annotation readOnlyHint=true already signals a read-only operation, and the description's mention of GET is consistent. However, it adds little beyond the annotation—no details about error behavior, required instance existence, or rate limits. It provides some value by explaining how arguments map to the request, but not enough to exceed baseline.
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, well-formed sentence with no fluff. It front-loads the endpoint and gives a brief, structured explanation of argument passing. Highly concise and readable.
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?
The description is too generic to be complete for this tool. It fails to state the purpose in plain language (e.g., 'get all RSS rules for an instance'), which is critical given the many RSS-related siblings. It also omits required parameters. The output schema covers return values, but the input side is incomplete, and the lack of use-case context makes the tool hard to select 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?
The schema is empty (only a generic 'arguments' blob, 0% coverage), so the description should compensate. It vaguely says to pass path variables in arguments but never lists them (e.g., instanceID is clearly needed from the path but not named). It also doesn't mention any query parameters or body fields for this specific endpoint, leaving the agent guessing.
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 the specific endpoint (GET /instances/{instanceID}/rss/rules) and the resource (RSS rules), which distinguishes it from siblings like qui_get_rss_items or qui_set_rss_rule. It doesn't explicitly say 'retrieve' but the HTTP method and path imply fetching rules. A clearer verb would make it 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 on when to use this tool versus alternatives. It doesn't say 'use this to list all RSS rules for an instance' or contrast with related tools like qui_set_rss_rule or qui_get_rss_items. The generic argument-passing convention applies to all tools, not this one specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the non-destructive nature, so the description does not need to restate it. The description adds useful context about how to structure arguments (path variables, query params, body), which is a behavioral expectation. However, it does not disclose any other traits such as rate limits, pagination, or data format, so it only partially enriches transparency beyond 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?
The description is a single sentence, perfectly concise and front-loaded with the endpoint. No unnecessary words or repetition, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists, the tool is part of a large family of similar qui_* tools, and the description provides no semantic context about what tracker domains are or why this endpoint would be used. The generic argument-passing note is helpful, but the lack of domain-specific context means an agent cannot determine if this tool is the right choice or what to expect from it.
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 is a generic container with no specific properties, and the description provides only a generic convention for passing path variables, query values, and body. It fails to list any endpoint-specific parameters (e.g., which path variables or query parameters are expected), so the agent cannot form correct arguments based on this description alone.
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 explicitly identifies the HTTP method (GET) and the exact endpoint (/torznab/indexers/tracker-domains), making the resource clear. However, it does not explain in plain language what 'tracker domains' are or what the response represents, slightly limiting clarity beyond the technical instruction.
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. There is no mention of scenarios, exclusions, or related tools like qui_list_torznab_indexers or qui_get_torznab_indexer, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only reveals the mechanics of the HTTP call, omitting effects like what settings are modified, potential side effects, or authorization requirements. This leaves the agent without critical behavior information.
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, direct sentence that front-loads the endpoint and efficiently communicates the calling convention. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are covered elsewhere. However, the description lacks domain context about cross-seed settings, what a PATCH operation implies, and when to use this tool. It's a minimal viable description for a low-level API wrapper but lacks broader operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single free-form 'arguments' object with 0% description coverage. The description compensates by clearly instructing how to populate it: path variables directly, query values in arguments.params, and a JSON request body in arguments.body. This provides essential structure that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the HTTP verb (PATCH) and resource (/cross-seed/settings), which clearly identifies the target operation. However, it doesn't explain the domain purpose (updating settings) and essentially restates the tool name, without distinguishing itself from similar tools like qui_update_cross_seed_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only explains how to structure arguments (path, params, body), not when or why this tool should be selected over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only gives HTTP mechanics (POST endpoint, argument passing). It does not disclose any behavioral traits such as side effects, required permissions, network calls, or what happens when the test fails. This is completely insufficient for a tool that likely triggers external network requests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that state the endpoint and the argument-passing convention. Every word contributes value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a complex API call with path, query, and body components, the description lacks crucial details such as required path variables, query parameters, and request body structure. Even with an output schema present, the input side is under-specified, making it difficult for an agent to construct a valid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains how to map arguments (path variables, query params, body) which adds value over the empty generic schema. However, it does not enumerate the actual parameters needed, such as indexerID or expected query/body fields, leaving the agent to infer from the endpoint template. It partially compensates for the 0% schema coverage but is still incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls a specific POST /torznab/indexers/{indexerID}/test endpoint, giving a specific verb and resource. This distinguishes it from sibling test tools like qui_test_arr_instance by naming the exact endpoint path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply describes the endpoint without mentioning prerequisites, alternatives, or when this should be preferred over other test tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals that this is a POST call, implying a mutation, but does not state consequences, required permissions, or what the response contains. The side effects of applying automations are entirely undisclosed.
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 endpoint and method, followed by concise parameter conventions. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description omits the tool's business purpose, expected request body content, and any side effects. For a mutating 'apply' operation, the agent needs more context to invoke it correctly, making the description incomplete for real-world use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is just a generic `arguments` object with `additionalProperties: true`, so the description adds essential semantics by specifying that path variables go directly in arguments, query values in `arguments.params`, and a JSON body in `arguments.body`. This compensates for the 0% schema coverage, although it doesn't enumerate the specific fields for this endpoint.
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 the exact endpoint and HTTP method (POST /instances/{instanceID}/automations/apply), providing a clear verb+resource. However, it does not explain what 'apply automations' does functionally or distinguish it from similar automation tools like qui_dry_run_automations or qui_run_cross_seed_automation, so it stops short of full clarity.
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 parameter-passing mechanics but no guidance on when to use this tool versus alternatives. It does not mention any preconditions, use cases, or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true signals destructiveness, but the description adds no additional behavioral context. It fails to mention that a search run must be active, what gets cancelled, or whether the operation is idempotent. The description essentially restates the endpoint name.
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 concisely cover the endpoint and argument mapping. Every word earns its place, and the information is front-loaded and easy to parse.
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?
The description lacks essential context for a destructive cancel operation: what run ID to pass, when cancellation is appropriate, and what side effects occur. Despite having an output schema, this minimal description leaves the agent guessing about preconditions and the exact parameters 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 schema is an empty free-form object, so the description's breakdown of path variables, query parameters, and request body in arguments is valuable and compensates well. It gives the agent a clear structure for constructing arguments, though it doesn't specify the actual field names or which parameters are 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 the endpoint and the cancellation action, distinguishing it from sibling tools that start or list searches. However, it uses 'Call... endpoint' rather than a direct verb like 'Cancels', which is slightly less clear but still understandable.
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 alternatives such as qui_cancel_cross_seed_automation or qui_cancel_directory_scan. It only explains how to invoke the endpoint, not the business context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only explains how to pass arguments (path, query, body) but does not mention side effects (creating a resource), required permissions, idempotency, or response behavior. This is a significant gap for a create operation.
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 endpoint and immediately clarifies argument mapping. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks essential context for successful invocation: required path variables, query parameters, body schema, expected request format, and side effects. The presence of an output schema does not compensate for missing request semantics, and there are no annotations to fill the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no structure. The description adds critical meaning by specifying that path variables are top-level keys, query values go under arguments.params, and a JSON request body under arguments.body. This compensates for the schema's lack of detail, although it does not enumerate the actual path, query, or body fields.
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 the exact endpoint (POST /arr/instances), which combined with the tool name implies creating an arr instance. It distinguishes from sibling tools by specifying a unique endpoint, but it does not explicitly state the semantic action ('create an arr instance') and relies on REST conventions and the name.
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 alternatives like qui_update_arr_instance or qui_list_arr_instances. The intended context is only implied by the endpoint and name, with no explicit conditions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only mentions the HTTP verb and argument structure, but does not state that this creates a resource, whether authentication is needed, or what side effects occur. The POST verb hints at mutation but isn't explicit.
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 endpoint and follows with argument conventions. Every word earns its place and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return types, but the description does not explain what a scan directory is, what body fields are required, or any prerequisites. For a create operation, the agent would lack the domain details needed to construct a valid request. The mention of path variables is also generic and irrelevant for this fixed endpoint.
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 a single generic 'arguments' property with no field descriptions (0% coverage). The description adds valuable structure by explaining how to route path variables, query values, and request body within the arguments object, which is essential for using the 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 specifies the exact endpoint (POST /dir-scan/directories/) and the tool name indicates creation. While it doesn't explicitly say 'create a scan directory', the endpoint path and name make the purpose clear. It distinguishes from sibling tools by being the POST/create variant.
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 like qui_update_scan_directory or qui_list_scan_directories. The description only explains how to call the API, not the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and safety implications. It reveals the HTTP method and argument structure but fails to state that this creates a tag resource, potential side effects, or required permissions. The actual behavior remains opaque beyond the request mechanics.
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 immediately states the endpoint and then explains argument organization. It is concise, front-loaded, and contains no unnecessary words.
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?
The tool has an output schema for return values, but the description lacks any explanation of the tool's purpose, when to use it, or what a successful call accomplishes. For a tool with complex request construction (path, query, body), the absence of contextual guidance makes it incomplete 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 input schema is a generic 'arguments' object with no property descriptions, so the description's instruction to place path variables directly, query values in arguments.params, and body in arguments.body adds essential meaning. It clarifies how to populate the parameter, even though it doesn't enumerate all possible fields.
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 exact endpoint (POST /instances/{instanceID}/tags), which specifies the resource and action. This distinguishes it from sibling tools targeting other resources, though it doesn't explicitly state 'creates tags' in plain language, relying on the endpoint name.
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, nor any mention of prerequisites or exclusions. The description only explains how to structure the request, not the context or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and safety profile, but it only mentions request construction. It does not state that this operation creates a resource, what data is affected, or whether it is destructive. The agent is left unaware of the tool's actual 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, clear sentence that directly explains the calling convention. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation operation with no schema details and no annotations, the description is incomplete. It fails to mention required fields, the meaning of the operation, or any behavioral outcomes. The output schema is said to exist but is not provided, so the description needs to carry more 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 is a generic 'arguments' object with no specific properties (0% coverage), so the description's instruction to put path variables in arguments, query values in arguments.params, and body in arguments.body is the only guidance for parameter construction. This adds crucial structure, though it omits domain-specific fields like indexer name or URL.
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 the exact endpoint (POST /torznab/indexers/) which in RESTful terms indicates creating an indexer, and the tool name confirms 'create'. It is specific about the resource and action, though it lacks a natural-language statement like 'Creates a new Torznab indexer' that would make it immediately obvious.
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 (e.g., update, delete, test). It only explains how to structure the HTTP call, not the semantic use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals destructive behavior. The description does not add context beyond this, such as irreversibility, required instance state, or effects on associated data. It merely restates the HTTP DELETE method, adding no new behavioral information.
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 sentence without fluff, efficiently conveying the endpoint and parameter-passing scheme. It is front-loaded with the action. It could be slightly more descriptive, but it is concise and to the point.
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 relatively simple (generic arguments, destructive annotation, output schema exists). The description explains parameter structure but does not explicitly state the deletion effect or any preconditions. This is adequate for an API-savvy user who can infer from the endpoint, but it leaves gaps for 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?
With schema coverage at 0%, the description compensates by explaining how to structure the arguments: path variables directly, query values in arguments.params, and request body in arguments.body. This is valuable because the schema only has a generic 'arguments' object. It could be improved by explicitly mentioning the instanceID path variable.
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 the exact DELETE endpoint, making it clear this deletes an instance. It names the HTTP method and resource, which distinguishes it from other instance-related tools. However, it's phrased as an API call rather than the intended effect ('delete an instance'), so it's not maximally clear.
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, prerequisites, or alternatives. It does not mention that this should be used to permanently remove an instance or that it should not be used for other operations. The description is purely instructional about the HTTP call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true, so the agent knows the operation is destructive. However, the description adds no extra behavioral context such as irreversibility, permission requirements, or side effects on related tasks. It merely restates the HTTP method, which is already implied by the tool name and annotation.
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 sentence, concise and to the point. It front-loads the endpoint and then explains parameter placement. Minor clarity could be improved by separating the parameter instructions, but overall it is appropriately sized and structured.
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 deletion tool with a destructive hint and a minimal schema, the description covers the essential mechanics of the call. However, it lacks any mention of what happens after deletion (e.g., success/failure responses, idempotency) or edge cases. An output schema exists, which reduces the need to document return values, but additional behavioral notes 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 is essentially opaque with only a free-form 'arguments' object, so the description's instruction to pass path variables directly in arguments, query values in arguments.params, and body in arguments.body is crucial. It does not explicitly list instanceID and taskID, but the endpoint template implies them, providing meaningful guidance beyond 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 clearly identifies the tool as calling the DELETE /instances/{instanceID}/torrent-creator/{taskID} endpoint, which unambiguously indicates a delete operation on a torrent creation task. It distinguishes from siblings by the specific resource and HTTP method, though it could be more explicit in stating 'this tool deletes a torrent creation task.'
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 prerequisites, scenarios such as canceling a queued or running task, or any exclusions. The description only explains how to call the endpoint, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already covers the read-only nature, and the description's mention of GET aligns with that. However, it adds no behavioral context beyond what's in the annotation—no mention of polling behavior, error cases, or what 'async-status' means. No contradiction detected.
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 dense sentence that front-loads the endpoint and immediately explains the argument structure. Every part earns its place, though it could benefit from a brief clarification of required 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?
Given the generic schema and the tool's endpoint complexity, the description provides a useful pattern for constructing arguments but omits specifics like required path variables or query parameters. The existence of an output schema reduces the need to explain return values, but the input side remains under-specified for a tool with path and query components.
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 a generic object with no parameter details (0% coverage), so the description's instruction to pass path variables directly in arguments, query values in arguments.params, and body in arguments.body is essential. This compensates well for the schema gap, even though it doesn't enumerate the specific path variables (instanceID, hash).
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 exact endpoint (GET /cross-seed/torrents/{instanceID}/{hash}/async-status) and specifies it's for cross-seed async status. It distinguishes from siblings by naming the unique endpoint, though it lacks a high-level purpose statement beyond the API call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling status tools (e.g., qui_get_cross_seed_status, qui_get_cross_seed_search_status). It explains how to call the endpoint but not the context or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates that this is a safe read operation. The description adds no extra behavioral context, such as authentication requirements, response structure implications, or side effects. It merely restates the HTTP method and argument passing convention, which does not go beyond the annotation.
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, front-loaded with the endpoint information and followed by clear instruction on argument placement. Every word earns its place, and 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?
This is a simple read-only GET tool with readOnlyHint and an output schema available, so the description does not need to explain return values. However, it lacks any statement about what the settings represent or when to use this tool, which would help an agent fully understand its role. The invocation details are present, but the semantic context is sparse.
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 is generic (arguments with additionalProperties true) and schema description coverage is 0%. The description explains the argument structure: path variables go directly in arguments, query values in arguments.params, and body in arguments.body. This is helpful for invocation, but it does not specify which path variables, query parameters, or body fields this particular endpoint expects. It provides a general convention rather than concrete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a GET request to the /cross-seed/search/settings endpoint, which implies retrieving cross-seed search settings. It is more specific than a vague statement, but it does not explicitly differentiate from sibling tools like qui_get_cross_seed_settings, leaving some ambiguity about the exact scope of 'search settings.'
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. It does not mention that this is the appropriate choice for fetching cross-seed search settings, nor does it exclude other scenarios or name sibling tools. The description focuses solely on invocation mechanics rather than usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares the operation safe, and the description adds that it is a GET endpoint, which is consistent but redundant. No additional behavioral traits are disclosed, such as what the status contains or whether it reflects in-progress searches.
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, immediately states the endpoint, and then defines the argument structure. It is concise, front-loaded, and contains no unnecessary 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?
It is minimally sufficient for a read-only status endpoint with an output schema, but it is a generic template that does not explain the meaning of the status or any relevant input values. The description would be stronger if it indicated what the status response represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a generic schema at 0% coverage, the description adds a clear convention for where path variables, query values, and request bodies go. However, it does not specify any actual parameters for this endpoint, so the agent still lacks endpoint-specific parameter knowledge.
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 the exact endpoint 'GET /cross-seed/search/status', which clearly identifies the resource and distinguishes it from sibling status tools. However, it uses the generic verb 'Call' and does not describe what the status means, so it stops short of a fully specific purpose statement.
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 only gives the mechanics of passing arguments (path, params, body) and offers no guidance on when to use this tool versus other status-related siblings. It does not mention alternatives, prerequisites, or scenarios where this tool is 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?
The readOnlyHint annotation already declares this is a read-only operation, and the GET verb is consistent. The description adds the argument-passing convention (path variables in arguments, query in arguments.params, body in arguments.body), which is useful but not rich. No other behavioral traits like pagination, auth, or side effects are disclosed.
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 efficiently states the endpoint and the argument-passing convention. Every word contributes value, with no redundancy or unnecessary details.
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 output schema exists, so return values are covered. However, the description lacks usage context, relationship to sibling tools, and specific parameter details, making it minimally complete for a simple read-only endpoint but with notable gaps in usability guidance.
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?
With 0% schema description coverage, the description must compensate for the generic 'arguments' object. It provides a high-level placement pattern but does not name any actual path variables, query parameters, or body fields for this endpoint, leaving the agent without concrete parameter knowledge.
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 operation as calling the GET /log-exclusions endpoint, which matches the tool name and distinguishes it from the sibling qui_update_log_exclusions by HTTP method. However, it does not explain what log exclusions are or what the endpoint returns, so it's clear but not fully differentiating.
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 like qui_update_log_exclusions or other log-related tools. It only provides invocation instructions without context on use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates the read-only nature. The description adds the HTTP method (GET), which is consistent, but it provides no additional behavioral context such as required permissions, response characteristics, or error conditions. The instruction to pass a JSON request body for a GET endpoint is potentially misleading and unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant content. It front-loads the endpoint and succinctly provides the argument-passing convention. Every word is functional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and readOnlyHint annotation is present, the description is relatively complete but minimal. It omits a clear functional summary and usage context, though the endpoint and argument pattern are provided. The generic argument instructions apply to all tools, not tailored to this one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the argument structure: path variables directly in arguments, query values in arguments.params, and request body in arguments.body. This adds value over the minimal schema which only has an open 'arguments' object. However, it does not enumerate the specific path variables (instanceID, hash) or any query parameters, leaving the agent to infer them from the endpoint.
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 the endpoint with HTTP method and resource path, indicating it retrieves peers for a torrent. However, it doesn't explicitly state the functional purpose in plain language, relying on the endpoint name to convey meaning. It distinguishes from siblings by naming a specific endpoint, but the description is mostly a restatement of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_get_torrent_properties or qui_get_torrent_trackers. It only explains the calling convention, not the selection criteria. There is no mention of prerequisites or scenarios.
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 annotation readOnlyHint: true already indicates a safe read operation. The description adds the HTTP method (GET) and the argument-passing pattern (path variables directly, query in arguments.params, body in arguments.body), which is helpful. However, it doesn't disclose any specific behavioral traits beyond the call structure, such as pagination or response 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 sentence that gets straight to the point. It is concise, front-loaded with the endpoint, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description covers the HTTP call and argument layout, but it omits necessary details like whether instanceID is required, what query parameters are supported, or expected response shape. The output schema may cover return values, but the gap on request parameters reduces completeness.
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 is extremely generic (an 'arguments' object with no defined properties), so the description must compensate. It mentions the path variable {instanceID} and the structure for query and body parameters, but it doesn't specify any other parameters or their meanings. This minimal enrichment is insufficient given the schema coverage of 0%.
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 endpoint 'GET /instances/{instanceID}/backups/runs', which clearly indicates a read operation that lists backup runs for a given instance. While it doesn't explicitly state 'list', the tool name and resource path make the purpose unambiguous. It is distinguishable from siblings like qui_delete_backup_run by the HTTP method and resource path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply instructs to call the endpoint. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's mention of GET aligns with that. However, no additional behavioral context is provided, such as authentication requirements, rate limits, or response behavior. Beyond the read-only hint, the description adds nothing.
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, direct sentence that front-loads the endpoint and clearly communicates the argument-passing convention. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema present, the description provides the core invocation details. However, it lacks endpoint-specific parameter information and does not distinguish this tool from the very similar qui_list_api_keys, leaving some ambiguity in selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is extremely generic (only an 'arguments' object with no property descriptions), leaving 0% schema coverage. The description compensates by explaining how to pass path variables, query values, and body via arguments, which is useful structural guidance. However, it does not specify any concrete parameters or query options for this particular endpoint.
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 the exact HTTP method and endpoint (GET /client-api-keys/), which clearly indicates the tool lists client API keys. It is differentiated from sibling tools like qui_list_api_keys by the resource path, though not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as qui_list_api_keys or qui_create_client_api_key. It only explains how to structure arguments, not under what circumstances the tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already provided, the description adds no additional behavioral context. It restates the GET method but doesn't mention response characteristics, permissions, pagination, or other side effects, so it adds no 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?
The description is a single concise sentence that directly states how to call the endpoint and how to structure arguments. There is no wasted text 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?
Given that the output schema exists and readOnlyHint is present, the description is minimally adequate, but it lacks domain-specific context about Torznab indexers, list size, or filtering options. It doesn't mention what the response contains or how to interpret the resource, leaving the agent to rely on the output schema and tool name.
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 a free-form 'arguments' property with no descriptions, and the description helps by explaining how to pass path variables, query params, and body fields. However, it doesn't specify which query parameters or body this endpoint supports, leaving the agent to infer the actual 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 explicitly names the HTTP method and endpoint path (GET /torznab/indexers/), making the action and resource clear. However, it does not explicitly say 'list' or 'retrieve all indexers', and lacks differentiation from the singular sibling qui_get_torznab_indexer, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 only explains how to structure arguments, not the contextual use case or when to prefer this over related tools like qui_discover_torznab_indexers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only discloses the HTTP method (POST) and argument placement. It doesn't describe side effects, idempotency, permissions, or what happens when an article is marked as read, which is a significant gap for a mutating operation.
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, front-loaded with the endpoint, and every part is informative. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for an open-ended mutation tool: it lacks a plain-language purpose, usage context, and detailed parameter examples. An agent would struggle to know what inputs are expected and what effect the call has.
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 is a free-form 'arguments' object with 0% field coverage, so the description's explanation of where to place path variables, query values, and body fields adds critical structural meaning. It doesn't enumerate the specific fields (e.g., which instanceID), but the convention helps agents structure calls 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 and resource (POST /instances/{instanceID}/rss/articles/read) and the endpoint path distinguishes it from other RSS tools. However, it doesn't explicitly state the tool's semantic purpose of marking an article as read; it relies on the tool name and endpoint path to convey that.
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 about when to use this tool versus alternatives, nor any exclusions or prerequisites. The description only gives the calling convention, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the endpoint and argument structure. It does not disclose side effects, permissions, rate limits, or response behavior, leaving the agent uncertain about the tool's safety and operational impact.
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 efficiently communicates the endpoint and argument convention without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic schema and no annotations, the description is insufficient to fully understand the tool's purpose, valid inputs, or expected outcomes. It outlines the call structure but lacks operational context, making it incomplete for an agent to use confidently.
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 a generic 'arguments' object with 0% coverage, and the description compensates by defining a clear structure: path variables directly, query values in arguments.params, and JSON body in arguments.body. This is valuable, though specific expected fields are not enumerated.
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 operation as calling the POST /arr/resolve endpoint on qui, specifying the HTTP method and resource. However, it does not explain what 'resolve' semantically does, so it is specific but not fully 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?
The description provides instructions on how to pass arguments (path variables, query params, body) but no guidance on when to use this tool versus alternatives, nor does it mention any use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it does not disclose side effects (e.g., triggering a background job, needing an active instance, or potential changes to torrents). It only states the HTTP method and endpoint, leaving behavioral implications unaddressed.
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, each with a distinct purpose: first identifies the endpoint, second explains parameter placement. No wasted words.
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?
Though an output schema exists, the description omits what response to expect and doesn't mention follow-up actions like polling status via qui_get_cross_seed_async_status. Given this is a run/action tool with nested parameter structure, more context is needed for correct 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 schema's single 'arguments' parameter is opaque, but the description provides a clear convention for mapping path variables, query values, and body content. This compensates for the schema's 0% coverage, though it doesn't enumerate the specific variables expected for this endpoint.
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 the endpoint and action (run), distinguishing it from sibling tools like qui_cancel_cross_seed_automation and qui_list_cross_seed_runs. However, it lacks a plain-language explanation of what running the automation does, relying on the tool name for meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as qui_get_cross_seed_status or qui_cross_seed_apply. The description only explains parameter passing, not the appropriate context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects, authorization needs, or whether the scan is asynchronous. It only mentions making a POST request, which implies a mutation but doesn't state what changes or consequences occur. No behavioral traits beyond the HTTP method are disclosed.
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, information-dense sentence. It front-loads the endpoint and HTTP method, then concisely explains the argument structure. Every word earns its place; there is no unnecessary content.
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?
Despite having an output schema (not shown) and a clear endpoint, the description lacks context: it doesn't explain the tool's purpose, when to use it, or any side effects. Given the large set of sibling tools and the absence of annotations, this is insufficient for an agent to fully understand the tool's role and behavior. It is a low-level API call instruction rather than a complete tool description.
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 extremely generic, with a single opaque 'arguments' object and 0% schema description coverage. The description compensates meaningfully by explaining how to pass path variables directly in arguments, query values in arguments.params, and a JSON body in arguments.body. This is essential, though it doesn't list the specific parameters for this endpoint (other than directoryID visible in the path).
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 the exact endpoint (POST /dir-scan/directories/{directoryID}/scan) and method, clearly indicating it triggers a scan for a specific directory. This distinguishes it from sibling tools that list, get, update, or delete scan directories. However, it doesn't explicitly state the high-level action in plain language (e.g., 'triggers a scan'), which would strengthen clarity.
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 related scan-directory tools (e.g., qui_cancel_directory_scan, qui_get_scan_directory_status). It only explains how to structure the API call, not the conditions or prerequisites for invoking it. There is no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing safety and side effects. It merely describes how to call the endpoint but does not mention whether it performs network I/O, whether it is read-only, what side effects it may have, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences and immediately front-loads the endpoint. Every word adds value, specifying both the HTTP method and how to structure arguments.
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?
While an output schema exists and so return values need not be described, the description omits crucial context about what the test does, what a successful response looks like, and how this differs from the sibling test tool. It is adequate for a simple wrapper but lacks situational guidance.
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 exposes only a generic 'arguments' object with no defined properties (0% schema coverage). The description compensates by explaining the internal structure: path variables at the top level, query values in arguments.params, and the request body in arguments.body. However, it does not enumerate the actual path variables, query parameters, or body fields required, so the compensation is partial.
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 the specific endpoint (POST /arr/test) and states its purpose as calling that endpoint. It is clear and specific about the action, but it does not distinguish this from the sibling tool qui_test_arr_instance, which likely tests an ARR instance in a different way.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context, or exclusions, leaving the agent to infer usage solely from the tool name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It reveals the HTTP method (PUT) which implies mutation, but doesn't state potential side effects, idempotency, required authentication, or error conditions. The description is purely about request formatting, leaving behavioral traits largely undisclosed.
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 endpoint and immediately explains the argument passing convention. Every word earns its place, with no redundant information or verbose explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema and lack of annotations, the description should specify the required parameters (e.g., instanceID) and any expected body fields. It only provides a generic pattern for argument structure without enumerating the actual path/query/body keys, making it insufficient for a standalone invocation. The presence of an output schema offsets return-value documentation, but key input specifics remain 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 description adds meaningful structure beyond the loose schema: path variables go directly in 'arguments', query values in 'arguments.params', and request body in 'arguments.body'. This is critical because the schema only has an arbitrary 'arguments' object with no inner field documentation, making the convention the only practical guide for constructing a call.
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 operation as a PUT to the /cross-seed/completion/{instanceID} endpoint, which is the 'update cross-seed completion' action. This distinguishes it from sibling tools like qui_get_cross_seed_completion which performs a read. However, it doesn't explain what 'completion' means or the effect of updating it, so it falls short of a full 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 provides no guidance on when to use this tool versus alternatives. It only explains how to call the endpoint (path/query/body structure) but doesn't mention scenarios, prerequisites, or why one would choose this over related tools like qui_update_cross_seed_settings or qui_cross_seed_apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only discloses that it is a PUT request, which implies mutation, but it does not explain side effects, required permissions, idempotency, or error behavior. It lacks any context about what changes occur to the notification target or whether existing notifications are affected. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the endpoint and the three parameter-passing conventions. It is front-loaded with the resource and method, with no wasted words. It earns its place by providing the exact HTTP endpoint and argument structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and a generic schema, this description is severely incomplete. It does not explain what a notification target is, what fields are updatable, whether other fields are required, or what the response contains. An agent would have to rely on external API knowledge to invoke this correctly. The terse endpoint reference is not sufficient context for safe and correct usage.
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 is generic (a single 'arguments' object with no property descriptions), so schema coverage is 0%. The description adds a structural convention: path variables directly in arguments, query values in arguments.params, and body in arguments.body. However, it does not name the specific path variable (e.g., id) or the valid fields for updating a notification target. This is only partial compensation for the missing schema detail.
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 identifies the tool as a call to the PUT /notifications/targets/{id} endpoint, which unambiguously indicates an update operation on a notification target. This is further reinforced by the tool name itself. It distinguishes from sibling tools like create, delete, list, and test by specifying the HTTP method and resource path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only explains how to invoke the endpoint (path variables, query params, body) but does not state that this is for updating an existing notification target, nor does it mention exclusion scenarios or fallback tools. The intended use is only implied by the tool name and the existence of related CRUD siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It merely says to call the endpoint without mentioning that this mutates settings, may require permissions, or could overwrite existing configuration. The PUT method implies a write operation, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the endpoint, and contains no filler. Every word contributes to explaining how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool is under-specified on input. The description explains the argument packing convention but not the structure of the JSON body or the required fields. An agent would still not know what settings to send in the request.
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 is a generic catch-all object with 0% field coverage. The description adds structural guidance on how to pass path variables, query values, and the request body, but it does not enumerate the actual settings fields or explicitly state that instanceID is required. This is syntactic help rather than semantic parameter meaning.
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 identifies the exact endpoint (PUT /instances/{instanceID}/orphan-scan/settings) and HTTP method, which conveys that this tool updates orphan scan settings. This is specific and distinguishes it from sibling tools like qui_get_orphan_scan_settings.
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, such as retrieving settings first or using a different update path. It only explains how to call the endpoint, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that this is a PUT call (implying mutation) but does not state side effects, required permissions, idempotency, or what happens on success/failure. The description is purely about request routing, not 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, well-structured sentence that front-loads the endpoint and efficiently explains the parameter convention. Every word earns its place, and there is no extraneous 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?
The description gives the endpoint template and parameter structure, which is a baseline for invoking the tool. However, it lacks domain context (what a tracker customization is), does not specify required fields, and relies on the output schema (not shown) for return values. It is adequate but not complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a free-form 'arguments' object with no named fields and 0% coverage, so the description's breakdown of path variables, query values, and body is essential. However, it does not specify which path variables are required (e.g., 'id') or what the body should contain, leaving significant ambiguity for correct invocation.
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 tool as calling the PUT /tracker-customizations/{id} endpoint, which unambiguously indicates an update operation on a specific resource. This is more technical than domain language, but it is specific and distinct from sibling operations (create, delete, list).
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 about when to use this tool versus alternatives. It does not mention that this should be used to modify an existing tracker customization, nor does it reference sibling tools like create or delete. The description only explains the call mechanics, not the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must convey side effects and behavioral details. It only states 'Call endpoint' without mentioning that this mutates state, requires authentication, or has any rate limits or associated risks. The effect of adding peers is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the endpoint and exact argument passing convention. No wasted words, easy to parse.
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?
While the description names the exact endpoint and argument structure, it omits critical details such as required path variables (instanceID), the request body schema, and any expected response. An agent would struggle to construct a valid call without additional context. The output schema exists but the input semantics remain underspecified.
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 a single generic 'arguments' object with 0% coverage, so the description's instruction to pass path variables, query values, and a JSON body adds structure beyond the schema. However, it doesn't identify which path variables, query parameters, or body fields are expected, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls a specific endpoint (POST /instances/{instanceID}/torrents/add-peers) to add peers to a torrent. This distinguishes it from sibling tools like qui_ban_peers or qui_get_torrent_peers by naming the exact action and 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?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, typical scenarios, or reasons to prefer this over other peer-related tools. The description only explains how to invoke it, not when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation indicates the action is destructive, but the description adds no further behavioral context, such as irreversibility, permission requirements, or what exactly gets deleted. It relies entirely on the annotation and name for transparency.
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 states the endpoint and the argument marshaling convention with no unnecessary words. It is concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the open-ended schema and destructive nature, the description could mention prerequisites (e.g., a completed orphan scan run) and the exact effect of confirmation. The existing text covers the HTTP call pattern and argument structure, which is helpful, but leaves behavioral semantics to the annotation and name, making it adequate but not 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 input schema is a bare free-form 'arguments' object with no descriptions (0% coverage), so the description's instruction to pass path variables directly, query values in arguments.params, and a JSON body in arguments.body is essential structural guidance. This compensates well, though it doesn't enumerate specific fields or value formats.
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 the specific endpoint POST /instances/{instanceID}/orphan-scan/runs/{runID}/confirm, which clearly indicates a confirmation action for orphan deletion, reinforced by the tool name. However, it does not explicitly differentiate this from sibling tools like qui_cancel_orphan_scan or qui_get_orphan_scan_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only instructs how to call the endpoint, without context such as 'use after an orphan scan run completes' or 'do not use if you only want to cancel the scan.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It merely instructs to call the endpoint without stating the mutating side effect (creating an API key), any required authentication, or potential consequences. The parameter-passing detail is structural, not behavioral.
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 endpoint and quickly explains argument structure. No filler or redundancy. Every clause serves a purpose.
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 provides the calling convention but lacks details on required body fields, expected input, or side effects. While the presence of an output schema covers return values, the agent remains uncertain about what to include in the JSON body. For a creation endpoint, this gap makes it functional but not 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 input schema is a generic arguments object with no field details (0% coverage). The description compensates by explaining how to pass path variables, query values, and a JSON body via arguments.params and arguments.body, which is essential for constructing a valid request. This adds significant value beyond 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 clearly specifies calling the POST /api-keys/ endpoint, which combined with the tool name indicates API key creation. It differentiates from siblings like qui_list_api_keys and qui_delete_api_key by referencing the create endpoint, though it could more explicitly state 'creates an API key'.
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 scenarios for use, nor does it differentiate from qui_create_client_api_key or other creation tools. The only 'guidance' is about parameter placement, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already signals destructiveness, but the description adds no further behavioral context such as irreversibility, prerequisites, or effects. It only describes the invocation format, not the behavior beyond the endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the HTTP method and endpoint. Every word serves a purpose, with no redundancy 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?
The description is adequate for a simple delete operation, and the presence of an output schema and destructiveHint covers return values and safety. However, it lacks an explicit plain-language statement of what the tool does and any usage context, making it minimally 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 input schema has a single generic 'arguments' parameter with no documented structure. The description adds valuable meaning by explaining that path variables go directly in arguments, query values in arguments.params, and the JSON body in arguments.body, which is essential for crafting a correct invocation.
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 it calls the DELETE /instances/{instanceID}/backups/runs/{runID} endpoint, which clearly indicates deletion of a specific backup run. It differentiates from sibling qui_delete_all_backup_runs by targeting a single runID, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it deletes a single backup run or that qui_delete_all_backup_runs should be used for deleting all runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already communicates the primary behavioral trait. The description adds no additional context about permanence, idempotency, error handling, or side effects. It merely restates the HTTP method and parameter passing, so it provides little value beyond the annotation.
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, efficiently conveys the endpoint and argument structure, and has no filler. It is appropriately front-loaded with the endpoint reference.
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 DELETE endpoint, the description gives the essential URL pattern and argument-passing convention. It does not explain the required path variable name or provide an example, but the endpoint placeholder '{id}' gives some clue. Given the minimal schema and the presence of an output schema, the description is just barely adequate for making the 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?
The input schema is a generic 'arguments' object with 0% coverage, but the description compensates by explaining how to structure arguments: path variables directly, query values in arguments.params, and a JSON body in arguments.body. This is critical for invocation. However, it does not explicitly name the required 'id' path variable or its key, though the endpoint URL implies it.
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 the tool calls the DELETE /filter-views/{id} endpoint, which clearly indicates it deletes a filter view. This distinguishes it from sibling tools like qui_list_filter_views, qui_create_filter_view, and qui_update_filter_view. However, it does not explain what a filter view is or the functional effect of deletion, 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?
The description provides no guidance on when to use this tool versus alternatives. It only gives technical instructions on how to pass arguments, not the appropriate context or prerequisites for deleting a filter view. No exclusions or alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already flags this as destructive, and the description adds no additional behavioral context such as side effects, prerequisites, or auth requirements. It merely restates the endpoint and parameter passing, missing an opportunity to disclose that the restore likely overwrites instance data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key information (the exact endpoint) and then explains the argument scheme without any 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 simple API wrapper, the description provides enough to construct a request, and the presence of an output schema reduces the need to describe return values. However, for a destructive restore operation with an otherwise empty input schema, it would benefit from explaining when to use it, what the restore entails, and any preconditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description's instruction to pass path variables directly, query values under arguments.params, and a JSON body under arguments.body is crucial. It gives the overall layout and implies the path variables from the URI template, though it does not enumerate required fields or validate the expected body shape.
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 the precise REST endpoint (POST /instances/{instanceID}/backups/runs/{runID}/restore), making the operation clear and distinct from sibling tools like preview_backup_restore. However, it does not explicitly state in plain language that this restores a backup to an instance, relying on the endpoint path and tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as preview_backup_restore or trigger_backup. The only usage-related content is the argument-passing convention, which pertains to parameter semantics rather than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the HTTP method (POST) implying a mutation, but fails to describe side effects, potential errors, required permissions, or runtime behavior. The agent is left guessing about what 'execute' actually does to the system.
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, well-structured sentence that front-loads the endpoint and then compactly explains the argument layout. Every word earns its place; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is an open-ended API caller with a single generic arguments field and an output schema exists, the description provides the essential routing information but lacks examples or expectations. It is minimally viable but not rich enough to fully guide an agent without external knowledge of the qui API.
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 description coverage (just a free-form object), so the description must compensate. It does so by explaining the internal structure of 'arguments': path vars directly, query params in 'params', and request body in 'body'. This adds significant meaning beyond the generic schema, though it doesn't enumerate specific 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 specifies the exact HTTP endpoint (POST /external-programs/execute) and thus clearly identifies the action. It distinguishes from sibling CRUD tools for external programs by indicating this is specifically the execute operation, though it could more explicitly state that it runs an external program.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It explains how to structure arguments but doesn't mention prerequisites, typical use cases, or why one would choose execute over list/create/update. For an agent, there is no contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description's use of GET aligns with that. It adds the argument structure convention but does not disclose potential errors, authentication needs, or return behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint and then summarizes the argument convention. There is no filler, but it could be slightly clearer by stating the purpose before the invocation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic input schema and presence of an output schema, the description provides the essential argument structure but lacks usage context, required parameter specifics, and comparison with siblings. It is adequate but not comprehensive for an agent to confidently select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description partially compensates by explaining the argument layout (path variables, params, body) and naming {instanceID} and {activityId} in the URL. However, it does not enumerate all possible path/query/body parameters, leaving some ambiguity.
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 endpoint being called (GET /instances/{instanceID}/automations/activity/{activityId}), which identifies the resource and operation. It distinguishes from siblings like list_automation_activity by targeting a single activity, though it does not explicitly state 'retrieve details'.
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 alternatives such as list_automation_activity or delete_automation_activity. It only explains how to structure arguments, not when this tool is the appropriate choice.
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 indicate readOnlyHint=true, and the description's 'GET' is consistent. The description adds the argument-passing convention (path, query, body), which is useful behavioral context, but does not disclose prerequisites, rate limits, or error behavior. 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 that front-loads the endpoint URL and then succinctly explains argument structure. No wasted words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered, but for a generic passthrough tool, the description lacks critical specifics such as the required instanceID path variable, available query parameters, and any error handling. The low schema coverage makes this incomplete for an agent to invoke correctly without additional info.
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 coverage is 0% (generic 'arguments' object). The description explains that path variables go directly in arguments, query in arguments.params, and body in arguments.body, but does not specify which path variables (e.g., instanceID) or query parameters are required. This provides a structural convention but lacks concrete parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls a GET endpoint for backup settings, which conveys a specific verb and resource. It distinguishes from sibling tools like qui_update_backup_settings by the HTTP method and path, though it doesn't explicitly name 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 description implies usage for retrieving backup settings via the endpoint name, but provides no explicit guidance on when to use this tool versus other backup-related tools. It does explain how to structure arguments (path/query/body), which indirectly helps in using it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds only the fact that it's a GET request, which aligns with the readOnlyHint annotation but adds little else. It does not disclose whether the instanceID must exist, if authentication is required, or what happens on success or failure. With annotations covering only read-only status, the description carries the burden but falls short.
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 delivers the essential calling convention and endpoint. It is front-loaded with the endpoint and avoids fluff, earning a top score for efficiency.
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 is minimally viable for a read-only GET endpoint with an output schema, but given the large sibling list and sparse schema, it lacks context about the resource's purpose, prerequisites, or when to choose it. The output schema exists but the description still leaves the agent guessing about the meaning of 'completion'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter details beyond the generic 'arguments' container, so the description compensates with important conventions: path variables directly, query values in arguments.params, and body in arguments.body. It also names the instanceID placeholder in the path. However, it does not list query or body fields, so coverage is incomplete.
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 explicitly names the endpoint GET /cross-seed/completion/{instanceID}, which clearly identifies the resource and operation. It goes slightly beyond a tautology by specifying the HTTP method and path, but it does not explain what 'completion' means or what the result represents, so it's not a full 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 alternative cross-seed tools like qui_get_cross_seed_status or qui_get_cross_seed_local_matches. The description only explains how to call the endpoint, not under what circumstances it should be chosen, making it inadequate for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, but the description adds no additional behavioral context such as rate limits, error handling, or response format. The argument structure guidance is more relevant to parameter semantics.
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?
Two sentences, direct and free of fluff. The information is dense but not overly verbose, though it could be more informative without adding length.
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 GET endpoint, the description covers the argument structure but omits the exact path variable name and any usage context. Output schema exists, so return values aren't needed, but invocation remains under-specified.
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 0% coverage (a generic 'arguments' object), so the description's guidance on path/query/body placement is valuable. However, it doesn't specify which path variables or query parameters exist, forcing the agent to infer from the endpoint URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls the GET /torznab/indexers/{indexerID}/errors endpoint, which is a specific verb and resource. This distinguishes it from sibling tools like qui_get_torznab_indexer_health or qui_get_torznab_indexer_stats.
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 only argument-passing mechanics, not when to use this tool. It doesn't mention alternatives or when to prefer this over other indexer-related tools, leaving usage context unspecified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates the operation is read-only. The description adds nothing about rate limits, authentication, pagination, or any side effects. It only explains how to pass parameters, which is not behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence identifies the action, the second explains argument structure. Perfectly sized.
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 provides enough to invoke the endpoint and structure arguments. With an output schema present, return values are likely documented. Missing is clarity on when to use this tool, which is a gap, but for a simple read-only list, it's minimally 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 input schema offers only a free-form 'arguments' object with no property descriptions (0% coverage). The description compensates by explaining that path variables go directly in arguments, query values in arguments.params, and the body in arguments.body. This is essential guidance, though it doesn't enumerate endpoint-specific 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 tells the agent to call qui's GET /themes/custom endpoint, which clearly indicates a read operation for custom themes. The tool name 'qui_list_custom_themes' further confirms the purpose. However, the description focuses on the endpoint call rather than explicitly stating 'lists custom themes', so it's clear but slightly indirect.
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 information is provided about when to use this tool versus other list tools. There is no mention of alternatives, exclusions, or prerequisites. The only guidance is about argument structure, which falls under parameter semantics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, and the description's 'GET' statement is redundant with that annotation. The description adds no additional behavioral context such as pagination, filtering options, or whether authentication is required. It merely reiterates the HTTP method and argument structure, providing little beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key action ('Call qui's GET /instances/ endpoint') and then concisely explains the argument-passing rules. There is no redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential invocation mechanics. However, it omits any specific query parameters or path variables that might be relevant (e.g., filters or pagination), and it doesn't explicitly state that no arguments are needed for a basic list call. The description is adequate but leaves some uncertainty for the 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 input schema is a generic free-form 'arguments' object with 0% coverage, so the description must compensate. It does so by defining the convention: path variables go directly in 'arguments', query values in 'arguments.params', and the request body in 'arguments.body'. This gives the agent actionable guidance for invoking the endpoint, though it doesn't list which parameters are valid for this specific list operation.
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 'Call qui's GET /instances/ endpoint', which clearly identifies the resource and HTTP method. The name 'qui_list_instances' also reinforces the purpose. However, it doesn't explicitly say 'List instances' or describe the return value, relying on the endpoint and name to imply the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it returns all instances, nor does it reference any sibling tools like 'qui_create_instance' or 'qui_list_arr_instances'. The only usage-related info is the generic argument-passing convention, which applies across all 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?
The annotation readOnlyHint=true covers the read-only nature, and the description's mention of a GET endpoint is consistent but adds no new behavioral context. No additional traits such as rate limits, pagination, or side effects are disclosed, so the description provides minimal value beyond the annotation.
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 immediately states the endpoint and gives the essential argument-passing convention, earning full marks for conciseness.
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 an output schema present, return values are covered, but the description lacks crucial context: it does not specify which path variables or query parameters are needed for the endpoint, nor does it provide usage guidance relative to siblings. This makes the tool under-specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given the input schema is generic (only an 'arguments' object with additionalProperties), the description's instruction to pass path variables directly, query values in arguments.params, and body in arguments.body adds useful structural meaning. However, it does not enumerate the specific parameters expected for this endpoint, leaving a significant gap in a 0% coverage scenario.
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 endpoint (GET /torznab/search/recent), which clearly implies the tool lists recent Torznab searches. However, it does not explicitly state the action or differentiate it from similar tools like qui_get_torznab_search_history, so it stops 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?
The description offers no guidance on when to use this tool versus alternatives, nor does it mention any exclusionary conditions. It only explains how to structure arguments, not when the tool is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects and safety. It only states that it calls a POST endpoint, which implies mutation, but 'preview' suggests a non-destructive operation. No information about permissions, reversibility, or whether the preview affects system state is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the endpoint and immediately reveals the parameter passing convention. No fluff or repetition; every word adds useful information for the caller.
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 request construction pattern but omits any explanation of the output or the purpose of previewing a restore. Even with an output schema available, the agent lacks context about what a 'preview' returns or what decisions it should inform (e.g., reviewing changes before executing). This is a minimal but functional description for a generic endpoint wrapper.
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 a generic 'arguments' object with zero description coverage, but the description compensates by explaining the structure: path variables directly in arguments, query values in arguments.params, and JSON body in arguments.body. It does not list the specific path variables (instanceID, runID) or body fields, but it gives essential framing for constructing a valid request.
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 explicitly names the endpoint and HTTP method (POST /instances/{instanceID}/backups/runs/{runID}/restore/preview), which clearly identifies the action as previewing a backup restore. While it doesn't define 'preview' in functional terms, the resource and operation are unambiguous and distinguish this from sibling tools like qui_execute_backup_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is a dry-run or pre-execution check, nor does it contrast with qui_execute_backup_restore or qui_list_backup_runs. An agent must infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. It only states the HTTP method and endpoint, implying a mutation (POST) but not explaining what 'refresh' does, whether it is destructive, if it is asynchronous, or what side effects occur. No behavioral context beyond the endpoint is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately front-loaded with the action and endpoint. It logically separates the argument passing conventions into a concise clause. Every word serves a purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is insufficient for correct invocation. It does not explain what path variables are required (e.g., instanceID), whether query parameters are needed, what the request body should contain, or the expected response/behavior. The generic schema and one-sentence description leave significant gaps for an agent to fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic envelope with an 'arguments' object and no property details, so the description's instruction to pass path variables directly, query values in arguments.params, and body in arguments.body adds some structure. However, it does not list specific path variables, query parameters, or body fields, leaving the agent to infer from the endpoint placeholder. It offers moderate semantic value but incomplete guidance.
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 identifies the exact HTTP method and endpoint (POST /instances/{instanceID}/rss/items/refresh), which is a specific action on a specific resource. The verb 'refresh' and resource 'RSS items' clearly distinguish this from all sibling tools, including other RSS-related tools like qui_get_rss_items or qui_remove_rss_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only gives technical call instructions, with no mention of use cases, prerequisites, or situations where another tool would be more appropriate. The agent is left to infer the purpose 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it is a POST call without explaining the toggle's effect, side effects, permissions, or reversibility. The term 'toggle' implies a state flip but does not make the behavioral consequences explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It efficiently communicates the endpoint and the argument structure without fluff.
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 has no annotations and a minimal schema, but an output schema exists. The description covers the calling convention but omits practical context such as when to use the toggle, what result to expect beyond the endpoint name, and whether the operation is destructive. Some gaps remain but it is not completely inadequate.
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 a generic free-form object with zero coverage, so the description's guidance on structuring arguments is valuable. It explains that path variables go directly in arguments, query values go in arguments.params, and the request body goes in arguments.body. However, it does not enumerate specific required parameters like instanceID or body fields.
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 operation as toggling alternative speed limits via a specific endpoint, which is a specific verb+resource. However, it does not explicitly differentiate this from the sibling qui_get_alternative_speed_limits, so it loses the distinction bonus.
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 only technical invocation instructions (how to pass path variables, query params, and body) but gives no guidance on when to use this tool versus alternatives like qui_get_alternative_speed_limits. There is no mention of context, prerequisites, or when toggling is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It mentions the HTTP method (implied mutation) and argument structure, but does not disclose side effects, authentication requirements, idempotency, error behavior, or what the response contains. This is minimal transparency for a mutating 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, focused sentence that immediately identifies the endpoint and then provides the argument structure. There is no redundancy or filler; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the unstructured schema and lack of annotations, this description is incomplete. It explains the top-level argument organization but fails to specify required path variables, available query parameters, or the JSON body's shape. The presence of an output schema doesn't mitigate the missing input specifications, leaving the agent guessing about the payload.
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 is a single free-form 'arguments' object with zero property definitions, so the description must compensate. It does add value by explaining that path variables go directly in arguments, query values in arguments.params, and the JSON body in arguments.body. However, it does not enumerate the required 'id' path parameter, query parameter names, or expected body fields, leaving much to be inferred.
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 tool as invoking the PUT /arr/instances/{id} endpoint, which semantically maps to updating an ARR instance. This differentiates it from sibling tools like create/get/delete by HTTP method and resource path, though it does not explicitly use the word 'update'.
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 provides implied usage context: since it is a PUT endpoint, the tool is meant to update an existing instance. However, it does not explicitly state when to choose this over alternatives (e.g., create, delete) and offers no exclusions or alternative tool references, leaving the when-to-use guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only repeats the endpoint name and gives argument-passing instructions. It does not disclose side effects, idempotency, required permissions, or whether settings are fully replaced. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the endpoint and then gives concise parameter-passing rules. No wasted words 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?
The description is minimally sufficient for a direct API call, but it lacks comparison with the PATCH sibling, expected body schema, and side-effect context. The presence of an output schema covers return values, but the generic input schema and missing annotations leave the agent uncertain about payload requirements and operational impact.
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 a generic 'arguments' object with zero structure. The description compensates by specifying the argument layout: path variables directly, query values in arguments.params, and a JSON request body in arguments.body. This is critical and goes beyond the schema, though it does not enumerate the actual path/query/body fields.
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 it calls the PUT /cross-seed/settings endpoint with the verb 'call' and resource 'cross-seed settings'. This distinguishes it from the GET (qui_get_cross_seed_settings) and PATCH (qui_patch_cross_seed_settings) siblings by the HTTP method, though it does not explicitly explain the PUT vs PATCH semantic difference.
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 like qui_patch_cross_seed_settings. The description only gives invocation mechanics (how to pass path/body/query), not when a full PUT is appropriate over a partial PATCH. There is no mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only reveals that this is a PUT mutation requiring a request body. It does not explain side effects, whether settings are fully replaced or merged, required permissions, or potential consequences. This falls short of transparent mutation 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 two sentences with no filler. It front-loads the endpoint and concisely explains argument conventions. Every word earns its place.
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?
The tool has a generic schema, no annotations, and an output schema, but the description does not compensate for missing parameter details or behavioral context. It lacks information about the request body shape, required authentication, and the exact update semantics, making it incomplete for an agent to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no specific parameters, so the description's explanation that path variables go directly in arguments, query values in arguments.params, and body in arguments.body adds meaningful structure. However, it does not enumerate the actual path variables or body fields, leaving critical parameter details 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 explicitly names the endpoint 'PUT /dashboard-settings' and the verb 'Call', making it clear this updates dashboard settings. It is specific enough to distinguish from the sibling 'qui_get_dashboard_settings' (read) and other update tools, though it doesn't explicitly say 'update dashboard settings'.
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 provides procedural instructions on how to structure arguments (path variables, query in arguments.params, body in arguments.body), which gives guidance on invocation. However, it does not state when to use this tool vs alternatives, nor does it mention exclusions, prerequisites, or the relationship to 'qui_get_dashboard_settings'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects, permissions, or idempotency. It only says to call the PUT endpoint, revealing nothing about the update semantics or consequences.
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 with clear, direct instructions on how to call the endpoint. Every word earns its place, and no unnecessary detail is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic schema and no annotations, the description provides essential request-structure guidance but is incomplete: it does not indicate required fields (e.g., the id path parameter), what the request body should contain, or how the response relates to the 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 is a generic 'arguments' object with 0% coverage, but the description compensates by explicitly stating where path variables, query values, and body go. This adds meaningful structure to an otherwise opaque schema, though specific field names are not mentioned.
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 specific endpoint (PUT /external-programs/{id}) and implies an update operation on external programs. It distinguishes from sibling tools by the HTTP method and resource, but does not explicitly state 'update' beyond the endpoint name.
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 create, delete, or list external program tools. It only describes how to structure the request, not the use case or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the HTTP method (PUT), implying mutation, but says nothing about side effects, authorization requirements, idempotency, or whether the update replaces or merges existing entries. No behavioral context beyond the method is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the endpoint and parameter conventions without any waste. Every part 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?
The description is minimally sufficient to make a basic HTTP call, but it lacks richer context such as typical use cases, prerequisites, or what the request body should contain. Since an output schema exists, return values need not be explained, but the tool would benefit from more behavioral and usage 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 a generic arguments object with 0% property description coverage. The description compensates by explaining the parameter-passing convention: path variables directly, query values in arguments.params, and body in arguments.body. This is essential for invoking the tool, but it doesn't enumerate the specific path, query, or body fields, leaving some ambiguity.
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 endpoint (PUT /log-exclusions) and the tool name implies updating log exclusions, which distinguishes it from sibling tools like qui_get_log_exclusions. However, it lacks a semantic explanation of what log exclusions are or what an update does, relying on the name for that context.
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, what prerequisites exist, or how it relates to other log exclusion or settings tools. It is purely a calling instruction with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is established. The description adds useful context about how arguments are mapped (path/query/body), which is a behavioral detail. However, it does not disclose additional traits like authentication requirements or rate limits. This is acceptable given the simple read-only nature and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the endpoint and gives concise invocation guidance. No unnecessary words, but it could arguably be slightly more informative about the tool's purpose beyond just calling the endpoint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It covers the essential mechanic of calling the endpoint, but lacks context on when to use it or what 'validate' means in this system. The description is adequate for a simple tool but leaves some interpretive burden on the agent.
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 is generic with only an 'arguments' free-form object, so parameter semantics are undefined. The description compensates by explaining where path, query, and body values go, but does not name any specific parameters or their meanings. For a validation endpoint, this may be sufficient, but it relies on the agent understanding the endpoint's expected inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls the GET /auth/validate endpoint, which aligns with the tool name 'validate_session'. It specifies a verb and resource, making the purpose apparent. However, it does not explicitly distinguish it from sibling tools like qui_get_current_user, though the intent is fairly unique.
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, nor any exclusions or prerequisites. It only explains how to structure arguments, which is mechanical rather than contextual. Users must infer that it validates a session based on the 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?
No annotations are provided, so the description carries the burden. It adds useful behavioral context by specifying HTTP method (POST) and argument mapping (path, query, body). However, it omits side-effect information (e.g., changes to license state), permission requirements, or response behavior. It does not contradict any annotations (none exist).
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 sentence, dense but not bloated. It front-loads the endpoint and then describes argument structure. Could be slightly clearer with separate sentences for readability, but it is concise and every clause 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?
There is an output schema (not shown), so return values are presumably covered. However, the description lacks usage prerequisites, specific path/query/body parameter names, and side-effect warnings. For a mutation tool with no annotations and an empty schema, it leaves some gaps in understanding what the endpoint actually needs.
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 (only an 'arguments' object with no properties), and schema description coverage is 0%. The description significantly compensates by explaining that arguments contain path variables, query values, and a JSON body. This gives meaning to the single parameter, though it does not enumerate the specific path/query/body fields.
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 the specific endpoint (POST /license/activate) and the action (activate a license). It distinguishes from sibling tools like validate_license, refresh_licenses, and delete_license by naming the activation endpoint, though it phrases the purpose as 'call endpoint' rather than a plain functional statement.
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 vs alternatives. There is no mention of license activation scenarios, prerequisites (e.g., having a license key), or why one would choose this over validate/refresh/delete. The description only explains how to call the endpoint, not when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks this as destructive, and the description adds no further behavioral context such as irreversibility, cascading effects, or required permissions. The description merely restates the DELETE method and provides argument structure guidance, which is more parameter-related than behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loaded with the operation, and every sentence serves a clear purpose: identifying the endpoint and explaining the argument structure. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and vague schema, the description is incomplete. It fails to state that an instance ID is required, how to pass it, or the consequences of deletion. The output schema exists but does not compensate for the missing input details.
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 is a generic object with no parameter definitions (0% coverage). The description provides a general convention for passing path variables, query values, and body, but it does not identify the specific 'id' path variable or any other required fields for this endpoint, leaving significant ambiguity.
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 as DELETE /arr/instances/{id}, which is specific to deleting an ARR instance. It distinguishes from sibling tools like qui_update_arr_instance and qui_get_arr_instance by explicitly identifying the HTTP method and resource.
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 from the DELETE method and endpoint, but the description does not explicitly state when to use it versus other ARR instance tools, nor does it provide prerequisites or alternatives. It focuses on how to call the endpoint rather than the condition for its use.
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 annotation destructiveHint=true already discloses the destructive nature. The description adds the precise HTTP method and endpoint path, but does not add additional behavioral context such as irreversibility, effect on associated files, or error behavior. Since annotations cover the core safety trait, 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?
Two concise sentences, no filler, front-loaded with the endpoint and immediately followed by argument-passing guidance. 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?
With an output schema present, return values need no explanation. But the description lacks any domain context about the purpose (beyond the endpoint), potential side effects, or usage conditions. It is minimally sufficient for a straightforward delete operation but could benefit from stating that this deletes a scan directory and any associated data.
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 is a generic freeform 'arguments' object with zero coverage. The description explains the argument structure (path variables, query params, body) and the endpoint path reveals that a directoryID must be supplied in arguments. However, it does not explicitly list required fields or types, so it only partially compensates for the missing schema detail.
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 as a DELETE call to a scan directory endpoint, and the tool name confirms it deletes a scan directory. It distinguishes from sibling scan directory tools (list, create, get, update) by specifying the DELETE method and the resource path. However, it lacks a plain-language statement of the effect (e.g., 'deletes the specified scan directory').
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 state prerequisites (e.g., directory must exist) or indicate when to prefer this over related directory tools. The description only explains how to invoke the endpoint, not when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds the parameter-passing convention (path, query, body) but does not disclose other behavioral aspects such as authentication needs, rate limits, or response structure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint URL, making the primary purpose immediately clear. The second sentence on argument passing is concise, though the generic instruction to include a body for a GET endpoint adds unnecessary noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple GET nature and presence of an output schema, the description covers the endpoint and argument convention adequately. However, it lacks usage context, specific parameter enumeration, and any caveats, leaving the agent to infer important details.
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 schema has zero description coverage and only a generic 'arguments' object. The description gives a general convention for passing path, query, and body values, but does not enumerate actual parameters (e.g., instanceID) except implicitly in the endpoint URL. For a GET operation, the instruction to include a JSON request body is likely irrelevant and could mislead.
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 explicitly names the exact GET endpoint for alternative speed limits on a specific instance, using a specific verb ('GET') and resource path. This clearly distinguishes it from sibling tools like qui_toggle_alternative_speed_limits.
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 when-to-use or when-not-to-use guidance, nor does it reference alternatives. Usage is only implied by the 'GET' verb and tool name, but there is no explicit statement of appropriate context 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?
The readOnlyHint annotation already covers safety, and the description adds the parameter-passing convention (path vars, query, body). It doesn't disclose response behavior, error cases, or what the response contains, but the annotation lowers the bar.
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, front-loaded with the endpoint, no filler. Every part contributes useful information about how to invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema and read-only annotation reduces the need to describe return values and safety. Still, the description lacks a functional statement of what local matches are and when to use the tool, making 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?
With 0% schema description coverage, the description does compensate by explaining how to organize arguments into path, query, and body. However, it doesn't define the specific parameters (instanceID, hash) or their types, leaving some ambiguity.
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 the exact HTTP method and endpoint path, making the operation clear. However, it doesn't explicitly state what 'local matches' are or how this tool differs functionally from sibling cross-seed tools beyond the endpoint name.
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, no exclusions, and no context about prerequisites. It simply instructs to call the endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds no behavioral context beyond the endpoint call, such as return format details, error behavior, or any side effects. It doesn't contradict annotations, but it also doesn't enhance transparency beyond 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, dense sentence that front-loads the endpoint and immediately provides the argument-passing convention. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists to describe returns, the description fails to explain what the cross-seed status represents or when to use this tool. It is a bare technical instruction with no functional overview, and the lack of usage guidance makes it incomplete for an agent deciding whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a free-form object with 0% property coverage, so the description provides essential guidance by specifying how to structure arguments: path variables directly, query values in arguments.params, and JSON body in arguments.body. This is critical for correct invocation and goes far beyond the ambiguous 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 identifies the exact endpoint and HTTP method, making it clear that the tool retrieves cross-seed status for a specific instance. It indirectly differentiates from siblings like qui_get_cross_seed_status by including {instanceID} in the path, though it does not explicitly state this 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?
There is no guidance on when to use this tool versus alternatives such as qui_get_cross_seed_status or qui_list_cross_seed_runs. The description only explains how to call the endpoint, not the intended use case or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation, and the description's mention of GET aligns with that. However, the description adds no additional behavioral context such as what the response contains, whether it requires network access, or any rate limits. It does not go beyond the annotation's disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the endpoint first and then explains argument structure. There is no fluff or redundancy; 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?
With an output schema present, return values are covered, and the tool is simple. However, the description lacks context about the meaning of 'latest version' (e.g., remote vs. installed) and does not tell the agent when this should be invoked relative to other version-related tools. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is a free-form object with no documented parameters (0% coverage), so the description's guidance on passing path variables, query values in arguments.params, and a body in arguments.body is valuable. However, it does not enumerate specific parameters for this endpoint, leaving the agent to guess what path variables or query parameters might be accepted, which limits its usefulness.
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 identifies the tool as calling the GET /version/latest endpoint, which is a specific resource and distinct from sibling tools like qui_get_version. The tool name also reinforces the purpose, making it unambiguous that this retrieves the latest version information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., qui_get_version for the current version). It simply says 'Call qui's GET /version/latest endpoint' without any context about use cases or exclusions, leaving the agent without decision 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?
The readOnlyHint annotation already indicates a safe read operation, lowering the bar. The description adds the endpoint structure and argument-passing conventions but no additional behavioral details (e.g., auth needs, rate limits, response shape). It is neither contradictory nor particularly enriching.
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 leads with the endpoint and immediately follows with how to structure arguments. 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?
Given the simple GET nature, the readOnlyHint, and the presence of an output schema, the description covers the essential invocation details. However, it omits the functional purpose (what 'licensed status' means) and any differentiation from sibling license-related tools, making it only minimally 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?
The input schema is completely open (additionalProperties: true) with zero descriptions, so the description must compensate. It explains the general structure for path variables, query parameters, and body, which is helpful. However, it does not list specific parameter names or expected values for this endpoint, leaving the agent to infer them.
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 calls the GET /license/licensed endpoint, which is a specific verb+resource. The tool name 'qui_get_licensed_status' reinforces that it retrieves licensed status. It distinguishes from siblings by naming the exact endpoint path, though it does not explicitly describe the returned status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like qui_validate_license or qui_list_licenses. It only explains how to pass arguments, not the appropriate use case 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?
The readOnlyHint annotation already declares a safe read operation, and the description aligns by specifying GET. However, it adds no extra behavioral context such as required authentication, pagination, or response format. The description is consistent with the annotation but adds minimal value beyond it.
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 sentence that efficiently covers the endpoint and argument structure. It is not bloated, but could be slightly improved by listing the argument categories in a more structured way. Still, it earns its place and is well-sized.
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 a simple read operation with an output schema, so return values need not be described. The description provides the endpoint and argument convention but lacks domain context about what 'reannounce activity' contains (e.g., dates, statuses). For a low-complexity tool, it is minimally adequate but leaves room for richer 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?
With 0% schema coverage and an open 'arguments' object, the description compensates by explaining how to structure arguments: path variables directly, query values in arguments.params, and body in arguments.body. This is crucial for correctly invoking the endpoint and grounds the otherwise generic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a GET to the reannounce/activity endpoint, with a specific verb and resource. However, it doesn't explain what 'reannounce activity' is or distinguish it from similar tools like qui_get_reannounce_candidates, making it clear but not fully differentiated.
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 only states the endpoint and argument-passing convention, but gives no context for when this tool is appropriate, such as 'use this when you need to view reannounce activity for an instance'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a read operation, and the description merely repeats the HTTP method. It does not add any additional behavioral context such as required permissions, rate limits, or side effects, so it adds little beyond the annotation.
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 conveys both the endpoint and the calling convention without unnecessary words.
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 GET endpoint with an output schema and readOnly annotation, the description provides the essential calling convention. However, it omits explicit mention of the required instanceID and any potential query parameters, leaving some inference to the 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?
With a generic schema (0% coverage), the description provides a valuable convention: path variables go directly in arguments, query values in arguments.params, and the body in arguments.body. This compensates for the schema's lack of detail, but it does not name the specific path variable (instanceID) or any query 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 references the specific endpoint GET /instances/{instanceID}/tags, which clearly indicates that this tool retrieves tags for an instance. It distinguishes from siblings like qui_create_tags and qui_delete_tags through the HTTP method, but it does not explicitly state the semantic result (e.g., 'returns tags').
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 alternatives. The description focuses solely on how to structure arguments (path variables, query params, body) rather than on the operational context, prerequisites, 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?
The readOnlyHint annotation already indicates this is a read-only operation. The description adds value by specifying argument routing: path variables directly, query values in arguments.params, and JSON body in arguments.body. This is beyond the annotation. However, it does not disclose whether a request body is actually expected for a GET, nor does it mention any response behavior 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 sentence that immediately states the endpoint and then explains argument routing. It is concise, front-loaded, and contains no redundant information. Every word contributes to the calling conventions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has an output schema and a readOnlyHint, the description doesn't need to explain return values. It adequately covers the argument-passing conventions. However, it lacks usage context (when to call this) and detailed parameter semantics, which makes it incomplete for a tool that requires an instanceID path variable. The description is sufficient for a simple GET but not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only has a generic 'arguments' object with no field-level descriptions (0% coverage). The description compensates by explaining that path variables go directly in arguments, query values go in arguments.params, and the body goes in arguments.body. This provides structural meaning, but it does not list the actual path variables (e.g., instanceID) or any query parameters, leaving the agent to infer from the endpoint URL.
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 tool as calling GET /instances/{instanceID}/torrent-creator/status, which indicates it retrieves torrent creation status. The endpoint and tool name are aligned, and it is distinct from siblings like qui_get_active_torrent_creation_count and qui_delete_torrent_creation_task. However, it doesn't explicitly state 'get status' in plain language; it just says 'call the endpoint.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only explains how to structure arguments for the request, with no mention of typical use cases such as polling after creating a torrent or checking the status of a specific creation task. It does not reference sibling tools like qui_create_torrent or qui_get_active_torrent_creation_count.
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 read-only nature is already declared by readOnlyHint, and the description adds the argument-passing convention (path variables, query in arguments.params, body in arguments.body) which is useful for invocation but not a behavioral trait. No additional side effects, error behavior, or permissions are disclosed beyond the annotation.
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 directly points to the endpoint and provides essential argument structure. No wasted words; it is front-loaded with the endpoint and then the argument-handling convention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple getter nature and the presence of an output schema, the description covers basic call mechanics but omits the business purpose and usage context. An agent might not know when to choose this over other getter tools or what to do with the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic (any object) with 0% description coverage, so the description's instruction to place path variables, query values, and body in specific sub-keys adds necessary structure. However, it does not specify which query parameters or body fields apply to this endpoint, leaving the agent to infer from the URI alone.
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 the specific endpoint GET /torznab/indexers/{indexerID}, making the operation clear from the URI. However, it does not explicitly state the semantic purpose (retrieve a specific Torznab indexer) and relies on the tool name to infer that, without differentiating from sibling tools like qui_get_torznab_indexer_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as 'use this to fetch details of a specific indexer' and does not mention any preconditions, exclusions, or linkage to other indexer-related 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=true, and the GET endpoint aligns with that. The description adds no extra behavioral context like authorization or rate limits, but it also doesn't contradict the annotations. Minimal added value beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, and the action is front-loaded. Every word earns its place, providing a clear template for the arguments structure.
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 health-check endpoint, the description gives the essential endpoint and argument structure, and the output schema covers return values. However, it lacks detail on whether query/body are actually required, and the generic mention could mislead. More specifics would make it 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?
The schema is essentially a generic 'arguments' container with zero coverage, so the description's explanation of passing path variables, query params, and body is helpful. However, it doesn't enumerate the specific parameters for this endpoint beyond the {indexerID} in the URL, leaving some ambiguity.
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 explicitly identifies the HTTP method and endpoint, which clearly states the tool's function: retrieving health data for a specific torznab indexer. However, it does not explicitly differentiate from sibling tools like qui_get_torznab_all_health, relying on the endpoint's {indexerID} to imply specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only explains how to structure arguments, not the context for selecting this endpoint over others such as all-health or stats endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation, and the description's mention of GET aligns with that. However, no additional behavioral details are disclosed, such as whether it returns all automations, supports pagination, or has any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence that front-loads the endpoint and method. Every word contributes to explaining the request structure, with no redundancy 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?
The tool is a simple GET request, but the description omits explicit mention of the required instanceID path parameter (though implied in the URL) and doesn't mention what the response contains. Given the low schema coverage, this is a noticeable gap, though the output schema partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is generic with no parameter details, but the description adds a structural convention: path variables go in arguments, query values in arguments.params, and body in arguments.body. This helps, but it doesn't specify the required instanceID or any available query parameters, leaving the agent to guess.
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 the HTTP method (GET) and endpoint (/instances/{instanceID}/automations/), clearly indicating a read operation to retrieve automations. However, it doesn't explicitly state 'list' or describe what the automations represent, and it doesn't differentiate from sibling tools like qui_list_automation_activity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as qui_list_automation_activity or qui_create_automation. The description only explains request mechanics, not use cases or context.
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, and the description's mention of GET aligns with that. However, it adds no additional behavioral context such as pagination, response size, or potential side effects. It does not contradict annotations, so a baseline 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?
The description is two sentences, front-loaded with the endpoint, and every word serves a purpose. It is concise and well-structured with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the very generic schema and no parameter details, the description is minimally sufficient for a simple read-only list operation, but lacks explicit statement of what is listed and any query parameter documentation. The output schema covers return values, so that is not a gap, but the missing parameter specifics make it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description offers a general convention for passing path/query/body parameters, but does not enumerate specific parameters like instanceID or any query parameters. It adds some meaning beyond the free-form schema but is insufficient to fully specify the call signature.
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 the specific GET endpoint /instances/{instanceID}/orphan-scan/runs, which clearly maps to listing orphan scan runs. It is specific in verb (GET) and resource, but does not explicitly distinguish it from sibling tools like qui_get_orphan_scan_run that retrieve a single run.
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 how to pass arguments (path variables directly, query values in arguments.params, body in arguments.body) but does not provide guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions 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?
The readOnlyHint annotation is consistent with the GET method mentioned in the description, so there is no contradiction. The description adds little beyond the annotation—no details about response size, pagination, or potential rate limits, but the annotation already covers the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, yet it communicates the endpoint and the three-part argument structure. Every word earns its place, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema present, the description is minimally adequate for invocation. It lacks contextual information such as what a 'run' represents, how to interpret results, or any caveats like pagination, but the output schema likely covers return structure. No alternatives are mentioned.
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 is essentially an empty object with only an 'arguments' property, and schema coverage is 0%. The description explains the generic argument structure (path variables, params, body) but fails to identify the required directoryID path variable or any query parameters. It leaves parameter specifics to be inferred from the endpoint URL, which is a significant gap.
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 endpoint and HTTP method (GET /dir-scan/directories/{directoryID}/runs), implying a read-only list operation for a specific directory's runs. It distinguishes from sibling tools via the resource path, though it lacks an explicit verb like 'list' in 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit instructions on how to structure arguments (path variables, params, body), which is essential for invoking the tool given the shallow input schema. However, it provides no guidance on when to use this tool versus related tools like qui_list_scan_run_injections or qui_get_scan_directory_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It mentions the HTTP method and argument structure, but does not state whether the operation is mutating, what side effects occur, or any prerequisites. The effect of 'refresh' is left entirely to inference from the tool name.
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 immediately names the endpoint and concisely communicates the argument passing convention. Every word contributes value, and the structure is front-loaded with the core purpose.
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 low complexity, and the description provides enough to invoke the endpoint correctly. However, it lacks usage context and business semantics beyond the endpoint name. With an output schema present, missing return-value details are acceptable, but the lack of when-to-use guidance leaves the description only minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with additionalProperties, so schema coverage is 0%. The description compensates by explaining the argument structure: path variables go directly in arguments, query values in arguments.params, and body in arguments.body. However, it does not enumerate the actual parameters needed, leaving ambiguity.
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 identifies the operation as refreshing licenses via the POST /license/refresh endpoint. The verb 'refresh' and resource 'licenses' are specific, and the endpoint naming distinguishes it from sibling license tools like list, activate, validate, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only explains how to invoke the endpoint, not the conditions under which a license refresh is appropriate or when to prefer other license operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must fully disclose behavioral traits, but it only reveals the HTTP method (PATCH). It does not mention side effects, permissions, whether changes are reversible, or what settings are affected.
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 immediately identifies the endpoint and then efficiently explains the argument conventions. No filler or repetition.
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 is adequate for a simple PATCH wrapper, but it lacks specifics about the request body structure and does not mention any return value or error behavior. Since an output schema exists, return values may be covered, but the missing fields for the settings payload still leave the description incomplete.
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's 'arguments' object is generic with 0% description coverage, so the description adds valuable structure by explaining how to map path variables, query values, and body. However, it omits the actual fields or keys for dir-scan settings, leaving the agent without enough detail to construct a precise request.
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 explicitly names the endpoint and HTTP method (PATCH /dir-scan/settings), making the tool's purpose unmistakably clear. It distinguishes itself from the sibling qui_get_dir_scan_settings by focusing on the update action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus qui_get_dir_scan_settings or other update tools. The description merely explains how to call the endpoint, not when or why to choose it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only explains the argument-passing convention (path variables, query params, body) but does not disclose the mutation nature, required permissions, partial versus full update semantics, or error behavior. This is a significant gap for a write operation.
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 wastes no words. It clearly states the endpoint and the argument convention, making it highly efficient 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 description is adequate for a simple HTTP wrapper given that an output schema exists, but it lacks any context about what a filter view is, when updating is appropriate, or what fields the request body should contain. The generic schema and absence of annotations leave noticeable gaps in fully enabling correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is a generic wrapper with 0% coverage, so the description's guidance on where to place path variables, query parameters, and request body adds critical value. However, it does not specify the actual fields for a filter view update, leaving the agent without endpoint-specific parameter details beyond the routing convention.
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 identifies the operation as a PUT request to /filter-views/{id}, which directly maps to updating a filter view. It distinguishes from sibling tools like list, create, and delete by specifying the HTTP method and resource path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create or delete filter views. The description only explains how to call the endpoint, not the appropriate context or prerequisites for updating a filter view.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects, whether the update is destructive/overwriting, permission requirements, or any other behavioral context. The description only explains the argument-passing convention, leaving behavioral traits completely unspecified.
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 provides the essential calling protocol without wasted words. It is front-loaded with the endpoint context and immediately tells the agent how to structure arguments, making it extremely efficient.
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?
Despite having an output schema, the description is incomplete for a complex update operation. It lacks any explanation of what the endpoint does semantically, required path parameters, expected body fields, or conditions for use. The sparse generic schema and lack of annotations heighten the need for more detail, but the description only covers argument structure, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with 0% coverage, so the description adds crucial structure: it explains that path variables go directly in arguments, query values go in arguments.params, and the request body goes in arguments.body. This compensates significantly for the schema's lack of detail, though it does not enumerate the actual fields (e.g., indexerID, body properties).
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 specific endpoint and HTTP method (PUT /torznab/indexers/{indexerID}), which distinguishes it from sibling CRUD tools (create, get, delete, test, sync). However, it relies on the tool name and endpoint path to convey the semantic 'update' action rather than explicitly stating it in user-friendly terms.
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 by the PUT method and tool name, indicating it modifies an existing Torznab indexer. There is no explicit guidance about when to use this tool versus alternatives like create or delete, and no exclusions or prerequisites 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?
The readOnlyHint annotation already indicates a safe read operation, and the description adds that it is a GET request. This provides some behavioral context, but the description does not disclose response behavior, auth requirements, or any potential side effects. The annotation covers the safety profile, so 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?
The description is two sentences long, directly front-loaded with the endpoint, and every word adds value. There is no redundant information 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 simple GET endpoint, the description is minimally adequate: it tells the agent how to invoke it. However, it omits the high-level purpose (checking if setup is required) and any context about expected return values or when to use it. The presence of an output schema helps with return values, but usage context is still 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 input schema is generic with no parameter descriptions, so the description's explanation of how to pass path variables, query values, and body parameters adds crucial meaning beyond the schema. It clarifies the structure of the arguments object, which is otherwise opaque. However, it does not describe endpoint-specific parameters, so it does not fully compensate for the schema's lack of detail.
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 as calling the GET /auth/check-setup endpoint, which is a specific verb+resource. The endpoint name implies the purpose of checking setup status, but the description does not explicitly state what the endpoint does or how it differs from other qui_* tools beyond the unique endpoint path.
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, nor does it mention any prerequisites or context. It only explains how to construct the request, not when it is appropriate to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only notes the HTTP method POST, implying mutation, but does not describe side effects, required permissions, or what happens on success/failure. It provides minimal insight beyond the endpoint itself.
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 clearly communicates the endpoint and argument-passing convention. It is concise, front-loaded, and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool likely requires a detailed request body to create a filter view, but neither the schema nor description provides field-level specifics. The output schema exists, so return values are not needed, but the missing request body specifications make the description insufficient for correct 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 description adds valuable structure guidance: path variables go directly in arguments, query values in arguments.params, and a JSON body in arguments.body. This is critical because the input schema is an opaque free-form object with zero property descriptions. However, it lacks field-level details for this specific filter-view creation 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 explicitly states the HTTP verb and resource path ('POST /filter-views/'), which clearly identifies the action as creating a filter view. The tool name 'create' distinguishes it from sibling tools like list, update, and delete.
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. There is no mention of use cases, prerequisites, or exclusions. The description only explains how to call the endpoint, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation indicates destructiveHint=true, so the agent knows it's destructive. However, the description adds no additional context such as permanence, what exactly is deleted, or side effects. It merely states the endpoint, providing no extra behavioral transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the endpoint and immediately followed by usage mechanics. No wasted words or redundancy, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic schema and 0% coverage, the description leaves too much unspecified. It does not explicitly mention that the client API key id must be passed as a path variable, nor whether any query parameters or body are required. The instruction to pass a JSON request body could mislead the agent into thinking a body is needed for a DELETE operation. The output schema exists, but input semantics are insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no specific parameters, and schema coverage is 0%. The description helps by explaining the argument structure (path variables at top level, query params in arguments.params, body in arguments.body). However, it does not specify what the required path variable {id} is or any query/body fields, leaving significant ambiguity.
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 explicitly names the HTTP DELETE endpoint for client API keys, which clearly identifies the resource and action. This distinguishes it from sibling tools like qui_delete_api_key, which targets a different resource.
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 provides instructions on how to structure arguments (path variables, query, body) but does not explicitly state when to use this tool over alternatives or any exclusions. Usage is implied by the endpoint, but no clear guidance is given for choosing between similar delete tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation readOnlyHint=true, and the description merely confirms it's a GET endpoint with no side effects. It adds no further behavioral context such as response size, potential errors, or required authentication, so value beyond annotations is minimal.
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 crisp sentences; the first states the endpoint and the second explains argument layout. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient for invoking the endpoint technically, and the presence of an output schema covers return values. However, it lacks context about what capabilities represent, when the tool should be used, and any prerequisites like requiring a valid instanceID, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With an input schema that has zero documentation on the single 'arguments' field, the description provides critical structure: path variables at the top level, query parameters under arguments.params, and body under arguments.body. This fully compensates for the schema's lack of detail.
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 the exact REST endpoint (GET /instances/{instanceID}/capabilities), making the resource and operation clear. However, it does not provide a plain-language statement of what 'capabilities' are in this context, and it doesn't explicitly differentiate from sibling tools like qui_get_instance_mediainfo or qui_get_instance_transfer_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 offers no guidance on when to choose this tool over alternatives among the many instance-related getters. It only explains parameter passing conventions, not selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read operation. The description adds only the HTTP method and argument-passing convention, with no additional behavioral context like response characteristics or required permissions.
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 is direct and free of fluff. It conveys the endpoint and parameter-passing convention 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?
The output schema exists, so return values are covered. The description explains the argument structure and the endpoint is simple. Missing explicit usage guidance prevents a perfect score, but overall it is reasonably complete for a read-only GET.
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 is a generic 'arguments' object with 0% coverage, so the description's note about passing path variables in arguments, query values in arguments.params, and body in arguments.body provides structural meaning. However, it does not specify which concrete parameters this endpoint expects, though the endpoint likely has none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls qui's GET /log-settings endpoint, identifying both the action (GET) and the resource (log settings). This distinguishes it from siblings like qui_update_log_settings and qui_get_log_exclusions.
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 using qui_update_log_settings for changes. The only usage advice is about argument-passing mechanics, which does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description consistently shows a GET request. It adds the specific endpoint structure but nothing else about behavior, such as error responses, authentication requirements, or the meaning of a response. The annotation lowers the bar, but the description still adds minimal context beyond it.
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 states the endpoint and call conventions without wasted words. It is structured clearly and is easy 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?
With an output schema present, return-value details are covered. The description provides the endpoint and argument-passing mechanics, but it doesn't clarify what an 'orphan scan run' is, how to obtain the instanceID/runID, or when to prefer this over sibling tools. This is adequate for a simple retrieval but lacks surrounding context.
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 schema provides no named parameters (0% coverage), so the description must compensate. It explains the structural convention (path variables directly in arguments, query values in arguments.params, body in arguments.body) but does not enumerate the actual parameters (instanceID, runID) or their meanings/types. The placeholders in the URL offer some hint, but the description itself leaves too much implicit.
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 precisely names the HTTP method (GET) and the full endpoint path with path variables (/instances/{instanceID}/orphan-scan/runs/{runID}), which unambiguously identifies the operation and distinguishes it from siblings like qui_list_orphan_scan_runs. This meets the standard of specific verb+resource+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?
No guidance is provided on when this tool should be used instead of alternatives. It doesn't mention that this fetches a single run while qui_list_orphan_scan_runs lists all runs, nor any prerequisite like needing a runID. The purpose must be inferred from the tool name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the HTTP method (GET) and the structure of arguments (path, query, body), which partially supplements the readOnlyHint annotation. However, it does not disclose potential side effects, authorization requirements, or rate limits, so behavioral transparency 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?
A single, direct sentence that immediately states the endpoint and argument-passing conventions. No wasted words, front-loaded with the key 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?
The description calls out the exact endpoint and argument structure, and an output schema exists (so return values need not be described). However, it omits usage context, prerequisites, and any detail about what query/body parameters are valid, leaving gaps for an agent to infer behavior.
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 a generic 'arguments' object with 0% property coverage, so the description's clarification that path variables go directly, query values go in arguments.params, and request body goes in arguments.body adds essential meaning. It does not enumerate specific query or body fields, but compensates for the schema's lack of detail.
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 explicitly states the tool calls qui's GET /instances/{instanceID}/reannounce/candidates endpoint, identifying the resource and operation clearly. It does not explicitly differentiate from sibling tools, but the endpoint URL is specific enough to be 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?
The description provides no guidance on when to use this tool or when to prefer an alternative. It only gives the endpoint and argument-passing mechanics, so an agent lacks context on the intended use case or decision boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already marks the tool as safe, and the description adds some context by specifying it's a GET request with path/query/body argument conventions. However, it doesn't disclose the return shape or any special behaviors beyond that. This is acceptable but minimal.
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 immediately identifies the endpoint and then provides concise, structured instructions. No wasted words, well 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?
The description covers the mechanical details of how to invoke the endpoint but omits semantic information about what 'activity' represents or when to use the tool. An output schema exists, so return values are documented elsewhere, but the tool still lacks a clear purpose statement.
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 completely generic (one free-form 'arguments' object), and description coverage is 0%. The description compensates by explaining how to pass path variables, query values, and body data, which is essential for using the tool. It doesn't list specific parameter names, but the structural guidance earns a strong score.
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 ('Call qui's GET /torznab/activity endpoint') and names the resource, making the tool's function clear at a basic level. However, it doesn't explain what 'activity' means or how it differs from sibling tools like qui_get_torznab_search_cache, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only gives instructions on argument formatting, not usage context or exclusions. No sibling tools 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 declare readOnlyHint=true, and the description adds the parameter-passing convention (path/query/body). However, it does not disclose any other behavioral traits such as required parameters, potential errors, rate limits, or pagination behavior. The description adds some value beyond annotations but is 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 immediately states the action and the argument structure. Every word earns its place; no redundancy 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?
The description covers the call mechanics but omits specific required inputs (e.g., the indexerID path variable is implied by the URL but not stated). There is an output schema, so return values need not be described, but for an agent to correctly invoke the tool, it should explicitly mention that an indexerID must be supplied and any relevant query parameters.
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 a catch-all 'arguments' object with no specific parameters (0% schema coverage). The description compensates by explaining that path variables go directly in arguments, query values in arguments.params, and body in arguments.body. This is helpful but does not enumerate the actual parameters (e.g., indexerID), so some inference is still 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 names the exact endpoint (GET /torznab/indexers/{indexerID}/stats), making it clear this tool retrieves indexer statistics. However, it does not explain what 'stats' includes or explicitly state the outcome, so it is not as transparent as listing the resource and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools (e.g., qui_get_torznab_indexer_health, qui_get_torznab_indexer_errors). The description only explains how to call the endpoint, not in what context or with what alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already indicates a safe read operation. The description adds that it is a GET request but provides no additional behavioral context such as pagination, returned data shape, or authentication needs. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the endpoint and action. Every word earns its place, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-operation tool with an output schema and readOnly annotation, the description covers the essential calling convention. It could benefit from noting any required or optional query parameters, but the presence of an output schema reduces the need to describe return values. Overall, it is sufficiently complete for basic use.
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 is generic (only 'arguments'), with 0% description coverage. The description explains the convention of passing path variables, query values, and body, which adds meaning beyond the empty schema. However, it does not specify which query parameters or path variables this particular endpoint supports, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls the GET /api-keys/ endpoint, which is a specific verb and resource. It implies listing API keys, and is distinguishable from siblings like qui_create_api_key and qui_list_client_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?
The description does not provide any guidance on when to use this tool versus alternatives. It only states the endpoint and how to pass arguments, with no mention of exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the read-only nature, and the description adds the GET method (redundant) and the argument-passing pattern. There is no disclosure of pagination, response size, or error behavior, but the annotation mitigates the safety concern, leaving only minor additional value.
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 exactly two sentences with no filler. The first sentence identifies the endpoint; the second explains parameter placement. It is concise, well-structured, and all content is useful.
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 core mechanics (endpoint call, argument mapping) and benefits from the readOnly annotation and an output schema. However, it lacks usage context, detailed parameter names for the endpoint, and behavioral notes, leaving the agent to infer specifics from the API path and conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0% and a generic 'arguments' object, the description's instruction to place path variables directly, query values in 'arguments.params', and a body in 'arguments.body' is essential. It gives structure to an otherwise opaque parameter schema, though it does not enumerate specific parameters for this endpoint.
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 precise HTTP endpoint ('GET /cross-seed/season-pack/runs') and links it to the tool name, which clearly indicates listing cross-seed season-pack runs. This distinguishes it from the sibling 'qui_list_cross_seed_runs' by endpoint path, though it lacks a plain-language statement of the result.
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 alternatives or in which contexts it is appropriate. The description only provides the endpoint and argument-handling instructions, with no mention of prerequisites, exclusions, or relationship to 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?
The readOnlyHint annotation already indicates a safe read operation, and the description adds the convention for passing path variables, query parameters, and body through arguments. However, it does not disclose output semantics, pagination, or error behavior, which would add more transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the endpoint, and contains no redundant information. 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?
The presence of an output schema covers return values, and the readOnly annotation covers safety. However, the description is generic and does not specify which path or query parameters, if any, are valid for this particular endpoint, leaving the free-form arguments object underspecified for real usage.
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 contains only a generic 'arguments' object with additionalProperties and no property descriptions. The description compensates by explaining how to structure arguments (path variables directly, query values in arguments.params, body in arguments.body), which is essential for invoking the tool even though endpoint-specific keys are not listed.
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 explicitly names the HTTP method and endpoint (GET /notifications/targets), which clearly identifies the operation as listing notification targets. It is distinct from sibling CRUD tools like qui_create_notification_target and qui_delete_notification_target, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as qui_list_notification_events or qui_create_notification_target. The instructions focus on argument-passing mechanics, not selection criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds no behavioral context beyond the HTTP method and argument structure, such as pagination, response format, authorization requirements, or side effects. It neither contradicts nor enriches the annotation, but fails to disclose anything beyond what annotations already 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 that packs in the endpoint and the argument-passing convention without redundancy. Every phrase adds value, and the information is front-loaded with the resource identifier.
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 that an output schema exists (as indicated in context signals), the description need not explain return values. The description covers the essential invocation details: the endpoint, how to supply path/query/body data, and implicitly identifies variables via the URL template. It lacks explicit query parameter names, but the tool appears simple enough that the provided pattern likely suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden of explaining parameters. It provides a general rule (path vars in arguments, query in params, body in body) but does not enumerate the actual path variables or query parameters beyond the URL template. This is helpful for agents familiar with the API but incomplete for those without prior knowledge of the endpoint.
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 the exact HTTP endpoint (GET /dir-scan/directories/{directoryID}/runs/{runID}/injections), which makes the tool's function clear and distinguishes it from sibling tools that list other resources (e.g., runs, files). However, it frames the purpose as 'Call endpoint' rather than explicitly stating the result (e.g., 'List injections'), slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the argument-passing convention (path vars, query params, body) but provides no guidance on when to use this tool versus related tools like qui_list_scan_directory_runs or qui_list_scan_directory_files. It implies usage for retrieving injection data for a specific run but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, and the description confirms a GET request, which is consistent. The description adds the endpoint structure and argument passing convention, which is useful but does not disclose additional behavioral traits such as required path variables (e.g., instanceID), error conditions, or response characteristics. It neither contradicts annotations nor provides substantial extra transparency.
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, front-loaded with the endpoint, and each clause serves a purpose. No redundant information or fluff. The structure clearly separates endpoint specification from argument passing rules.
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 has an output schema, so return values need not be explained. However, the description omits critical context like the required 'instanceID' path variable, possible query parameters (e.g., pagination), or how to obtain a valid instance ID. For a simple listing operation, it is minimally viable but not fully complete given the unconstrained schema and no examples.
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 defines a single flexible 'arguments' object with no property descriptions (coverage 0%). The description compensates by explaining the internal structure of 'arguments' (path variables, query params, body), which is essential for the agent to invoke the tool correctly. It does not enumerate specific fields like 'instanceID' or query options, but the high-level guidance significantly adds meaning beyond 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 clearly identifies the resource and HTTP verb via the endpoint '/instances/{instanceID}/torrents/'. It is distinguishable from sibling tools like qui_list_cross_seed_runs. However, it focuses on the mechanics of the API call rather than explicitly stating the purpose ('list torrents for an instance'), though that is strongly implied by the endpoint and tool name.
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 invocation mechanics ('Pass path variables directly in arguments, query values in arguments.params...') but no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or why one would choose this over similar list tools. The 'how' is present, but the 'when' is absent.
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 annotation readOnlyHint: true is consistent with the description's 'GET' method, so there is no contradiction. The description adds the HTTP method and argument structure, but these are more about parameter semantics than behavioral disclosure. It does not mention potential response behavior, but the existence of an output schema reduces the need for that here. Overall, the description adds some value but does not go deeply 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?
The description is a single, dense sentence with no wasted words. It front-loads the endpoint and immediately explains the argument layout. Every clause contributes to the agent's understanding, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the generic schema and presence of an output schema, the description is partially complete. It explains how to structure arguments, but it omits any functional context (what a preview does) and does not explicitly identify required path variables. The endpoint placeholders imply instanceID and ruleName, but a fully complete description would state these explicitly. The output schema covers return values, so that omission is 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 input schema is a generic 'arguments' object with zero description coverage, so the description must carry the burden. It does so by explaining the mapping: path variables directly in arguments, query values in arguments.params, and a JSON body in arguments.body. This is essential but it stops short of listing the specific path variables (instanceID, ruleName) or query parameters, which the agent must infer from the endpoint URL. Still, this significantly compensates for the schema's lack of structure.
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 specific endpoint and HTTP method (GET /instances/{instanceID}/rss/rules/{ruleName}/preview), which distinguishes it from sibling RSS tools. However, it does not explain what the preview operation functionally does; the meaning is left to the tool name 'preview_rss_rule_matches'. Thus it is specific but not fully explicit about purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states how to call the endpoint, without explaining context, prerequisites, or exclusion criteria. For an agent choosing among many RSS- and preview-related tools, this lack of usage context 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?
The destructiveHint annotation already indicates destructive behavior, and the description's reference to DELETE is consistent. However, it adds no further behavioral context such as irreversibility, required permissions, or side effects, so it only minimally supplements the annotation.
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 clearly explains the argument structure without any redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the endpoint and argument structure but omits specifics about what identifies the RSS item to be removed (e.g., which path/query/body field) and any prerequisites. The presence of an output schema helps for return values, but input details remain ambiguous for a destructive 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 input schema is a free-form object with 0% coverage, so the description's explanation of how to structure arguments (path variables directly, query in params, body in body) is essential and adds significant meaning. It does not list the actual path variables or body fields needed, but it provides a crucial framework.
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 the specific HTTP DELETE method and resource path (/instances/{instanceID}/rss/items), which clearly implies removing an RSS item. It is specific but does not explicitly contrast with sibling tools like qui_move_rss_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only explains how to call the endpoint, not the circumstances or exclusions for using it.
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 annotation already flags destructiveHint=true, and the description adds the HTTP DELETE method, which is consistent. However, it does not disclose additional behavioral traits such as idempotency, what happens if the scan is not running, or whether results are deleted. With the annotation covering the safety profile, the description adds minimal extra value but does not contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with no filler. The first sentence states the endpoint, the second explains the argument structure. Every word earns its place, and the structure is front-loaded with the essential action.
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 cancellation endpoint with an output schema and a destructive hint, the description is fairly complete. It identifies the HTTP method, resource path, and argument-passing approach. However, it lacks explicit usage guidance and does not mention any conditions or side effects beyond the delete action. Given the simplicity of the operation and the presence of annotations, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic container with no specific parameter details. The description compensates by explaining how to pass path variables, query values, and a JSON body, providing a crucial convention for using the tool. It does not enumerate the specific parameters (e.g., directoryID), but the path template indicates the required variable. This is valuable beyond 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 clearly identifies the API endpoint with the DELETE method and a specific resource path, which maps directly to the tool's name 'cancel_directory_scan'. It implies cancellation of a scan but does not explicitly state 'use this to cancel a running directory scan,' leaving some room for interpretation. Still, it is specific enough to distinguish from sibling tools like 'scan_directory'.
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. It does not mention prerequisites, such as the scan needing to be in progress, or situations where this tool should be avoided. The description only explains how to construct the request, not the broader usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose whether the dry-run has side effects, what it returns, or any prerequisites. The word 'dry-run' implies non-destructive behavior but it is not explicitly stated.
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, direct, no filler. It front-loads the endpoint and gives structural guidance.
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 basic call mechanics, but lacks context on the purpose of dry-run, required path parameters, and what the response contains. The presence of an output schema mitigates the need for return details, but the overall contextual guidance is minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining how to structure arguments: path variables at top level, query parameters in arguments.params, and JSON body in arguments.body. This is essential given the schema is a generic object with 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls a specific POST endpoint for automations dry-run, distinguishing it from other automation tools like qui_apply_automations. It uses a specific verb and resource, making the action 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it should be used for testing automations without side effects, nor does it reference 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?
The readOnlyHint annotation already indicates a safe read operation, and the description does not contradict it. However, the description adds no behavioral details beyond the call syntax; it does not mention authentication requirements, response characteristics, or side effects. The annotation lowers the bar, but the description provides marginal extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the endpoint name. Every phrase earns its place, and there is 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?
Given the presence of an output schema and the readOnlyHint annotation, the description is fairly complete for a simple GET endpoint. It correctly identifies the endpoint and argument passing convention. However, it omits explicit mention that this returns the authenticated user's information, relying on the tool name for that.
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 a generic 'arguments' container with no property descriptions (0% coverage). The description compensates by explaining that path variables go directly, query values go in arguments.params, and the body goes in arguments.body. This provides essential semantics that the schema lacks.
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 explicitly names the endpoint 'GET /auth/me' and the tool name 'get_current_user' together imply retrieval of the current user. It is clear and specific, though it does not explicitly state what the endpoint returns or differentiate it from sibling tools like validate_session.
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 alternatives. The description only explains how to pass arguments, not when to invoke the tool or what context it is appropriate for.
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 mark the tool as read-only, so the description doesn't need to explain safety. It adds context about argument passing conventions (path vs query vs body), which is useful for invocation. However, it does not disclose any behavioral traits such as authentication requirements, response shape, or potential errors, leaving some burden unmet.
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 endpoint and immediately explains the argument structure. Every phrase is informative and there is no padding.
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 is a simple read-only GET with an output schema available, the description is largely sufficient. It covers how to invoke the request, and the readOnlyHint covers the safety aspect. It could be more complete by explicitly stating what the settings are used for or adding a note about when to use it, but for its simplicity it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is completely opaque (one generic 'arguments' object with no descriptions). The description compensates by explaining that path variables go directly, query values go under 'arguments.params', and the body under 'arguments.body'. This adds critical structural meaning beyond the bare schema, though it does not list specific 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 identifies the specific endpoint (GET /dir-scan/settings) and the HTTP verb, making it clear this retrieves directory scan settings. It distinguishes from sibling 'update' tools by emphasizing GET, though it could be more explicit about the tool's purpose rather than just saying 'Call endpoint'.
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. It does not mention that this should be used to fetch current settings, nor does it reference the comparable update tool (qui_update_dir_scan_settings). The only usage-related info is how to pass arguments, not when to choose it.
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, and the description states it's a GET call, which is consistent. The description adds no additional behavioral context such as side effects, authentication needs, or response specifics. The argument passing convention is more about parameter semantics than behavioral transparency. 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?
The description is a single, front-loaded sentence that directly states the endpoint and argument passing rules. There is no fluff or redundancy. It is appropriately sized for a simple API wrapper tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return-value details are not needed. The main gap is the lack of explicit identification of required path variables (instanceID) and clarification of what 'app-info' returns versus other instance-related tools. The description is adequate for a straightforward endpoint call but leaves room for ambiguity in a large sibling set.
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 zero documentation for parameters (only a generic 'arguments' object). The description provides a structural pattern for passing path variables, query values, and body, which partially compensates. However, it does not name specific required parameters like instanceID, leaving the agent to infer from the URL template. This is minimal but non-zero value.
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 the exact endpoint (GET /instances/{instanceID}/app-info), making the tool's purpose clear: retrieving application info for an instance. It does not explicitly explain what 'app-info' contains or differentiate from sibling tools like qui_get_instance_capabilities, but the endpoint name and method provide a strong clue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to pass arguments (path variables directly, query values in arguments.params, body in arguments.body), which is useful for invocation. However, it does not indicate when to choose this tool over alternatives, nor does it mention any prerequisites or conditions. Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description's GET method aligns. The description adds the argument-passing convention (path variables, query in params, body), which is essential for invoking the tool correctly. It does not contradict annotations and provides a small but useful extra context beyond the schema and 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 that front-loads the endpoint and gives a clear instruction structure. Every word earns its place, with no redundancy or unnecessary 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?
The description is generic to all qui API calls and lacks resource-specific context, such as what an ARR instance is or that this lists all configured instances. Since an output schema exists, return details are not needed from the description, but the tool-specific context is thin. It is minimally complete for a simple read-only operation but leaves room for uncertainty about the exact purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a single open-ended 'arguments' property with 0% description coverage. The description provides a generic structural convention for passing parameters, but doesn't identify endpoint-specific parameters or expected values. This partially compensates for the missing schema details, but the information is generic to all qui_* API tools rather than specific to this operation.
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 'Call qui's GET /arr/instances endpoint', which clearly identifies the HTTP verb and resource path. Although it doesn't literally say 'list ARR instances', the tool name and endpoint path make the purpose unambiguous. It is specific to ARR instances, distinguishing it from generic instance tools like qui_list_instances.
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 siblings like qui_get_arr_instance or qui_list_instances. The description only explains how to call the endpoint, not the appropriate context or alternatives. Given the extensive sibling list, this 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already conveys the read-only nature. The description adds only a generic note about argument structure, with no behavioral specifics like response format, pagination, or error handling. It does not contradict the annotation, but adds minimal value beyond it.
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. It states the endpoint and the argument-passing convention without unnecessary detail, earning its place 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 simple GET list endpoint, the description is adequate but bare. It does not mention that this returns a list of external programs or clarify whether any query parameters are expected. The presence of an output schema covers return values, but the lack of endpoint-specific call details limits completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no descriptions (0% coverage). The description explains that path variables, query parameters, and body can be passed within 'arguments', which adds some structure beyond the schema. However, it provides no endpoint-specific parameters for this list operation, so compensation is partial.
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 identifies the tool as calling the GET /external-programs/ endpoint, which is a specific verb and resource. It distinguishes from sibling tools like qui_create_external_program, qui_update_external_program, etc., by implying a read-only list operation.
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 lists external programs via HTTP GET. However, it does not explicitly state when to use this over alternatives or mention exclusions. The context of sibling tools hints at the distinction, but the description itself provides no direct comparison.
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 provide readOnlyHint=true, and description adds the HTTP method and argument passing conventions. However, it doesn't disclose response format, pagination, or any side effects, though none are expected for a read-only GET.
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 sentence, no filler, front-loads the endpoint.
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 has an output schema, but the description omits usage context and any specific parameters. It's minimally sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is an open 'arguments' object with no descriptions. The description explains how to pass path variables, query values, and body within arguments, which adds structure. Yet it lacks endpoint-specific parameter details and uses generic boilerplate that may not apply to /logs/files.
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 explicitly names the GET /logs/files endpoint, making the resource and operation specific. Combined with the tool name qui_list_log_files, it clearly differentiates from siblings like qui_get_log_settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternative log-related tools. It only provides invocation mechanics, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only reveals that this is a PATCH (mutation). It does not disclose authentication requirements, side effects on the settings, or response behavior. This is similar to the update_drive example that scored 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the endpoint and then explains the argument mapping in a clear, structured manner.
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 core calling convention, but it omits prerequisites (e.g., authentication) and does not clarify what the request body should contain for a PATCH. Given the generic schema and lack of annotations, more context would help, though the existence of an output schema lessens the need to describe return values.
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 is generic (an empty object with additionalProperties), and the description compensates by explaining how to structure arguments: path variables directly, query values in arguments.params, and body in arguments.body. This is essential and goes beyond the schema, though it doesn't enumerate specific fields.
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 HTTP verb (PATCH) and the exact resource (/cross-seed/search/settings), which distinguishes it from sibling tools like qui_get_cross_seed_search_settings. The purpose is specific and actionable.
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 alternatives such as qui_get_cross_seed_search_settings or qui_update_cross_seed_settings. It only explains how to call the endpoint, not the conditions that warrant a PATCH vs. a GET or full update.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the destructiveHint annotation. It does not mention permanence, permissions, side effects, or what exactly gets destroyed. Since the annotation already signals destructiveness, the description provides no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the endpoint and parameter-passing conventions. It is front-loaded with the action and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool, the description covers the endpoint and parameter structure, but omits explicit mention of required path variables, whether query/body are needed, and any prerequisites or error scenarios. The output schema may address return values, but usage context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining how to pass path variables, query values, and body within the arguments object. However, it does not specify the exact keys (instanceID, ruleName) or expected query/body content, leaving significant room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls a DELETE endpoint for RSS rules, unambiguously indicating removal of a specific rule. It distinguishes from sibling tools like qui_get_rss_rules and qui_rename_rss_rule by focusing on deletion.
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 via the DELETE method, but provides no explicit when-to-use guidance or exclusions. It does not mention alternative tools or conditions under which this tool should be selected, leaving the agent to infer based on the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only mentions the HTTP method (PUT) and argument structure, but omits side effects such as session invalidation, authentication requirements, or reversibility. This is a significant gap for a mutation-like operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each dedicated to a specific aspect: the endpoint and the argument structure. It is concise, front-loaded, and contains no irrelevant 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?
The description covers how to invoke the endpoint (argument structure) but fails to state the tool's purpose explicitly or disclose any behavioral consequences. The endpoint name 'change-password' hints at functionality, and an output schema exists, but the description is minimal for a password-changing operation. It is adequate but leaves the agent to infer intent and effects from the tool 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?
The input schema is extremely generic (a free-form object with 0% coverage), so the description's guidance on how to distribute path variables, query values, and body across the arguments object adds meaningful structure. Without this, the agent would have no clue how to construct the request, making this a strong compensatory 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?
The description clearly identifies the tool as calling the PUT /auth/change-password endpoint, which signals the purpose of changing a password. It distinguishes from sibling tools by referencing a unique endpoint, though it phrases the action as 'call endpoint' rather than explicitly stating 'change password'.
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 explicit instructions on how to structure arguments: path variables directly, query values in arguments.params, and a JSON body in arguments.body. This gives clear usage context for invoking the tool. It doesn't mention alternatives, but no sibling tools serve the same password-change purpose, so this is acceptable.
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 indicate readOnlyHint=true, and the description adds value by explaining the argument passing convention (path variables, query in params, body in body). However, it doesn't disclose any other behavioral traits such as error handling, required authentication, or return structure beyond what output schema 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?
Two sentences, front-loaded with the endpoint, and every word adds value. No filler or unnecessary repetition; it efficiently conveys the purpose and the argument structure.
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 GET with a read-only annotation and output schema, the description covers the essential calling convention. However, it omits what application info is returned and doesn't distinguish this tool from the closely related 'qui_get_instance_app_info', leaving a gap in contextual understanding. It's adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is extremely vague (just an open 'arguments' object with additionalProperties), so the description carries the full burden for parameter understanding. It clearly maps arguments to HTTP components: path variables directly, query values in 'params', and a JSON body in 'body'. This is essential and fully compensates for the schema's lack of detail.
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 resource ('GET /application/info endpoint') and the action ('Call'), making it distinct from other tools. However, it doesn't explain what 'application info' contains or differentiate it from the similar sibling 'qui_get_instance_app_info', so it's slightly incomplete.
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 only explains how to structure arguments (path, query, body), but gives no guidance on when to use this tool vs alternatives. Notably, it doesn't mention that 'qui_get_instance_app_info' might be more appropriate for instance-specific information, so no exclusions or alternative tool references are 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?
The readOnlyHint annotation already indicates a non-mutating operation, lowering the burden on the description. The description adds the endpoint and how to pass arguments (path variables, query values, body), but does not disclose additional behavioral aspects such as authentication requirements or error conditions. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the endpoint and provides the argument-passing convention. It is efficient and avoids unnecessary fluff, though it could be slightly more informative without losing conciseness.
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?
Although an output schema exists (so return values are covered), the description omits endpoint-specific parameter requirements and includes a generic 'request body' instruction that is irrelevant for a GET request. Given the sparse schema and annotations, this description is too generic to enable correct invocation without additional inference.
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% with a generic 'arguments' object, so the description must compensate. It provides a general convention for passing path variables, query values, and body, but does not specify what path variables (beyond the implicit instanceID) or query parameters this endpoint accepts. The agent is left without concrete parameter names or required fields.
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 explicitly identifies the target endpoint (GET /instances/{instanceID}/categories) and the resource (categories), making the tool's purpose unmistakable. It also distinguishes itself from sibling tools like qui_create_category, qui_edit_category, and qui_remove_categories by focusing on the GET operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool fetches categories for a specific instance, but it does not explicitly mention when to use this tool versus alternatives or provide exclusions. The read-only nature and endpoint make the usage obvious, but explicit guidance is absent, so it falls at 'clear context, no exclusions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the readOnlyHint annotation already provides. It states the HTTP method (GET) which aligns with the annotation but does not mention authentication, response format, error handling, or any other operational traits. Since the annotation already covers safety, there is no extra transparency contributed.
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 constructed sentence that front-loads the endpoint and then provides the parameter-passing convention. There is no redundant or vacuous wording; every clause carries necessary 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?
The description adequately covers the generic pattern for a GET endpoint and relies on the output schema for return details. However, it does not specify which path, query, or body parameters this particular endpoint expects, leaving the agent dependent on external API knowledge to populate arguments. This is a clear gap for a self-contained tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic free-form 'arguments' object with 0% property description coverage. The description fully compensates by explaining the critical convention: path variables go directly in arguments, query values in arguments.params, and a JSON body in arguments.body. This is essential for constructing valid calls and goes far beyond the schema's minimal information.
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 identifies the tool as a wrapper for the GET /dashboard-settings endpoint, specifying the HTTP verb and resource. This distinguishes it from sibling tools like qui_update_dashboard_settings, which performs the opposite operation. The purpose is unambiguous and directly tied to the tool name.
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 provide any guidance on when to use this tool relative to alternatives. It focuses entirely on how to structure arguments (path, query, body) but omits context such as 'use this to retrieve dashboard settings' or when this is preferable to other tools. Usage is only implied by the endpoint 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?
The readOnlyHint annotation already signals a safe read operation, and the description adds that it's a GET request and explains how arguments map to path, query, and body. This adds some behavioral context beyond the annotation, but does not cover response details, authentication requirements, or error conditions. 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, front-loaded with the core purpose, followed by a compact instruction for argument construction. No redundant phrasing 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?
The tool has an output schema and a generic arguments object; the description covers the invocation pattern for path, query, and body, which is sufficient for a simple endpoint wrapper. However, it does not provide details on the specific parameters or expected payload for tracker-icons, so the agent must rely on external knowledge of the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by specifying how the single 'arguments' field should be used: path variables directly, query values in arguments.params, and a JSON body in arguments.body. This gives essential meaning to an otherwise opaque catch-all parameter, though it does not enumerate the specific parameters accepted by the endpoint.
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 explicitly states the tool calls the GET /tracker-icons endpoint, naming both the HTTP method and resource. This is specific enough to distinguish it from sibling tools that target other qui endpoints, though it stops short of describing the functional outcome (e.g., 'list available tracker icons').
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—whenever you need to interact with the tracker-icons endpoint—but it offers no explicit guidance on alternatives or conditions for use. The naming and endpoint path provide context, but there is no discussion of when not to use this tool or how it differs from other qui 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?
The readOnlyHint annotation already covers the safety profile, and the description's mention of GET is consistent. The description adds context about argument passing (path vs query vs body), which is useful but not behavioral. It doesn't describe pagination, return format, or side effects, but annotations lower the bar.
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 with the endpoint and immediately explains argument structure. Every word earns its place; there is no fluff or 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?
The tool has an output schema, so return values are covered. The main gap is that the description doesn't list specific path variables or query parameters accepted by this endpoint. For a simple list endpoint, the generic argument structure may suffice, but it leaves the agent to infer what to put where.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only a generic 'arguments' object with no field descriptions (0% coverage). The description fully compensates by explaining how to structure arguments: path variables directly, query values in arguments.params, and body in arguments.body. This is essential and unambiguous.
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 explicitly identifies the endpoint (GET /notifications/events) and implies the list action via the tool name and HTTP method. It distinguishes from siblings like qui_list_notification_targets by pointing to a different resource, though it doesn't explain what a 'notification event' is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states how to make the call, not when it's appropriate or what it's best used for. There is no mention of alternative tools 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?
The annotation already marks this as destructive, so the description doesn't need to repeat that. The description adds minimal behavioral context beyond the annotation, including the HTTP DELETE method and the instruction to pass path variables, but no details on effects or irreversibility. It doesn't contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with the most important information (endpoint and purpose) first. Every sentence adds value and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructiveness and the need to specify instance ID, torrent hash, and tracker list, the description is incomplete. It doesn't mention what the request body should contain, doesn't give an example, and relies on the annotation for destructive awareness. The generic arguments schema with no property definitions leaves the agent with insufficient guidance to construct a valid call, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions (0% coverage) and only a generic 'arguments' object. The description compensates by explaining that path variables go directly in arguments, query values in arguments.params, and body in arguments.body. However, it doesn't specify the actual path variable names (instanceID, hash) or the expected body structure for the trackers to be removed, leaving some ambiguity.
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 identifies the tool as calling the DELETE endpoint for removing trackers from a torrent, with the path structure exposed. The verb 'DELETE' and the name 'remove_torrent_trackers' make the purpose unambiguous and distinguish it from sibling tools like add or edit trackers.
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 doesn't explicitly say when to use this tool versus alternatives. It only describes the API call mechanics. There is no mention of situations where removal is appropriate or alternative tools like qui_edit_torrent_tracker for modifying trackers. The usage is implied by the name and endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only explains how to pass arguments (path, query, body) but does not state what the test action does, whether it is read-only or has side effects, or what kind of response to expect. This is a significant gap for a mutation-like 'test' endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the endpoint, and every word earns its place. No fluff, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is incomplete for safe and correct use. It omits the purpose/effect of 'test' (e.g., connectivity check, configuration validation), any side effects, and required path variables are only implied. The generic schema and absent annotations leave the description as the main source of context, and it does not fully cover the 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 schema is completely generic (a single `arguments` object with no properties). The description compensates by providing a clear convention: path variables directly in arguments, query values in arguments.params, and JSON body in arguments.body. This adds meaningful structure beyond the empty schema, though it does not enumerate specific fields like instanceID.
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 explicitly names the target resource and action: 'Call qui's POST /instances/{instanceID}/test endpoint.' This clearly identifies testing a specific instance, and the path distinguishes it from sibling tools that test other resources (arr, torznab, notification targets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternative exclusions are given. The usage is implied by the endpoint name and path, but the description does not contrast with other test tools or state prerequisites. It is adequate but relies on 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 include destructiveHint=true, and the description confirms the DELETE endpoint. However, the description adds no further behavioral context, such as permanence, required permissions, or side effects. It neither contradicts annotations nor adds meaningful transparency beyond what the structured hint 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 two concise sentences with no filler. The first sentence identifies the endpoint, the second gives parameter-passing conventions. Every word earns its place, and it is appropriately 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?
The description is adequate for invoking the endpoint but omits key contextual details: it never explicitly says the tool deletes an automation, does not name the required path variables (instanceID, ruleID), and does not mention the destructive consequence beyond what annotations imply. Given the output schema exists, return values are covered, but the missing explicit statement of purpose and required parameters leave a 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?
With schema coverage at 0% and a generic 'arguments' object, the description provides essential structure: 'Pass path variables directly in arguments, query values in arguments.params, and a JSON request body in arguments.body.' This compensates for the schema's opacity by explaining how to organize path, query, and body components, though it stops short of naming the specific required variables.
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 explicitly states 'Call qui's DELETE /instances/{instanceID}/automations/{ruleID} endpoint', which precisely identifies the action (DELETE), the resource (automations), and the path structure. This clearly distinguishes it from sibling tools like qui_create_automation or qui_update_automation.
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 how to structure arguments (path/query/body) but provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites like needing an instanceID and ruleID, nor does it reference the preview tool (qui_preview_automation_delete) for safe verification. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals a safe read operation, and the description's explicit 'GET' matches that. However, it adds little behavioral context beyond the annotation—no mention of auth requirements, rate limits, response shape, 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?
One sentence conveys the endpoint and argument-passing convention with no filler or redundancy. Every part 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?
The output schema covers return format and the annotation covers safety, but the description omits specific parameter names and usage caveats. For a simple GET with a generic input schema, it is minimally viable but not fully self-contained.
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 generic (only an 'arguments' object with no properties), so the description must compensate. It explains that path variables go in arguments, query values in arguments.params, and a JSON body in arguments.body—valuable structure not present in the schema. It stops short of naming 'instanceID' explicitly, but the endpoint template makes that inferable.
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 endpoint 'GET /instances/{instanceID}/mediainfo' with a clear verb and resource, making it easy to distinguish from sibling tools like qui_get_torrent_file_mediainfo or qui_get_instance_capabilities. It also specifies the argument-routing convention.
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, nor any mention of prerequisites or exclusions. The description focuses entirely on invocation mechanics rather than selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it's a GET request, which aligns with the readOnlyHint annotation, but adds little beyond that. It doesn't disclose response structure or any side effects, though the output schema covers return values.
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 endpoint and then clearly explains the argument structure. 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?
Given the tool is a thin wrapper and the output schema exists, the description sufficiently covers the invocation pattern. It lacks explicit mention of what the response contains, but the output schema compensates, making this complete for a simple GET tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description provides a crucial convention for passing path variables, query values, and body, which adds significant meaning beyond the loose 'arguments' schema. It doesn't list actual parameters, but the generic pattern is essential for invocation.
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 the exact endpoint for fetching torrent properties, making the tool's purpose clear through the resource path. It distinguishes from sibling tools like qui_get_torrent_field or qui_get_torrent_trackers, although it doesn't explicitly state 'retrieves torrent properties'.
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 by the endpoint name and the generic call instructions, but there is no explicit guidance on when to prefer this tool over alternatives or any prerequisites. The sibling list provides context but the description itself doesn't clarify 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?
The readOnlyHint annotation already declares the operation as read-only, lowering the bar. The description adds the HTTP method (GET) and endpoint context, but does not disclose additional behavioral details like required authorization or error conditions. This meets the baseline but adds no extra depth.
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 efficiently conveys the endpoint and parameter structuring rules with no redundant information. It is well-sized for the tool's simplicity.
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 essential invocation pattern despite the generic schema, and the presence of an output schema means return values need not be documented. However, mentioning a JSON request body for a GET endpoint is atypical and could mislead; it also fails to explicitly state that instanceID and hash are required path parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with zero property descriptions, so the description's instruction to place path variables, query values, and body in specific argument fields adds necessary structure. However, it does not name the path variables (instanceID, hash) or any query/body fields, requiring inference from the endpoint URL.
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 explicitly names the exact endpoint (GET /instances/{instanceID}/torrents/{hash}/trackers), making the verb and resource unambiguous. This clearly distinguishes it from sibling tools like qui_get_torrent_peers or qui_get_torrent_files.
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 trackers for a specific torrent need to be retrieved, but does not explicitly state when to use this tool versus alternatives. It focuses on argument structuring rather than providing selection 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?
The description adds useful behavioral context by specifying the HTTP method (PUT) and how to structure arguments (path, query, body), which is valuable given no annotations. However, it does not disclose side effects, idempotency, or required permissions, leaving transparency incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences convey the endpoint and the exact argument structure. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides complete invocation details for the single arguments parameter, and an output schema exists to cover return values. However, it lacks an explicit business-purpose statement and usage context, which is notable given no annotations and similar sibling tools for create/delete operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no defined properties (0% coverage). The description fully compensates by explaining that path variables go directly in arguments, query values in arguments.params, and the request body in arguments.body—making the parameter usage unambiguous and complete.
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 the specific PUT endpoint for automations, making it clear the tool updates an automation. However, it does not explicitly state 'updates an automation' or contrast with create/delete, relying on the endpoint and name for clarity.
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 creating or deleting automations. It only explains how to format the request, missing usage context such as prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true, and the description adds no further behavioral context such as irreversibility, side effects, or required permissions. The only additional information is the argument-passing convention, which does not pertain to behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no redundant wording. Every sentence provides distinct useful 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 thin REST wrapper, the description adequately specifies the endpoint and argument structure. The output schema and destructiveHint annotation cover response and safety aspects. Minor omissions (e.g., explicit statement of required id) are largely covered by the endpoint path.
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 is generic with a single 'arguments' property and 0% parameter coverage. The description compensates by explaining that path variables go directly in arguments, query values in arguments.params, and JSON body in arguments.body. This provides essential structure for constructing the call, even though it does not enumerate specific fields like 'id'.
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 precisely identifies the action as calling the DELETE /api-keys/{id} endpoint, clearly conveying that this tool deletes an API key by ID. This distinguishes it from sibling tools such as qui_create_api_key and qui_list_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to delete an API key via the endpoint, but it does not explicitly state when to use it vs alternatives or provide exclusions. The parameter-passing instructions are useful for invocation but not for selection 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?
The description repeats the destructive nature via 'DELETE' but adds little beyond the destructiveHint annotation. It does mention that a JSON request body can be passed, which is a mild behavioral detail, but it does not disclose side effects, irreversibility, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the endpoint and then provides concise argument-passing rules. Every clause is necessary and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the open schema and presence of an output schema, the description covers the invocation pattern but does not explicitly identify that the path variable is the customization ID. This is a notable gap, though the tool name hints at it. Additional context about the resource being deleted would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is a generic 'arguments' object with no defined properties. The description compensates fully by explaining the argument convention: path variables go directly in arguments, query values in arguments.params, and body in arguments.body. This is essential for correct invocation and goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it calls the DELETE /tracker-customizations/{id} endpoint, making it clear the tool deletes a tracker customization. This distinguishes it from sibling tools like qui_create_tracker_customization and qui_update_tracker_customization by the delete operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as the customization needing to exist, nor does it contrast with create/update operations. The usage context is only implied through the endpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates the operation is safe/non-destructive. The description adds the fact that it is a GET request and explains argument passing conventions, but does not disclose any additional behavioral traits such as response structure, pagination, or error handling. With annotations covering safety, this is a minimal but acceptable contribution.
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, no fluff. It clearly states the endpoint and the argument-passing convention. Every word earns its place, and the structure is easy to 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 simple GET endpoint with an output schema available, the description is sufficient to invoke the call correctly. It does not describe the return value, but the output schema presumably handles that. The only minor gap is not clarifying that the request body is likely unnecessary for a GET, but the generic instruction is not misleading.
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 is generic (a single free-form 'arguments' object) with 0% parameter coverage. The description adds crucial meaning by specifying where path variables, query parameters, and the request body should go. This is essential for correctly invoking the tool, so it compensates for the schema's lack of detail.
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 identifies the specific endpoint ('GET /cross-seed/status') and the resource being accessed. It distinguishes this from sibling tools like qui_get_cross_seed_async_status or qui_get_instance_cross_seed_status by naming the exact endpoint path.
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 how to pass arguments (path, query, body) but gives no guidance on when to use this tool versus alternatives such as qui_get_cross_seed_async_status or qui_get_cross_seed_local_matches. No context or exclusions are provided, leaving the agent to infer the use case from the endpoint name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the read-only nature, and the description's explicit GET statement reinforces it. However, it adds no additional behavioral context such as authentication requirements, error handling, or response format. With annotations present, minimal extra value is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the endpoint and then explains the argument passing convention. No wasted words 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?
The description is sufficient for a simple GET operation: it names the endpoint and explains argument structure. The output schema exists, so return values are covered. Minor gaps include lack of prerequisites (e.g., how to obtain instanceID) and authentication context, but these are not critical for a straightforward read 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 a generic 'arguments' object with additionalProperties, providing no parameter structure. The description compensates by explaining how to pass path variables directly, query values in arguments.params, and a JSON body in arguments.body. This adds significant meaning beyond the schema, though it doesn't enumerate specific path variables beyond the endpoint's instanceID.
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 explicitly states the tool calls the GET /instances/{instanceID}/preferences endpoint, identifying the verb and resource. It distinguishes from sibling tools like qui_update_preferences by the HTTP method. This meets the 5= specific verb+resource criterion.
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 no explicit when-to-use guidance or mention of alternatives. Usage is implied from the GET verb and endpoint path, but there are no exclusions or explicit context about when this is appropriate versus qui_update_preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds no extra behavioral context (e.g., response format, side effects, or rate limits) beyond the mere fact that this is a GET endpoint, which adds little beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that immediately state the endpoint and the parameter-passing convention. There is no extraneous information, and the most important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema is present and the tool is a simple status fetch, the description sufficiently covers the endpoint and argument structure. It could be slightly more explicit about the required path variable, but the URL placeholder and the explanation of 'path variables directly in arguments' make it complete enough for correct 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 input schema is a generic 'arguments' object with zero specific fields. The description crucially explains that path variables are placed directly in 'arguments', query values in 'arguments.params', and the body in 'arguments.body', compensating for the schema's lack of detail. The specific {directoryID} is visible in the endpoint URL, providing adequate semantic information.
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 precisely names the HTTP method and endpoint (GET /dir-scan/directories/{directoryID}/status), making the tool's purpose unambiguous and differentiating it from siblings like qui_get_scan_directory or qui_list_scan_directory_runs which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to call the endpoint but does not specify when to use it versus alternatives such as qui_list_scan_directory_runs. Usage context is implied by the name and endpoint, but no explicit guidance or exclusions are 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?
The readOnlyHint annotation already establishes this is a safe read operation. The description adds that it is a GET request and explains the argument-passing convention. However, it does not disclose potential error behavior, response format, or any special conditions beyond that.
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 is front-loaded with the endpoint and then gives clear argument conventions. No wasted words or 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?
Given the output schema exists, return values are covered elsewhere. The description sufficiently explains input structure and the endpoint path, allowing an agent to infer the required path variables. It could be more complete by listing those variables explicitly or noting any required query parameters, but it is adequate for a simple GET wrapper.
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 entirely generic with a single 'arguments' object and no specific parameter definitions. The description compensates by explaining that path variables go directly, query values under arguments.params, and JSON body under arguments.body. This is critical given the 0% schema coverage, though it does not enumerate the exact variables for this 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 identifies a specific operation: calling the GET endpoint for torrent file mediainfo. It names the exact resource path with variables, making it distinct from sibling tools like qui_get_instance_mediainfo or qui_get_torrent_properties.
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. It only explains how to structure the call, not the intended use case or any prerequisites. No references to if the file index is required or how to obtain it.
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 mark readOnlyHint=true, and the description's GET endpoint aligns. It adds the argument-passing convention (path vs query vs body) which is useful, but doesn't describe response behavior or error conditions beyond what the output schema covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first identifies the endpoint and operation, second explains the argument structure. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only GET with an output schema, the description covers the key invocation pattern. It could be improved by explicitly naming the required path variables, but the endpoint template makes them inferable.
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?
Input schema has only a generic 'arguments' object with 0% coverage, so the description's instruction to pass path vars directly in arguments, query values in arguments.params, and body in arguments.body adds essential structure. However, it doesn't enumerate the specific path parameters (instanceID, hash) or any query options, leaving the agent to infer them from the endpoint URL.
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 states it calls the dedicated webseeds endpoint for a torrent, clearly distinguishing it from sibling tools like qui_get_torrent_peers or qui_get_torrent_files. The verb 'GET' and resource path specify exactly what is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to choose this over other torrent sub-resource tools; usage is implied by the endpoint name. It provides no alternatives or exclusions, though the purpose is clear from the endpoint.
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 declare readOnlyHint=true and the description's GET method aligns without contradiction. The description adds some context about how to structure path, query, and body arguments, but does not disclose behavioral details such as pagination, filtering, or auth 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?
The description is a single sentence that starts with the endpoint and provides directly actionable instructions without unnecessary 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?
This is a simple read-only list operation and an output schema exists, so return value expectations are covered elsewhere. The description gives the endpoint and argument convention, but omits any mention of optional query parameters or auth dependencies.
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 an opaque arguments object with 0% property coverage, so the description's guidance on where to place path variables, query values, and body is essential. This compensates for the schema gap, though it lacks filter-view-specific parameter names.
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 explicitly identifies the GET operation on the /filter-views/ endpoint, which clearly conveys listing filter views. It distinguishes this tool from sibling create/update/delete filter-view operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description only explains how to call the endpoint, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: true already conveys the safe read-only nature of this tool. The description adds the endpoint context (GET) but does not disclose additional behavioral traits such as response structure, pagination, or error behavior. Given the annotation, the description adds minimal but sufficient context, so a mid-range score 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?
The description is a single, concise sentence that is front-loaded with the endpoint and follows with concrete instructions on argument handling. Every phrase adds value; there is no filler or 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?
Given the existence of an output schema, the description does not need to explain return values. It covers the invocation pattern thoroughly for a simple GET tool. However, it omits any note about required path variables (instanceID, hash) being mandatory, which would be useful for the agent to know, though it is inferable from the endpoint path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0% and a generic 'arguments' object, the description compensates well by explaining the argument structure: path variables directly, query values in 'arguments.params', and JSON body in 'arguments.body'. This is essential semantic information beyond the empty schema, and it clearly maps to the endpoint's variables.
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 specifies the tool's function: calling the GET /instances/{instanceID}/torrents/{hash}/files endpoint, which indicates retrieval of torrent file listings for a given instance and hash. This is a specific verb+resource that distinguishes it from sibling tools like qui_get_torrent_properties or qui_get_torrent_trackers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only explains how to structure arguments, but does not mention use cases, prerequisites, or exclusions. There is no explicit 'when to use' or comparison with 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?
The destructiveHint annotation already informs the agent that this is destructive, so the description doesn't need to repeat that. The description adds the HTTP method (DELETE) but does not disclose any side effects, irreversible actions, or permission requirements. 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?
Two short sentences, no redundant phrasing, and front-loaded with the key information (the endpoint). Every word serves a purpose, and the structure is clear and direct.
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 delete operation with a destructive annotation and an output schema, the description sufficiently explains the invocation pattern. It covers the HTTP endpoint and the argument conventions, which is the main challenge given the generic schema. It doesn't elaborate on return values, but the output schema presumably covers that.
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 is generic with a single 'arguments' object and no property descriptions (0% coverage). The description compensates by explaining how to pass path variables, query values, and request body (arguments.params and arguments.body). This is essential for invoking the tool correctly, though it doesn't enumerate specific parameter names (e.g., id).
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 explicitly names the HTTP endpoint ('DELETE /external-programs/{id}') and states the action (call the endpoint), clearly identifying it as the operation to delete an external program. This distinguishes it from sibling tools like qui_list_external_programs, qui_create_external_program, and qui_update_external_program.
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 by the name and endpoint (it's the delete operation for external programs), but no explicit guidance is given about when to use this versus alternatives, prerequisites (e.g., ID must exist), or consequences. The description focuses on how to structure the call rather than when to use it.
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, and the description's 'GET' confirms a read operation. No additional behavioral context (side effects, scope, auth) is provided, which is acceptable for a simple fetch but adds little beyond the annotation.
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 sentence, front-loaded with the endpoint, 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?
Given the simple GET operation and the presence of an output schema, the description covers invocation essentials. It doesn't enumerate specific endpoint parameters, but the generic argument convention is sufficient for a basic settings fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with a single free-form 'arguments' property. The description compensates by explaining how to route path variables, query values, and request body, which is essential for correctly invoking 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 clearly states the tool calls the GET /cross-seed/settings endpoint, specifying the verb and resource. This distinguishes it from sibling tools like update or patch settings, even though it doesn't name them explicitly.
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?
It provides no explicit guidance on when to choose this tool over alternatives, but implies it's for reading cross-seed settings. The argument-structuring advice is more about invocation than 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, and the description does not contradict it. The description adds no behavioral context beyond the HTTP method, such as permissions, rate limits, or side effects. With annotations covering safety, a neutral score 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?
Single sentence, front-loaded with endpoint, and no fluff. Every clause is informative for making the call. Excellent conciseness.
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 output schema exists, return values don't need description. The endpoint and argument-structuring conventions are clear. Minor gap: doesn't explicitly state which placeholders are path variables, but they are visible in the endpoint itself. Adequate for a simple GET.
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 generic with only an 'arguments' object and no property descriptions (0% coverage). The description compensates by explaining how to structure arguments: path variables directly, query values in arguments.params, body in arguments.body. However, it doesn't list the specific required fields (instanceID, hash) or query/body parameters for this 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?
Description explicitly states it calls the GET /instances/{instanceID}/torrents/{hash}/pieces endpoint, naming the exact resource and action. This distinguishes it from sibling tools like qui_get_torrent_peers and qui_get_torrent_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use vs alternatives. The endpoint and name imply it's for retrieving torrent piece information, but there's no mention of exclusions or alternative tools. The usage is implied rather than 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?
The annotation readOnlyHint=true already signals a safe read operation. The description adds no behavioral details beyond the call mechanics—no mention of return format, scope, permissions, or side effects. With annotations covering the safety profile, this is acceptable but minimal.
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, directly informative sentence. It is front-loaded with the endpoint and provides the necessary parameter-passing convention in a compact way, with every word adding value.
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 GET endpoint with no required parameters, the description covers the argument structure but omits any possible query parameters or path variable specifics. Since the output schema exists, return values need not be explained, but the lack of optional parameter details leaves a gap for the agent to know what filters might be available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is a generic 'arguments' object with no property descriptions. The description significantly compensates by explaining exactly how to structure arguments: path variables directly, query values in arguments.params, and a JSON body in arguments.body. This is crucial operational guidance absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly names the endpoint 'GET /tracker-customizations/' and the HTTP verb, making it clear this tool lists tracker customizations. It distinguishes from sibling create/update/delete tools by its GET method and collection resource.
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 does not explicitly state when to use this tool vs alternatives, but the endpoint and name imply it is for retrieving tracker customizations. It lacks explicit context like 'use this to list all existing customizations' or any mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds the important behavioral convention for passing arguments: path variables directly in arguments, query values in arguments.params, and body in arguments.body. This goes beyond the schema/annotations by explaining how the tool expects inputs, which is valuable for correct invocation. 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 two concise sentences, each providing essential information: the endpoint to call and how arguments should be structured. No unnecessary words, fluff, or repetition of schema data. It is front-loaded with the core purpose and immediately followed by usage mechanics.
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 GET-by-ID tool, the description covers the essential invocation details (path/query/body structure) and the read-only nature is known from annotations. An output schema exists, so return values are documented elsewhere. The only minor gap is that it leaves the agent to deduce from the endpoint path that this retrieves a specific instance, but the tool name and path make that clear 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?
The input schema is generic (an 'arguments' object with no defined properties), providing 0% coverage. The description compensates by explaining the argument-passing structure (path/query/body). However, it does not enumerate the specific path variables or query parameters required, leaving the agent to infer from the endpoint path that an 'id' is needed. Still, it adds meaningful semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls the GET /arr/instances/{id} endpoint, which unambiguously indicates retrieving a specific ARR instance by ID. This distinguishes it from siblings like qui_list_arr_instances (list) and create/update/delete mutations. The verb 'get' and the resource path are specific and clear.
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 this tool (when you have an ID to fetch a specific instance) by referencing the path template, but it does not explicitly compare with alternatives or state when not to use it. There is no mention of using qui_list_arr_instances for listing all instances or the mutation tools for changes, so usage 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by explaining the argument-passing convention: path variables go directly in arguments, query values in arguments.params, and body in arguments.body. This is a behavioral trait of the generic HTTP client wrapper, and it is consistent with the GET method and readOnlyHint.
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 directly states the endpoint and the argument-passing rules. Every phrase is necessary, with no redundancy or superfluous 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 straightforward GET settings endpoint with an output schema, the description provides the essential invocation details: method, path, and argument organization. It does not describe the response format, but the present output schema likely covers that. The lack of mention of authentication or extra requirements is acceptable given the readOnlyHint and simplicity of the 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?
With 0% schema description coverage, the description is the sole source for parameter structure. It explicitly describes how to map path variables, query parameters, and body to the arguments object, and the endpoint path reveals the instanceID variable. This compensates for the schema gap, though it does not enumerate all possible query or body fields.
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 identifies the tool as a GET request to a specific endpoint for orphan scan settings. It specifies the HTTP verb, resource path, and the instanceID variable, making it distinct from sibling tools like qui_update_orphan_scan_settings or qui_trigger_orphan_scan.
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 GET method and the endpoint name, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It focuses on how to pass arguments rather than when to apply them.
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 declare readOnlyHint=true, and the description aligns with a GET request. It does not add significant behavioral context beyond the parameter-passing convention, but nothing contradicts 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 superfluous words; it states the action and parameter structure efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the readOnly annotation, and the presence of an output schema, this description covers the essential invocation details. It doesn't explain return values, but the output schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines a generic 'arguments' object with no specific parameters (0% coverage). The description compensates by explaining how to pass path variables, query values, and body, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calls the GET /version endpoint, which is a specific verb and resource. The endpoint name distinguishes it from sibling tools like qui_get_latest_version and qui_get_application_info.
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 provides parameter-passing instructions but no guidance on when to prefer this tool over alternatives like qui_get_latest_version. The usage is implied by the endpoint name, but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![qui-mcp MCP server](https://glama.ai/mcp/servers/arr-mcps/qui-mcp/badges/card.svg)](https://glama.ai/mcp/servers/arr-mcps/qui-mcp)

Score Badge

Copy to your README.md:

[![qui-mcp MCP server](https://glama.ai/mcp/servers/arr-mcps/qui-mcp/badges/score.svg)](https://glama.ai/mcp/servers/arr-mcps/qui-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/arr-mcps/qui-mcp'

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