What can you do with this server?

This server integrates with Radarr and Sonarr to search for and manage movies and TV shows. * Search Movies – Search for movies by title using Radarr's built-in lookup (search_movies) * Add Movies – Add a specific movie to Radarr using its TMDb ID, with an optional custom root folder path (add_movie_by_id) * Search & Add TV Shows – Search using a natural language description and optionally auto-add to Sonarr if only one result is found (search_and_add_show) * Add TV Shows – Add a specific TV show to Sonarr using its TVDB ID and title, with an optional custom root folder path (add_show_by_tvdb_id) * Test Configuration – Verify configuration and API connectivity for both Radarr and Sonarr (test_config) * Check Server Status – Get the live status of both Radarr and Sonarr instances (get_server_status) Connection details (URLs, API keys, quality profiles, root folders) are configured via environment variables, and root folders are auto-detected from Radarr/Sonarr when not explicitly provided.

Which integrations are available for this server?

Enables adding movies to Radarr via natural language queries, with capabilities to search for movies by title and add them by TMDB ID with optional custom root folder specification. Enables adding TV shows to Sonarr via natural language queries, with capabilities to search for and add shows by description or TVDB ID with optional custom root folder specification.

How do I use arr-assistant-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@arr-assistant-mcp add The Matrix to my movie collection" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

arr-assistant-mcp

by omniwaifu

Overview Schema Related Servers Score Discussions

Python

Remote

Arr Assistant MCP

MCP server for searching movies and TV shows and adding them to Radarr and Sonarr.

The server talks directly to the Radarr and Sonarr v3 APIs. Searches and status checks are read-only; the add_* tools and search_and_add_show(..., auto_add=True) create media entries and start searches in the configured Arr service.

Setup

Requires Python 3.12+ and uv for local development.

git clone https://github.com/omniwaifu/arr-assistant-mcp.git
cd arr-assistant-mcp
uv sync --group dev

Related MCP server: overseerr-mcp

Run From Source

Add this to your claude_desktop_config.json to run the checked-out project directly:

{
  "mcpServers": {
    "arr-assistant": {
      "command": "uv",
      "args": [
        "run",
        "--project",
        "/path/to/arr-assistant-mcp",
        "src/arr_assistant_mcp/main.py"
      ],
      "env": {
        "RADARR_URL": "https://radarr.example.com",
        "RADARR_API_KEY": "your-radarr-api-key",
        "SONARR_URL": "https://sonarr.example.com",
        "SONARR_API_KEY": "your-sonarr-api-key",
        "QUALITY_PROFILE_ID": "1",
        "RADARR_ROOT_FOLDER": "/storage/movies",
        "SONARR_ROOT_FOLDER": "/storage/shows"
      }
    }
  }
}

Trailing slashes in RADARR_URL and SONARR_URL are normalized automatically. API keys are required for the corresponding service. Never commit them; pass them through your MCP client or local environment. Prefer HTTPS because Arr API keys are sent with every request. Plain HTTP is safe for loopback URLs; for a trusted LAN or VPN where HTTPS is unavailable, the server allows plain HTTP but logs a warning identifying the service and destination.

Build An MCP Bundle

Packaged release artifacts should now use the .mcpb extension.

npm ci --prefix .github/mcpb-tooling --ignore-scripts
npm audit --prefix .github/mcpb-tooling --audit-level=moderate
npm exec --prefix .github/mcpb-tooling -- mcpb validate manifest.json
npm exec --prefix .github/mcpb-tooling -- mcpb pack . arr-assistant-mcp.mcpb

Open the resulting .mcpb file in Claude Desktop to install it.

Configuration Notes

Radarr/Sonarr API keys: Settings > General > Security > API Key
Quality profile: Use the numeric profile ID from your Radarr or Sonarr instance
Root folders: If omitted, the server auto-detects the first available root folder from each service

Tools

