Arr MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ARR_TIMEOUT | No | Seconds to wait for an answer. Default 30. | 30 |
| ARR_BAZARR_KEY | No | Bazarr API key | |
| ARR_BAZARR_URL | No | Bazarr base URL, e.g. http://localhost:6767 | |
| ARR_RADARR_KEY | No | Radarr API key | |
| ARR_RADARR_URL | No | Radarr base URL, e.g. http://localhost:7878 | |
| ARR_SONARR_KEY | No | Sonarr API key | |
| ARR_SONARR_URL | No | Sonarr base URL, e.g. http://localhost:8989 | |
| ARR_VERIFY_TLS | No | Set to false to skip TLS verification for an https address with a self-signed certificate. | |
| ARR_JELLYFIN_KEY | No | Jellyfin API key | |
| ARR_JELLYFIN_URL | No | Jellyfin base URL, e.g. http://localhost:8096 | |
| ARR_PROWLARR_KEY | No | Prowlarr API key | |
| ARR_PROWLARR_URL | No | Prowlarr base URL, e.g. http://localhost:9696 | |
| ARR_OVERSEERR_KEY | No | Overseerr API key | |
| ARR_OVERSEERR_URL | No | Overseerr base URL, e.g. http://localhost:5055 | |
| ARR_QBITTORRENT_URL | No | qBittorrent web UI URL | |
| ARR_QBITTORRENT_PASS | No | qBittorrent web UI password | |
| ARR_QBITTORRENT_USER | No | qBittorrent web UI username |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| arr_servicesA | List which services are set up (Sonarr, Radarr, Prowlarr, Bazarr, Seerr, Jellyfin, Plex, qBittorrent, Tdarr). Shows addresses only, never keys. |
| arr_callA | Call any API path on a service. service: sonarr, radarr, prowlarr, bazarr, seerr, jellyfin, plex, qbittorrent or tdarr. path: the path after the API root, for example /series, /movie/12, /system/status, /torrents/info, /Items, /get-nodes. Do not add a query string. method: GET, POST, PUT, DELETE or PATCH. params: query options (for qBittorrent POST calls these are the form fields). body: JSON body for POST and PUT (not used by qBittorrent). API roots added for you: Sonarr and Radarr /api/v3, Prowlarr and Seerr /api/v1, Bazarr /api, qBittorrent and Tdarr /api/v2, Jellyfin and Plex none. Plex paths look like /library/sections, /status/sessions, /accounts is blocked. Plex answers in JSON because this tool asks for it. Tdarr reads its database with POST /cruddb and a body like {"data": {"collection": "LibrarySettingsJSONDB", "mode": "getAll"}}. Those read modes run at once. Other modes need confirm=true. GET runs at once. Any change is NOT run until you set confirm=true, and you must first tell the user what will change and get a clear yes. Deleting, restarting, restoring a backup, host or security settings and password changes also need confirm_phrase set to exactly " ", for example "sonarr DELETE /series/5". Never guess a body: read an existing item with GET first and send it back with changes. |
| arr_statusA | Check that services answer. Shows version and health warnings. service: one name, or leave empty to check every service that is set up. |
| arr_queueA | Show what Sonarr and Radarr are downloading right now. service: sonarr, radarr, or empty for both. |
| arr_searchA | Look up a show or movie by name. Nothing is added. service: sonarr (shows), radarr (movies) or seerr (both). Shows the id to use with arr_add. "in_library" is set when it already exists. |
| arr_addA | Add a show to Sonarr or a movie to Radarr. service: sonarr or radarr. external_id: the TVDB id for a show, or the TMDB id for a movie (from arr_search). quality_profile: profile name. If empty and there is only one, it is used. root_folder: folder path. If empty and there is only one, it is used. search_now: start looking for downloads right away. First call without confirm to see what will be added. Ask the user, then call again with confirm=true. |
| arr_calendarB | Upcoming episodes (sonarr) or movie releases (radarr) for the next days. |
| arr_downloadsB | Show qBittorrent torrents. filter: all, downloading, seeding, completed, paused, active, stalled, errored. |
| arr_requestsA | Show Seerr requests. filter: pending, approved, available, processing, unavailable, failed, all. To approve or decline, use arr_call with POST /request//approve (or /decline) after the user says yes. |
| tdarr_summaryA | Show what Tdarr is doing: nodes, workers, and how many files are in each state. show_failed: how many failed file names to list (0 to 50). |
| jellyfin_now_playingA | Show who is watching on Jellyfin right now, and on which device. |
| plex_now_playingA | Show who is watching on Plex right now, and on which device. |
| plex_librariesA | List the Plex libraries with their folders and how many items each has. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Most tools target distinct resources (search vs add, queue vs torrents, plex vs jellyfin now-playing are clearly separated by description). The main ambiguity is arr_call, a generic escape hatch that overlaps with every other tool and could tempt agents to bypass the specific ones. arr_downloads (qBittorrent) and arr_queue (Sonarr/Radarr) are close but the descriptions disambiguate them.
The dominant arr_ prefix is used for 9 tools, but jellyfin_, plex_, and tdarr_ prefixes break the pattern into per-service namespaces. Verbs and nouns are mixed (arr_add, arr_search vs arr_services, arr_calendar, arr_status). Still readable but not a single predictable convention.
13 tools is well within a comfortable range for a multi-service media-management server. Each tool maps to a distinct user intent (search, add, monitor, queue, requests, health, playback) and none feel redundant.
Core read workflows (search, calendar, queue, downloads, status, now-playing, libraries) and add are covered, plus arr_call as a generic escape hatch for the rest. However, mutations beyond add — delete/remove, edit quality profile, monitor toggles, request approve/decline — only exist via raw arr_call rather than dedicated tools, so agents face steeper paths for common write operations.