Enables management of TV series collections through Sonarr, including searching and adding series, managing quality profiles and season monitoring, interactive release browsing, manual downloads, and series deletion with granular season control.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sonarr MCP Server search for The Mandalorian TV series"
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.
A Model Context Protocol (MCP) server for Sonarr, enabling AI assistants to manage your TV series collection through natural language interactions.
🔍 Search Series - Find TV series to add to your collection
➕ Add Series - Add TV series with quality profiles, season monitoring, and search options
📋 List Series - View your entire TV series library with episode counts
📺 Series Details - Get detailed information including episode status and downloads
⚙️ Update Series - Change quality profiles, season monitoring, and trigger searches
🗑️ Delete Series/Seasons - Remove entire series or specific seasons (with optional file deletion)
🔍 Interactive Search - Browse available releases for episodes with quality and seeder info
📊 Quality Profiles - View available quality settings
⬇️ Download Release - Manually download specific releases for episodes
🎯 Season Control - Granular monitoring and management of individual seasons
Related MCP server: Sonarr & Radarr MCP Server
pip install sonarr-mcpgit clone https://github.com/MichaelReubenDev/sonarr-mcp.git
cd sonarr-mcp
uv sync# Using uvx (if installed from PyPI)
uvx sonarr-mcp --url http://localhost:8989 --api-token YOUR_API_TOKEN
# Using uv run (from source)
uv run sonarr-mcp --url http://localhost:8989 --api-token YOUR_API_TOKEN
# With debug logging
uv run sonarr-mcp --url http://localhost:8989 --api-token YOUR_API_TOKEN --debugAdd this to your Claude Desktop MCP configuration:
{
"mcpServers": {
"sonarr": {
"command": "uvx",
"args": [
"sonarr-mcp",
"--url", "http://localhost:8989",
"--api-token", "YOUR_API_TOKEN"
]
}
}
}For testing and development:
npx @modelcontextprotocol/inspector uv run sonarr-mcp --url http://localhost:8989 --api-token YOUR_API_TOKEN--url: Your Sonarr base URL (e.g., http://localhost:8989)
--api-token: Your Sonarr API token (found in Settings → General → Security)
--debug: Enable debug logging
Tool | Description | Parameters |
| Search for TV series to add |
|
| Add a TV series to Sonarr |
|
| List all TV series in library | None |
| Get detailed series information |
|
| Update series settings |
|
| Delete a series or specific seasons |
|
| Browse available releases |
|
| Download a specific release |
|
| List available quality profiles | None |
The monitor_type parameter supports these options:
all - Monitor all episodes
future - Monitor future episodes only
missing - Monitor missing episodes
existing - Monitor existing episodes
recent - Monitor recent episodes
first - Monitor first season only
latest - Monitor latest season only
none - Monitor no episodes
season_specific - Monitor specific seasons (requires monitor_seasons array)
Search for series: "Search for Breaking Bad TV series"
Add series: "Add Breaking Bad with HD-1080p quality, monitor all episodes"
Add with specific seasons: "Add The Office with monitor_type: 'season_specific' and monitor_seasons: [1, 2, 3]"
Check status: "Show me details for Breaking Bad"
List series: "Show me all my TV series"
Update monitoring: "Change series ID 123 to monitor only seasons 2 and 4"
Update quality and search: "Change series ID 123 to 4K quality and start searching for missing episodes"
Browse releases: "Show me available releases for series ID 123 season 2"
Monitor specific seasons: "Update series ID 123 with monitor_type: 'season_specific', monitor_seasons: [1, 3, 5]"
Delete specific seasons: "Delete seasons 2 and 4 from series ID 123 including files"
Search specific episodes: "Show releases for series ID 123 season 3 episode 5"
Get series details: "Show me the status of Game of Thrones"
Interactive search: "What releases are available for The Walking Dead season 1?"
Episode search: "Find releases for series ID 456 season 2 episode 10"
Python 3.13+
Sonarr v3+ with API access
Network access to your Sonarr instance
# Clone the repository
git clone https://github.com/MichaelReubenDev/sonarr-mcp.git
cd sonarr-mcp
# Install dependencies
uv sync
# Test with the MCP Inspector
task mcp_inspector
# Run with debug logging
uv run sonarr-mcp --url http://localhost:8989 --api-token YOUR_TOKEN --debugFork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
This project is licensed under the MIT License - see the LICENSE file for details.
Sonarr - The amazing TV series collection manager
Model Context Protocol - For enabling AI tool integration
Anthropic - For Claude and MCP development
Add a TV series to Sonarr
| Name | Required | Description | Default |
|---|---|---|---|
| tvdb_id | Yes | TVDB ID of the series | |
| quality_profile_id | Yes | Quality profile ID (use get_quality_profiles to see available options) | |
| root_folder_path | No | Root folder path for the series | /tv |
| season_folder | No | Whether to use season folders | |
| monitor_type | Yes | Which episodes to monitor: 'all' (all episodes), 'future' (future episodes only), 'missing' (missing episodes), 'existing' (existing episodes), 'recent' (recent episodes), 'first' (first season), 'latest' (latest season), 'none' (no episodes), 'season_specific' (monitor specific seasons only - requires monitor_seasons) | |
| monitor_seasons | No | Specific season numbers to monitor (only used with monitor_type: 'season_specific'). Example: [1, 3, 5] | |
| search_for_missing_episodes | No | Whether to automatically search for missing episodes after adding |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility for behavioral disclosure. It only states the action without mentioning side effects (e.g., creating a database entry, possibly triggering searches), required permissions, or whether the operation is 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?
While extremely concise at one sentence, it is under-specified for a tool with seven parameters and no corresponding context. The description lacks structure and fails to front-load critical usage 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?
Given no output schema, no annotations, and seven parameters, the description is severely inadequate. It provides no context about return values, error conditions, or prerequisites (e.g., requiring quality_profile_id from get_quality_profiles).
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 description does not need to add parameter details. The schema already documents all parameters. The description adds no additional meaning beyond the schema, resulting in a baseline score.
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 'Add a TV series to Sonarr' with a specific verb and resource. While brief, it unambiguously identifies the tool's action and domain, and the name 'add_series' distinguishes it from siblings like 'update_series' or 'delete_series'.
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 no guidance on when to use this tool versus alternatives. It does not specify that it is for new series only, nor does it mention prerequisites like having quality profiles or root folders configured.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a TV series or specific seasons from Sonarr
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | Sonarr series ID (use the ID from list_series output) | |
| delete_seasons | No | Specific season numbers to delete (if not provided, deletes entire series). Example: [2, 4] | |
| delete_files | No | Whether to delete files from disk (applies to entire series or specific seasons) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that deletion is destructive, and the schema clarifies the delete_files parameter defaults to false, so files are not deleted by default. However, it lacks details on irreversibility, side effects, or prerequisites.
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, concise sentence with no waste. It directly conveys the tool's purpose.
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 deletion tool with no output schema, the description is adequate but minimal. It does not explain the return value or confirmation behavior, leaving some gaps for an AI agent.
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%, providing clear parameter descriptions. The description does not add additional meaning beyond restating the action. 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 verb 'Delete' and the resource 'a TV series or specific seasons from Sonarr'. It distinguishes this tool from siblings like add_series or update_series by focusing on 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 description implies a clear use case (deleting a series or seasons) but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a specific release for an episode
| Name | Required | Description | Default |
|---|---|---|---|
| release_guid | Yes | Release GUID from interactive_search results | |
| series_id | Yes | Sonarr series ID |
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 only says 'Download' but does not disclose side effects (e.g., triggers download in Sonarr, requires authentication, or modifies state). This is insufficient for an action 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?
The description is a single concise sentence, front-loaded with the action. However, it could benefit from additional context without becoming verbose.
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 description is too brief for a mutation tool with no annotations and no output schema. It does not clarify what 'Download' entails (e.g., queuing vs. direct download) or how it relates to interactive_search. Incomplete.
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% with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, which is acceptable for high-coverage parameters. Baseline 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 uses a specific verb 'Download' and resource 'release', clearly indicating the action. It distinguishes from siblings like interactive_search (search) and get_series (retrieve series info).
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 on when to use this tool versus alternatives like interactive_search. The description does not mention prerequisites or that it should be used after obtaining a release_guid from interactive_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all quality profiles from Sonarr
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must cover behavioral context. It only states a read operation without details like return format, data volume, or potential errors.
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?
Single sentence with no fluff; efficiently communicates the tool's purpose.
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 no-parameter read tool, the description is mostly complete. Could mention that it returns all profiles, but not essential.
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?
No parameters exist, so the description adds no extra info beyond the schema. With 0 params, baseline is 4.
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?
Description clearly states the verb 'Get' and resource 'quality profiles' from 'Sonarr', which distinguishes it from sibling tools focused on series management and downloads.
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 explicit guidance on when to use this tool versus alternatives. Implicit differentiation from siblings exists but no direct statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific TV series
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | Sonarr series ID (use the ID from list_series output) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'get detailed information', lacking any disclosure of side effects, error handling, auth requirements, or rate limits. The read-only nature is implied but not explicit.
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?
Single sentence of 8 words, no fluff. Front-loads purpose. Could benefit from slightly more detail, but no wasted 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?
Lacks explanation of what 'detailed information' includes, no output schema or example. For a simple retrieval tool with multiple siblings, more context needed to guide correct usage.
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 provides good description for series_id at 100% coverage. Description adds no extra meaning beyond what schema offers, so baseline 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?
Clear verb 'Get' and resource 'detailed information about a specific TV series'. Differentiates from siblings like add/delete/update, but doesn't contrast with list_series which also retrieves series info.
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?
Schema suggests using ID from list_series, implying a retrieval context. No explicit when-to-use or when-not, and no mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for available releases for a TV series episode
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | Sonarr series ID (use the ID from list_series output) | |
| season_number | No | Season number (optional, searches all seasons if not provided) | |
| episode_number | No | Episode number (optional, searches all episodes if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only says 'search for available releases' without explaining side effects, return format, or interactive nature. Minimal disclosure.
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?
Single sentence, no wasted words, front-loaded with the key action. Could benefit from slight expansion on behavior without being verbose.
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?
No output schema exists, so the description should explain return values or effect. It does not. With 3 parameters and no output schema, the description is insufficient for full understanding.
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?
Input schema has 100% coverage with clear parameter descriptions. The overall description adds no extra meaning beyond the schema, 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?
Description clearly states it searches for available releases for a TV series episode. Verb+resource is specific and distinguishes from siblings like search_series (series search) and download_release.
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?
Usage is implied from the description, but there is no explicit guidance on when to use this tool versus alternatives like search_series. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all TV series from Sonarr
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action, omitting traits like read-only nature, potential emptiness, or any 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?
The description is extremely concise at six words with no wasted content, though it could benefit from additional front-loaded context without becoming verbose.
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 lack of output schema and annotations, the description fails to inform the AI about the return format, pagination, or error conditions, leaving the tool under-specified for complex decision-making.
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 no parameters, and schema coverage is trivially 100%. The description adds no extra meaning beyond what the input schema provides, meeting the baseline for high 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 clearly states the verb 'Get', resource 'all TV series', and source 'Sonarr', effectively distinguishing it from sibling tools like 'get_series' which likely targets a single series.
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 provided on when to use this tool versus alternatives such as 'get_series' or 'search_series', leaving the AI without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for TV series in Sonarr
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | TV series title to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only says 'Search', omitting details like result format, pagination, or that it's a read-only 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?
The description is a single sentence with no extraneous text. It is appropriately short but could incorporate a small amount of additional context without losing conciseness.
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 tool, the description omits expected behavior (e.g., returns matching series list). With no output schema, the description should clarify the 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?
Schema coverage is 100% with a clear description for the only parameter 'query'. The description adds no new meaning beyond what the schema already provides, so 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 ('Search') and resource ('TV series in Sonarr'), distinguishing it from siblings like 'list_series' by implying query-based retrieval. However, it could be more specific about search criteria beyond title.
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 provided on when to use this tool over similar siblings like 'interactive_search' or 'list_series'. The agent lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update series settings (quality profile, monitoring, search)
| Name | Required | Description | Default |
|---|---|---|---|
| series_id | Yes | Sonarr series ID (use the ID from list_series output) | |
| quality_profile_id | No | New quality profile ID (optional, use get_quality_profiles to see options) | |
| monitor_type | No | Which episodes to monitor: 'all', 'future', 'missing', 'existing', 'recent', 'first', 'latest', 'none' | |
| monitor_seasons | No | Specific season numbers to monitor (overrides monitor_type if provided). Example: [1, 3, 5] | |
| start_search | No | Whether to search for missing episodes in monitored seasons after update |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it updates settings, but lacks disclosure on side effects (e.g., irreversible changes, permissions required, behavior on invalid series_id). Minimal 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?
Single sentence with no extraneous words. Front-loaded with verb and resource, followed by key settings. Excellent conciseness.
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?
Adequate for a basic update tool given rich parameter descriptions and no output schema. Lacks information on return status, error handling, or persistence guarantees. Sufficient but not thorough.
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 baseline is 3. Description adds no additional parameter meaning beyond the schema's detailed descriptions (e.g., series_id references list_series, quality_profile_id references get_quality_profiles).
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?
Description explicitly states verb 'update' and resource 'series settings', listing the specific settings (quality profile, monitoring, search). Clearly distinguishes from siblings like add_series, delete_series, and list_series.
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?
Implies use for modifying existing series settings, but no explicit guidance on when to use vs alternatives (e.g., add_series for creation, delete_series for removal). No context on prerequisites or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0add_seriesdelete_seriesdownload_releaseget_quality_profilesget_seriesinteractive_searchlist_seriessearch_seriesupdate_seriesEach tool targets a distinct action or resource: add/delete/update series, list/get/search series, search/download releases, and get quality profiles. No two tools overlap in purpose.
Most tools use a consistent verb_noun pattern (e.g., add_series, delete_series, download_release). The exception is interactive_search, which mixes an adjective with a noun, breaking the pattern slightly.
With 9 tools, the set is well-scoped. Each tool covers an essential function for Sonarr management, not too few or too many for the domain.
The set covers core CRUD operations and key workflows (search, add, download). Minor gaps exist, such as tools for managing episode status or series seasons, but the main operations are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage digital signage screens, playlists and media from your AI assistant.
The media memory layer for AI agents and their humans. Your AI client gets 29 tools to search your collection, add items, update ratings, preview music, and find patterns across everything you've read, watched, and listened to.
Unlock a world of television with the TV Maze MCP server. Effortlessly search for shows by name or
Control Android TV from any AI. 38 MCP tools: playback, recap, recommend, smart-home, schedules.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/micky-devs/sonarr-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