test_config() - Test configuration and connectivity for both Radarr and Sonarr
search_movies(title) - Search for movies by title
add_movie_by_id(tmdb_id, root_folder=None) - Add a movie to Radarr
search_and_add_show(description, auto_add=False) - Search for TV shows and optionally auto-add the only match to Sonarr; returns both the matches and an explicit auto_add_result
add_show_by_tvdb_id(tvdb_id, title, root_folder=None) - Add a show to Sonarr
get_server_status() - Check Radarr and Sonarr status

Usage

search_movies("The Matrix")
add_movie_by_id(603)

# A search is read-only unless auto_add is explicitly enabled.
search_and_add_show("Doctor Who", auto_add=False)

# Specify a custom root folder
add_show_by_tvdb_id(123456, "Attack on Titan", "/storage/anime")

Root folders are auto-detected from your Radarr and Sonarr configurations when not provided, but can still be overridden per request.

Development and Testing

Run the local checks with:

uv run ruff check src tests
uv run ruff format --check src tests
uv run pytest

The default suite never contacts a real Arr instance. An additional opt-in suite performs only read-only status and root-folder requests against locally configured services:

ARR_ASSISTANT_LIVE_TESTS=1 \
RADARR_URL=https://radarr.example.com \
RADARR_API_KEY=your-radarr-api-key \
SONARR_URL=https://sonarr.example.com \
SONARR_API_KEY=your-sonarr-api-key \
uv run pytest tests/test_live.py -v

Use environment variables or a local ignored .env file for credentials. Do not paste real API keys into source files, test fixtures, shell scripts, or commits.

Releases

Versions are kept in sync across pyproject.toml, manifest.json, and the package. Pushing a tag matching the project version (for example, v0.2.2) runs linting, tests, a dependency audit, and package validation before publishing the MCPB, wheel, and source distribution to a GitHub release.

Available Tools

6 tools

add_movie_by_idA

Add a specific movie to Radarr using its TMDb ID.

ParametersJSON Schema

Name	Required	Description	Default
`tmdb_id`	Yes	The Movie Database ID for the movie
`root_folder`	No	Optional root folder path (e.g., "/storage/movies")

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	Yes
`success`	Yes
`media_id`	No

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'Add' without mentioning potential side effects (e.g., failure if movie already exists), prerequisites, or behavior of the optional root_folder. This is a significant gap for a mutation tool.

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

Conciseness5/5

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

The description is a single clear sentence with zero redundant words or restating of schema information. It earns high marks for conciseness.

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

Completeness3/5

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

The tool is simple with 2 params and an output schema, so the brief description is partially sufficient. However, it lacks explicit usage context (e.g., that the movie must first be found via search_movies) and behavioral details, making it less complete than ideal for a mutation tool without annotations.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents both parameters well. The description adds marginal meaning by reinforcing 'using its TMDb ID,' but it does not clarify the root_folder default semantics beyond the schema's own description.

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

Purpose5/5

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

The description uses the specific verb 'Add' with a clear resource ('a specific movie to Radarr') and method ('using its TMDb ID'). It distinguishes itself from sibling tools like 'add_show_by_tvdb_id' (TV shows) and 'search_movies' (searching).

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

Usage Guidelines3/5

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

The description implies usage when a TMDb ID is known, but it does not explicitly state when to use this tool versus alternatives like 'search_movies' to find the ID first, or 'add_show_by_tvdb_id' for shows. No exclusions are provided.

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

add_show_by_tvdb_idA

Add a specific TV show to Sonarr using its TVDB ID.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	The title of the show
`tvdb_id`	Yes	The TV Database ID for the show
`root_folder`	No	Optional root folder path (e.g., "/storage/anime")

Output Schema

ParametersJSON Schema

Name	Required	Description
`message`	Yes
`success`	Yes
`media_id`	No

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states the core action, but doesn't disclose side effects (e.g., what happens if the show already exists), whether the root_folder is required if not provided, or any verification steps. Minimal behavioral disclosure.

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

Conciseness5/5

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

Single sentence, front-loaded with action and key parameter, no wasted words. Ideal length for the function's simplicity.

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

Completeness3/5

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

