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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.