Skip to main content
Glama

manage_stalled_downloads

Audit qBittorrent downloads that are stalled or slow, then delete only the user-approved torrents and their files.

Instructions

Lists qBittorrent downloads that are stalled or slower than a threshold (AUDIT), and deletes chosen ones with their downloaded files (PURGE_STALLED). PURGE_STALLED only deletes the torrents whose hashes you pass, taken from an AUDIT the user has seen and agreed to; it never deletes anything else, and Radarr and Sonarr are not told.

Input Schema

NameRequiredDescriptionDefault
actionYesAUDIT lists stalled downloads with their hashes and changes nothing; PURGE_STALLED deletes the torrents named in hashes, with their files.
hashesNoPURGE_STALLED only: the hashes, from AUDIT, of the torrents the user agreed to delete. Required for PURGE_STALLED.
minSpeedKbpsNoA download slower than this (KB/s) counts as stalled, as does one qBittorrent reports as stalled.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.4.0
    • changedInput schema / properties / action / description
      Previous value: -"AUDIT returns stalled candidates; PURGE_STALLED wipes them and flags a re-search."New value: +"AUDIT lists stalled downloads with their hashes and changes nothing; PURGE_STALLED deletes the torrents named in hashes, with their files."
    • addedInput schema / properties / hashes
      Added value: +{
      +  "description": "PURGE_STALLED only: the hashes, from AUDIT, of the torrents the user agreed to delete. Required for PURGE_STALLED.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / minSpeedKbps / description
      Previous value: -"The minimum allowed speed threshold before a torrent is considered stalled."New value: +"A download slower than this (KB/s) counts as stalled, as does one qBittorrent reports as stalled."
    • addedInput schema / properties / minSpeedKbps / minimum
      Added value: +0
  2. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses that AUDIT changes nothing, that PURGE_STALLED deletes only the passed hashes and never anything else, deletes downloaded files too, and explicitly notes Radarr/Sonarr are not notified. This is the key behavioral context an agent needs before a destructive operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two dense sentences front-load the read/write split and the safety constraint; only a minor amount of repetition between the action enum description and the top-level description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description supplies exactly the missing behavioral and safety context: read-vs-write modes, deletion scope, file removal, and absence of *arr notifications. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents action, hashes, and minSpeedKbps in detail. The description reinforces that hashes come from AUDIT and are required for PURGE_STALLED, but adds little beyond the schema on the threshold semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States precise verbs and resources for both modes: lists stalled/slow downloads (AUDIT) and deletes chosen ones with files (PURGE_STALLED). The dual-mode action is made explicit, and the description distinguishes itself from the many sibling tools focused on media status, search, and infrastructure.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly directs that PURGE_STALLED should only be used with hashes from a user-agreed AUDIT, giving a strong precondition. It does not name alternatives or state when not to use the tool, but the audit-then-purge workflow is well spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.