For a simple 3-param tool with output schema, the description is adequate but minimal. It doesn't explain prerequisites like root_folder default behavior or duplicate handling, but given the schema covers all parameters and there's no annotation burden, a score of 3 reflects the minimum viable while leaving some gaps.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. The description mentions the TVDB ID and title but doesn't add meaning beyond the schema. The optional root_folder is not explained further. Description adds no extra semantic value beyond the schema.

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

Purpose5/5

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

The description clearly states the action (add), the resource (specific TV show to Sonarr), and the method (using its TVDB ID). It distinguishes from siblings like search_and_add_show by specifying direct ID-based addition.

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

Usage Guidelines3/5

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

The description implies usage for direct ID-based addition, but there is no explicit when/when-not guidance or mention of alternatives like search_and_add_show. The context is clear from the name, but the description doesn't formally distinguish it from sibling tools.

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

get_server_statusA

Check the status and connectivity of Radarr and Sonarr servers.

Returns: Status information for both servers

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It discloses the action (checking connectivity) and return type (status information), but does not detail side effects, rate limits, or operational behavior. Adequate for a simple read-only tool.

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

Conciseness5/5

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

Two sentences, concise and front-loaded. The first sentence states the purpose, the second indicates return format. No unnecessary text.

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 zero parameters and existence of an output schema, the description is complete. It sufficiently describes the tool's function and return value for a simple status check.

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

Parameters4/5

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

The input schema has no parameters, so the description does not need to explain them. Baseline of 4 is appropriate since no additional parameter meaning is needed.

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

Purpose5/5

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

The description clearly states the tool checks status and connectivity of Radarr and Sonarr servers, using specific verb 'Check' and specific resources, which distinguishes it from sibling tools like add_movie_by_id or search_movies.

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

Usage Guidelines3/5

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

The description implies usage for checking server status, but does not explicitly state when to use versus alternatives or provide exclusions. Context from sibling tool names helps, but the description itself is not explicit.

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

search_and_add_showA

Search for TV shows using natural language description and optionally add to Sonarr.

ParametersJSON Schema

Name	Required	Description	Default
`auto_add`	No	If True and only one result found, automatically add to Sonarr
`description`	Yes	Natural language description of the TV show (e.g., "British time travel show with the Doctor")

Output Schema

ParametersJSON Schema

Name	Required	Description
`results`	Yes
`auto_add_result`	No
`auto_add_requested`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

There are no annotations, so the description carries the burden of disclosing side effects. It only says 'optionally add to Sonarr' without stating that auto_add defaults to false, only triggers on unique matches, or what write actions occur.

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

Conciseness5/5

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

The description is a single, front-loaded sentence with no filler. It efficiently captures both the search and optional add behavior.

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

Completeness3/5

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

The tool is simple and has full parameter schema plus an output schema, but the description lacks explicit behavior around the auto_add path and when not to use it. Given no annotations, the description is adequate but not fully complete.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already describes both parameters well. The description adds only minimal mapping between 'natural language description' and the description parameter, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool searches for TV shows using natural language and optionally adds to Sonarr. This distinguishes it from siblings like search_movies and add_show_by_tvdb_id.

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

Usage Guidelines4/5

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

It gives clear context: use for natural-language TV show lookup with an optional add step. It does not explicitly name alternatives or exclusions, but the phrasing implies this is not for movie search or TVDB ID-based adds.

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

search_moviesA

Search for movies by title using Radarr's built-in lookup.

ParametersJSON Schema

Name	Required	Description	Default
`title`	Yes	Movie title only (e.g., "The Matrix" or "Primer")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the transparency burden. It clearly indicates a search operation, implying a non-destructive read, but does not explicitly state safety or side effects. Since it is a search, a reasonable assumption is made, but explicit disclosure would improve transparency.

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

Conciseness5/5

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

The description is a single, concise sentence with no unnecessary words. It directly conveys the purpose and method without redundancy, achieving high efficiency.

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?

With a simple one-parameter schema and a clear description, the tool is fully contextualized. Since an output schema is present, return value details are not required in the description, and the given information is sufficient for a user to understand its use.

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

Parameters5/5

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

