arr-mcp

Overview Schema Source Related Servers Discussions Admin

Download queue

get_queue

Read-only

Lists active downloads and stalled items across Radarr, Sonarr, Whisparr, Lidarr, SABnzbd, NZBGet, Transmission, qBittorrent and Bookdrop, with bytes, ETA, import-blocked status, and seeding details for cleanup decisions.

Instructions

Everything downloading or stalled, merged across Radarr, Sonarr, Whisparr, Lidarr, SABnzbd, NZBGet, Transmission and qBittorrent, plus files waiting in Grimmory's Bookdrop. Sizes are bytes, ETAs seconds; release names are fenced as untrusted data. An *arr row carries downloadId and statusMessages: a finished download stuck at importState: "importBlocked" is imported with trigger_scan action: "import" and that downloadId, but a title mismatch or unknown episode fails the same way on every retry and has to be fixed in the service. At detail: "full" a torrent carries seeding (ratio, time seeded, the limit that applies, overLimit) and, with Cleanuparr, the rule that governs it, its strikes and dueAt; cleanuparrDue totals what falls due within 7 days. Remove a row with remove_queue_item. Field reference: arr://docs/get_queue.

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum items to return. Defaults to 50, hard maximum 500.
`detail`	No	How much per-item detail to return. Defaults to standard.	standard
`offset`	No	Items to skip: page two of 50 is `offset: 50`. Pair it with `sort`, or items can move between pages.

Output Schema

Name	Required	Description	Default
`items`	Yes
`total`	Yes
`counts`	No
`offset`	Yes
`degraded`	Yes
`returned`	Yes
`truncated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv1.74.0Nov 9, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

changedInput schema / properties / offset / description

Previous value: -"How many items to skip before the window `limit` returns — page two of 50 is `offset: 50`. `total` always counts the whole list, so `offset + returned < total` is how you know there is another page. Pair it with `sort` for a stable walk: without one the order is whatever the services returned, and an item can move between pages."New value: +"Items to skip: page two of 50 is `offset: 50`. Pair it with `sort`, or items can move between pages."

removedInput schema / properties / offset / maximum
```
Removed value: -9007199254740991
```

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / properties / counts / description

Removed value: -"How many results each service contributed."

removedOutput schema / properties / degraded / description

Removed value: -"Services that could not be reached. Their contribution is missing from `items`, so a short list may be an outage rather than an answer."

removedOutput schema / properties / items / description

Removed value: -"The window of results. What an item carries depends on the tool and on `detail`."

removedOutput schema / properties / offset / description

Removed value: -"How many were skipped. `offset + returned < total` means there is another page."

removedOutput schema / properties / offset / maximum
```
Removed value: -9007199254740991
```
removedOutput schema / properties / offset / minimum
```
Removed value: --9007199254740991
```
removedOutput schema / properties / returned / description
```
Removed value: -"How many are in `items`."
```
removedOutput schema / properties / returned / maximum
```
Removed value: -9007199254740991
```
removedOutput schema / properties / returned / minimum
```
Removed value: --9007199254740991
```

removedOutput schema / properties / total / description

Removed value: -"How many matched in total — the whole list, never the window. Compare against `returned` before reporting a count to anyone."

removedOutput schema / properties / total / maximum
```
Removed value: -9007199254740991
```
removedOutput schema / properties / total / minimum
```
Removed value: --9007199254740991
```

removedOutput schema / properties / truncated / description

Removed value: -"True when this is not the whole list — including on the last page of a paged walk, where the rest is behind you rather than ahead."

First observedv0.1.0Nov 9, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Consistent with readOnlyHint: true and adds substantial context the annotations cannot carry: data is merged across eight clients, sizes are bytes and ETAs seconds, release names are fenced as untrusted data, and detail: "full" adds seeding and Cleanuparr strike/dueAt fields. It also discloses the retry-vs-fix-in-service distinction, which is exactly the behavioral nuance an agent needs.

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

Conciseness4/5

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

Front-loads the resource scope in the first clause and then layers the actionable details; every sentence carries information. It is dense and long-sentenced, and the cleanuparrDue totals note is somewhat niche, but nothing is redundant filler.

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

Completeness5/5

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

An output schema exists, so return-shape explanation is not required, yet the description still pre-explains the notable per-item fields and their units. For a three-optional-parameter read tool spanning multiple backends, an agent has everything needed to call it and interpret the result.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning to the detail enum by spelling out what appears at "full" (seeding ratio, time seeded, limit, overLimit, Cleanuparr rule, strikes, dueAt). limit and offset are left entirely to the schema, which already documents them well including the pagination-plus-sort caveat.

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?

Opens with a specific resource and scope: everything downloading or stalled, merged across eight named services plus Bookdrop. That is clearly distinguishable from siblings such as get_history, get_wanted and get_releases, which cover different states of the media lifecycle.

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?

Routes the agent to concrete alternatives in context: remove_queue_item for removing a row and trigger_scan with action: "import" plus a downloadId for importBlocked items. It also explains the failure case that cannot be retried (title mismatch/unknown episode), which implicitly tells the agent when not to retry. It stops short of an explicit statement of when to prefer get_queue over get_history or get_wanted.

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