Tdarr MCP Server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct resource and action; even close pairs like delete_job_report/delete_job_reports or restart_server/relaunch_server/restart_node are clearly separated by description and target. The detailed descriptions make misselection unlikely.
Naming Consistency4/5
Overall naming follows a predictable verb_noun snake_case pattern (list_x, get_x, delete_x, update_x, search_x). There are minor inconsistencies like check_for_update vs verify_folder_exists, find_duplicates instead of list_duplicates, and alter_worker_limit vs update_node, but these deviations do not obscure the general convention.
Tool Count1/5
85 tools is far beyond the 25+ threshold and creates an enormous, unwieldy surface for an agent to consider. Even if each tool is individually focused, the set as a whole is excessive and hard to navigate.
Completeness3/5
The set covers operations, monitoring, plugin management, read-only flows, job reports, backups, and run-only automations, but lacks create/update/delete tools for libraries, flows, and automations, and has no backup restore. These are notable gaps for full lifecycle management, though core transcode workflows are covered.
Average 4.1/5 across 85 of 85 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It conveys the core toggle action, but does not state side effects (e.g., interaction with the scanner, whether disabling affects ongoing or scheduled scans), persistence, permission requirements, or what the response looks like. This is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action and includes the API endpoint for precision. Every element earns its place with zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core action and all parameters are clearly specified and the schema is complete, but with no annotations and no output schema, the description omits expected return values, behavioral consequences, and any link to related tools like verify_folder_exists or the scanner workflow. Adequate for a simple toggle, but with real gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (folder, status, library_id) already documented in the schema, so the baseline is 3. The description adds no parameter-level meaning beyond the schema, but it does not need to since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Enable or disable') and a specific resource ('folder watching for one of a library's folders'), and clarifies the action beyond the tool name. It is distinguishable from sibling scan/list tools by object, but it does not explicitly name an alternative or state what it is not, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as toggle_schedule, scan_library, or verify_folder_exists. No preconditions, exclusions, or workflow context are mentioned, leaving the agent to infer when folder watching should be toggled.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It labels the operation as a search and gives the endpoint, but it does not disclose the return format, whether empty searches return all items, pagination behavior, or any potential cost or side effects. This is thin for a tool with no annotation support.
Agents need to know what a tool does to the world before 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 compact sentence that front-loads the action, identifies the resource, adds a clarifying parenthetical definition, and includes the endpoint. There is no filler or redundant phrasing.
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 two-parameter search tool with full schema coverage, the description is mostly adequate. However, with no annotations and no output schema, it omits return-value expectations and does not distinguish when to choose this over closely related search tools, leaving meaningful gaps for agents.
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%, with both parameters already clearly documented. The description adds no additional parameter-level meaning, but none is strictly required since the schema provides explicit descriptions for 'search' and 'plugin_type'.
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 ('Search'), names the resource ('flow plugins'), and additionally defines what flow plugins are ('individual nodes available inside a Tdarr flow'). It also includes the exact endpoint, making the tool's purpose unambiguous and distinct from sibling tools like search_plugins or search_flow_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as search_plugins, search_flow_templates, or list_nodes. With over 70 sibling tools, an agent is left to infer the correct choice from the name and resource definition alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It does disclose the endpoint, the HTTP method, and the returned metrics, which is useful. However, it does not describe the response structure, whether the call has side effects, or any authentication requirements, so behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the core action and resource, then adds the endpoint and the metrics returned. Every part adds information and there is no redundant or filler 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 one optional parameter and no output schema, the description is largely sufficient: it identifies the resource, the endpoint, and the returned metrics. It could be more complete by describing the output shape or timeframe format, but the schema covers the parameter and the description covers the basic return content.
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 only parameter, 'timeframe', with a reasonable description ('Timeframe to report over, as used by the Tdarr UI'), and schema coverage is 100%. The description adds no extra parameter detail such as accepted formats or example values, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the action ('Get'), the target resource ('Tdarr Server resource history'), and even provides the exact POST endpoint. It also specifies the returned metrics (CPU, memory, heap usage over time), which distinguishes it from generic status tools, though it does not explicitly contrast it with sibling tools like get_resource_stats or get_performance_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over the many similar sibling tools such as get_resource_stats or get_performance_stats. The endpoint and metric list imply a use case, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It identifies a destructive action, but does not disclose whether the deletion is permanent, whether backup data is removed from disk, whether there are any safety checks, or what the response contains. The endpoint detail is useful but does not substitute for behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that communicates the action, the target resource, and the HTTP endpoint with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive tool with no annotations and no output schema, the description is minimally sufficient for an agent to know what the tool does and what input it needs. However, it omits important behavioral context such as irreversibility, side effects, or whether confirmation is returned, which leaves a meaningful gap for a delete 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 fully documents the single 'name' parameter and already notes 'Backup name, from list_backups,' so baseline is 3. The description itself adds no parameter-level meaning beyond what the schema provides, but high schema coverage means the description does not need to compensate.
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 ('Delete a Tdarr database backup') and the resource, and includes the concrete endpoint (POST /api/v2/delete-backup). This makes it immediately distinguishable from backup-related siblings like list_backups, create_backup, get_backup_status, and reset_backup_status.
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 tool when you want to delete a backup — but it does not explicitly state when not to use it or how it compares to related backup tools. The parameter schema mentions 'from list_backups,' but the description itself provides no routing or prerequisite 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 of behavioral disclosure. It states the action and HTTP endpoint but does not disclose side effects, whether the operation is destructive or reversible, permission requirements, or what happens if no scan is running.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the action, target, and endpoint with no redundant content. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the core invocation details are present. However, the agent is left without information about what a successful kill returns or how errors are surfaced, which keeps it at a minimum viable level.
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, library_id, is documented as 'Library ID (dbID), from list_libraries'. The tool description itself adds no additional parameter 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?
The description uses a specific verb ('Stop') and a clear resource ('a library's file scanner'), and the qualifier 'mid-run' distinguishes it from sibling tools like scan_library and get_scanner_status. Even without naming alternatives, an agent can tell exactly what operation this performs.
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 'mid-run' implies the tool is appropriate when a scanner is currently executing, which gives some usage context. However, it does not explicitly state when to prefer this tool over alternatives like scan_library or get_scanner_status, nor does it mention conditions such as scanner-not-running behavior.
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 reveals that this is a POST mutation and that the schedule controls when Tdarr can process the library, but it does not disclose the response format, idempotency, or potential side effects beyond toggling the blocks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action, the scope, and the domain context. It contains no filler or redundant repetition of the tool name.
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 mutating tool with no annotations and no output schema, this is adequate but not complete. It explains the effect on the processing schedule, but leaves out return behavior and validation details such as whether start must precede end or how type maps to schedule definitions.
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 every parameter has a description. The description adds helpful context by explaining that blocks are hourly and the range is contiguous, which clarifies start/end, but it does not add per-parameter 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 states exactly what the tool does: turning a contiguous range of hour blocks in a library's weekly schedule on or off. This clearly distinguishes it from schedule-related siblings like update_schedule_block, which updates individual blocks rather than toggling a range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this tool when you need to enable or disable a range of weekly schedule blocks. However, it does not explicitly say when to prefer this over update_schedule_block or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveal the one-step increment/decrement behavior and the need for repeated calls, but it does not mention side effects, failure conditions, permissions, or what happens to existing workers when the limit changes.
Agents need to know what a tool does to the world before 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 core behavior is front-loaded, and the repeated-call guidance earns its place by preventing misuse.
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 three-parameter mutation tool, the description is largely complete: it states the action, scope, endpoint, and the key nuance about repeated calls. A small gap is the lack of any note about return values or error conditions, but this is minor given the simple contract.
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 each parameter already has a clear description in the schema. The tool description adds no additional parameter-level meaning beyond confirming the one-step directionality, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: increasing or decreasing by one the number of workers of a given type on a node. It is specific about the verb, resource, and scope, though it does not explicitly differentiate itself from sibling tools like kill_worker or cancel_worker_item.
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 used to adjust worker limits incrementally, and it explicitly instructs to call repeatedly to move the limit by more than one. However, it provides no explicit guidance about when to choose this tool over alternatives such as kill_worker or restart_node.
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 behavioral disclosure burden. It does disclose that this is a read-style status operation and includes the HTTP endpoint, but it does not describe side effects, failure behavior, or what happens when no backup is in progress.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loads the action and resource, and then provides the exact endpoint in parentheses. Every part is useful and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, invocation is trivial, but the tool has no output schema and the description does not describe what status information is returned or how the status is represented. It also doesn't clarify how this tool relates to reset_backup_status or list_backups, leaving some gaps for an agent trying to fully understand the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing meaningful for the description to add about parameters. The description correctly stays silent on parameters, matching the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it retrieves the status of a backup that is currently in progress. It is clearly distinct from siblings like list_backups or create_backup, though it does not explicitly differentiate itself from get_status or other status-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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'backup in progress' implies when this tool should be used, but the description provides no explicit when-to-use or when-not-to-use guidance. It also doesn't mention alternatives such as get_status, list_backups, or reset_backup_status, leaving the agent to infer the right context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The List verb signals a non-destructive read operation and the scope (defined on the server) is clarified, but the description adds nothing about output shape, pagination, or how the detailed parameter changes behavior beyond what the schema already says.
Agents need to know what a tool does to the world before 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 zero wasted words. The first states the action and the return fields; the second ties flows to libraries via flowId, which is genuinely useful context. Each 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 listing tool with one optional boolean and no output schema, the description covers the core usage and explains the library relationship. Minor gaps remain: the meaning of size is undefined, and the sibling get_flow is not mentioned as the alternative for fetching an individual flow's details, but an agent can still invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100 percent; the detailed boolean parameter is fully documented in the schema as returning the full flow graphs instead of the summary. The tool description itself adds no 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List), a resource (Tdarr flows defined on the server), and the returned fields (ID, name, description, size). It clearly identifies what the tool does, though it does not explicitly differentiate it from the sibling get_flow.
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 line about a library's flowId coming from list_libraries gives useful domain context, implying when list_flows becomes relevant. However, there is no explicit when-to-use or when-not-to-use guidance, and the natural alternative get_flow for retrieving a single flow is never mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it does not state side effects, overwrite behavior, failure modes, required permissions, or what the response contains. It also introduces an 'action' concept that does not map cleanly to any parameter in the schema, which can mislead an agent about how to provide the execution logic.
Agents need to know what a tool does to the world before 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 at three sentences, front-loads the endpoint and scope, and adds a useful read_plugin/save_plugin workflow without redundancy. Every sentence contributes.
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 12-parameter creation tool with no annotations and no output schema, the description is only minimally complete. It provides useful workflow context, but it omits expected response behavior, overwrite/duplicate handling, and a clear mapping from the abstract 'action' to the actual preset/operation fields.
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 schema already documents all parameters well. The description adds little beyond framing conditionals as matching logic, and the reference to 'action' is not tied to preset, operation, or any actual schema field.
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 what the tool does: 'Create a basic local classic plugin' and names the exact endpoint. It also scopes the tool to 'basic' and 'local' plugins, which helps distinguish it from plugin-read, plugin-save, and community-plugin siblings.
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 concrete workflow guidance: create the basic plugin here, then refine it with read_plugin and save_plugin for anything beyond a simple condition/action pair. It names those sibling tools explicitly, though it does not cover every alternative scenario such as community plugins or plugin verification.
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, and it does disclose the return format: one summarized record per match with listed fields. However, it is silent on the 'detailed' parameter, which changes results to full records with ffProbe and MediaInfo data, so the stated return shape is incomplete for one valid invocation mode.
Agents need to know what a tool does to the world before 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 states the action and criteria, the second states the endpoint and return shape. All 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.
Completeness3/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 the default summarized mode, but it does not mention that setting 'detailed' to true returns full ffProbe/MediaInfo records instead of the summarized record. Since there is no output schema, the description should carry more of this return-shape burden, and it also omits any mention of result limits or pagination.
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 some context by clarifying that 'search' matches against filename/file path and that size filters are supported, but it does not substantially add meaning beyond the schema. The slight wording shift from 'file path' in the schema to 'filename' in the description is minor but not clarified.
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 ('Search'), a specific resource ('Tdarr file database'), and the key filter dimensions (filename substring, file size). It also names the endpoint and describes the returned record shape, making it easily distinguishable from sibling search tools like search_plugins or search_job_reports.
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 find files in the Tdarr database by substring or size. However, it does not explicitly state when not to use it or name alternatives such as get_file, query_table, or query_database, so an agent must infer routing from context rather than being told.
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 the key destructive fact that the report is removed from both the database and disk, which is important context. However, it does not mention irreversibility, permissions, or what happens if the job_id does not exist.
Agents need to know what a tool does to the world before 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, scope, and endpoint efficiently, and every word contributes to understanding the tool's 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 simple delete tool with one parameter and no output schema, the description is largely sufficient. It explains what is deleted and where. The only notable gap is the lack of explicit warning that deletion is permanent, which would be useful for a destructive operation without annotations.
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 fully documents the single job_id parameter as 'Job ID of the report to delete.' The description adds no parameter-specific meaning beyond that, 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 clearly states a specific action ('Delete one job report'), the resource ('one job report'), and the scope ('from the database and from disk'). The singular 'one' distinguishes it from the sibling delete_job_reports, making the tool's purpose explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for deleting a single job report, and the presence of delete_job_reports as a sibling suggests a plural/bulk alternative. However, it does not explicitly state when to use this tool versus delete_job_reports or provide any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the return payload composition (ffProbe, MediaInfo, transcode/health history, queue status), which is valuable given the absence of an output schema. However, it does not explicitly state that the operation is read-only/idempotent or describe behavior when file_id does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with the core verb+resource front-loaded, followed by an em-dash list of contained data. There is zero filler, and every element — scope ('one file', 'full record') and content enumeration — 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 single-parameter getter with no output schema and no annotations, the description covers the essentials: scope and the composition of the returned record. It omits error handling and alternative routing, but those are minor for a read-oriented tool of this simplicity, so it is nearly complete rather than merely adequate.
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 file_id parameter description already provides a non-obvious detail — that the ID is actually the file's full path as Tdarr Server sees it. The tool description adds no parameter-level meaning, but at full schema coverage 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 verb and resource: 'Get one file's full database record', then enumerates the record's contents (ffProbe output, MediaInfo, transcode and health check history, queue status). The 'one file' and 'full record' scope clearly differentiates it from siblings like search_files, get_job_report, and list_file_job_reports in a large toolset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied — whenever a single file's complete database record is needed — but the description never names an alternative or states when NOT to use it. With over 100 siblings (e.g., scan_file_details, get_job_report, search_files), explicit routing guidance would materially help an agent choose 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 provided, the description carries the behavioral disclosure burden. It does explain what the call returns by listing the setting categories, and 'Get' implies a read-only operation. However, it does not disclose whether special permissions are required, how invalid library IDs are handled, or whether the response has a particular structure beyond the listed fields.
Agents need to know what a tool does to the world before 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 with the primary action front-loaded. The enumeration of settings is compact and every word adds value, with no redundant filler or restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter getter with no output schema, the description adequately explains what the tool returns by listing the setting categories, and the schema covers the parameter source. It does not address edge cases like missing libraries or permission failures, but the low complexity of the tool makes that a minor gap rather than a critical omission.
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 covers 100% of the parameter documentation, with library_id described as 'Library ID (dbID), from list_libraries'. The description adds no new parameter semantics, but none are needed because the schema already provides clear meaning and provenance for the only required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one library's full settings record'), and it enumerates the setting categories included, such as folders, filters, schedule, and plugin stack. This clearly distinguishes it from sibling tools like list_libraries, which lists libraries rather than fetching a single library's settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need a single library's full settings. However, it does not explicitly state when not to use it or mention alternatives like list_libraries for listing libraries or scan_library for scanning actions. Usage context is inferable but not spelled out.
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 full behavioral burden. It does disclose that this is a POST endpoint and that it aggregates stream-level facts across the library's files, implying a read-only statistical operation. It does not reveal whether results are computed live, cached, or what the aggregation granularity is, but for a simple stats tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The verb and resource are front-loaded, followed by the endpoint and a compact list of what the statistics contain. Every element 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-optional-parameter tool with 100% schema coverage, the description sufficiently explains the tool's scope and return content. It could be more explicit about whether the output is counts, arrays, or a structured breakdown, but the provided information is enough for an agent to invoke it correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: library_id is fully described with its optionality and default of all libraries. The description adds no new parameter-level semantics beyond mentioning 'the library's files,' 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 names a specific verb and resource ('Get stream-level statistics'), cites the endpoint, and enumerates the exact data categories returned: codecs, languages, and stream types. This clearly differentiates it from sibling stats tools like get_resource_stats or get_performance_stats by focusing on stream-level content.
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 by listing the data returned, so an agent can infer it is appropriate when stream composition details are needed. However, it does not explicitly state when to prefer this tool over alternatives such as get_resource_stats or get_performance_stats, nor does it describe 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?
No annotations are provided, so the description carries the behavioral burden. The word 'Read' implies a non-mutating operation and the endpoint is supplied, but there is no explicit mention of side effects, return content, or authentication needs. This is adequate for a simple read but not highly 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 filler. The core purpose is front-loaded, and the usage note adds necessary context 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 simple three-parameter read tool, the description plus fully documented schema is largely complete: it says what the tool does, when to use it, and where the IDs come from. The main missing piece is explicit differentiation from the sibling get_job_report, and there is no output schema to clarify the return shape.
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%, as each of the three parameters has a description already. The tool description adds no parameter-level detail 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.
Purpose4/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 ('one report file belonging to a job'), and explicitly links to list_file_job_reports. It does not explicitly contrast with the sibling get_job_report, so it stops just short of fully distinguishing among all report-related 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?
It gives a concrete when-to-use scenario: individual files from list_file_job_reports when a job produced more than one report. However, it does not mention get_job_report or state an explicit when-not-to-use condition, so alternatives are only partially addressed.
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 meaningfully discloses that running workers are interrupted and their files are requeued, which is the key disruptive side effect of the operation. It does not cover auth, failure modes, or response behavior, but the core behavioral consequence is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler: the first names the operation and endpoint, the second explains the behavioral effect. Every sentence earns its place and the key 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?
For a simple, one-parameter action with no output schema, the description supplies the essential information: what happens, the endpoint, and the effect on workers and files. It lacks explicit expected-response details and usage routing, but the necessary invocation context is otherwise 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 description coverage is 100%, and the single parameter node_id is already described as coming from list_nodes. The description adds no additional parameter-level meaning, but because the schema fully documents the parameter, 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 ('Restart a node process'), identifies the resource, and includes the exact HTTP endpoint. It also explains the immediate consequence, which makes the tool's purpose unambiguous and distinguishable from sibling tools like restart_server and restart_ui.
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 for when to use this tool instead of alternatives such as disconnect_node, update_node, restart_server, or kill_worker. The side effect of requeueing files hints at one scenario, but there is no explicit condition, prerequisite, or exclusion stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state the core effect (enable/disable a block) and the HTTP method (POST), which is helpful, but it does not mention side effects, reversibility, or what happens after the update.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, scope, and endpoint without wasted words. Every element contributes to understanding 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 three-parameter mutation with full schema coverage, the description is nearly complete. It identifies the operation and resource clearly; only minor details like post-update effects or response behavior are absent.
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 clearly. The description adds no new parameter-specific meaning beyond what the input 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 ('Enable or disable'), names the exact resource ('a single block in a library's weekly schedule'), and includes the API endpoint. It clearly distinguishes itself from broader schedule tools like toggle_schedule by emphasizing 'single block'.
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 enable or disable one schedule block. However, it provides no explicit guidance about alternatives, prerequisites, or situations where this tool should not be used.
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 reveals the HTTP method (POST) and that it returns internal performance timings, but it does not explicitly state that the operation is read-only or describe any side effects or output format. For a low-risk stats tool this is adequate, though not deeply 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 a single efficient sentence that front-loads the action and resource, then adds the endpoint and use case. It contains 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 no-parameter statistics tool, the description sufficiently covers what the tool does and when to use it. It does not describe the response structure, but no output schema exists and the nature of the returned data (timings) is already indicated. This is complete enough for the tool's low 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 and an empty schema, so the 100% schema coverage is trivial. The baseline for 0-parameter tools is 4, and the description correctly adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Get Tdarr internal performance statistics,' and clarifies the content as 'timings for server operations.' It also states the use case ('diagnose a slow server or database'), which gives functional clarity. However, it does not explicitly distinguish itself from sibling diagnostic tools like get_resource_stats or get_server_time, so it falls short of the top tier.
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 usage context: 'used to diagnose a slow server or database.' This tells an agent when to invoke the tool. It lacks explicit alternatives or exclusions, but the stated diagnostic purpose is enough to guide 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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It communicates that the tool is pollable and that scanning was started elsewhere, but it does not explicitly state that the call is side-effect free, what the progress payload looks like, or when polling should stop. These are useful inferences but not explicit disclosures.
Agents need to know what a tool does to the world before 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 core purpose and endpoint are front-loaded, and the usage instruction follows immediately with the correct sequential relationship to scan_library.
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 well-documented parameter, and the description gives a clear use sequence after scan_library. However, there is no output schema, and the description never explains what the returned progress data looks like or how an agent can tell the scan is complete, leaving an important gap for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, library_id, is already fully documented in the schema with a description including 'from list_libraries'. The description's reference to 'a library's scanner' adds no meaningful semantic detail beyond what the schema already 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 uses a specific verb and resource: 'Get the progress of a library's file scanner', and even names the exact endpoint. Its focus on scanner progress clearly distinguishes it from generic siblings like get_status and get_job_report, and it is naturally paired with scan_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?
The instruction 'Poll this after scan_library' gives explicit, actionable when-to-use guidance and makes the relationship to the initiating sibling clear. It does not mention when not to use it or compare with alternatives such as kill_scanner, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. 'Get' and the stats endpoint imply a read-only operation, and the purpose of checking busy/idle adds interpretive context. However, it does not disclose details like response format, whether any filtering occurs, or any operational caveats. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states exactly what the tool returns, the second gives the practical use case. The key information is front-loaded and every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and no output schema. The description conveys the nature of the result ('history of running worker counts by type') and the use case. However, it does not describe the response structure, the default behavior when timeframe is omitted, or the granularity of the history, leaving some ambiguity 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 the schema already documents the only parameter, timeframe. The description adds only a slight contextual link between 'over a period' and the timeframe parameter, not meaningfully more than 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 uses a specific verb ('Get'), a clear resource ('history of running worker counts by type'), and even includes the exact endpoint. It clearly differentiates from siblings like get_worker_verdict_history and get_resource_history by focusing on worker-count activity and the busy/idle use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use it to check whether workers were actually busy over a period, or idle waiting for work.' It clearly states when to use the tool, though it does not mention alternatives or exclusions, so it falls short of a perfect 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?
No annotations exist, so the description carries the full disclosure burden. It does disclose the actual operations performed (ExifTool, MediaInfo, closed-caption scan) and that results are returned, which is meaningful. However, it never explicitly states the operation is read-only/side-effect-free, and the runtime cost caveat for closed_captions lives only in the schema rather than the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the primary action front-loaded and zero filler. The parenthetical POST endpoint is mildly redundant for an MCP consumer since the tool name already conveys the operation, but it is short and does not detract from readability.
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 four-parameter tool with full schema coverage, the description plus schema cover correct invocation: what scans run, their defaults, and path scoping. The main gap is that no output schema exists and 'return the results' gives no shape of the return value, but this is a minor omission for a straightforward scan utility.
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 each boolean parameter already documents its default, so the baseline is 3. The description adds a small but real semantic clarification for file_path by saying the path need not be in a library, but it contributes nothing beyond the schema for the three scan-type flags.
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: it runs ExifTool, MediaInfo and/or a closed-caption scan against a single file and returns results. The clause 'Works on any path the server can read, whether or not it is in a library' clearly differentiates it from library-scoped siblings like scan_library, so an agent can distinguish them at a glance.
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?
Gives clear context: this is for single-file scans at arbitrary server-readable paths, including outside a library. That implicitly routes the agent away from scan_library and rescan_file, but it never names an alternative or states an explicit when-not-to-use exclusion, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It does reveal this is a mutating POST that resolves a pending transcode, but it does not state whether the verdict is reversible, what happens when a verdict is applied, or what error/success behavior to expect. It is acceptable but not deeply 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?
Single sentence with no filler: action, resource, endpoint, and resolution types are all present and front-loaded. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter write operation, the workflow context is reasonably complete and the schema covers parameter meanings. However there is no output schema or annotation, and the description does not say what the tool returns, whether the action is permanent, or what side effects follow a reject/resolve. Those are meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters already have descriptions in the schema: item is the staged record from query_table, and verdict is the UI-style verdict string. The description adds general verdict categories ('accept, reject or otherwise resolve') but does not enumerate exact acceptable verdict values or clarify item structure. Baseline 3 applies because schema coverage is high.
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 clear action verb ('Take action') on a specific resource ('item staged for user approval'), and spells out the outcomes: accept, reject, or otherwise resolve a transcode waiting for a decision. The mention of the POST endpoint and the distinction from read-only siblings such as query_table make its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use this tool when an item is staged for user approval and a transcode decision is pending. It does not explicitly name alternatives or when-not-to-use conditions, but the workflow context is strong enough to route an agent 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?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the update object is merged into each listed file and gives concrete examples of effects. However, it does not mention potential side effects, failure behavior, permissions, or whether changes are reversible.
Agents need to know what a tool does to the world before 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 core action and endpoint are front-loaded, and the examples are compact and directly informative.
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 two-parameter tool with full schema coverage, the description provides enough to invoke correctly: what it does, how it applies updates, and representative field values. It is slightly incomplete because there is no output schema and no mention of return values or error behavior, but these are not critical for basic selection and 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 parameters are already documented. The description adds value with concrete examples of valid update payloads ({ holdUntil: 0 } and { TranscodeDecisionMaker: 'Queued' }), clarifying the shape and purpose of the updates object beyond the generic schema text.
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 ('Update'), a specific resource ('fields on specific file records by ID'), and includes the endpoint. It is clearly distinct from siblings like bulk_delete_files because it targets field updates rather than deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples imply usage for releasing holds and requeueing files, but no explicit guidance is given about when to prefer this tool over related siblings like requeue_files or bulk_delete_files. Usage context is present but not directly contrasted with 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?
With no annotations, the description carries the disclosure burden. It does reveal that the tool is safe by default and that applying an update requires a relaunch, but it does not discuss side effects of reset_updater, the destructive nature of installation, or what happens if apply_update is set without download_update. The description is adequate but not fully 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 focused sentences: the first front-loads the core purpose and default behavior, the second covers optional modes and the required follow-up. There is no filler or redundant prose.
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 three-boolean tool, the description covers the main workflow, optional modes, and sequencing, while the schema fills the parameter details. However, there is no output schema, and the description does not describe what a check returns, nor does it mention reset_updater, so a couple of minor gaps remain.
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 every parameter is already documented with its default and meaning. The description restates download_update and apply_update semantics and adds the relaunch dependency, but that dependency is also present in the schema, so it adds little beyond what structured data already 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 states a specific action ('check whether a Tdarr update is available') against a named resource and includes the exact endpoint. The 'defaults to a check only' phrasing also clarifies the tool's scope, distinguishing it from the install/apply behavior it can optionally trigger.
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 the default check-only behavior, when to set download_update and apply_update, and explicitly requires calling relaunch_server afterwards. It does not explicitly contrast this tool with sibling update tools like update_node, but the workflow guidance is strong enough for an agent to use it 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 behavioral burden. It discloses the core mutation—creating a 30-second sample—and that the sample path is returned. However, it does not clarify whether a new file is persisted on disk, whether the original file is modified, or whether the sample is temporary.
Agents need to know what a tool does to the world before 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 action, duration, endpoint, return value, and use case are all packed compactly and front-loaded. 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 tool is simple with a single param and no output schema, so the description is nearly complete: it says what is created, how long the sample is, and what is returned. Minor gaps like failure behavior and output format are not necessary at this complexity level.
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 describes the only parameter (`file_path` as 'Full file path, as Tdarr Server sees it'), so schema coverage is 100%. The description adds little beyond the word 'file', which is the baseline scenario for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a 30 second sample of a file' and explicitly mentions the POST endpoint. It also states the return value (path of the sample), which makes it clearly distinguishable from sibling inspection tools like get_file or search_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 description gives a concrete use case: 'testing a plugin stack or flow on a short clip before running it on a whole library.' It does not mention alternatives or when not to use it, but the intended context is clear enough for an 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 full burden of behavioral disclosure. It clearly warns that this deletes real media and removes the file from the database, which is critical for a destructive operation. It does not mention irreversibility explicitly, but 'deletes real media' strongly implies permanence.
Agents need to know what a tool does to the world before 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 deliver the core action, the resource affected, and the critical user-confirmation warning. No filler or redundancy, and the most important behavioral warning is placed at the end for emphasis.
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 destructive tool with a fully documented schema, the description is nearly complete. It covers what the tool does, that it affects real media, and that confirmation is required. The only minor gap is not explicitly stating the operation cannot be undone, though this is strongly implied.
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, documenting file_id as the full path from search_files. The description does not add 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 states a specific action ('Delete one file from disk') and a specific resource (file, Tdarr database), and clarifies this is the single-file variant as opposed to bulk deletion. The API endpoint is also included, making the tool's intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is for deleting a single file and explicitly instructs to confirm with the user first. However, it does not mention alternatives such as bulk_delete_files or delete_unhealthy_files, so an agent gets no explicit guidance on when to choose this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the most important non-obvious side effect — that deleting a referenced plugin leaves that stack broken — which goes beyond what the name alone implies. However, it doesn't disclose other behavioral traits: whether deletion is reversible, what happens if the plugin_id doesn't exist, or what the response looks like.
Agents need to know what a tool does to the world before 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 zero waste. The primary action and endpoint are front-loaded in the first sentence, and the second sentence carries the crucial risk warning and precaution. 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 destructive tool with 2 fully-documented parameters and no output schema, the description is nearly complete: purpose, endpoint, key risk, and mitigation are all present. The only gaps are minor — no statement of success/error response format and no mention of reversibility — which an agent could infer from the POST endpoint and the existence of create_plugin/copy_community_plugin_to_local siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both plugin_id and plugin_source already described, so the baseline is 3. The description adds no parameter-level detail beyond the schema, but it doesn't need to — the schema fully documents both required fields including the allowed values for plugin_source.
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 — 'Delete a plugin from the server' — plus the exact HTTP endpoint. This cleanly distinguishes it from the many plugin-related siblings (read_plugin, save_plugin, create_plugin, verify_plugin, manage_library_plugin) without needing to inspect any of 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 gives clear context and an explicit when-not-to-proceed condition: deleting a plugin a library's stack still references breaks the stack. It names a concrete sibling tool (list_libraries) to consult first. It stops short of a full 5 because it doesn't route between overlapping tools (e.g., using manage_library_plugin to detach a plugin first rather than deleting it outright).
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 exist, so the description carries the full burden. It discloses the forceful nature and the stale-node cleanup scenario, but it does not mention side effects such as whether a live connection is terminated, whether the action is reversible, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading: the action and purpose come first, and the HTTP endpoint adds useful context without bloat. 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 tool with no output schema and no annotations, the core usage context is well covered. Missing details like return values or error conditions are minor, though a bit more side-effect clarity would make it fully 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 node_id parameter is already documented as 'Node ID, from list_nodes.' The description adds no parameter-level detail, 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 states a specific verb ('forcefully disconnect'), a clear resource (node), and the trigger condition (node shows as connected but is actually gone). The HTTP endpoint reinforces the operation, and the purpose clearly distinguishes it from siblings like restart_node or update_node.
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 an explicit use case: 'Use it to clear a node that shows as connected but is actually gone.' This provides clear context for when to choose this tool, though it does not name alternatives or exclusion 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?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals that results are bucketed over time and filterable, and the 'Get' wording implies a read-only stats operation, but it does not explicitly state the operation is non-mutating, mention auth requirements, or describe pagination/output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main purpose, bucketing behavior, endpoint, and filtering use case are all front-loaded and concise. Every clause adds useful information, and the endpoint path is included for precise invocation.
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 stats tool with zero required parameters and a fully documented schema, the description provides enough context to invoke the tool meaningfully. The lack of an output schema means return-structure details are not covered, but the description's 'space saved over time, bucketed' gives reasonable expectation of the result shape.
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?
All five parameters have schema-level descriptions with 100% coverage, so the schema already documents the filter semantics. The description adds interpretive value by connecting filters to the goal of determining which component actually saves storage, but it does not add 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 names a specific resource — 'space saved by transcoding' — and a specific action ('Get'), while adding the temporal 'bucketed' aspect. It is clearly distinct from sibling stats tools like get_pie_stats or get_resource_stats because of the explicit 'space saved by transcoding' target.
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: to see which library, node, worker type, or plugin actually saves storage. It does not explicitly name alternatives or state when not to use it, but the filtering guidance effectively communicates the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that results are bucketed over time and include successes, errors, and not-required counts, which is useful behavioral context. However, it doesn't describe response structure, default scoping when no params are provided, or details about what 'not-required' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, includes the endpoint, and then immediately gives the practical use case.
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 stats query with four optional well-documented parameters, the description covers the main purpose, the data returned, and the scenario for use. Minor gaps remain around default behavior and exact response shape, but nothing blocks an agent from correctly invoking it.
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 general context about bucketed counts but doesn't add details about parameter format, constraints, or default behaviors beyond what the schema says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a specific resource ('transcode and health check outcomes over time'), and the key data returned ('successes, errors and not-required counts'). It also includes the exact API endpoint, making the purpose unambiguous and easy to distinguish from broader stats tools like get_worker_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?
The description gives clear context: 'The quickest way to see whether a change made failures go up.' This tells an agent when to prefer this tool. It doesn't explicitly name alternatives or exclusions, but the use case is stated clearly.
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 explaining behavior. It makes the operation a read-only list, names the scope ('configured' libraries), and specifies the returned fields and the significance of the _id. It does not explicitly describe the summary-vs-full-record behavior of the detailed parameter, though that is documented in the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the first states the action and output fields, and the second provides the most important usage fact. 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 one-parameter list tool with no output schema, the description is largely complete: it enumerates the output fields and points out why the tool matters. It stops short of explicitly stating the summary default and that detailed=true swaps to full records, but the input schema covers that 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?
Schema description coverage is 100% for the single optional 'detailed' parameter, so the schema already explains its meaning. The description adds no parameter-level detail, which is acceptable under the high-coverage baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('List the configured Tdarr libraries') and enumerates the returned fields, so an agent knows exactly what it does. It does not explicitly differentiate from the singular get_library sibling, although the plural 'configured libraries' and the dbID note make the role mostly clear.
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 a concrete use case: this tool returns the library _id/dbID that every other library and file tool needs, so an agent should call it first when it needs identifiers. It provides clear context but no explicit when-not-to-use instructions or a named alternative such as get_library.
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 disclosure burden. It does state the three actions and the basic/non-plugin scope, but it does not mention side effects, persistence, idempotence, authorization requirements, or what happens when adding a codec that already 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 concise sentences, with the action and target front-loaded and the non-plugin clarification earning the second sentence. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple five-parameter mutation tool with fully documented enums and schema, the description plus input schema provides enough context for an agent to select and invoke it correctly. The lack of an output schema and absence of behavioral caveats keep it from a 5.
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 mostly restates the action semantics already present in the schema and adds no extra detail about status handling, accepted formats, or edge cases.
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 phrase ('Add, remove or toggle'), a precise resource ('a codec in a library's basic transcoding include/exclude list'), and explicitly scopes it to basic non-plugin video/audio transcode settings. This clearly differentiates it from plugin-related tools such as manage_library_plugin.
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 that the tool applies only to the basic non-plugin transcode settings, which implicitly routes the agent away from plugin settings and related sibling tools. It does not explicitly name alternatives or state when not to use it, so it falls short of a 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?
No annotations are provided, so the description carries the full burden. It clearly discloses the three actions and the scope (classic plugin stack only), plus add prerequisites. However, it does not mention side effects, reversibility, permission requirements, or behavior when the operation fails, which would be valuable for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences, front-loaded with the core action and followed by high-value details: requirements, ID source, and the flow-library exclusion. 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 six-parameter tool with no output schema and no annotations, the description covers action modes, prerequisites, ID sourcing, and a key boundary condition. The schema handles parameter-level details. It does not mention response or error behavior, but that is 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 coverage is 100%, so the baseline is 3. The description adds a little by noting that source and position are required for 'add' and that plugin IDs come from search_plugins, but the schema already documents these parametric relationships. It does not significantly augment the schema's parameter descriptions.
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 and resource: 'Add, remove or enable/disable a classic plugin in a library's plugin stack.' It also distinguishes the tool from flow-plugin management by noting that flow-based libraries are not affected, making its scope clear even among many similar plugin 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: adding requires a source and stack position, plugin IDs should come from search_plugins, and flow-based libraries are explicitly out of scope. It does not explicitly name an alternative tool for flow-based libraries, but the usage boundary and prerequisites are clearly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It conveys the read-only nature through the verb 'Read', discloses the endpoint, and clarifies that source handling differs for Community vs Local plugins. However, it does not disclose error behavior, permissions, or explicitly confirm an absence of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, ~50 words, zero filler. The action and endpoint are front-loaded, followed by the two use cases. Every sentence earns its place with no redundant marketing or restating of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter read tool with no output schema and no annotations, the description covers the essential context: what it does, when in the workflow to use it, and that the result is plugin source text. Slightly more detail on response format or failure modes would push it to 5, but nothing critical is missing 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 the schema already documents plugin_id ('from search_plugins') and plugin_source ('Community' or 'Local'). The description adds marginal value by mapping plugin_source values to concrete use cases, but it does not introduce new parameter-level semantics beyond the schema baseline.
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 ('Read') and resource ('the source of a classic plugin'), and includes the concrete HTTP endpoint (POST /api/v2/read-plugin-text). The two use cases — reading a Community plugin before adding it to a library, or a Local plugin before editing it — clearly distinguish this from sibling tools like save_plugin, create_plugin, verify_plugin, and copy_community_plugin_to_local, so an agent can tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: use this when you need to understand a Community plugin before adding it to a library, or a Local plugin before editing it. It does not explicitly name alternatives or when-not-to-use conditions — for instance, it doesn't say to use search_plugins for discovery — so it stops one point short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It discloses the immediate effect (refreshes ffProbe data and queue status) and implies mutation via the POST method. However, it does not mention side effects on an in-progress queue entry, reversibility, failure modes, or what response to expect — meaningful gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The primary action and purpose lead, the endpoint is tucked into parentheses, and the usage condition is a clean second sentence. 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 2-parameter action with fully documented schema, the description adequately covers what the tool does and when to call it. The remaining gap is the absence of any mention of the response shape or behavior when the file is not found or is mid-processing — with no output schema, a brief note on the return would fully close it.
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 both parameters well — file_id even tells the agent where to source the value ('from search_files') and library_id explains it is the dbID. The description adds no parameter information beyond the schema, landing at the baseline of 3.
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 ('Rescan') with a scoped resource ('a single file') and states the exact purpose (refreshes ffProbe data and queue status). The phrase 'single file' clearly distinguishes it from sibling scan_library, and the endpoint reference adds precision. This is a model of purpose clarity.
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 an explicit trigger condition: 'Use it after changing a file on disk outside Tdarr.' This tells an agent exactly when the tool is appropriate. It does not name alternatives or state when not to use it, so it falls just short of the 5-level explicitness.
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 must carry behavioral disclosure. It clearly states that a help command is executed and its output returned, and frames it as a read-only capability check. However, it does not explicitly confirm the operation is side-effect free or note any restrictions on the 'text' argument, which is a meaningful gap for a tool that runs a binary server-side.
Agents need to know what a tool does to the world before 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 endpoint and core action are front-loaded, followed immediately by a practical usage example. 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 two-parameter tool with no output schema, the description provides enough to understand its purpose, behavior, and intended use. It does not explain the exact output formatting or error conditions, but those are minor for a help-command utility whose output is simply returned. The sibling list contains no comparable tool, so extra disambiguation is unnecessary.
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%, with both 'mode' and 'text' already described clearly. The description adds useful context about checking encoders/filters/presets, but it does not provide additional parameter-level semantics beyond the schema. The baseline of 3 is appropriate when the schema carries the parameter documentation burden.
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') and resource ('ffmpeg or HandBrake help command on the server') and clarifies that it returns the output. It distinguishes itself from all sibling tools, none of which execute help commands, and explicitly names the POST endpoint.
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, explicit guidance on when to use the tool: to check which encoders, filters, or presets the server's binaries actually support before writing transcode arguments. It does not state when not to use it or list alternatives, but no similar sibling exists, so exclusions are not necessary.
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 transparently presents the operation as a search and reveals the HTTP endpoint, implying a read-only style operation. However, it does not state whether results are paginated, require authentication, or what the response structure looks like, so the transparency is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences carry exactly the needed content: what the tool searches, the endpoint, and why an agent would use it. There is no filler, and the core purpose 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 two-parameter search tool with no output schema and no annotations, the description is largely sufficient. It names the endpoint, describes the resource, and frames the use case. It could add explicit return-value details, but the statement that templates show how official flows wire nodes gives the agent enough understanding of what will come back.
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 both parameters, including the useful note that 'search' can be empty to list everything. The tool description adds context that the search targets ready-made templates, but it does not add meaning beyond what the schema already 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 opens with a specific verb and resource: 'Search the ready-made flow templates' and even gives the exact endpoint. It also clarifies what these templates are ('how the official flows wire their nodes together'), which distinguishes them from related sibling tools like search_flow_plugins that search plugins, not flow compositions.
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 when-to-use trigger: 'Read one before designing a flow from scratch.' This tells the agent the intended context for the tool. It does not explicitly name alternatives or exclusions, but the context is specific enough to guide 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 full behavioral disclosure burden. It discloses the HTTP method, the resource being searched, and the exact fields returned, which covers the core behavior. However, it does not explicitly state that this is read-only, mention authentication needs, or describe pagination/result limits, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before 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: it states what the tool does, gives the endpoint, and lists the return fields in two sentences. Every clause 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?
The description is appropriately complete for a search tool: it explains what is searched, what fields are returned, and how the results connect to manage_library_plugin. It does not mention pagination, sorting, or result limits, and it does not call out search_flow_plugins as the alternative for flow plugins, so a small gap remains, but the core operational context 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 describes both parameters fully: search string and plugin_type filter, with an example for plugin_type, so 100% schema coverage earns a baseline of 3. The description adds no additional parameter-level meaning beyond what the schema already 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 states a specific verb and resource: 'Search the classic plugins available to the server', and even names the HTTP endpoint. It also lists the exact return fields, which makes the tool's purpose unmistakable and distinguishes it from related tools like search_flow_plugins.
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 this tool by explaining that the returned source and ID are needed by manage_library_plugin. It does not explicitly mention alternatives or exclusion criteria, but the intended use case is clear enough for an agent to route to it appropriately.
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 exist, so the description carries the full disclosure burden. It adds useful behavior context: the HTTP method (POST), the endpoint, and the return type (boolean). However, it does not state error behavior, whether any state changes occur, or permission requirements — though for an existence check these risks are low, the disclosure is not comprehensive.
Agents need to know what a tool does to the world before 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 wasted words. The core action is front-loaded, followed by the return type and a usage hint. Every clause earns its place; the endpoint reference adds precision without bloat.
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 2-parameter boolean check with no output schema and no annotations, the description covers the essentials: purpose, endpoint, return type, and when to call it. Minor gaps remain — notably the meaning/behavior of a false result versus an error — but nothing critical is missing 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% — both community and plugin_id are described in the input schema, so baseline 3 applies. The description adds contextual meaning (classic plugin, library stack) that indirectly clarifies plugin_id's role, but it provides no param-specific detail beyond what the schema already documents.
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: 'Check whether a classic plugin exists on the server.' The 'classic' qualifier distinguishes it from flow-plugin tools (search_flow_plugins), and 'exists' differentiates it from verify_folder_exists (folder vs plugin) and search_plugins (searching vs existence check). The endpoint and boolean return tighten the definition further.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context: 'use it before adding a plugin to a library's stack.' This positions the tool as a pre-condition check. However, it does not name alternatives or state when not to use it (e.g., when to prefer read_plugin or search_plugins), so it stops short of the full 5.
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 discloses that this is a GET (read-only) operation, states the readiness condition it verifies, and describes the return shape as { ready, reasons }. It does not detail the contents of reasons, but that is acceptable for this simple readiness probe.
Agents need to know what a tool does to the world before 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 the purpose, endpoint, return structure, and usage timing with zero filler. Every clause 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 tool with one optional parameter and no output schema, the description is complete: it explains what the tool checks, when to call it, the HTTP endpoint, and what it returns. No critical information 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 only parameter, number_of_nodes, is already fully documented in the schema with 100% coverage. The description adds no extra parameter detail, 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.
Purpose4/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 checks server dispatch readiness and completed server/node plugin setup, and even names the endpoint. It is clearly distinguishable from most siblings, though it does not explicitly differentiate itself from the similarly named get_status.
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 explicit invocation context: 'call it before queueing work after a restart.' This provides clear timing guidance for the agent, but it does not mention exclusions or alternatives such as get_status or get_server_time.
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 disclosing behavior. It correctly frames the operation as fetching package metadata despite the POST endpoint, which reduces concern about mutation. However, it does not mention potential side effects, response size, or error behavior; for a zero-parameter read this is a moderate but not severe gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and resource, then adds the endpoint and the returned content. Every part 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 zero-parameter tool with no output schema and low complexity, the description fully conveys what the agent will get (versions and artifacts) and why the tool exists. No additional operational detail is necessary 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?
There are no parameters, so there is nothing for the description to add beyond what the schema already states. The description focuses on the resource semantics instead, which is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a specific resource ('Tdarr package index'), and clarifies the semantic content: 'the versions and artifacts the updater can install.' This makes it clearly distinct from sibling tools like check_for_update or update_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for inspecting available updater versions and artifacts, which gives the agent a reasonable context for when to use it. However, it does not explicitly state when to prefer it over related siblings such as check_for_update, nor does it mention any exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the HTTP method and the output fields, and the verb 'List' implies a read-only operation. It does not explicitly state that no side effects occur, nor does it mention ordering, limits, or failure modes, but for a zero-parameter list call 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?
The description is a single, front-loaded sentence that states exactly what the tool does, the resource, the main output attributes, and the endpoint. There is no filler or redundant 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 parameterless list operation with no output schema, the description provides the essential information: what is listed, which attributes are returned, and the full endpoint. There are no nested objects, required parameters, or hidden settings that would require additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description has no parameter semantics to add. Per the baseline for zero-parameter tools, this scores well because there are no undocumented inputs that could confuse an agent.
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'), a clear resource ('Tdarr database backups'), and enumerates the return fields ('name, size and date'). It also includes the exact endpoint, making the tool's purpose unambiguous and distinct from related backup tools like create_backup and delete_backup.
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 intended usage is implied by 'List the Tdarr database backups' — an agent should call this when it wants an inventory of backups. However, there is no explicit guidance about when not to use it or how it compares with sibling backup operations like get_backup_status or delete_backup.
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, and it delivers meaningful behavioral context: it is a bulk write affecting every file in a library, and it explicitly discloses the major side effect that requeueing from table2 're-runs the whole library.' It does not mention reversibility, permissions, or load impact, but the whole-library consequence is the key trait an agent needs.
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 core action is front-loaded in the first clause, and the endpoint parenthetical is tight. The table enumeration is long but earns its place because it is essential for choosing the correct source table. Slightly dense dash-delimited formatting, but every sentence carries 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 4-required-param mutation tool with no output schema and no annotations, the description covers the operation's scope, the endpoint, all table semantics, and the primary side effect. It lacks explicit warning about the operational weight of resubmitting an entire library and does not describe the response, but nothing required 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?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine value beyond the schema: the full table1–6 taxonomy maps the entire value space of the 'table' parameter and clarifies how 'table' and 'process_status' interact ('requeueing from table2 back to the transcode queue re-runs the whole library'). This exceeds the schema's single example.
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 ('Requeue every file of a library') with distinct purposes ('for transcoding or health checking'). The scope qualifier 'every file of a library' differentiates it from per-file operations like rescan_file or get_file among the siblings, and the API endpoint reinforces the specific 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 table-mechanics explanation implies the usage scenario (re-running a whole library by moving table2 files back to the transcode queue), which is useful context. However, it never explicitly names alternatives or says when not to use this tool versus bulk_update_files, scan_library, or rescan_file, leaving routing largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the triggering action, the scoping behavior, and cautions about bypassing worker/staged-file limits. However, it does not disclose side effects of running an automation, whether execution is queued or asynchronous, or what kind of response or failure behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the action and endpoint, the second conveys scoping and bypass guidance. Every phrase 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with 8 parameters and 100% schema coverage, but it leaves gaps because there is no output schema and no annotations. It does not mention what happens after triggering, whether runs can be destructive, or how results are returned. These are notable for a tool that executes automations.
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 value by mapping the scoping intent to libraries/nodes and by explicitly warning that bypass flags should be used only deliberately to jump worker or staged-file limits. This goes beyond the individual property descriptions.
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 clear verb-and-resource statement, 'Manually trigger an automation,' and reinforces it with the exact endpoint, 'POST /api/v2/run-automation.' This clearly distinguishes the tool from sibling tools like list_automations and get_automation, which query rather than execute.
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 actionable context: scope the run to libraries or nodes, and reserve bypass flags for deliberate limit-jumping. It does not explicitly name alternatives or state when not to use the tool, but the 'only when you deliberately want...' phrasing provides a clear exclusion for the bypass behavior.
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 of disclosing destructive behavior. It clearly states that it 'deletes real media' and also removes records from the database, and alerts the agent to confirm with the user first. This is strong transparency for a destructive tool, though it stops short of stating irreversibility explicitly.
Agents need to know what a tool does to the world before 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. The first states the action and scope, and the second delivers the crucial safety warning. 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 one-parameter destructive tool with no output schema, the description covers the essential details: what it deletes, that it also updates the database, and the required confirmation step. It could add information about irreversibility or expected response, but the definition is sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents file_ids as 'File IDs (full paths) to delete' with 100% coverage. The description reinforces that these are multiple files but adds no new 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 starts with a specific verb and resource: 'Delete several files from disk and remove them from the Tdarr database.' It clearly states the bulk nature of the operation, distinguishing it from single-file tools like delete_file. The endpoint is also included for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for deleting multiple files at once. It gives an explicit safety instruction ('list the files for the user and confirm before calling') which guides when and how to use it. It doesn't explicitly name alternatives like delete_file for single deletions, but the bulk context is unmistakable.
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 explains the key side effects: the worker stays alive, the cancelled file goes back to the queue, and a cause is recorded. This is solid transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The primary action and endpoint are front-loaded, followed by the important behavioral consequences.
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 three-required-param mutation with no output schema, the description covers what happens to the worker and the item. It is complete enough for an agent to select and invoke the tool correctly, though an explicit note on expected response behavior would be marginally useful.
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 each parameter already has a meaningful description, including source hints for node_id and worker_id. The tool description adds no extra parameter detail, so 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 uses a specific verb-resource pair ('Cancel the item a worker is currently processing') and names the endpoint. It clearly distinguishes itself from kill-style tools by stating the worker stays alive and the file returns to the 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 clear behavioral context: this cancels the current item without stopping the worker. It implicitly contrasts with kill_worker and requeue-style tools, but it does not explicitly name alternatives 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.
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 disclosure. It clearly identifies this as a copy operation and adds a meaningful behavioral consequence: the local copy is safe from plugin-update overwrites. It does not cover edge cases like existing local copies, but the core behavior and purpose are 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 a single, well-structured sentence that front-loads the action and purpose, then includes the endpoint. There is no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter copy tool, the description plus complete schema provides enough information for an agent to decide when and how to invoke it. Return-value details are absent, but the copy action and its purpose are sufficiently described without needing an output 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?
The input schema fully documents both parameters, including plugin_id's source and force_overwrite's default behavior. The description itself adds no parameter-specific detail, so the baseline of 3 applies because the schema covers parameter semantics completely.
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 ('Copy') and names the source and destination ('Community plugin' into 'Local plugins'), so the action is unambiguous. It also distinguishes this tool from sibling plugin operations like read_plugin, save_plugin, create_plugin, and delete_plugin by stating its copy-based purpose and the reason for doing it.
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: copy a Community plugin locally so edits are not overwritten by plugin updates. It does not explicitly list alternatives or when not to use it, but the stated rationale effectively routes an agent to this tool instead of editing or saving a plugin directly.
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 full behavioral disclosure. It clearly warns that with no filters this deletes every report and instructs the agent to confirm with the user first. This goes beyond the literal word 'delete' and reveals the high-impact destructive nature of the 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 earn their place: the first states the action and endpoint, the second immediately surfaces the critical safety warning and mitigation. No fluff, 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.
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 full schema coverage, the description covers the essential context: bulk operation, filter narrowing, all-reports risk, and user confirmation. It does not mention return values or irreversibility, but for this dangerously destructive operation the main safety context is sufficiently 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%, so the schema already explains that filters select which reports to delete and that omitting them deletes all. The description adds 'pass filters to narrow it' but no additional type, format, or syntax meaning beyond what the schema provides, so 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 ('Delete'), a specific resource ('job reports'), and a clear scope ('in bulk'), and even includes the endpoint. 'Bulk' differentiates it from the singular sibling delete_job_report, so an agent can tell them apart.
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 clear operational guidance: pass filters to narrow deletion, omit filters to delete everything, and confirm with the user first. It does not explicitly name the singular delete_job_report as the alternative for deleting one report, but the 'in bulk' phrasing and dangerous no-filter behavior provide strong contextual 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, the description does the heavy lifting. It clearly conveys that this is a read operation returning configuration data, not executing the automation or modifying anything. Naming the specific payload components adds useful behavioral context, though it does not discuss error cases, permissions, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the action and the contents of the result without any filler. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description gives a solid overview of the return value (trigger, payload shape, targets). It could be slightly more explicit about the exact shape of the returned configuration, but 'in full' plus the listed elements is sufficient for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents config_id, so the baseline is 3. The description adds value by clarifying that the ID is from list_automations and that the returned content includes trigger, payload shape, and targets — linking the parameter to expected inputs and outputs beyond the raw type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one automation configuration') and enumerates what is included ('its trigger, payload shape and targets'). This cleanly distinguishes it from siblings like list_automations (which presumably returns summaries) and run_automation (which executes rather than retrieves).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the phrase 'one automation configuration in full' — an agent can tell it is for fetching full details rather than listing all configs. However, there is no explicit statement of when to choose this tool over siblings such as list_automations or run_automation, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. 'Get the status' clearly indicates a read-style operation, but it does not disclose details such as side effects, authentication requirements, or what happens when the database is corrupted. This is adequate for a simple status tool but leaves some behavioral specifics implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and immediately provides a practical usage trigger. Every word contributes meaning, with no 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 zero parameters and no output schema, the description is largely complete: it states what is retrieved and when to use it. It does not describe the exact response shape, but for a simple status-checking tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to add beyond the schema. The baseline for zero parameters is 4, and the description correctly implies a parameterless call.
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 status of the Tdarr databases.' This clearly identifies what the tool does and distinguishes it from generic siblings like get_status. The endpoint path further reinforces the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit invocation condition: 'Use when the UI reports the database as loading, busy or corrupted.' This provides clear context for when the tool is appropriate, though it does not mention alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of disclosing behavior. The wording 'Get' and 'Read this' signals a non-mutating operation, and the description clearly states what will be returned: a complete graph of nodes, plugin IDs, inputs, and edges. It does not explicitly address side effects or error cases, but for a read-only graphing 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?
The description is two sentences with no filler. It front-loads the core action and return contents, then follows with the intended use case. 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?
With a single required parameter, full schema coverage, and no output schema, the description does a good job of explaining the return value by listing nodes, plugin IDs/inputs, and edges. It could be slightly more explicit about the exact shape of the returned graph, but it is sufficient for an agent to understand what the tool provides.
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 flow_id parameter is already documented as 'Flow ID, from list_flows.' The tool description does not add semantic detail beyond the schema, 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 'Get one flow's complete graph' and specifies the exact contents: every node with its plugin ID and inputs, plus the edges between them. This clearly distinguishes get_flow from siblings like list_flows or get_library by emphasizing the full structural graph.
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 an explicit use case: 'Read this to explain or debug what a library's flow actually does.' It provides clear context for when to call the tool, though it does not name alternatives 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.
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 does so effectively by revealing what the response contains beyond the tool name, including whether the job is still running and that the report holds ffmpeg command-line details and errors. It does not mention auth, rate limits, or error cases, but for a simple GET-style report tool this is reasonable coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first precisely defines the operation and return content, and the second adds immediately useful diagnostic context. No filler or redundant detail; 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?
For a tool with one parameter and no output schema, the description explains what the response contains and offers practical usage context. It does not discuss related tools for searching or filtering reports, but that is outside the core need for invoking get_job_report correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has full coverage: it documents job_id as a required string 'Job ID'. The description adds only the implicit sense that job_id identifies the job whose report is returned. Since schema coverage is 100%, the baseline of 3 applies and the description does not need to compensate.
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 a job report by job ID') and identifies the exact endpoint. It also clarifies the return contents: the full worker log, metadata, running status, and the ffmpeg command line/errors. This clearly distinguishes it from sibling report-related tools like search_job_reports or delete_job_report.
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 concrete situational guidance: 'read it first when a transcode fails' and explains that the ffmpeg command line and errors live here. It does not explicitly name alternatives or state when not to use this tool, but the intended context is clear 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?
No annotations are provided, so the description carries the full burden. It discloses the output format (plain text), the scoping behavior (trailing lines only, default 100), and the raw HTTP endpoint. It does not cover error behavior for invalid node IDs, but for a read-only diagnostic tool the key behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: verb+resource in sentence one, output scoping in sentence two, and the use case in sentence three. The endpoint hint is minor redundancy but not wasteful.
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 (2 params, 1 required, no nested objects) and the schema covers 100% of parameters. With no output schema, the description's 'plain text' and 'trailing lines' notes partly fill the return-value gap. Missing error-case guidance is a minor gap for a log-read 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?
Schema description coverage is 100%, with both node_id and lines already well documented, including the lines=0 full-log option. The description's purpose statement contextualizes the parameters but adds no new parameter-level semantics, 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 verb ('Get'), resource ('a node's log'), and constrained behavior ('trailing lines only, default 100', 'plain text'). It clearly differentiates from the sibling get_server_log by scoping to a node's log rather than the server log.
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?
'Use it to see why a node's transcodes are failing' gives an explicit diagnostic scenario for choosing this tool. It stops short of naming alternatives or stating when not to use it, but the provided context is clear and actionable.
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 reveals that the tool returns plain text, only trailing lines, defaults to 100, and that the full log is potentially very large. This goes beyond the parameter schema and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no filler. The endpoint, return type, default behavior, and caveat are all communicated efficiently 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter read tool with no output schema, the description is nearly complete: it covers what is returned, the default behavior, and a relevant warning. It could mention how the 'lines' parameter interacts with the 'full log' note, but the schema already covers that.
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 fully documents the lone 'lines' parameter, including default and the 0-for-full behavior. The description mostly repeats this and adds only a caveat about log size, so it adds minimal new semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Get the Tdarr Server log'), states the return format ('as plain text'), and includes the exact API endpoint. This clearly distinguishes it from sibling tools like get_node_log.
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: this retrieves only the trailing lines of the server log and warns that the full log can be very large. It does not explicitly discuss alternatives or exclusions, but the server vs node distinction is implied by the resource naming.
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 clarify that killing the worker removes the worker itself and is meant for unresponsive workers, which is useful. However, it does not mention side effects, reversibility, or what happens to the work/task currently running on that worker.
Agents need to know what a tool does to the world before 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 core action is stated first, and the comparison with cancel_worker_item is packed into a single useful contrast. 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 destructive action, the description gives enough information to select and invoke the tool correctly. It is slightly incomplete because it does not explain what response to expect or explicitly warn about consequences, but the low complexity and strong sibling differentiation keep the gap small.
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 both parameters have descriptive definitions pointing to list_nodes / list_nodes(detailed). The description adds no additional parameter meaning, but the baseline of 3 applies because the schema already documents them 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 states a specific action ('Kill a worker on a node') with a clear resource and even includes the API endpoint. It explicitly distinguishes itself from cancel_worker_item by noting this removes the worker itself, so an agent can immediately tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the alternative (cancel_worker_item) and gives the exact condition for choosing this tool: when a worker is wedged and not responding to a cancel. This is explicit routing guidance rather than leaving the decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden, and it does disclose the key behavioral nuance: results are as seen by Tdarr Server, not the host filesystem. It also identifies the exact API endpoint. It doesn't explicitly state that the operation is read-only or describe error behavior, though 'List' strongly implies non-mutating behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary action is stated first, followed by the use case and the critical path-scoping caveat. 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 single-parameter tool with no output schema and no annotations, the description covers the action, the purpose, and the important input-semantics caveat. The agent has enough to invoke it correctly. Minor details like return format or error cases could be added but are not essential here.
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 already describes folder_path as 'visible to Tdarr Server,' so the baseline is 3. The description adds extra meaning by explaining that these are container paths, not host paths, which is not stated in the schema. This additional context helps the agent supply correct path values.
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?
Names a specific verb and resource ('List the subfolders of a path') and clarifies the Tdarr Server viewpoint, distinguishing it from filesystem-level or host-path tools. The container-vs-host path distinction further differentiates it from sibling tools like list_libraries or verify_folder_exists.
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 states the intended use case: 'Use it to discover the paths a library can point at.' The warning that the server sees container paths, not host paths, gives practical guidance for valid inputs. It does not name alternatives or exclusions, but this is adequate for a simple discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It surfaces one crucial behavioral trait—does not interrupt transcoding—which is genuinely useful. However, it omits other expected side effects of a restart, such as brief UI downtime or session termination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single focused sentence with the action front-loaded, the endpoint in parentheses, and the key caveat placed at the end. Every word earns its place—no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description sufficiently explains what happens and when to invoke it. Minor gaps include not mentioning what the caller should expect after invocation (e.g., UI downtime or recovery time), but these are not critical for a simple restart action.
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 semantics to clarify. The schema is 100% complete by virtue of having an empty properties object, and the description adds no necessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Restart', the resource 'Tdarr web UI process', and the exact endpoint. This distinguishes it from sibling tools like restart_server or restart_node by explicitly focusing on the UI process.
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?
Gives an explicit trigger condition: 'use it when the UI is unresponsive but jobs are fine.' The clarification that it does not interrupt transcoding also implies a boundary for when not to use it, though it doesn't name alternative tools.
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 disclose key behavioral traits: scanning is asynchronous and should be followed with get_scanner_status. It also explains what each mode does (adds new files, rescans from scratch, scans specific paths), which goes 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 description is exactly three sentences with no filler: it states the action, explains the modes, and gives post-invocation guidance. Each 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 4-parameter asynchronous action with no output schema, the description covers the start action, mode selection, and follow-up polling. It does not state what the API immediately returns, but the polling instruction partially fills that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining the three mode values in plain language and implicitly linking scanFolderWatcher to the paths parameter, which the schema only labels as 'required for scanFolderWatcher'.
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 'Start' and resource 'a file scan on a library', names the HTTP endpoint, and explains all three scan modes. This clearly distinguishes it from status-only or single-file 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for starting a library scan and tells the caller to poll get_scanner_status for progress. However, it does not explicitly mention when to prefer this tool over alternatives like rescan_file or scan_file_details, nor 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?
No annotations are provided, so the description carries the transparency burden. It clearly states the core behavior (stop) and the precondition (running), which is adequate for basic invocation. However, it does not mention side effects such as whether already-detected duplicates are preserved, or what happens if no pass is currently running.
Agents need to know what a tool does to the world before 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 states the action, the target, and the HTTP endpoint with no filler. Every word contributes to the agent's understanding.
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 cancellation tool, this is nearly complete: it names the action, the target, and the endpoint. The only gap is the behavior when no duplicate detection pass is running, but the core invocation context 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?
The tool accepts no parameters, so schema coverage is trivially complete. The description adds enough context by identifying what operation is being stopped, which is all the parameter information an agent needs.
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 ('Stop') and a specific resource ('running duplicate detection pass'), making the tool's function unmistakable. It also implicitly distinguishes this from its sibling find_duplicates, which starts the corresponding operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a running duplicate detection pass' clearly states the context in which this tool is appropriate. It does not explicitly name alternatives or exclusions, but with zero parameters and a clear counterpart in the sibling list, the intended use is unambiguous.
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 behavioral burden. It reveals that the tool mutates state on every connected node and implies code reload, but it does not disclose potential side effects such as node restarts, failure behavior when nodes are unreachable, or idempotency. This is a meaningful gap for a multi-node write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action and endpoint are front-loaded, followed by a concise usage trigger. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description covers the core semantics and the appropriate sequencing. It stops short of 5 because it omits any caveats about the operational impact on nodes, which would be useful given there are no annotations to convey safety or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to add. The baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Push') and resource ('server's current plugins out to every connected node'), and includes the exact endpoint. This clearly distinguishes it from sibling tools like save_plugin or update_community_plugins, which modify the plugin source rather than propagate it.
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 states when to run this tool: after update_community_plugins or save_plugin, with the reason being so nodes execute new code. It doesn't mention exclusions or alternatives, but no sibling tool offers the same sync behavior, 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?
With no annotations, the description carries full behavioral burden. It clearly discloses that the action is destructive ('Delete'), scoped to leftover cache files, and intended for interrupted-work cleanup. It does not discuss return values or error cases, but 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?
Two sentences with no filler. The endpoint, operation, and use case are front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, single-action delete tool, the description is complete. It specifies the operation, the resource, the path semantics via the schema, and the exact scenario for use. No critical information is missing for an agent 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 coverage is 100%: the single required parameter 'file' is already described as 'Full path of the cache file to delete'. The description adds usage context but no additional parameter-level meaning, so the 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?
States a specific verb ('Delete'), a precise resource ('leftover file from the Tdarr transcode cache'), and the intended purpose ('clear partial output from an interrupted worker'). The cache-specific framing clearly differentiates it from sibling deletion tools like delete_file or delete_job_report.
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 identifies the usage scenario: cleaning up leftover/partial cache output from an interrupted worker. It does not enumerate exclusions or name alternative tools, but the context is narrow and clear 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?
Annotations are absent, so the description carries the full burden; it clearly discloses that this deletes real media in bulk and is destructive. It also provides a concrete precautionary procedure. It does not detail failure modes or permission needs, but it flags the most critical behavioral trait well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence states the action and scope, and the second delivers the mandatory safety warning. The most critical 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?
Given the single enum parameter, the full schema coverage, and absence of an output schema, the description provides all necessary context: what the tool does, what data it targets, that it is destructive, and the required confirmation workflow.
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% coverage by describing table3 and table6 meanings and the enum constraint. The description repeats this mapping but adds no new parameter-level details, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Delete'), a precise resource scope ('every file in the transcode-error table or health-check-error table'), and the destructive nature ('from disk', 'deletes real media in bulk'). It also names the API endpoint, making it fully distinguishable from sibling delete tools like delete_file or bulk_delete_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 description gives clear operational guidance: 'always list the affected files with query_table and confirm with the user first.' This tells the agent when and how to use the tool safely. It does not explicitly discuss when to prefer sibling deletion tools, but for this distinct bulk-destructive operation 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It communicates the read-only nature via 'Get', adds the underlying POST endpoint, specifies what dimensions are aggregated, and clarifies that omitting library_id returns totals across every library. This is strong behavioral context for a low-complexity stats tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, information-dense sentence front-loads the purpose, adds the API endpoint, enumerates the statistic categories, and closes with the parameter behavior. There is no filler or redundancy.
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 tool with one optional parameter and no output schema, the description is complete: it states what is returned, the scoping parameter's effect, and the endpoint. An agent has everything needed to select and invoke it 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 already describes library_id as the scoping ID with a default of all libraries, so baseline is 3. The description adds extra meaning by explaining that omitting it yields 'totals across every library', which clarifies the aggregation semantics beyond a literal reading of 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 names a specific verb ('Get'), a concrete resource ('pie-chart statistics'), and enumerates exactly what the statistics cover: file counts by transcode status, health status, container, codecs, resolution, and channel layout. This clearly distinguishes it from the many other get_* 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is relevant (Tdarr dashboard pie stats) and even explains the default behavior of omitting library_id. However, it does not explicitly say when to choose this tool over related sibling tools like get_resource_stats, get_performance_stats, or get_stream_stats, 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 explains what data is returned and the endpoint, but it does not explicitly state that the operation is read-only, whether it may be expensive on large node counts, or any other behavioral caveats. The 'get' wording implies a safe read, but more explicit disclosure would strengthen it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The main action and returned fields are front-loaded, and the practical use case is added in a compact second sentence.
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 read tool, this description is complete: it identifies the resource, the scope, the returned process attributes, the endpoint, and a real-world diagnostic use case. Nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids inventing parameter-related detail and focuses on what the tool returns, which is sufficient.
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 clear verb ('Get') and a specific resource: the process tree of the server and every connected node. It enumerates the returned fields (pid, ppid, executable, script, memory usage) and includes the exact endpoint, making it easy to distinguish from sibling tools like get_status or get_resource_stats.
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 concrete use case: spotting stuck ffmpeg/HandBrake child processes. This provides clear context for when to call the tool, though it does not explicitly name alternatives 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?
There are no annotations, so the description carries the burden. It states the listing behavior and the key field (_id), but does not disclose output shape, ordering, pagination, or whether it returns full configuration details or only metadata. The read-only nature is reasonably implied by 'list', but not fully elaborated.
Agents need to know what a tool does to the world before 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, each earning its place. The list action and server scope are front-loaded, and the downstream relationship to run_automation is stated without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool, the description is complete: it defines what is listed, from where, and what the returned _id is used for. The lack of an output schema is acceptable because the description already identifies the critical field an agent would need.
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 trivially 100%, so there is little to document. The description adds useful semantic context by linking the returned _id to run_automation's config_id, which helps an agent understand the value it will receive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and a clear resource ('automation configurations defined on the server'). It also anchors the tool's purpose by explaining that the returned _id is the config_id consumed by run_automation, which distinguishes it from related automation 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 clearly implies when this tool is useful: when you need the _id to pass to run_automation. It does not explicitly mention alternatives like get_automation or state when not to use it, but it provides clear operational context without being misleading.
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 and does so well: it states the match criterion, that this is a server-side search, the exact return fields, and the next action. It does not cover empty-result or error behavior, but that is not critical for a simple search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the purpose, state the return value, and link to the next tool. The endpoint method adds useful context without bloat.
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-parameter search tool with no output schema, the description is complete: it covers what is searched, how the parameter maps to behavior, what is returned, and what to do with a result. No essential invocation information 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 sole parameter 'search' already has 100% schema coverage ('Search terms matched against report filenames'), and the description does not add new parameter-level semantics beyond restating that matching is by filename. The baseline of 3 is appropriate because the schema carries the semantic load.
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 ('Search') with a clear resource ('job reports') and scoping mechanism ('by filename'). It also states the output (filenames and last-modified time), which distinguishes it from related report tools like list_file_job_reports and get_job_report.
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 indicates the tool is for finding job reports by filename and suggests the follow-up read operation with get_job_report. It lacks an explicit when-not-to-use note (e.g., to enumerate all reports use list_file_job_reports), but the context is otherwise 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 full behavioral disclosure burden. It explicitly warns that Community plugins are overwritten and that Local plugins are unaffected, which are the key behavioral traits beyond the action itself. It does not detail irreversibility or side effects beyond the overwrite warning, but the warning is sufficient for this tool's risk profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action and endpoint are front-loaded, and the critical overwrite warning is placed immediately after, making the description scannable and efficient.
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 one-optional-parameter tool with no output schema, the description provides everything an agent needs to invoke it correctly: the purpose, the scope, the endpoint, and the destructive overwrite warning. No critical calling information 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?
Schema description coverage is 100%, so the schema fully documents the 'force' parameter. The description adds no additional detail about the parameter beyond what the schema already provides, 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 names a specific action ('Pull the latest Community plugins'), a specific resource ('Tdarr plugin repo'), and the exact endpoint. It distinguishes itself from sibling plugin tools by stating it operates on all Community plugins and leaves Local plugins untouched.
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 scope clear: use this tool to update Community plugins from the Tdarr repo. The statement that Local plugins are untouched provides an exclusion, though it does not explicitly name alternative tools such as copy_community_plugin_to_local or sync_plugins_to_nodes.
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 the HTTP method and endpoint, the fact that it checks both existence and readability, and the return type (boolean). The verb 'Check' implies a non-mutating operation, which is appropriate for this verification tool. It does not explicitly state 'no changes are made', but for a simple read-only check 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?
A single concise sentence communicates purpose, endpoint, and return value without wasted words. The most important information is front-loaded, and there is no redundant repetition of the tool name or schema details.
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 verification tool with one fully documented parameter and no output schema, the description is complete: it explains what is checked, what input the agent must provide, and what the boolean result means. No additional context such as pagination, side effects, or complex return structure is needed.
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 parameter folder_path is already well-defined in the schema as 'Folder path to check, as visible to Tdarr Server'. The tool description reinforces the server-visible/path concept but does not add significant new 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 states a specific action ('Check whether a folder exists and is readable') on a clear resource (a folder path), and includes the exact endpoint. It is clearly distinct from siblings like list_subdirectories or search_files, since this tool returns a boolean verification rather than performing discovery or file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear when to use the tool: whenever an agent needs to confirm that a folder exists and is readable by Tdarr Server before performing file operations. It does not explicitly name alternative tools or list exclusions, but the verification-oriented purpose is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the operation runs asynchronously, compares metadata or hashes content, and that sha256 is slow but accurate. This goes beyond the schema and exposes important runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with purpose, then method details, then async lifecycle behavior. Every sentence carries useful information with no 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?
For an asynchronous tool with no annotations and no output schema, the description covers what the tool does, how to choose detection parameters, and how to stop it. It does not mention how to retrieve detection results afterward, but that is a follow-up concern rather than a blocker to 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 already strong. The description adds meaningful semantics for detection_method and hash_amount, explaining the tradeoffs and effect on file reads. threshold and count are not expanded, but the schema already documents them 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 opens with a specific verb and resource: 'Start Tdarr's duplicate detection', and identifies the exact API endpoint. It also differentiates itself from stop_find_duplicates by positioning itself as the asynchronous start operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to choose 'metadata' vs 'sha256' and how hash_amount behaves with sha256. The async behavior is stated along with the explicit stop action, giving an agent clear operational guidance, though it does not enumerate exclusions or alternative scanning tools.
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 full burden. It transparently states the operation is a read-style stats retrieval, lists the returned metrics, and includes the exact endpoint. It does not state whether side effects are possible or mention auth requirements, but the 'Get' phrasing and stats-oriented content make the read-only nature clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence front-loads the core purpose, then provides a compact list of returned metrics and the endpoint. There is no redundancy or filler; every part of the description adds 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?
With no output schema, the description must document return values, and it does by naming process uptime, heap, CPU percentage, and memory used/total. Exact field names or units are not specified, but for a zero-parameter statistical snapshot this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter meaning to supplement beyond the empty schema. The schema already fully covers this case, and the description does not need to add parameter details. Baseline 4 for zero-parameter tools 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 and resource: 'Get current Tdarr Server resource usage' and then enumerates the exact metrics returned (process uptime, heap, host CPU, memory). This clearly distinguishes it from sibling tools like get_resource_history or get_server_time without needing to read 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 word 'current' establishes a clear point-in-time use case: the agent can choose this tool when it wants an immediate server resource snapshot. It does not explicitly name alternatives or exclusion conditions, so it stops short of a perfect score.
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 discloses the key side effect: the call interrupts running jobs. It also clarifies the required prior state. It does not mention response format or server availability during the relaunch, but the most important 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 dense sentences carry the action, purpose, endpoint, precondition, and side-effect warning. Information is front-loaded and there is no 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?
For a zero-parameter tool with no output schema, the description covers purpose, endpoint, when to call, and major side effects. It could be slightly stronger by naming the generic restart_server alternative, but nothing essential 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 tool has zero parameters and the schema is trivially complete. The description adds useful context about update semantics and preconditions, meeting the baseline for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Relaunch'), names the resource ('Tdarr Server'), and states the exact purpose ('to finish applying a downloaded update'). It also includes the endpoint, which makes the tool's role unambiguous and distinguishes it from generic restart 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 an explicit precondition: 'Only call this after check_for_update reported the update as applied.' It also warns that the call interrupts running jobs. It does not explicitly name an alternative like restart_server for non-update restarts, so it stops just short of full alternative 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 full burden of behavioral disclosure. It reveals a key behavioral trait: node_updates is merged into the node record, implying a partial update rather than a full replacement. It also notes the node must be connected. It does not discuss reversibility or permissions, but the merge semantics are 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the action and endpoint, the merge semantics with examples, and the prerequisite read step. Front-loaded and free of fluff.
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 two-parameter update tool with no output schema, the description covers the operation, the update mechanism, example payloads, and the recommended read-before-write workflow. It doesn't describe return behavior or error cases, but those are less critical given the tool's simplicity and the presence of the prerequisite guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so node_id and node_updates are already documented. The description adds value by giving multiple concrete examples of node_updates payloads and explaining the merge behavior, going beyond the schema's single example.
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 ('Update') and resource ('a connected node's settings'), provides explicit examples (pause, rename, priority), and is clearly distinct from sibling tools like restart_node or disconnect_node.
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 prerequisite: 'Read the current record with list_nodes(detailed) first.' This tells the agent the recommended workflow and points to the correct sibling for reading. It does not explicitly enumerate when not to use this tool, but the context 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?
With no annotations, the description carries the full behavioral burden. It discloses that the operation runs asynchronously and that progress must be checked via get_backup_status. This is meaningful behavioral context beyond a simple 'create' statement, though it does not detail retention, overwrite behavior, or failure modes.
Agents need to know what a tool does to the world before 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 cover purpose, endpoint, asynchronous behavior, polling guidance, and recommended usage. No filler or repetition; the most important action and context are 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 zero-parameter, no-output-schema tool, the description provides everything an agent needs: what it does, how to invoke it, how to track completion, and when it should be used. No critical operational gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so there is no parameter information missing. The description does not need to explain parameters, and the baseline for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Create a backup of the Tdarr database', and reinforces it with the exact endpoint. This clearly identifies the operation and differentiates it from siblings like list_backups or get_backup_status.
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 a clear when-to-use directive: 'Take one before any bulk change to libraries or files.' It also instructs polling get_backup_status for progress. It does not explicitly discuss exclusions or alternative creation paths, but none are needed given the tool's unique purpose.
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 explaining behavior. It clearly identifies this as a read-only retrieval operation with no side effects, and specifies the output unit (Unix epoch milliseconds). The only minor gap is that the exact response shape (e.g., raw number vs. wrapped object) is not disclosed, but for such a simple getter 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 concise sentences with no filler. The core action and output format are front-loaded, and the second sentence adds practical context that justifies the tool's existence. 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 zero-parameter, read-only tool with no output schema, the description is complete. It states what the tool returns and why it is useful. No significant detail an agent would need to call 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 tool accepts zero parameters, so the baseline is 4. The description adds relevant context about the returned timestamp format, though there is no parameter semantics to elaborate on. Nothing is missing here.
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 specific action (get), the resource (current time on the Tdarr Server), and the exact format (Unix epoch in milliseconds). This is unambiguous and distinct from any sibling tool, none of which appear to provide time information.
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 concrete use case: interpreting epoch timestamps in file and job records. Since no alternative tool for retrieving server time exists, explicit when-not guidance is unnecessary. The stated purpose effectively tells an agent when to invoke 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 the behavioral disclosure burden. It discloses that this is a GET request, what response fields to expect, and adds the diagnostic role of a connectivity/API-key check. The main gap is not explicitly stating error or unauthorized-access behavior, but the API-key check phrasing implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words; the core purpose and returned fields are front-loaded, and the second sentence adds the practical diagnostic use case. 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?
For a zero-parameter, read-only status tool with no output schema, the description is complete: it lists the return fields, gives the endpoint, and explains how to use the call as a first diagnostic step. This is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema has nothing to document and the baseline of 4 applies. The description appropriately doesn't include 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?
States a specific action and resource: 'Get Tdarr Server status' and enumerates the exact fields returned (version, build date, uptime, OS, server engine), plus the GET endpoint. This clearly distinguishes it from sibling status tools like get_db_statuses or get_scanner_status.
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 says to call this first when something looks wrong, positioning it as a connectivity/API-key check. This gives a clear decision rule for when to use it, though it does not name sibling alternatives 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.
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 does this reasonably by stating that the operation returns every job report for one file and that footprintId uniquely identifies the file across renames and transcodes. It does not mention ordering or output size, but for a simple listing operation 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?
Two sentences, front-loaded with the core purpose, followed by a useful endpoint reference and a compact explanation of footprintId. There is no wordiness or redundant repetition of schema fields.
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?
The tool has a single required parameter, no output schema, and no annotations. The description provides the necessary context to invoke it correctly: what it lists, how to obtain the footprintId, and why footprintId is the right identifier. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes footprint_id as 'File footprintId, from get_file', so the description does not need to repeat that. The description adds value by explaining that footprintId identifies the file across renames and transcodes, giving the agent deeper context for the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair: list every job report for one file. It also names the endpoint and explains the footprintId concept, which helps distinguish this from siblings like search_job_reports or get_job_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use this tool: after retrieving a file via get_file, to see all job reports tied to that file. It does not explicitly say when not to use it or call out alternatives for cross-file search, but the prerequisite 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 full behavioral burden. It discloses that this is a GET operation, that results are keyed by node ID, and what fields the summary versus detailed response includes. It could mention default behavior or empty-result handling, but it gives solid transparency for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The core purpose and endpoint are front-loaded, followed by a clear summary-vs-detailed distinction. Every sentence contributes useful information.
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 optional-boolean list tool with no output schema, the description is complete. It explains the return structure for both summary and detailed modes, and there are no additional parameters or complex behaviors that need elaboration.
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 boolean 'detailed' parameter is already described in the schema. The description adds meaningful nuance by specifying exactly what the summary contains and what additional data the detailed mode returns, going beyond the schema's one-line 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 states the verb ('List'), the resource ('connected Tdarr nodes'), and the endpoint (GET /api/v2/get-nodes). It also distinguishes the tool from node-related siblings by focusing on listing nodes rather than updating, restarting, or fetching node logs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes a clear context: it is for listing connected Tdarr nodes and covers both summary and detailed views. It does not explicitly name alternatives or exclusions, but the purpose is unambiguous enough that an agent can infer when this tool is appropriate compared to other node-management tools.
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 of disclosing behavior. It clearly indicates a read-only listing operation, specifies the output fields, and even names the HTTP endpoint. It does not discuss auth or error behavior, but for a simple zero-parameter list tool the description 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 tight sentences deliver the action, resource, output fields, endpoint, and usage context with no filler. The essential information is front-loaded in the first sentence.
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 with no output schema, the description is complete: it identifies what is listed, what fields are returned, the endpoint, and the intended use case. Nothing essential is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain beyond the schema. The 100% schema coverage plus the lack of parameters makes the baseline 4 appropriate; the description adds no parameter-specific detail 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 opens with a specific verb and resource: 'List recent commits on the Tdarr plugin repo'. It also enumerates the returned fields (SHA, date, message, author), making the tool's behavior unmistakable and clearly distinct from siblings like check_for_update or update_community_plugins.
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 'Use it to see what changed upstream before pulling plugin updates' gives a clear intended context. It does not explicitly name alternatives or state when not to use it, but the reference to 'before pulling plugin updates' effectively separates it from update-oriented sibling tools.
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 disclosure burden. It does well by stating the disruptive nature and concrete side effects: 'running workers are interrupted and every node reconnects.' It could add what the response looks like or whether the call is asynchronous, but the critical 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?
The description is two sentences and every clause earns its place: the endpoint, the disruptive consequence, and the user-consent requirement. No filler 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 zero-parameter, no-output-schema tool, the description is complete with respect to complexity. It names the action, gives the endpoint, warns about side effects, and mandates user confirmation—arguably all an agent needs to decide to invoke it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is therefore fully self-explanatory at 100% coverage. The description does not need to add parameter meaning, and for a no-parameter tool the baseline of 4 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 and resource: 'Restart Tdarr Server', backed by the exact endpoint '(POST /api/v2/restart-server)'. This clearly identifies the tool's action and distinguishes it from sibling restart tools aimed at the UI or individual nodes.
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 invocation guidance: it is disruptive and the agent must 'Ask the user before calling this.' It does not explicitly compare with alternatives like relaunch_server, but the safety and consent context is strong and 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 of behavioral disclosure. It explicitly states the read-only nature: 'this tool cannot insert, update or remove documents'. It also warns about the potentially large result of getAll on FileJSONDB and redirects to search_files. This goes beyond the schema and covers the most important behavioral traits, though it does not mention response format or other edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. The purpose is front-loaded in the first sentence, the read-only constraint is in the second, and the important getAll caveat is in the third. The structure is logical and scannable.
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 generic fallback query tool with no output schema and no annotations, the description covers the core requirements: what it reads, that it is read-only, when to use it, and one critical caveat about data size. It does not describe response structure or pagination, but those are less critical given the tool's role as a catch-all and the schema's already thorough parameter 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 schema already covers parameter meaning with 100% description coverage, so the baseline is 3. The description adds extra semantic value by highlighting a mode-collection combination hazard: 'getAll' on FileJSONDB returns the entire file database and recommends search_files instead. This is not present in the schema and helps agents reason about the interaction between mode and collection.
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: 'Read a Tdarr database collection directly (POST /api/v2/cruddb)'. It clearly states the tool's scope as a general-purpose reader for anything dedicated tools do not cover, listing examples like global settings and jobs. It also differentiates from the sibling search_files by explicitly preferring that tool for FileJSONDB getAll, making the boundary between tools apparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'for anything the dedicated tools do not cover'. It also provides a concrete exclusion: 'prefer search_files there' when using getAll on FileJSONDB. This gives an agent actionable routing guidance relative to siblings, satisfying the when/when-not requirement.
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 conveys that this is a read-style query operation, mentions server-side filtering/sorting/paging, and warns that it is low-level. It could be more explicit about no mutation or response behavior, but the verb and framing are 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?
The description is three sentences with no filler. The core purpose is front-loaded, the low-level nature is stated, and the alternative is named efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 6 parameters and no output schema, the description covers the essential context: endpoint, valid value source, relationship to search_files, and pagination capabilities. It stops short of describing the expected response envelope or error behavior, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful context by explaining that valid client_type and opts.table values are the ones used by the Tdarr UI, which is not stated in the schema and is essential for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Query one of the paginated tables behind the Tdarr UI') and identifies the underlying endpoint. It also distinguishes itself from search_files, making its purpose and scope immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames the tool as a low-level escape hatch for views search_files cannot express and instructs agents to prefer search_files for plain file lookups. This gives a concrete selection rule and clearly identifies the main alternative.
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 clearly signals a mutation via 'Reset' and the POST endpoint, and explains the intended use case. It does not detail side effects or permissions, but for a zero-parameter status-reset operation, the disclosure 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?
The description is two sentences with no filler. It front-loads the core purpose, includes the endpoint for precision, and immediately follows with the usage condition. 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 operation with no output schema, the description provides enough context: what the tool does, when to use it, and the HTTP endpoint. It omits response details, but those are not essential for selecting and invoking this 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 parameters, and schema description coverage is 100%. The description therefore does not need to document any parameter semantics; the baseline of 4 applies because there is nothing for the description to add.
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: 'Reset a stuck backup status', which clearly identifies the action and target. It also distinguishes itself from get_backup_status by focusing on clearing a stale state rather than reporting current status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use it when get_backup_status keeps reporting a backup that is no longer running.' This names the relevant sibling tool and gives a concrete triggering condition, leaving no ambiguity about when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full behavioral disclosure burden and handles it well. It reveals the destructive overwrite behavior ('Overwrites the whole file'), the prerequisite read step, and the non-persistence trait of Community plugin edits. It stops short of disclosing response format or error conditions, which keeps it from a 5.
Agents need to know what a tool does to the world before 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 sentences, each carrying distinct information: purpose, destructive behavior plus workflow, and scope restriction. The core purpose is front-loaded and there is zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter write tool with fully documented schema fields and no output schema, the description covers purpose, behavior, safe workflow, and scope exclusions. A note on success indicators or a verify_plugin follow-up would make it fully complete, but nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining why 'text' must be the complete source (because of the whole-file overwrite) and reinforcing that plugin_source is 'Local' by restricting usage to Local plugins. This connects the parameters to the tool's behavior rather than merely restating them.
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 ('Write'), a precise resource ('the source of a local classic plugin'), and even the raw HTTP endpoint, leaving no ambiguity about what the tool does. It also distinguishes itself from siblings like read_plugin and create_plugin by narrowing scope to 'local classic' plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit workflow guidance: 'read_plugin first and send back the full modified source,' naming the sibling tool to use beforehand. It also states when not to use it ('Only edit Local plugins — Community plugins are overwritten on the next plugin update'), making the selection criteria fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses the destructive effect (removes file records), the non-destructive effect on disk, the need to rebuild scan results, and the mandatory user confirmation. This is exemplary transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: the first states the core action, the second clarifies the key non-effect and consequence, and the third gives an explicit instruction. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool with no output schema, the description covers action, side effects, recovery path, and required user consent. The reference to scan_library and the explicit warning make this complete enough for an agent to call it correctly and safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with library_id described as 'Library ID (dbID), from list_libraries'. The description adds minimal parameter-specific meaning beyond 'of a library', which is already in 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove every file record of a library from the Tdarr database') and the resource affected, and it explicitly distinguishes this from touching files on disk. It also names the sibling tool scan_library for rebuilding scan results, making differentiation easy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to ask the user before calling, and it explains when this operation is appropriate and what it does not do (touch files on disk), plus the follow-up action needed (rebuild with scan_library). This gives clear usage context and an alternative tool.
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:

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

Score Badge

Copy to your README.md:

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

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