The parameter 'title' has a descriptive annotation specifying 'Movie title only' with examples, which clarifies the expected input format and distinguishes it from other identifiers. This adds significant meaning beyond the schema's type definition.

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

Purpose5/5

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

The description clearly states the action (search for movies) and the resource (by title using Radarr's built-in lookup). It distinguishes from sibling tools like search_and_add_show (for shows) and add_movie_by_id (for adding by ID), making the purpose unambiguous.

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

Usage Guidelines4/5

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

The description implies when to use this tool (searching movies by title) and indirectly differentiates from siblings (e.g., search_and_add_show for shows). However, it does not explicitly state when not to use it or alternative cases, but the implied context is sufficiently clear.

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

test_configA

Test the current configuration and API connectivity.

Returns: Configuration status and basic connectivity tests

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description should disclose behavioral traits. It mentions returns (configuration status and connectivity tests) but omits side effects, auth requirements, or safety implications. Since it's a test tool, it likely has no side effects, but this is not stated.

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

Conciseness5/5

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

The description is concise with two sentences, front-loading the purpose. No unnecessary words. Every part provides value.

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

Completeness5/5

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

Given the tool's simplicity (no parameters, no annotations, but has output schema), the description adequately covers its purpose and return value. Complete for its complexity.

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

Parameters4/5

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

There are no parameters, so the description does not need to add parameter semantics. Schema coverage is 100%. The baseline for 0 parameters is 4, and no extra info is required.

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

Purpose5/5

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

The name 'test_config' and description 'Test the current configuration and API connectivity' clearly specify the tool's function. It is distinct from siblings like 'add_movie_by_id' and 'get_server_status', which have different purposes.

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

Usage Guidelines3/5

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

The description implies the tool is for testing configuration and connectivity, but does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or alternative tool references are provided.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct target: movies vs shows, status vs config, search vs add. No functional overlap.

Naming Consistency4/5

Most tools follow verb_noun pattern (add_movie, add_show, get_server_status, search_movies, test_config). 'search_and_add_show' is a combined verb phrase but still readable.

Tool Count5/5

With 6 tools covering both Radarr and Sonarr basics, the count is well-scoped and not overwhelming.

Completeness3/5

The set covers adding media and checking status but lacks delete/update for both movies and shows, and has no standalone search for shows (combined with add). Some gaps for full lifecycle.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
Airweave Search
io.github.airweave-ai
MCP server for searching Airweave collections with natural language queries.
Search Art & Culture Open Data
25,729
Kody
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2514
Tv Maze Mcp
io.github.varvararatta
Unlock a world of television with the TV Maze MCP server. Effortlessly search for shows by name or
Search Entertainment & Media
2

Related MCP Servers

nas-mcp-server
Entertainment & Media Search
matthieurosset
A
license
A
quality
D
maintenance
MCP server for managing a media server stack (Plex, Radarr, Overseerr, Bazarr, Prowlarr, Trakt.tv) using natural language to browse, request, and discover content.
Updated 7 months ago (2026-02-01 21:33 UTC)
12
MIT
overseerr-mcp
Entertainment & Media Search
Milli42
F
license
Not graded
quality
B
maintenance
MCP server for Overseerr that enables searching, requesting, and managing media (movies and TV shows) through natural language, with integration to Radarr/Sonarr for automated downloads.
Updated 2 months ago (2026-06-21 23:23 UTC)
media-mcp
Entertainment & Media Content Management Systems
ava-hip
F
license
A
quality
B
maintenance
Enables users to manage Sonarr and Radarr instances through natural language, allowing search, addition, deletion, and monitoring of TV series and movies.
Updated a month ago (2026-08-03 20:04 UTC)
60
Radarr and Sonarr MCP Server
Entertainment & Media Search
g2dgaming
F
license
Not graded
quality
C
maintenance
An MCP server that enables AI assistants to manage your Radarr movies and Sonarr TV shows, including search, add, delete, monitor, and grab releases.
Updated 2 months ago (2026-07-05 20:05 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/omniwaifu/arr-assistant-mcp'

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