Radarr MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct resources or actions, and the descriptions differentiate pairs like list_movies/get_movie and get_history/get_movie_history well. However, singular/bulk pairs such as update_movie/edit_movies and delete_movie/delete_movies could still be confused without carefully reading the descriptions.
Naming Consistency4/5
The server overwhelmingly follows a snake_case verb_noun pattern, with list_/get_/add_/delete_/remove_ used predictably. Minor deviations like update_movie vs edit_movies, create_tag vs add_movie, and mixing delete_ with remove_ keep it from being perfectly consistent.
Tool Count1/5
61 tools is far beyond the typical well-scoped MCP surface and exceeds the extreme-mismatch threshold. Even for a complex application like Radarr, exposing nearly every endpoint as a separate tool creates a bloated surface where many list, test, and config tools could be consolidated.
Completeness4/5
Core Radarr workflows are thoroughly covered, including movie CRUD, queue and file handling, release searching/grabbing, history, wanted, blocklist, commands, and system diagnostics. Minor gaps exist around full admin CRUD for indexers, download clients, import lists, notifications, and quality profiles, which are only list/test rather than fully manageable.
Average 4.1/5 across 61 of 61 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It goes beyond a simple 'update' by explaining that the settings control whether new collection movies are added and searched, and where they get placed. However, it does not disclose overwrite semantics, permission requirements, idempotence, or what happens to existing movies.
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 front-loads the main verb and resource, but the colon list is clunky and forces the reader to parse which toggles map to which parameters. It is concise in length but not well structured, so it sits at an adequate rather than polished level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and seven parameters, the description leaves too much unspecified: it never mentions the required collection_ids parameter, omits minimum_availability, and says nothing about return values or failure behavior. An agent would need to inspect the schema heavily to understand how to call 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 description coverage is 100%, so the baseline is 3. The description adds a high-level mapping of the settings (monitored, monitor_movies, search_on_add, quality_profile_id, root_folder_path) but does not add meaning not already in the schema. It omits minimum_availability entirely, but the schema covers 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 clearly identifies the tool as updating collections in bulk and lists the key editable settings (monitoring, add/search behavior, profile, root folder). It distinguishes itself from list_collections and movie-specific tools, though the phrasing 'monitoring, whether new collection movies are added and searched' is grammatically awkward.
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 phrase 'in bulk' implies the tool is for updating multiple collections at once, which gives some usage context. However, it does not explicitly state when to use this vs alternatives, nor does it mention constraints like 'collections must already exist' or that single-collection updates should also use this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate the key side effect: import lists will stop re-adding the movie. However, it omits whether the operation is idempotent, how it handles an already-existing exclusion, any permission requirements, or the response shape. The disclosure is minimal but not contradictory.
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 first sentence is concise and directly useful. The second sentence, however, is confusing and potentially erroneous—'add_import_exclusion' is neither this tool name nor a sibling tool—so it does not clearly earn its place. The overall length is short, but the unclear second sentence lowers the structural quality.
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 three-parameter mutation with no output schema, the description covers the core purpose and effect. But the ambiguous second sentence and the lack of any detail about error conditions, idempotency, or return behavior leave it only minimally complete for an agent trying to invoke 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?
Schema description coverage is 100%, so all parameters are already documented. The description adds no meaningful semantic value beyond what the schema provides: 'by TMDB id' repeats the tmdb_id property description, and 'shown in the exclusions list' is already part of the movie_title schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Exclude'), the resource ('a movie from import lists'), and the mechanism ('by TMDB id'), and explains the intended outcome. However, it does not contrast with sibling tools like remove_exclusions, and the second sentence introduces an unclear reference to 'add_import_exclusion', slightly muddying the otherwise clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'so lists stop re-adding it' implies the primary use case but provides no explicit guidance on when to prefer this tool over alternatives such as remove_exclusions or delete_movie. The second sentence attempts an alternative but is ambiguous and fails to clearly specify a condition or workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the output is a 'compact summary' and adds context that stalled/failed imports surface in trackedDownloadStatus/statusMessages. However, it does not explain pagination behavior, default filtering, or whether completed items appear in the list, so behavioral expectations remain partially unclear.
Agents need to know what a tool does to the world before 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. The first sentence front-lodes the primary action and output scope, the second adds relevant status detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 optional parameters and no output schema, the description gives a useful overview but lacks important contextual elements. It does not differentiate from get_queue_status, does not describe the full response shape, and does not clarify default status inclusions. Schema fill some gaps, but the tool's role among sibling queue tools remains ambiguous.
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 75%, so the schema already documents most parameters. The description adds no parameter-specific meaning beyond what the schema provides, and does not clarify protocol or sort_direction enums. The baseline of 3 is appropriate because schema does most of the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List the download queue as a compact summary' with specific content details (downloading progress, remaining time, import warnings/errors). This is a specific verb+resource with a clear scope. It does not explicitly distinguish itself from get_queue_status, but the purpose is 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 versus alternatives like get_queue_status, remove_queue_items, or grab_queue_items. It does not mention exclusions, prerequisites, or typical use cases, leaving the agent to infer when a compact queue summary 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?
With no annotations provided, the description carries the burden of behavioral disclosure. 'List' implies a read operation, and the explanation about movies not being allowed to add back adds meaningful domain context. However, it does not disclose pagination defaults, sort behavior, or what the response contains, so transparency is only partially covered.
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 the main action front-loaded and no filler. The phrasing 'movies import lists are not allowed to add back' is grammatically awkward but still understandable and compact.
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 paginated list tool with no output schema and no annotations, so the description alone must make the tool usable. It conveys the core purpose but does not explain expected return values, default pagination behavior, or how it relates to exclusion management siblings, leaving some gaps for the agent to infer.
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 75%: page, sort_key, and page_size have descriptions, while sort_direction only has an enum. The description adds no parameter-specific semantics beyond the schema, so it neither improves nor harms parameter understanding. Baseline 3 is appropriate given partial 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 states a specific verb and resource: 'List import list exclusions.' The added clause clarifies the domain purpose (movies that import lists cannot add back), which helps distinguish it from sibling tools like list_import_lists and add_exclusion. However, it doesn't explicitly name a sibling or contrast itself, so it doesn't earn 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is the read-only lookup for exclusions and gives context about what exclusions are, so an agent can infer when it is relevant. It does not explicitly state when to use this tool versus alternatives like add_exclusion or remove_exclusions, nor does it provide exclusion 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?
No annotations are provided, so the description carries full responsibility. It states the operation and effect but does not disclose whether removal is permanent, whether it is reversible, or any other side effects. For a destructive mutation tool, this is a meaningful 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?
A single sentence with no filler. It front-loads the action and resource, then gives the purpose. 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 tool is simple with one fully documented parameter and no output schema, so the description does not need to explain return values. However, with no annotations and no behavioral detail about the destructive nature or result of the operation, the description is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter 'ids' is already described as 'Exclusion ids (from list_exclusions)'. The description adds no additional meaning about the parameter beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove', the resource 'import list exclusions', and the intended effect 'so lists may add those movies again'. It is immediately distinguishable from siblings like add_exclusion and list_exclusions by the action and outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when previously excluded movies should become eligible for lists again. However, it does not explicitly mention when not to use it or point to alternatives like list_exclusions to first obtain ids, though the schema partially covers the id source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It communicates a read-only data retrieval along with a connectivity/API key check, which conveys the basic behavior. It does not mention output format, error behavior on invalid API keys, or whether any sensitive system details are exposed, so the transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words. The main content enumerations are front-loaded, and the second sentence adds a distinct secondary purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with no output schema, the description provides a solid overview of what the agent will receive by listing the main data categories. It could be more complete by clarifying how the connectivity/API key check result is returned or by explicitly stating it has no side effects, but the core usage context is sufficiently covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no input schema to augment. The description does not need to explain parameter meanings; the baseline of 4 applies because the parameter surface is trivial.
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 status retrieval operation with a specific verb ('Get') and resource ('system status'), and it enumerates concrete content areas such as version, branch, runtime, database, install path, and package details. It does not explicitly differentiate this from sibling tools like get_health or get_config, but the listed fields make the scope reasonably distinct.
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 phrase 'Also serves as a connectivity and API key check' gives a practical use case, implying this tool is appropriate for verifying connectivity or API key validity. However, it does not explicitly state when to use this tool instead of alternatives like get_health or get_config, nor does it provide any when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that omitting the id tests all lists, which is a useful scope detail, but it does not explain what testing entails, whether it creates side effects, requires special permissions, or what happens on failure. For a test operation, an agent would benefit from knowing it is non-destructive and whether it contacts external services.
Agents need to know what a tool does to the world before 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 with no wasted words. The primary purpose is front-loaded in the first sentence, and the second sentence adds a critical behavior for the optional parameter. It is concise without being underspecified.
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 tool with one optional parameter and no output schema, the description covers the core invocation logic. However, it lacks any indication of the return value or success/failure semantics of a connectivity test, and with no annotations it also omits safety/behavioral context. It is minimally adequate but leaves an agent to guess about the response.
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 100%; the id property already has a description ('Import list id; omit to test all'). The description essentially repeats this by saying 'Without an id every list is tested,' so it adds minimal semantics beyond the schema. The baseline of 3 applies because the schema already sufficiently documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Test import list connectivity.' This clearly distinguishes the tool from siblings like list_import_lists (listing), test_indexers, and test_download_clients (testing other connectivity). The purpose is immediately understandable without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's usage context is clear: use it to verify import list connectivity. It also provides specific guidance about the optional id parameter: 'Without an id every list is tested.' It does not explicitly mention alternatives or exclusions, but the resource-specific naming and the test/list distinction in siblings make the appropriate use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It provides meaningful domain context by explaining that tags drive delay profiles, release profiles, import lists, and notification targeting, but it does not disclose duplicate-label behavior, idempotency, permissions, or return 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 short sentences: the first states the action, and the second provides essential domain context. There is no filler, and the key action is 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?
The tool is simple with one documented parameter and no nested objects or output schema. The description explains the role of tags in the system, which is enough for an agent to understand the operation, though it could mention what the response contains or duplicate behavior.
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 already provides 100% coverage for the single 'label' parameter with a clear example ('4k' or 'kids'). The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the unambiguous verb-object pair 'Create a tag' and then explains why tags matter, referencing profiles and targeting. This distinguishes it from sibling tools like update_tag, delete_tag, and list_tags through the explicit create 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 implies usage: use this when you need to create a new tag. However, it does not explicitly state when not to use it or contrast it with update_tag or delete_tag, leaving the selection reasoning mostly to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly states that files are kept unless delete_files is set, which is a useful consequence for an agent to know before invoking. It does not mention reversibility, import-exclusion effects, or payload/response behavior, but the core default behavior is covered.
Agents need to know what a tool does to the world before 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 front-loaded sentence communicates the primary purpose and the most important behavioral caveat with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward batch deletion with three well-described parameters, the description plus schema are enough to use the tool. It lacks an explicit note about return values or error cases, but since there is no output schema and the invocation contract is simple, this is a minor gap.
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 100%, so the schema already documents all three parameters. The description adds a small amount of context by linking delete_files to file retention, but it does not materially expand on movie_ids or add_import_exclusion 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 names a specific action ('Remove several movies') and resource ('from the library'), and the plural 'several' combined with 'in one call' distinguishes it from the singular delete_movie sibling. It does not explicitly name the alternative, so it doesn't hit the strongest level of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The wording implies this is for batch removal, leaving single-movie deletion to delete_movie, and file-only deletion to delete_movie_files. However, there is no explicit when-to-use or when-not-to-use guidance, no mention of prerequisites, and no named alternatives.
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?
There are no annotations, so the description carries the full burden. It discloses important partial-update semantics with 'Only the given fields change' and explains apply_tags behavior. However, it does not mention potential side effects like move_files moving actual files on disk, any required permissions, or what the response contains.
Agents need to know what a tool does to the world before 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 primary purpose, and no wasted words. The second sentence adds the critical partial-update safety note, and the third clarifies the tag mode behavior. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an edit tool with 8 parameters and no output schema, the description conveys the core operation and the key safety guarantee clearly. It could be slightly more complete by explicitly noting that move_files may physically move files and by mentioning what the response returns, but the schema covers the parameter details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all eight parameters in detail. The description adds little beyond grouping the fields and paraphrasing apply_tags, which is already described in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Bulk-edit movies' and names the specific resource (movies) plus the exact fields affected: monitoring, quality profile, minimum availability, root folder, and tags. This distinguishes it clearly from update_movie, which is implied to be a single-movie 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?
The description implies this is for bulk editing multiple movies at once, especially with 'movie_ids' being plural and 'in one call'. However, it never explicitly says when to use this instead of update_movie or any other alternative, nor does it state any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully says that the response includes status, result, and any exception, which is meaningful. However, it does not describe behavior for unknown or expired ids, whether the command may still be running, or the read-only guarantee beyond the verb 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence contains the verb, object, selector, and output content with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema, the definition is nearly complete: it names the input source via the schema, the operation, and the returned data. It lacks only explicit not-found or polling semantics, which are minor for such a simple getter.
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 100%: the only parameter, id, is documented as the command id returned by run_command. The description's 'by id' reinforces rather than extends the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get'), a specific resource ('one command'), and the selection key ('by id'), which clearly distinguishes it from siblings like list_commands and run_command. It also names what is returned: status, result, and any exception.
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 phrase 'by id' implies a targeted lookup, and the schema's id description ('Command id returned by run_command') supplies the prerequisite. However, the description itself does not explicitly say when to use this tool instead of list_commands or that it is meant for checking the result of an asynchronously started command.
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 full transparency burden. It does disclose that the response is complete and contains quality items and custom format scores, but it does not mention read-only safety, error behavior, 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?
One concise, front-loaded sentence with no filler or redundant content. Every phrase adds value to the agent's understanding of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get-by-id tool, the description is nearly complete: it identifies the resource, explains the expected level of detail, and the schema covers the parameter. It does not capture every possible behavioral detail, but none are critical for this straightforward operation.
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 already fully documents the single parameter 'id' as 'Quality profile id' with 100% coverage. The description adds no additional parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get one quality profile in full') and clearly distinguishes this from the sibling list_quality_profiles by emphasizing a single, complete profile. The mention of including every quality item and custom format score adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving one full profile when an id is known, but it never explicitly names list_quality_profiles as the alternative or says when listing is preferable. Usage context is present but mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it discharges part of it by noting that credentials are redacted, a genuinely useful output behavior. 'List' also implies a read-only, non-mutating call, so no destructive behavior needs disclaiming.
Agents need to know what a tool does to the world before 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 front-loaded sentence: 'List import lists' leads, then field detail and the redaction caveat. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description names the fields returned and the only notable output caveat (redacted credentials). With no input schema requirements or output schema to reconcile, this is adequate for an agent to call and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema fully defines this (coverage 100%), so parameter documentation is trivially satisfied. There is nothing missing that the description needed to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('import lists') and enumerates the data fields returned (monitor mode, root folder, quality profile, sync settings), so an agent can tell this is a read-only enumeration tool. It doesn't explicitly contrast with sibling test_import_lists, but the name and scope make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance about when to choose this tool over test_import_lists or the movie/indexer listing endpoints, and no exclusions or prerequisites. Usage must be inferred from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does disclose important side effects: the release is blocklisted and a replacement is searched if the movie is still monitored. However, it does not mention permissions, idempotency, or what response to expect, so the behavioral transparency is 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?
The description is two concise sentences with no filler. The primary action is stated first, followed by the consequential behavior. Every sentence contributes 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 simple one-parameter tool with no output schema, the description is largely complete: it states what the tool does and its side effects. It could mention expected response behavior, but the tool is simple enough that this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single 'id' parameter is already described as 'History record id (from get_history)'. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark a grabbed history record as failed') and the resource involved. It effectively distinguishes this tool from read-only siblings like get_history by indicating a state-changing operation on a history record.
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: use this when a grabbed history record should be marked as failed. It does not explicitly name alternatives or when-not-to-use conditions, but no sibling tool performs a similar action, so the usage intent is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It clearly indicates a mutating operation and its effect, but does not mention permanence, idempotency, authorization needs, or what the response will contain.
Agents need to know what a tool does to the world before 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, front-loaded sentence with no filler. Every element contributes to understanding the tool's purpose and consequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, a single required and well-documented parameter, and no output schema, the description plus schema is nearly complete. It could be improved by noting permanence or response behavior, but an agent can invoke the tool correctly with the provided 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 already provides 100% documentation coverage, including the helpful note that ids come from get_blocklist. The description adds no parameter-specific meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('blocklist'), and states the intended effect ('so those releases can be grabbed again'). This clearly distinguishes it from sibling tools like get_blocklist and remove_queue_items.
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 phrase 'so those releases can be grabbed again' implies the appropriate use case: unblocking entries that should become eligible for grabbing again. However, there is no explicit guidance about when not to use it or how it compares to alternatives such as remove_queue_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Test' implies a non-destructive connectivity check, and the 'without an id every indexer is tested' nuance adds useful behavior. However, it does not disclose any potential network load, failures, or output shape, leaving some ambiguity.
Agents need to know what a tool does to the world before 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 tight sentences convey purpose, default behavior, and usage context without filler. Every phrase earns its place and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the essential call behavior and a clear use case. It is mostly complete, though a brief note about what kind of result to expect would make it fully self-contained.
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 100%, and the id parameter is already described as 'Indexer id; omit to test all'. The description reinforces this with 'Without an id every indexer is tested', but does not add new 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?
Description starts with a specific verb-resource pair, 'Test indexer connectivity', clearly stating what the tool does. It is distinguishable from sibling tools like list_indexers and test_download_clients by naming indexers specifically, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance with 'Run this when searches return nothing', giving a concrete condition for using the tool. It also clarifies the default behavior when no id is supplied, but it does not explicitly mention when not to use the tool or name 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?
With no annotations, the description carries the behavioral burden. It clearly explains the key behavioral distinctions: 'missing' movies have no file and 'cutoff' movies have a file below the quality cutoff. The verb 'List' clarifies this is a read operation, though it does not describe output structure or pagination behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one efficient sentence that front-loads the operation and immediately defines the important domain terms. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list-style tool with a well-covered schema, the description explains the central semantic difference between the two result types. It does not describe the return fields or default sorting, but the core behavior and required kind parameter are sufficiently covered.
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 high at 83%, so the baseline is 3. The description adds meaningful context by defining what the 'kind' parameter values ('missing' and 'cutoff') actually mean, which the schema's enum alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb ('List') and a distinct resource ('wanted movies'), then defines the two kinds ('missing' and 'cutoff') with concrete meanings. It is clear and not tautological, but it does not explicitly name sibling tools to distinguish itself from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by explaining that it lists wanted movies with two variants, but it does not explicitly state when to prefer it over list_movies or other list-like siblings. No when-not conditions or alternative routing are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly indicates this is a read-only listing operation, specifies the output content (size limits in MB/minute), and explains the real-world meaning of the data. This is sufficient for a simple list tool with no visible side-effects or external dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The primary action and resource are front-loaded, and the clarifying note about size limits and release rejection adds meaningful information without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only list operation with no output schema, the description is largely complete: it states what is returned and what the values mean. It does not explicitly state the return format (e.g., an array of objects), but 'List' strongly implies that, and no other usage 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 tool has zero parameters and the schema has no properties, so there is no parameter documentation burden. The baseline for zero-parameter tools is 4, and the description appropriately focuses on the output semantics instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('quality definitions') and adds substantive context about size limits and what these definitions do (reject releases as too small/large). It does not explicitly contrast with sibling tools like list_quality_profiles, but 'quality definitions' is distinct enough that an agent can identify the intended 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 implies when to use this tool (when you need quality definitions and their size limits) and explains the purpose of the returned data. However, it does not provide explicit guidance on when not to use it or which sibling tool might be a better fit, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well by disclosing the default non-destructive behavior ('Files are kept unless delete_files is set') and the re-add protection effect of add_import_exclusion. It does not mention irreversibility or permission requirements, but the core destructive behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the primary action is stated first and the two key options follow immediately. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity three-parameter delete operation, the description covers the main action, the destructive default nuance, and the import-list side effect. No output schema exists, so a bit more about the return/status could be added, but nothing blocks 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?
Schema coverage is 100%, so the baseline is 3, and the description adds value beyond the schema by explaining the default behavior ('Files are kept') and the consequence of each flag in practical terms. This helps an agent understand why it would set delete_files or add_import_exclusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and a clear resource ('a movie from the library'), immediately distinguishing this from read, add, update, and file-focused sibling tools. The singular 'a movie' also separates it from the bulk delete_movies sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose delete_movie versus alternatives like delete_movies, delete_movie_files, or remove_queue_items. The conditional advice about delete_files and add_import_exclusion concerns parameters, not tool selection, so usage context is essentially 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully explains why releases appear in the blocklist, but it does not disclose response format, pagination behavior, or explicitly confirm read-only semantics beyond the verb 'List'. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The first sentence delivers the core purpose and expected content; the second adds just enough domain context to explain the list's provenance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list endpoint with all-optional parameters and a well-described schema, the description plus schema gives an agent enough to invoke it correctly. A minor gap is not naming the companion removal tool or detailing the output shape, but the description partially covers output content already.
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 high (80%), so the schema already documents page, sort_key, movie_ids, and page_size, while sort_direction's allowed values are given as an enum. The description adds no parameter-specific guidance, which is acceptable but not additive.
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 opens with a specific verb ('List') and a distinct resource ('blocklisted releases'), then enumerates the key data attributes ('what was blocked, when, from which indexer and why'). This makes the tool's function unmistakable and distinguishes it from related listing tools like get_history or get_queue.
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 for when entries belong here: after a failed download or an explicit blocklist. This tells an agent when this tool is relevant, though it does not explicitly name alternatives or list when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. The verb 'Read' makes the read-only nature clear, and it adds useful meaning for the 'naming' and 'mediamanagement' sections. However, it does not disclose response shape, error behavior, or any access 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 compact and front-loaded with the core purpose, followed by a complete enumeration of sections and targeted clarifications for ambiguous ones. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool, the description is largely complete: it enumerates all valid sections and clarifies the two most ambiguous ones. The remaining sections are self-explanatory, and while an output schema is absent, the returned settings object is reasonably predictable.
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 100%, so the baseline is 3. The description adds genuine value by explaining what 'naming' and 'mediamanagement' refer to, which helps an agent pick the right enum value without external knowledge. This goes beyond the schema's generic 'Settings section to read'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('a Radarr settings section'), then enumerates the exact valid sections. This makes it immediately distinguishable from the many list/get siblings that deal with movies, quality profiles, or root folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need a Radarr settings section. It does not explicitly name alternatives or state when not to use it, but the context is reasonably clear because this is the only tool dedicated to reading config sections.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It does disclose pagination, ordering, and filtering behavior. However, it does not mention output format, default behavior, or any non-obvious side effects, leaving some room for improvement.
Agents need to know what a tool does to the world before 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, front-loaded sentences convey the resource, ordering, and a practical filtering use case without waste. Every phrase 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?
The description is complete enough for a paginated log-reading tool: it captures pagination, ordering, filtering, and a motivating scenario. It does not describe the response shape, but the lack of an output schema is partially mitigated by the simplicity of the operation and the clear input schema.
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 75%, and the description adds purpose to 'page' and 'level' by connecting them to the log-review workflow. However, it does not explicitly explain page_size or sort_direction, and with no output schema the parameter context is only partially enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Page through'), a clear resource ('Radarr's log entries'), and key ordering ('newest first'). It also explains the filtering purpose, making it easy to distinguish from the unrelated sibling tools on the list.
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 a concrete use case: filtering by level to find the error behind a failed grab or import. It does not mention exclusions or alternatives, but no direct alternative exists among the siblings, so the guidance is sufficient for typical 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?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the forced import behavior and the target condition, but it does not mention side effects, whether the operation is asynchronous, or what happens to the queue item after grabbing. This is adequate but not richly transparent for a mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that leads with the action, specifies the resource and state, and includes a helpful example. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter action tool with no annotations and no output schema, the description covers the main invocation context: what to force, which items apply, and an example trigger condition. It could mention expected return values or side effects, but the core information an agent needs to select and call it is present.
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 100% and the only parameter, 'ids', is already described as 'Queue item ids (from get_queue)'. The description adds the pending-state constraint, but the schema already handles the essential meaning, so the baseline of 3 is appropriate.
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 action ('Force Radarr to import'), the resource ('queue items'), and the specific state ('waiting in the pending state'). It also gives a concrete example, making it easy to distinguish from siblings like remove_queue_items or get_queue.
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 for when this tool is relevant: when queue items are stuck in pending state, such as due to a delay profile. It does not explicitly name alternatives or exclusions, but the context is specific enough to route an agent toward this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It clearly signals a read-only listing operation and discloses that the tool aggregates missing-movie counts per collection. It does not mention pagination, auth, or rate limits, but for a simple list tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence communicates the resource, scope, and the key distinguishing output. Every word earns its place, with no redundant 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 low complexity, the one optional parameter is fully documented in the schema, and no output schema exists, the description is largely complete. It could add a note about the absence of pagination or the response shape, but it is sufficient 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?
Schema description coverage is 100%, so the sole parameter include_movies is already fully explained in the schema. The description adds no additional parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List TMDB collections Radarr knows about.' It also adds a distinctive output detail—how many movies are still missing—so the tool is clearly differentiated from sibling tools like list_movies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you want collection-level missing-movie counts for Radarr's known TMDB collections. However, it does not explicitly say when to use this instead of list_movies or other related tools, and it gives no exclusions or 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?
No annotations are provided, so the description carries the full behavioral burden. It discloses the important default side effect that the download is also removed from the download client, and explains the blocklist and skip_redownload options. However, it omits the change_category behavior and does not explicitly warn about irreversibility.
Agents need to know what a tool does to the world before 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, leads with the primary action, and packs the key behavioral defaults into compact, useful phrasing. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with a fully described schema, the description covers the most important behavioral consequences. The main gaps are that change_category is not mentioned and there is no statement about what the tool returns, which would be helpful since no 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?
Schema description coverage is 100%, and the schema already provides meaningful descriptions for all five parameters. The description adds context around defaults and consequences, but it does not significantly extend the parameter-level meaning beyond what the schema already contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove'), a clear resource ('items from the queue'), and indicates it can handle one or more items. It is immediately distinguishable from queue-management siblings like grab_queue_items and from movie deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for removing queue items, but it does not explicitly state when to use it versus alternatives, nor does it mention when not to use it. There is no comparison to related tools such as remove_blocklist_items or delete_movies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that omitting id tests every client, which is useful, but it does not mention potential side effects, required permissions, or what the test result looks like. Still, the operation is a connectivity test, so its non-destructive nature is reasonably implied.
Agents need to know what a tool does to the world before 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 sentence, front-loaded with the action, then the key behavior, then the use case. Every word earns its place; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-optional-parameter test tool, the description gives the purpose, the behavior when id is omitted, and the symptom it addresses. The only missing piece is explicit output/result semantics, but the simplicity of the tool makes this a minor gap.
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 100% and the id parameter is already well-described in the schema. The description reinforces the optionality and the 'test all' behavior, but adds no new parameter-level syntax or format details 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 uses a specific verb ('Test') and resource ('download client connectivity'), clearly distinguishing this from list_download_clients and other test tools like test_indexers. The diagnostic purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear, concrete trigger: 'Run this when grabs never reach the queue.' It does not explicitly name alternative tools or when not to use it, but the diagnostic context is strong enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a key behavioral trait: renaming keeps existing associations intact. However, it omits other potentially relevant behavior such as uniqueness constraints, validation rules, permission requirements, or error behavior, so transparency is only partial.
Agents need to know what a tool does to the world before 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 deliver the core action and the one critical side-effect with no wasted words. The purpose is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter CRUD operation, the description plus full schema coverage is largely sufficient for correct invocation. It falls slightly short of complete because there is no output schema and no mention of edge-case behavior such as invalid ids or duplicate labels, but these are minor for this level of complexity.
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 100%, with clear descriptions for both id and label. The description adds little beyond the schema, so the baseline score of 3 is appropriate; it neither confuses nor significantly enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('rename') and resource ('existing tag'), and adds that associations are preserved. This clearly distinguishes it from sibling tools like create_tag and delete_tag without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the use case: renaming an existing tag rather than creating or deleting one. It does not explicitly name alternatives or when-not-to-use conditions, but the context is clear enough for an agent to route correctly.
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?
There are no annotations, so the description carries the full burden. It discloses the candidate-style return behavior, the key tmdbId field, and the special case where results already in the library include a Radarr id. It does not mention pagination or external API rate limits, but for a search tool these are not critical omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The purpose is front-loaded, followed by the output contract, then the library edge case. Every sentence 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 tool has no output schema, so the description needs to explain return meaning, which it does reasonably. However, it never explicitly states that at least one of term, imdb_id, or tmdb_id is required, especially since the schema marks all parameters as optional. This could lead to a no-parameter 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 already describes all three parameters with examples, so the description only re-frames them as alternative search modes. It adds the important context that tmdbId is the value add_movie needs, but parameter-level semantics are largely already covered by 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 states a specific verb and resource: 'Search TMDB for movies', and enumerates the accepted lookup keys (free-text, IMDB id, TMDB id). It also distinguishes itself from library-oriented siblings by explaining the output is candidate movies with tmdbId, which is exactly what add_movie consumes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals when to use this tool: before add_movie, to resolve a TMDB candidate. It also gives a useful conditional behavior: results already in the library carry a Radarr id. However, it does not explicitly name alternative siblings such as list_movies or get_movie, nor state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the internal two-step behavior ('Looks the movie up first, then posts it'), which is valuable. However, with no annotations and no mention of side effects like automatic indexer search (search_for_movie defaults to true), duplicate handling, or permission requirements, behavioral coverage remains partial.
Agents need to know what a tool does to the world before 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 contain the essential action, workflow order, and prerequisite tool references with no filler. The most important information is 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 8 parameters, no annotations, and no output schema, the description covers the required workflow and relies on the schema for optional fields. It doesn't describe the return value or what happens if the movie is already in the library, but the provided guidance is sufficient to call the tool correctly with valid inputs.
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 already documents all 8 parameters at 100% coverage, so the baseline is 3. The description adds cross-tool semantics by telling the agent to source tmdb_id via lookup_movie and validate root_folder_path/quality_profile_id via list_* tools, giving practical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Add a movie to the library by TMDB id' and differentiates it from sibling tools like update_movie and delete_movie by specifying the exact resource, input key, and required configuration (root folder, quality profile).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs the agent to use list_root_folders, list_quality_profiles, and lookup_movie to prepare valid inputs, which is excellent contextual guidance. It does not mention when to prefer alternatives like update_movie for already-imported movies, so exclusion criteria are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It reveals a key non-obvious side effect: movies stay in the library and, if monitored, become wanted again. It does not discuss irreversibility or recycle-bin behavior, but the central nuance is covered.
Agents need to know what a tool does to the world before 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 filler. The first delivers the core action, and the second explains the consequence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive action with no output schema and no annotations, the description plus schema cover the action, the id source, and the important behavioral consequence. It could add an explicit note about permanence or alternatives, but it is sufficient 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 already documents ids as 'Movie file ids (from list_movie_files)', giving 100% coverage. The tool description adds no additional parameter-level meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action, 'Delete movie files from disk', and immediately clarifies that the library record is retained. This clearly distinguishes it from sibling tools like delete_movie or delete_movies, which remove the movie entry itself.
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 second sentence establishes the appropriate context: use this when you want to remove files but keep movies in the library and allow reacquisition if monitored. It does not explicitly name alternative tools or state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the key cascading effect: deleting the tag removes it from everything using it. It does not mention irreversibility, permissions, or response type, but the main destructive behavior is clearly surfaced.
Agents need to know what a tool does to the world before 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-loading the core action and immediately adding the important side effect. The safety hint is placed after the main behavior, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with no output schema, the description covers the essential behavior and gives a practical safety precondition. It could mention whether the operation is reversible or what a success response looks like, but the core calling context is 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 already documents the single parameter 'id' with 100% coverage, so the description does not need to add much. It adds no extra nuance beyond the schema, which matches the baseline expectation for a fully described 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 names a specific verb ('Delete') and resource ('a tag') and clearly states the cascading effect: 'remove it from everything using it.' This distinguishes it from tag-related siblings like list_tags, create_tag, and update_tag, and from unrelated delete_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises checking list_tags first, which gives the agent a concrete precondition before invoking the destructive operation. It does not explicitly state when to avoid using this tool or mention alternatives, but the deletion context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the behavioral burden. It communicates a non-mutating discovery operation through the verb 'List' and discloses the output shape as 'candidates with tmdbIds.' It does not cover pagination or empty-result behavior, but for a simple list tool this is reasonable.
Agents need to know what a tool does to the world before 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 core purpose and scope are front-loaded, and the useful output hint about tmdbIds is appended without bloating the 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?
For a tool with no output schema, the description provides the key return concept: candidates with tmdbIds for add_movie. The source context is clear and the schema covers parameter details. It could be more complete with explicit defaults and a note distinguishing it from list_movies, but the essential information is present.
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 already documents all four parameters with descriptions, so the description only needs to add high-level meaning. It does this by mentioning optional Radarr feeds, which maps to the include_* booleans, but it does not clarify defaults or how limit is applied across the merged sources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'List movies suggested by the import lists plus, optionally, Radarr's recommended, trending and popular feeds.' This clearly distinguishes it from library-centric siblings like list_movies. It also signals the downstream purpose by saying it returns candidates with tmdbIds for add_movie.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when the agent needs to surface candidate movies from import lists or Radarr feeds before adding them. It explicitly ties the output to add_movie, which helps routing, though it does not name alternative tools or state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully reveals the default window and that results include release date types and on-disk status, but it does not disclose pagination, sorting, output structure, or whether the operation is purely read-only beyond the verb 'List.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The core action is front-loaded, followed by the key scoping details and the default behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with fully documented optional parameters, the description covers the essential call context: what is listed, the date-window concept, release-date subtypes, on-disk status, and default range. Minor gaps remain around pagination and exact output formatting, but the lack of an output schema is partially compensated by the description's mention of fields returned.
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 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the 'window' concept and the default of the next 30 days. It does not add much for tags or unmonitored, but those are already clearly described in 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 states a specific verb and resource: 'List movies with a release date in a window.' It further differentiates itself by specifying cinema, digital, and physical release dates plus on-disk status, which clearly separates it from sibling tools like list_movies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for date-windowed movie release queries, especially with the default 'next 30 days' behavior. It does not explicitly name alternative tools or state when not to use it, but the context is strong enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It makes the read-only nature clear with 'List' and specifies the exact scope ('every drive Radarr can see, including the root folders'). It could mention output shape or failure behavior, but for a simple no-argument listing tool it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence delivers the action, the measured quantities, and the scope. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool, the description is nearly complete: it names the returned data (free/total space) and the scope (every drive including root folders). It doesn't specify units or formatting, but that is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter ambiguity is impossible. The baseline for a parameterless tool is 4, and the description correctly implies no inputs are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List free and total space for every drive Radarr can see.' This makes the tool's purpose unambiguous and distinguishes it from siblings like list_root_folders, which return paths rather than capacity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: call this when you need drive capacity rather than just root-folder paths. However, it does not explicitly state when not to use it or name an alternative, so the guidance 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.
Behavior4/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. 'Get' accurately signals a read-only operation, and the description transparently conveys what the response contains. It doesn't cover edge cases like not-found behavior, but for a simple GET tool this is a minor 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?
One compact sentence that front-loads the core action and resource, then lists what the full record includes. Every clause earns its place with 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 one-parameter read-only tool with a fully described schema and no output schema, the description adequately covers what the agent needs: the action, the resource, and the content of the response. The absence of an output schema is compensated by the explicit category list.
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 already provides 100% coverage for the single parameter, including an explicit note that `id` is the Radarr movie id and not the TMDB id. The description adds no significant parameter-level detail beyond what the schema states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('full record for one movie'), and explicitly enumerates the content categories (file details, ratings, images, availability, statistics, add options). This clearly distinguishes it from list_movies (which returns multiple) and lookup_movie (which searches external sources rather than the local library).
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?
'Get the full record for one movie in the library' provides clear context: use this when you need the complete record for a single known movie using its Radarr id. It doesn't explicitly name alternatives or exclusions, but the 'in the library' scope differentiates it from lookup_movie and the singular 'one movie' differentiates it from list_movies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully discloses that the response is 'full, unpaged' and includes all event types including failures. This goes beyond the schema and gives the agent important expectations about completeness and potential payload size.
Agents need to know what a tool does to the world before 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 filler. The key distinguishing facts ('full, unpaged', 'for one movie', event types) appear first, and the purpose statement is a useful second sentence.
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 relatively simple read-only tool with a fully documented schema, the description provides the essential context: scope, completeness, and use case. It does not describe return shape or ordering, but no output schema exists and those details are not essential 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?
Schema description coverage is 100%, so both parameters are already documented. The description reinforces that movie_id scopes the history to one movie but adds no additional parameter-level detail beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Get the full, unpaged history for one movie.' It further specifies the content ('every grab, import, rename and failure') and gives the intended purpose. This clearly distinguishes it from broader tools like get_history by scoping to a single movie.
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 a clear use case: 'Use this to explain why a movie has the file it has.' This gives an agent strong contextual guidance. It does not explicitly contrast with alternatives or state when not to use it, but the single-movie scoping and purpose are sufficient for most routing decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. 'Render' implies a non-mutating, read-only operation and the context is clear, but the description does not explicitly state that nothing is changed or describe the exact shape of the returned examples.
Agents need to know what a tool does to the world before 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-loads the core behavior in the first sentence, and adds a practical usage note in the second. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, low-complexity tool, the description conveys purpose, behavior, and usage context in just two sentences. It could be slightly more explicit about the output format, but the tool is simple enough that the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema confirms this with 100% coverage, so there are no parameter semantics to document. The description's reference to the 'current naming configuration' provides relevant context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Render[s] example file and folder names' for the current naming configuration. This specific verb and resource distinguish it from siblings like get_rename_preview, which concerns previewing a rename operation rather than generating examples.
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 explicitly says to use it to 'sanity-check a naming format before adopting it,' providing clear context for when it is appropriate. It does not mention alternative tools or when not to use it, but the use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it states the tool only previews, returns only files whose names would change, and does not apply changes. This communicates the key non-destructive behavioral trait. It does not detail the exact return payload, but the preview scope is clearly 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?
Two senttenences, no fluff, front-loaded with purpose and key behavior. Every word adds value: preview scope, filtered output, and the apply alternative are all included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential context: what is previewed, what is returned, and how to actually apply changes. Minor gaps remain about the exact fields in the returned rename previews, but nothing blocks 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?
Schema description coverage is 100%, and the parameter description ('Radarr movie ids to preview') already explains the only input. The tool description adds no new meaning about the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Preview') and resource ('files would be renamed'), and clearly distinguishes this read-only preview from the apply step (RenameFiles command) and from sibling tools like get_naming_examples. An agent can tell exactly what this tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs the agent to 'run the RenameFiles command to apply', establishing when to use this preview tool versus the action that performs the rename. It does not enumerate alternative preview tools or exclusions, but the usage context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing side effects, and it does disclose the key non-obvious behavior: the release will be grabbed even if it was rejected. This warning is essential for safe invocation. It does not cover response/error behavior or reversibility, but the most critical behavioral trait is present.
Agents need to know what a tool does to the world before 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 leads with the action, then provides the critical warning. 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 low complexity, three parameters, and no output schema, the description plus the fully described schema provides enough for correct invocation. It names the source of the release and the caution about rejections. It could mention the optional movie_id use case, but the schema covers it, and no other critical context is 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 provides 100% coverage with descriptions for 'guid' and 'indexer_id,' and the description does not add meaning beyond what the schema already states. It implicitly ties the parameters to search_releases through 'from search_releases,' but that is already in the schema descriptions. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Send a release from search_releases to the download client.' It clearly identifies the source, destination, and action, and the rejection warning adds a distinguishing nuance. This is enough to separate it from siblings like grab_queue_items, which operate on the queue rather than search results.
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 states when to use the tool: after obtaining a release from search_releases. It also gives an explicit precondition: 'check the rejections first,' because Radarr grabs it even if rejected. It does not name alternative tools explicitly or give a when-not-to-use, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the command states included and that results are returned, implying a read-only list. However, it does not clarify how 'recently finished' is bounded or what fields the result contains.
Agents need to know what a tool does to the world before 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 with no filler. The action and scope are front-loaded, and the usage guidance is immediate and useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple zero-parameter list operation: it identifies the resource, the states covered, and the intended use case. The lack of an output schema and ambiguity around 'recently finished' are minor gaps, but they do not block 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 tool has zero parameters and schema coverage is 100%, so there are no parameter semantics to explain. The description correctly avoids inventing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List') and resource ('commands'), then narrows scope by state (queued, started, recently finished) and payload (status and result). This clearly differentiates it from get_command and run_command.
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?
Explicitly gives the intended use: check whether a search or refresh has completed. It does not mention alternatives like get_command for individual command detail, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly signals a read-only listing operation and discloses the response content and diagnostic purpose. It does not cover edge behaviors like filter defaults or permission requirements, but for a list-style tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The purpose is front-loaded, and the use case is appended in a short, scannable second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's modest complexity, a fully documented schema, and no output schema requirement, the description covers what the tool does, what it returns, and when to use it. It is slightly light on exclusions or alternatives, but is otherwise complete for an agent selecting 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 100%, so the schema already documents all four parameters. The description adds contextual meaning around manual import and queue diagnostics, but does not add parameter-level detail beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'List files Radarr found for a manual import.' It also specifies what the response includes (matched movie, parsed quality, rejections), and the diagnostic use case distinguishes it from related tools like list_movie_files or get_queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: 'diagnose downloads stuck in the queue with an import warning.' It does not explicitly mention when not to use it or name alternative tools, but the intended context is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does convey a read-only intent through 'List' and explains the empty-parameter behavior ('neither for every file'), but it does not address what happens when both movie_ids and movie_file_ids are supplied, nor does it describe pagination or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence fronts the action and result fields; the second covers the three invocation modes. 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?
The tool is simple with two optional params and no output schema. The description covers return contents ('quality, size, languages and media info') and filter mechanisms. The only notable gap is the semantics of combining both movie_ids and movie_file_ids, which an agent might reasonably attempt.
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 100%, so the parametters are individually documented. The description adds meaning by clarifying the selection modes: movie ids, file ids, or neither for all files. This goes beyond the plain schema descriptions and helps an agent understand how to use the optional filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: list media files for movies, including quality, size, languages, and media info. This clearly distinguishes it from sibling tools like list_movies or get_movie, which deal with movie metadata rather than files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Pass movie ids, file ids, or neither for every file in the library' gives clear practical guidance on how to invoke the tool. It does not explicitly name alternatives or state when not to use it, but the tool's purpose is evident from the description and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly notes that 'Credentials are redacted', a meaningful privacy-relevant trait, and it clarifies the output content by mentioning which events each connection fires on. It does not discuss side effects or pagination, but for a parameterless read operation this is sufficient.
Agents need to know what a tool does to the world before 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 of approximately 14 words. It front-loads the core function ('List notification connections') and includes only one additional useful fact about credential redaction. There is no unnecessary verbosity.
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 zero parameters and no output schema, the description conveys the essential behavior: what is listed (notification connections), what detail is included (events each one fires on), and a key output trait (credentials redacted). It does not specify the exact response shape or field names, but for a simple list operation the description is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties and 100% schema description coverage, so there are no parameter semantics to explain. The baseline for 0 parameters is 4, and the description does not need to compensate for any parameter documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a specific resource 'notification connections' and adds the important detail 'which events each one fires on'. This clearly defines the tool's function and distinguishes it from all sibling tools, none of which relate to notifications.
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 is given about when to use this tool versus alternatives. There are no sibling notification tools, so the intended usage is self-evident, but the description does not state exclusions, prerequisites, or typical scenarios. The 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.
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 of behavioral disclosure. It clearly states the operation is 'List' (a read-only action) and explains the mapping orientation, but it does not detail the return format, pagination, error cases, or authorization needs. The diagnostic hint adds context but not deep 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?
Two sentences with no filler: the first defines the action and resource, the second adds a useful diagnostic note. The information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema list tool, the description is largely complete: it defines the resource, the mapping direction, and a common use case. It could mention what fields are returned, but the mapping-direction definition partially compensates for the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds semantic value by explaining what a remote path mapping is (download client path -> Radarr path), which helps the agent interpret results. No parameter-level detail is necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('remote path mappings'), and defines the mapping direction as 'download client path -> Radarr path,' which is unambiguous. It is distinct from sibling tools, none of which overlap with this functionality.
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 a clear diagnostic context: wrong mappings are the usual cause of 'file not found' import failures, implying when an agent should use this tool. It doesn't explicitly name alternatives or exclusions, but there are no sibling tools with similar functionality, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. 'Parse' and 'diagnosing' strongly imply a read-only, non-mutating operation, and the description discloses what kind of interpretation Radarr produces. It does not explicitly state side effects, but for a parse endpoint this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and wastes no words. The main action and useful diagnostic context are front-loaded, and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter diagnostic tool, the description is largely complete: it states the input, the purpose, and the categories of output the caller should expect. It does not describe the exact return schema, but with no output schema provided and such a simple input contract, the description gives enough context for an agent to call it appropriately.
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 100%, and the schema already documents the single 'title' parameter with a concrete example. The description adds no parameter-level detail, but none is needed beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('parse a release title') and a specific resource ('release title'), and it enumerates the exact dimensions of the result: movie, quality, languages, edition, release group, and custom formats. It clearly positions this tool as a diagnostic utility, which distinguishes it from sibling tools like search_releases or get_movie.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: diagnosing why a release is rejected or misidentified. It does not explicitly name alternatives or say when not to use the tool, but the diagnostic framing makes its context of use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool queries every enabled indexer, that it is interactive, and that it may take a while. It also implies it does not grab releases by pointing to grab_release, though it does not explicitly state side effects or lack thereof.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main purpose is front-loaded, followed by an important performance caveat and a pointer to the next step. Every sentence 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?
The description explains what the tool returns, how broad the search is, and that it can be slow, which is enough for an agent to select and invoke it. It does not elaborate on what 'interactive' means operationally, but the schema covers the required movie_id and optional params.
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 100%, so the schema already documents all three parameters. The description adds little parameter-level meaning beyond mentioning 'releases' and 'rejections,' but the schema covers limit and include_rejected adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run an interactive indexer search'), names the resource ('a movie'), and specifies the output ('releases found, with their rejections and custom format scores'). It also differentiates itself from the sibling grab_release by explicitly saying 'Grab one with grab_release.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use this tool to search across every enabled indexer, and it can be slow. It also points to grab_release as the follow-up action. It doesn't explicitly list when-not-to-use alternatives, but the search-then-grab flow is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' clearly signals a read-only operation, and the detail about specifications and quality-profile scores communicates what the response will contain. It does not mention output format, but for a zero-parameter listing tool that is a minor 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?
Two short sentences with no filler. The first sentence states the core action and resource; the second adds useful domain context about quality-profile scores. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter read-only list tool with no output schema, the description is complete. It tells the agent what the tool returns and why it matters, and no additional prerequisites or edge cases are relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The description correctly focuses on the tool's behavior rather than inventing parameter details, meeting the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('custom formats') and clarifies that the returned data includes specifications and quality-profile scores. This clearly distinguishes it from sibling tools like list_quality_profiles or list_tags, 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 implies when to use the tool: when you need to see custom formats or understand how their scores influence release preferences. However, it does not explicitly state when-not-to-use it or name alternatives, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explicitly notes that API keys and passwords are redacted, which is a valuable security-related behavioral detail. The verb 'List' also indicates a read-only operation, though auth requirements and potential failure modes are not addressed.
Agents need to know what a tool does to the world before 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 with no filler. It front-loads the action and scope ('List configured indexers') and then adds relevant return-field and redaction details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, this description is complete enough for an agent to select and invoke the tool. It identifies the target entity, names the important returned attributes, and discloses the redaction behavior. Nothing material is missing 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 has zero parameters, so schema description coverage is effectively 100% and there is no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('configured indexers'), and it enumerates the key fields returned: protocol, priority, search modes, and settings. This clearly distinguishes it from sibling tools like test_indexers, which perform an action rather than listing configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to see configured indexers and their settings. However, it does not explicitly state when to use it versus alternatives such as test_indexers, nor does it provide any exclusion criteria or alternative routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It usefully discloses that Radarr returns the entire library in one response and that filtering happens client-side, which lets an agent anticipate performance and output size. It also lists the output fields. It could mention pagination or lack of server-side filtering more prominently, but the key behaviors are covered.
Agents need to know what a tool does to the world before 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 deliver the output shape, the alternative tool, and the crucial behavioral note about client-side filtering. Every clause earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with fully documented parameters, the description plus schema is complete. It explains the return style, field set, filtering behavior, and the relationship to get_movie. No critical operational detail is 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 input schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds a general note about client-side filtering and the compact summary field list, but it does not add meaningfully to each parameter beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('movies in the library'), and explicitly distinguishes this tool from get_movie by noting it returns a 'compact summary' with the exact fields included. This makes the tool's role unambiguous and easily separable 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for compact summaries and use get_movie for the full record. It also explains that filters are client-side because Radarr returns the whole library, which informs an agent about when this tool is appropriate. It doesn't enumerate exhaustive when-not scenarios, but the get_movie alternative is 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?
With no annotations provided, the description carries the burden of behavioral transparency. It does disclose the meaningful behavioral difference caused by the details flag, explaining that detailed results include attached entity ids. It does not state pagination or ordering behavior, but for a simple list operation this is a reasonable disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and then explains the parameter behavior. Every sentence earns its place without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-boolean-parameter list tool with no output schema, the description is sufficient for an agent to invoke it correctly. It explains the tool's purpose, the effect of details, and what the extended response contains. No critical information is missing given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the details parameter. The description adds semantic value by specifying exactly what 'details' includes: ids of movies, indexers, import lists, notifications, and profiles using each tag. This goes beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the verb ('List') and resource ('tags'), making the purpose immediately obvious. It distinguishes list_tags from the sibling tag tools create_tag, update_tag, and delete_tag by virtue of being a read-only listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: an agent would infer that list_tags is for retrieving tags, especially given the sibling tag tools. However, there is no explicit guidance about when to use this over alternatives or any exclusions, so it only meets the baseline for implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It transparently reveals that execution is asynchronous and that the response only carries an id. It also clarifies parameter mapping per command, which is not visible from the schema alone. It stops short of describing failure modes or error responses, but the critical async behavior is well covered.
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 dense and front-loaded with the most important behavior (async execution and polling). The long allowed-command list is necessary because it defines the tool's entire surface. No filler or redundant restatement of the schema is present.
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 complex 17-command tool with no output schema, the description covers the essential operational details: async nature, polling mechanism, allowed commands, and parameter expectations. It does not describe error cases or cancellation, but the core workflow an agent needs is fully specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already high, but the description adds real value by mapping specific command names to movie_ids and explicitly stating that all other allowed commands take no parameters. The example for params ('{ files: [1, 2] } for RenameFiles') clarifies how extra body fields are passed, which goes 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 states a specific verb ('Queue') and resource ('a Radarr command'), and the allowed command list makes the scope unmistakable. The async note and reference to get_command distinguish it from sibling command-management tools like list_commands and get_command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains that commands run asynchronously and that the response id should be polled with get_command, which directly guides usage. It also clarifies which commands take movie_ids and which take none. It does not explicitly state what to do with list_commands, but the polling workflow is enough for an agent to use the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the global scope, the event categories included, the default newest-first ordering, and the available filtering mechanics. It does not explicitly state read-only status or response shape, but the history/paging framing strongly implies a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences front-load the core behavior ('Page through the global history') and then add scope, ordering, and filter purpose with no redundant wording. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, the description covers the main pagination behavior, default sort, event types, and filter-driven use case. It is slightly incomplete around return shape and sort_key/sort_direction specifics, but those are either inferable or already covered by the input 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?
Schema coverage is 86%, so the structured schema already covers most parameters. The description adds meaning by connecting event_type, movie_ids, and download_id to the tracing use case and by noting default ordering behavior. It adds less value for sort_direction and pagination parameters, but those are adequately documented in 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 uses a specific verb-resource pair ('Page through the global history') and enumerates the covered event types (grabs, imports, failures, deletions, renames). It also states default ordering and filter dimensions, clearly distinguishing it as the global history tool from per-movie siblings like get_movie_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly identifies a concrete use case ('trace what happened to a specific download') and describes filter dimensions (event type, movie ids, download id). It does not name alternatives or exclusion conditions, so it lacks full when-not-to-use routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries full responsibility for behavior, and it discloses the returned data (root folders, free space, reachability) and the downstream dependency for add_movie. The verb 'List' also implies a read-only operation. It could mention permissions or error behavior, but for a zero-parameter read tool this is sufficient.
Agents need to know what a tool does to the world before 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 with no filler: the first states the operation and output, and the second states the key use case. The most important information is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool with no output schema, the description covers the essential output fields (paths, free space, reachability) and the practical need (add_movie path selection). It does not specify output formatting or edge cases, but those are minor for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter details for the description to add. The baseline of 4 for zero-parameter tools applies, and the description instead focuses on the output semantics, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource, 'root folders', and states exactly what information is returned: free space and Radarr reachability. It also distinguishes the tool's purpose by linking it to add_movie, which requires one of these paths. This makes it distinct from sibling list tools like list_movies or get_disk_space.
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 second sentence, 'add_movie needs one of these paths,' explicitly identifies the primary use case and tells an agent to call this tool before add_movie. It does not explicitly exclude alternative tools or state when not to use it, but the resource is unique enough among siblings that no strong exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses a key non-obvious behavior: the tool reads the existing record, merges fields, and preserves unspecified fields. It also reveals the move_files side effect, which is important for file relocation. It does not mention permissions or return values, but core behavioral disclosure is strong.
Agents need to know what a tool does to the world before 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 compact sentences deliver purpose, behavioral semantics, and conditional parameter guidance with zero redundancy. The most important information is 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?
All eight parameters are fully documented in the schema, and the description covers the critical merge behavior and move_files condition. With no output schema or annotations, it could add return-value or permission details, but the essential information for calling the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining merge semantics (unspecified fields preserved) and by linking move_files to path/root_folder_path changes. This helps the agent understand how to use multiple parameters together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update one movie's settings') and a clear resource. The singular 'one movie' distinguishes it from plural sibling tools like edit_movies and delete_movies, preventing routing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the read-merge-write behavior and gives actionable guidance: set move_files when changing path or root_folder_path to relocate files. It does not explicitly name an alternative for batch updates, but the singular scope and conditional guidance provide clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It communicates that this is a read-only listing operation and explains the meaning of an empty result. It omits auth or rate-limit details, but those are less critical for a zero-parameter status 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 short sentences with no filler. The first sentence states the action and sope, the second gives the key interpretation rule, keeping the most important information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter health check, the description is complete: it explains what is returned, that each item has a wiki link, and how to interpret an empty response. There is no output schema, so the description appropriately covers the return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has full description coverage of an empty object. There is no parameter behavior to document, so the baseline for zero parameters applies and the description satisfies it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it lists active health check warnings and errors, and even adds the useful detail that each item includes a wiki link. This clearly differentiates it from siblings like get_system_status or get_disk_space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly describes its purpose and gives an interpretative rule for the response: an empty result means Radarr is healthy. It does not explicitly name alternatives or exclusion cases, but for a health-check tool the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It signals that this is a low-cost, read-only health check and lists exactly what information it returns. It does not cover error behavior or response formatting, but for a zero-parameter status endpoint that is a minor 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?
One tightly packed sentence states the purpose, return contents, and intended usage without waste. It is front-loaded with the main action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema health-check tool, the description fully covers what it returns and when to call it relative to the heavier full-queue operation. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no properties and no required parameters, so there is nothing for the description to add beyond the empty schema. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it returns queue counters for total, errors, warnings, unknown items, and a manual-import flag. This clearly distinguishes it from the sibling get_queue, which returns the full queue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says this is a cheap health check before pulling the full queue, so an agent knows when to call it. It does not explicitly name the sibling get_queue as the alternative, but the context makes that clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. 'List' signals a read-only operation, and the phrase 'available Radarr updates' scopes what is returned while naming version, release date, and changelog as outputs. It does not discuss pagination or failure modes, but this is sufficient for a zero-parameter listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tight sentence front-loads the verb and resource, then packs in the key output fields. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing, the description is complete. It provides the return-value detail because no output schema exists, and 'List' conveys the operation's safety. Nothing an agent needs to invoke it correctly 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 input schema is empty with 0 parameters and 100% description coverage, so there are no parameter details to add. The baseline of 4 applies because no parametric meaning needs to be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('List'), names the exact resource ('available Radarr updates'), and enumerates the returned fields (version, release date, changelog). No sibling tool targets updates, so it is immediately distinguishable from the other list-style tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended context is clear: call this tool when you need the catalog of available Radarr updates. It does not explicitly state when not to use it or name alternatives, but no sibling provides this functionality, so there is no real ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds a valuable transparency note: 'Credentials are redacted.' The verb 'List' also implies a read-only operation, though the description does not explicitly state the absence of side effects or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action, resource, returned fields, and the redaction behavior efficiently, earning every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is complete: it names the resource, the key output attributes, and the credential handling. No output schema exists, but the description sufficiently conveys what an agent should expect when invoking the 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 tool takes no parameters, so there is no parameter semantics gap for the description to fill. The baseline of 4 applies because the input schema is empty and the description correctly focuses on behavior and return contents rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and exact resource ('configured download clients'), then specifies the returned fields: category, priority, and removal settings. This clearly differentiates it from siblings such as test_download_clients, which tests connectivity rather than listing configuration.
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 for when to use the tool: when a list of configured download clients and their settings is needed. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough that an agent can route to this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. 'List' accuritely signals a non-destructive read operation, and the sentence adds useful context about what the ids are for. A small gap is that it doesn't detail the exact response shape, but for a zero-parameter list endpoint this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every clause earns its place: the action, the scope, and the intended use of the returned ids.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter list tool with no output schema, the description is complete: it names the resource, the returned values (languages and ids), and the domain context. Nothing needed for an agent to decide to call it 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 input schema has zero parameters, so there is nothing for the description to explain beyond what the schema already shows. Baseline for a zero-parameter tool is satisfied, and the description's note about id usage is not parameter-related but remains harmless context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('languages Radarr knows'), and adds why the ids matter ('used in profiles and release filters'). It clearly differentiates this read-only lookup from the movie/queue/config 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ids used in profiles and release filters' gives an agent a clear context for when this tool is relevant. It does not explicitly name alternatives or exclusions, but no sibling tool provides language data, so that omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'List' and the content description make the operation's read-only, non-mutating nature clear, and the downstream ID use is stated. Pagination/ordering are not mentioned, but they are not material for a zero-parameter profile listing.
Agents need to know what a tool does to the world before 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 contain exactly the needed information: what is listed, what fields are included, and why an agent needs it. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter list tool without an output schema, the description conveys the return contents and the practical caller context. An agent can decide when to call it and what to do with the resulting IDs without additional documentation.
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, so there are no parameter semantics to explain; a zero-parameter tool gets a baseline of 4. The description instead adds useful output meaning (cutoff, allowed qualities, IDs consumed by other tools), which goes beyond the empty 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 opens with a specific verb and resource: 'List quality profiles', and immediately specifies the output content ('cutoff and allowed qualities'). It is easily distinguished from sibling get_quality_profile (list vs. single) and list_quality_definitions (profiles vs. definitions).
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 second sentence gives concrete usage guidance: add_movie and update_movie require one of these IDs, so an agent knows to call this tool before those mutations. It does not explicitly contrast with get_quality_profile, but the list/get sibling pair makes that distinction inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read-only listing operation and adds useful context about the kind of status information returned. It does not discuss edge cases like what happens when no tasks exist, but for a simple list tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey the purpose and the distinguishing behavioral detail without wasted words. The primary action is front-loaded, and the added sentence provides meaningful specificity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and no output schema, the description adequately explains what the agent can expect: task identity, timing fields, and running status. This is enough to invoke and interpret the result for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is nothing to document about parameters, and the schema confirms none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('list') and resource ('scheduled tasks') and enumerates what is included: interval, last execution, and next run. It further clarifies that it reports whether RSS sync, refresh, and housekeeping are actually running, which distinguishes it from the many other read tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the use case clear: it is for checking scheduled tasks and their execution status, especially whether specific maintenance activities are actually running. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to select this tool over unrelated list tools.
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:

[![radarr-mcp MCP server](https://glama.ai/mcp/servers/OrellBuehler/radarr-mcp/badges/card.svg)](https://glama.ai/mcp/servers/OrellBuehler/radarr-mcp)

Score Badge

Copy to your README.md:

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

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