FlixBridge is an MCP server that bridges AI assistants with media management services (Sonarr, Radarr, SABnzbd) for monitoring, managing, and automating TV shows and movies.
Service Discovery: list_services to identify all configured media services and downloaders
System Health: system_status for health, version info, and performance metrics per service; server_metrics for FlixBridge-level monitoring
Queue Management: queue_list for progress tracking, queue_grab to force retry downloads, queue_diagnostics to diagnose/auto-fix stuck items
Media Search & Addition: search for new series or movies, add_new to add them with quality profiles and root folders
Library Management: quality_profiles to list quality configs, root_folders for storage info, import_issues to detect stuck imports, history_detail for download/import history
Multi-Service Diagnostics: all_services_diagnostics to run diagnostics across all instances simultaneously
Unified Download Status: download_status for a combined cross-service overview
Content Removal: remove_content for safe removal of queue, library, or downloader items with dry-run preview support
Provides comprehensive movie management capabilities including adding new movies, managing quality profiles, monitoring download queues, running diagnostics, and accessing system health information
Enables TV show management through tools for adding series, configuring quality profiles, monitoring downloads, managing libraries, and performing automated diagnostics and troubleshooting
Click on "Deploy 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., "@FlixBridge check my download queue status"
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.
Media Management MCP Server
Connect your AI assistant to TV shows and movie management services
FlixBridge is a Model Context Protocol (MCP) server that bridges AI assistants with media management services. It provides a unified interface for monitoring downloads, managing libraries, and automating media workflows.
🎬 Multi-Service Support - TV shows, movies, and download clients
🔄 Real-Time Monitoring - Queue status, system health, and diagnostics
🤖 Smart Automation - Auto-fix stuck downloads and optimize workflows
🏢 Multi-Instance Ready - Quality tiers, content types, environments
🔍 Intelligent Search - Find and add new content with smart quality profiles
📊 Unified Dashboard - Single view across all your services
🐛 Advanced Debugging - Comprehensive logging and diagnostics
⚡ High Performance - Efficient, lightweight, TypeScript-first
Related MCP server: Trakt
# Install globally
npm install -g @thesammykins/flixbridge
# Or install locally in your project
npm install @thesammykins/flixbridge# Clone the repository
git clone https://github.com/thesammykins/FlixBridge.git
cd FlixBridge
# Install dependencies and build
npm install && npm run build# 1. Configure your services via environment variables
export SONARR_URL="http://localhost:8989"
export SONARR_API_KEY="your-sonarr-api-key"
export RADARR_URL="http://localhost:7878"
export RADARR_API_KEY="your-radarr-api-key"
# Optional downloader
export SABNZBD_URL="http://localhost:8080"
export SABNZBD_API_KEY="your-sabnzbd-api-key"
# 2. Build and run
npm run build
npm startOr with slug-based configuration for multiple instances:
# Multiple Sonarr instances
export SONARR_HD_URL="http://localhost:8989"
export SONARR_HD_API_KEY="your-hd-sonarr-key"
export SONARR_4K_URL="http://localhost:8990"
export SONARR_4K_API_KEY="your-4k-sonarr-key"
# Multiple Radarr instances
export RADARR_MAIN_URL="http://localhost:7878"
export RADARR_MAIN_API_KEY="your-main-radarr-key"
export RADARR_UHD_URL="http://localhost:7879"
export RADARR_UHD_API_KEY="your-uhd-radarr-key"
npm startFlixBridge v0.3.x uses environment-only configuration with slug-based discovery. No config files and no JSON-in-env mapping required.
Sonarr: SONARR_<SLUG>_URL, SONARR_<SLUG>_API_KEY, SONARR_<SLUG>_NAME (optional)
Radarr: RADARR_<SLUG>_URL, RADARR_<SLUG>_API_KEY, RADARR_<SLUG>_NAME (optional)
SABnzbd: SABNZBD_<SLUG>_URL, SABNZBD_<SLUG>_API_KEY, SABNZBD_<SLUG>_NAME (optional)
Prefixed aliases are also accepted: FLIX_BRIDGE_SONARR_<SLUG>_URL with _KEY or _API_KEY.
Single-instance prefixed aliases are accepted too, e.g. FLIX_BRIDGE_SABNZBD_URL with FLIX_BRIDGE_SABNZBD_KEY.
SONARR_URL
SONARR_API_KEY
RADARR_URL
RADARR_API_KEY
SABNZBD_URL
SABNZBD_API_KEY
# Sonarr
export SONARR_MAIN_URL="http://sonarr-main:8989"
export SONARR_MAIN_API_KEY="{{SONARR_MAIN_KEY}}"
export SONARR_4K_URL="http://sonarr-4k:8989"
export SONARR_4K_API_KEY="{{SONARR_4K_KEY}}"
# Radarr
export RADARR_MAIN_URL="http://radarr-main:7878"
export RADARR_MAIN_API_KEY="{{RADARR_MAIN_KEY}}"
export RADARR_UHD_URL="http://radarr-uhd:7878"
export RADARR_UHD_API_KEY="{{RADARR_UHD_KEY}}"
# SABnzbd (optional)
export SABNZBD_MAIN_URL="http://sab-main:8080"
export SABNZBD_MAIN_API_KEY="{{SAB_MAIN_KEY}}"Notes:
Service names default to sonarr-<slug> / radarr-<slug> (slug lowercased, _ → -).
If you set <KIND>_<SLUG>_NAME, that overrides the final name (ensure it contains "sonarr"/"radarr" to pass current detection).
Single-instance fallback (SONARR_URL/RADARR_URL/SABNZBD_URL) still works for simple setups.
⚠️ Important: Always call
list_servicesfirst to discover available services before using any other tools.
list_services - Discover all configured services and downloaders
system_status - Health and version information
queue_list - Download queue with progress tracking
queue_grab - Force retry/grab specific downloads
queue_diagnostics - Analyze stuck items; pass autoFix:false for read-only checks
manual_import - Preview and execute one-item manual imports with confirmation-token flow
remove_content - Preview and remove queue, library, or downloader items with confirmation
root_folders - Storage locations and free space
search - Find new series/movies to add
add_new - Add media with intelligent quality profiles
quality_profiles - List available quality configurations
history_detail - Download and import history
import_issues - Detect stuck downloads and import problems
all_services_diagnostics - Run diagnostics across all instances
download_status - Unified status across services and downloaders
server_metrics - Local operation metrics and health status
Production Safety:
queue_diagnosticsandall_services_diagnosticsdefault toautoFix:true; explicitly passautoFix:falsefor read-only production baselines. Useremove_contentwithdryRun:truefirst and execute only with the returnedconfirmationTokenafter checking the preview.
Use this prompt with your coding agent to install FlixBridge and return a ready-to-paste MCP config:
Install and configure FlixBridge MCP for me.
Requirements:
1) Install package: @thesammykins/flixbridge
2) Generate MCP config for Claude Desktop using command "npx" and args ["@thesammykins/flixbridge"]
3) Include these env vars in the config with my values:
- SONARR_URL
- SONARR_API_KEY
- RADARR_URL
- RADARR_API_KEY
- SABNZBD_URL (optional)
- SABNZBD_API_KEY (optional)
4) Return only:
- exact install command(s)
- exact claude_desktop_config.json snippet
- a 3-step verification checklist
5) After setup, remind me to call list_services first.If you use slug-based multi-instance setup, ask the agent to use SONARR_<SLUG>_*, RADARR_<SLUG>_*, and SABNZBD_<SLUG>_* variables.
Add to claude_desktop_config.json:
{
"mcpServers": {
"flixbridge": {
"command": "npx",
"args": ["@thesammykins/flixbridge"],
"env": {
"SONARR_URL": "http://localhost:8989",
"SONARR_API_KEY": "your-sonarr-api-key",
"RADARR_URL": "http://localhost:7878",
"RADARR_API_KEY": "your-radarr-api-key"
}
}
}
}# Install globally for easier usage
npm install -g @thesammykins/flixbridgeThen use with Claude Desktop by providing environment variables (standard or via mapping):
{
"mcpServers": {
"flixbridge": {
"command": "flixbridge",
"env": {
"SONARR_URL": "http://localhost:8989",
"SONARR_API_KEY": "your-sonarr-api-key",
"RADARR_URL": "http://localhost:7878",
"RADARR_API_KEY": "your-radarr-api-key",
"SABNZBD_URL": "http://localhost:8080",
"SABNZBD_API_KEY": "your-sabnzbd-api-key"
}
}
}
}export SONARR_URL="http://localhost:8989"
export SONARR_API_KEY="your-sonarr-api-key"
export RADARR_URL="http://localhost:7878"
export RADARR_API_KEY="your-radarr-api-key"
export SABNZBD_URL="http://localhost:8080"
export SABNZBD_API_KEY="your-sabnzbd-api-key"Enable comprehensive debug logging:
FLIX_BRIDGE_DEBUG=1 npm run dev# Basic functionality test
npm run smoke
# Test with debug output
FLIX_BRIDGE_DEBUG=1 npm run smokeInstallation & Setup - Requirements and installation
Configuration Guide - All configuration methods
Usage Guide - MCP client setup and workflows
API Reference - Complete tool documentation
Multi-Instance Setup - Advanced multi-instance patterns
Troubleshooting - Common issues and solutions
Architecture Guide - Technical architecture for developers
Read the Architecture Guide
Follow engineering principles in AGENTS.md
Maintain TypeScript strict mode
Add tests for new features
Run npm run smoke before submitting
MIT - see LICENSE file for details
Check the troubleshooting guide
Run diagnostics: npm run smoke
Enable debug mode: FLIX_BRIDGE_DEBUG=1
Review logs from your media management services
Made with ❤️ for the home media automation community
Add new media to library
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| service | Yes | ||
| foreignId | Yes | ||
| monitored | No | ||
| rootFolderPath | No | ||
| qualityProfileId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description does not disclose any behavioral traits beyond 'add', such as whether it is destructive, creates duplicates, requires authentication, or has rate limits. No annotations are provided to fill the gap.
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 exceedingly short (3 words), which is concise but at the cost of informativeness. It does not earn its place as it omits critical details about usage and behavior.
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 tool with 6 parameters, no output schema, and no annotations, the description is completely inadequate. It fails to cover the process, effects, or return values, leaving the agent without essential context.
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 description coverage is 0%, so the description must compensate, but it adds no information about parameters. It does not explain what 'service', 'foreignId', or other fields mean, leaving the agent to guess.
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 states 'Add new media to library' which is a clear verb+resource, but it lacks specificity about what kind of media or library, and does not differentiate from sibling tools like 'manual_import' or 'search'.
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. Sibling tools include 'manual_import', 'search', etc., but there is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze and auto-fix stuck queue items across all services
| Name | Required | Description | Default |
|---|---|---|---|
| autoFix | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'auto-fix' indicating mutation/destruction, but does not detail side effects, permissions required, or what exactly is fixed. This is insufficient for a tool performing automated repairs.
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 fluff, but it is overly brief. It could include more context without becoming verbose, striking a better balance between conciseness and informativeness.
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 tool has one optional parameter, no output schema, and no annotations, the description should provide more context about behavior, return values, and usage examples. It is incomplete for making an informed tool choice.
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 description coverage is 0%, and the description adds no meaning to the 'autoFix' parameter beyond its name. Whether setting it to false means analysis-only or something else is unclear. The description should explain the parameter's effect.
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 explicitly states the action ('Analyze and auto-fix') and the target resource ('stuck queue items across all services'). This clearly distinguishes it from sibling tools like 'queue_diagnostics' which might be more focused or per-service.
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 usage for stuck queue items but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, despite potential overlap with 'queue_diagnostics' or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get unified download status across arr services and downloaders
| Name | Required | Description | Default |
|---|---|---|---|
| services | No | ||
| downloader | No | ||
| includeDownloader | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavior. It only mentions 'unified status', lacking details on auth, rate limits, or whether it is read-only.
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 is concise but omits necessary details. It front-loads intent but does not structure information efficiently.
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 parameter documentation, and lack of sibling differentiation, the description is insufficient for a tool with three optional parameters.
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 description coverage is 0%. The description fails to explain the parameters 'services', 'downloader', and 'includeDownloader', which are critical for effective use.
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 it retrieves unified download status across arr services and downloaders, distinguishing it from broader tools like server_metrics or system_status.
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 provided on when to use this tool versus siblings such as queue_list or server_metrics. Usage context is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get download/import history details
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| since | No | ||
| service | Yes | ||
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get...details', implying a read operation, but does not confirm idempotency, required permissions, rate limits, or pagination behavior. The agent lacks critical behavioral information.
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, which is concise but not structured. It is front-loaded with the action and resource, but lacks details. While it avoids verbosity, it does not fully earn its place due to missing critical 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 the tool has 4 parameters, no output schema, and many sibling tools, the description is overly simplistic. It fails to explain the output, parameter usage, or how it relates to other history or diagnostic tools. The agent would struggle to invoke it correctly without additional hints.
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 description coverage is 0%, meaning no parameter descriptions in the schema. The tool description does not add any meaning to parameters like 'page', 'since', 'service', or 'pageSize'. An agent cannot infer their purpose or expected format from the description alone.
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 says 'Get download/import history details', which clarifies it's about retrieving history. However, it is somewhat tautological as it restates the tool name 'history_detail'. It does not specify what kind of details or differentiate from sibling tools like 'download_status' or 'import_issues'.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for import issues and stuck downloads
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only indicates a read-like operation. It does not disclose other behavioral traits such as idempotency, authentication needs, or side effects. The description is minimal.
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 of 5 words, which is concise but under-specified. It does not waste words but it is too short to be effective.
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 a single required parameter and no output schema or annotations, the description fails to provide sufficient context. It does not explain the return value, the meaning of the parameter, or usage scenarios. The tool definition is 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?
The schema has 0% description coverage for its single parameter 'service'. The tool description does not explain what the parameter does, its format, or allowed values. It adds no semantic value beyond the schema field name.
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 states a verb 'Check' and resource 'import issues and stuck downloads', but it is vague and does not differentiate from sibling tools like download_status or queue_diagnostics. No scope or specificity is provided.
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 gives no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured services and downloaders. Call this first to see available services.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation by stating 'list', but does not explicitly confirm non-destructiveness or other behaviors. However, for a simple listing tool, this is sufficient and not misleading.
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 one sentence plus a usage instruction. Every word earns its place; it is front-loaded with the action and ends with guidance. 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?
The tool has no parameters, no output schema, and is simple. The description completely covers what the tool does and when to use it, making it fully adequate for agent invocation.
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?
There are no parameters and 100% schema coverage, so the description does not need to add parameter meaning. The baseline is 4 for zero-parameter tools, and the description meets this.
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 tool's function: 'List all configured services and downloaders.' It uses a specific verb and resource, and distinguishes from sibling tools by focusing on listing all available services, which is the first step before using other tools.
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 explicitly tells the agent when to use this tool: 'Call this first to see available services.' This provides clear guidance on prioritization and context, which is especially helpful given the lack of annotations or other metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview and execute high-confidence ARR manual imports for queue items
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| dryRun | No | ||
| service | Yes | ||
| confirmationToken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors fully. It mentions 'preview and execute' but does not elaborate on side effects, required permissions, or the meaning of 'high-confidence'. The confirmationToken parameter suggests a confirmation step, but this is not explained.
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, but it sacrifices clarity for brevity. It is not verbose but lacks sufficient detail to be fully helpful.
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 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain return values, error handling, or the import flow, leaving the agent without critical context.
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 description coverage is 0%, and the description does not explain any parameters. While parameter names hint at usage (e.g., dryRun for preview), there is no explicit mapping or clarification, leaving the agent to guess.
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 states specific verbs 'Preview and execute' and a resource 'manual imports for queue items', clearly indicating the tool's action. However, it does not differentiate from siblings like 'import_issues' or 'queue_grab'.
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, nor any prerequisites or conditions for use. The description is purely functional without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available quality profiles with recommendations
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read operation ('List'), but does not explicitly state it is non-destructive, require no permissions, or discuss rate limits. The behavioral context is minimal.
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 redundancy. It is front-loaded with the primary action and resource. However, it could be more informative 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?
Despite the low complexity (1 parameter, no output schema), the description is incomplete. It does not explain what quality profiles are, what criteria the recommendations are based on, or the format of the response. An agent lacks sufficient context to use this tool effectively.
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 schema has 1 required parameter ('service') with no description (0% coverage). The description adds no semantic meaning to this parameter—it does not explain what values are valid (e.g., service names) or how it affects the results. The phrase 'with recommendations' pertains to output, not parameter usage.
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 tool lists quality profiles, with the additional qualifier 'with recommendations', which indicates the output includes recommendations. The verb 'List' implies a read-only operation. However, it does not differentiate from sibling tools like 'list_services', lacking explicit distinction.
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 mention prerequisites, typical use cases, or exclusions. Sibling tools exist (e.g., 'list_services', 'add_new') but no comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze and auto-fix stuck queue items
| Name | Required | Description | Default |
|---|---|---|---|
| autoFix | No | ||
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only says 'analyze and auto-fix' without explaining what auto-fix entails (e.g., destructive effects, retries, status changes). This ambiguity is insufficient for safe invocation.
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 short sentence, which is concise but overly terse. It front-loads the action but sacrifices necessary detail, making it minimally adequate in length.
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 only 2 parameters with 0% description coverage, the description fails to convey return values, side effects, or parameter roles. It is completely inadequate for reliable tool 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 description coverage is 0%, yet the description omits any explanation of the two parameters (autoFix and service). The agent gets no clues about their meaning or usage, leaving critical gaps.
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 specific verbs 'Analyze and auto-fix' and specifies the resource 'stuck queue items', making the tool's purpose clear. However, it does not differentiate from sibling tools like queue_grab or queue_list.
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. The description implies it's for stuck items but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force grab/retry download of queued items
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It mentions 'force grab/retry', suggesting potential destructive or overriding behavior, but provides no details on consequences, permissions, or side effects. This is insufficient.
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 short sentence, efficient and front-loaded. It could be slightly more informative without losing conciseness, but it is not 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 no output schema and no annotations, the description lacks critical context about return values, error conditions, and behavioral guarantees. It is incomplete for an agent to invoke correctly.
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 0%, so the description must add meaning to parameters. It does not explain 'service' or 'ids'. Without explanation, the agent cannot infer what values are valid or how they affect the operation.
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 states 'Force grab/retry download of queued items', which identifies a verb and resource. However, 'grab' is ambiguous and doesn't clearly distinguish the action from sibling tools like 'queue_diagnostics' or 'queue_list'. The purpose is vague.
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 usage guidance is provided. There is no indication of when to use this tool versus alternatives or any prerequisites. The sibling tools suggest a broader context but the description offers no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List items in download queue with status and progress
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| service | Yes | ||
| pageSize | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions listing with status and progress, omitting important behavior like pagination, sorting, or whether it shows all items.
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?
Very concise single sentence, but lacks necessary detail. Could include more information 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?
Severely incomplete given no output schema, no annotations, and 0% schema coverage. Does not explain return format or parameter 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 coverage is 0%, and description does not mention any of the 3 parameters (page, service, pageSize) or their meaning.
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 lists items in the download queue with status and progress. However, it does not differentiate from sibling tools like 'queue_diagnostics' or 'download_status'.
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 vs alternatives. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview and remove queue or library items with confirmation
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| dryRun | No | ||
| target | No | ||
| service | No | ||
| blocklist | No | ||
| downloader | No | ||
| deleteFiles | No | ||
| manualImport | No | ||
| queueTimeoutMs | No | ||
| removeFromClient | No | ||
| confirmationToken | No | ||
| addImportExclusion | No | ||
| allowManualRemoval | No | ||
| removeFromDownloader | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior (preview then remove with confirmation) but omits critical details like destructiveness, authentication needs, or side effects of parameters like deleteFiles.
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 is concise and front-loaded with key actions. Could benefit from slight expansion for clarity 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?
For a 14-parameter tool with no output schema, the description is insufficient. It does not explain the preview workflow, confirmation process, or what happens upon successful removal.
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?
With 0% schema description coverage, the description only hints at the target parameter ('queue or library items') but provides no explanation for 13 other parameters like dryRun, blocklist, or confirmationToken.
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 states the tool previews and removes queue or library items with confirmation, clearly indicating the primary action and resource. It distinguishes from sibling tools like add_new and download_status.
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 vs alternatives like queue_grab or manual_import. The 'with confirmation' hint is insufficient to set usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured root folders and storage information
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the responsibility for behavioral disclosure. It only states a read action ('List') but omits key traits like required permissions, side effects, or result format. This is minimal transparency for a tool that likely interacts with filesystem configurations.
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 very concise at 11 words, but it sacrifices substance for brevity. It is front-loaded with the action but lacks essential details, making it borderline under-specified.
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 tool's simplicity (single parameter, no output schema), the description should cover the parameter meaning and the nature of 'storage information'. It fails to do so, leaving significant gaps in 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?
The schema description coverage is 0%, so the description must compensate by explaining the 'service' parameter. However, the description does not mention parameters at all, leaving the agent without guidance on what values are expected or how they affect the listing.
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 'List' and resource 'configured root folders and storage information', which clearly states the tool's function. It distinguishes itself from sibling tools like 'all_services_diagnostics' or 'system_status' by focusing on root folders.
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. No context, exclusions, or prerequisite conditions are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for media (series/movies) to add
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is extremely brief, failing to disclose any behavioral traits such as API calls, limitations, side effects, or response format. The agent has no insight into what happens when the tool is invoked.
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 short sentence, making it concise but lacking necessary detail. It earns a middle score because it is not verbose, but the brevity sacrifices completeness.
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 zero annotations, no output schema, and three parameters with no description, the description is severely inadequate. It fails to provide enough context for an agent to use the tool correctly or understand the returned data.
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 0%, meaning the description adds no explanation for the three parameters (limit, query, service). The agent must infer meaning from parameter names alone, which is insufficient for correct usage.
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 a specific verb ('search') and resource ('media') and includes the intent 'to add', distinguishing it from sibling tools like 'list_services' or 'add_new'. However, it could be more specific about what kind of search (e.g., by title or ID) and what the output is.
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 explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical workflows (e.g., search then add_new), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get server performance metrics and health status
| Name | Required | Description | Default |
|---|---|---|---|
| service | No | ||
| detailed | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It implies a read-only operation ('Get...') but does not disclose possible performance impact, authentication requirements, or response volume.
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, well-structured sentence that front-loads the core purpose. It is concise but could benefit from additional details 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 annotations, output schema, and parameter guidance, the description is insufficient for an agent to fully understand the tool's behavior and constraints. Minimal viable completeness is not achieved.
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 description coverage is 0%, and the description does not explain the two parameters ('service', 'detailed'). The agent has no clues about valid values or effect of setting 'detailed' to true.
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 states 'Get server performance metrics and health status' – a clear verb+resource. However, it does not differentiate from sibling tools like 'system_status' or 'all_services_diagnostics', which also provide health-related information.
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. The description lacks any context for invocation, such as prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system status and health information
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It implies a read operation but lacks details on return format, permissions, or any side effects. The minimal phrase 'health information' is insufficient.
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, which is concise, but it is under-specified and lacks structure. Every sentence should earn its place, and this one barely adds value.
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 absence of an output schema and annotations, and the presence of many sibling tools, the description is incomplete. It does not explain what 'service' refers to or what 'health information' entails.
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 input schema has one required parameter 'service' with no description, and schema coverage is 0%. The tool description does not mention or clarify this parameter, failing to add any meaning beyond what is in the schema.
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 states 'Get system status and health information', which identifies the verb and resource, but it is somewhat tautological with the tool name 'system_status'. It does not differentiate from sibling tools like 'server_metrics' or 'all_services_diagnostics'.
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 'all_services_diagnostics' for broader diagnostics or 'server_metrics' for performance data. There are no exclusions or context hints.
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.
v0.3.18manual_importv0.3.9remove_contentv1.0.0add_newall_services_diagnosticsdownload_statushistory_detailimport_issueslist_servicesquality_profilesqueue_diagnosticsqueue_grabqueue_listroot_folderssearchserver_metricssystem_statusScored across 16 tools
Several tools overlap heavily, especially all_services_diagnostics, queue_diagnostics, and import_issues, which all deal with stuck queue items and import failures. system_status, server_metrics, and download_status also blur the line between health/performance and download status.
Names are a mix of noun-first, verb-first, and adjective-noun forms without a consistent pattern. Examples like queue_list, list_services, and add_new show inconsistent conventions; queue_grab reverses the expected verb_noun order.
16 tools is on the higher end for the apparent scope, and several diagnostic/status tools could be consolidated. The count is not absurd, but it feels heavier than necessary due to redundancy.
Core media management workflows are covered: search, add, queue management, imports, history, removal, and configuration listings. A notable gap is direct library listing/management beyond content removal, though the surface covers the main ARR-type workflows.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Tigris MCP Server seamlessly connects AI agents to Tigris bucket and object management.
