ダウンロードクライアント（SABnzbd (usenet) および qBittorrent (torrents)）用の MCP サーバーで、Docker コンテナとしてパッケージ化されています。servarr-mcp のようなメディア管理 MCP のコンパニオンです。
各クライアントはオプションです。実際に実行しているものだけを設定すれば、そのツールのみが登録されます。
ツール | 説明 |
| 速度と ETA を含む現在のダウンロードキュー |
| 最近の履歴（新しい順） |
| 設定されたカテゴリ |
| SABnzbd のバージョン情報 |
ツール | 説明 |
| トレントの一覧（オプションでステータスフィルタリング可能） |
| info-hash によるトレントの詳細 |
| トレント内のファイル |
| グローバル転送統計 |
| 設定されたカテゴリ |
| qBittorrent アプリケーションのバージョン |
Related MCP server: NZBGet MCP Server
各クライアントを有効にするには、完全な設定ブロックが必要です。設定が不完全な場合、クライアントはサイレントに無効化されます。
クライアント | 必要な環境変数 | デフォルトポート |
SABnzbd |
| 8080 |
qBittorrent |
| 8080 |
API キーや認証情報は各アプリの設定から確認できます：
SABnzbd: 設定 → 一般 → API キー
qBittorrent: ツール → オプション → Web UI (デフォルトユーザー admin)
注: SABnzbd と qBittorrent はどちらもデフォルトでポート 8080 を使用します。同じホストで両方を実行する場合は、いずれかの設定でポートを再マッピングしてください。
少なくとも 1 つのクライアントを設定する必要があります。設定がない場合、サーバーはエラーで終了します。
docker build -t downloader-mcp .
docker run -i --rm \
-e SABNZBD_URL=http://192.168.1.50:8080 -e SABNZBD_API_KEY=... \
-e QBITTORRENT_URL=http://192.168.1.50:8081 \
-e QBITTORRENT_USERNAME=admin -e QBITTORRENT_PASSWORD=... \
downloader-mcpclaude_desktop_config.json に以下を追加します：
{
"mcpServers": {
"downloader": {
"command": "docker",
"args": [
"run", "-i", "--rm",
"-e", "SABNZBD_URL", "-e", "SABNZBD_API_KEY",
"-e", "QBITTORRENT_URL",
"-e", "QBITTORRENT_USERNAME", "-e", "QBITTORRENT_PASSWORD",
"downloader-mcp"
],
"env": {
"SABNZBD_URL": "http://192.168.1.50:8080",
"SABNZBD_API_KEY": "...",
"QBITTORRENT_URL": "http://192.168.1.50:8081",
"QBITTORRENT_USERNAME": "admin",
"QBITTORRENT_PASSWORD": "..."
}
}
}
}実行しないクライアントの -e/env エントリは削除してください。
npm install
cp .env.example .env # then edit
SABNZBD_URL=... SABNZBD_API_KEY=... npm run devコンテナは非 root ユーザー (mcp) として実行されます。
認証情報は環境変数を介して渡され、イメージに組み込まれることはありません。
.githooks/pre-commit は gitleaks (シークレット) と PII パターンチェック (ユーザーホームパス、個人ドメインメール) を実行します。クローンごとに一度有効化してください：git config core.hooksPath .githooks。
List configured qBittorrent categories.
| 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 it lists categories, with no mention of side effects, authentication, edge cases (e.g., empty list), 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?
The description is a single, concise sentence that directly states the tool's purpose. No unnecessary words.
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?
While the operation is simple, the description lacks any hint about the return format or structure. Without an output schema, this is a gap. The description could mention that it returns a list of category objects.
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 no parameters (100% coverage trivially), so baseline is 4. The description adds the purpose of listing categories, which is essential given the empty 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 clearly states the action 'List' and the resource 'configured qBittorrent categories', providing a specific verb+resource combination. It distinguishes the tool from siblings like qbittorrent_list_torrents and sabnzbd_categories.
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. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or context for listing categories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a single torrent by info-hash.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The torrent info-hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get details', implying a read operation. It does not explicitly state if it has side effects, requires authentication, or what errors may occur. 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?
One sentence, no redundancy, but could add more detail about what 'details' includes. Still efficient.
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 output schema or description of return value, so agent doesn't know what to expect. For a simple retrieval, this is acceptable but not fully complete.
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 single parameter 'hash' is described in the schema as 'The torrent info-hash'. The description adds nothing beyond that. Since schema coverage is 100%, 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?
Clearly states the tool retrieves details for a single torrent using the info-hash. The verb 'Get' and resource 'details for a single torrent' are specific, and it distinguishes from sibling tools like qbittorrent_list_torrents that list multiple torrents.
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 qbittorrent_list_torrents or qbittorrent_torrent_files. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List torrents, optionally filtered by status (all, downloading, completed, paused, active, inactive, resumed).
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional status filter: all|downloading|completed|paused|active|inactive|resumed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states listing with filter; no disclosure of output format, pagination, authentication needs, or performance impact. Lacks behavioral context beyond schema.
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, front-loaded with verb and resource, no unnecessary words. Efficiently communicates core functionality.
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?
Minimally adequate for a simple list tool, but lacks any hint about return format (e.g., torrent names vs full metadata). No output schema to compensate.
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 100% for the single parameter; description restates filter values without adding new semantics (e.g., default behavior, result ordering). Baseline score 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?
Clearly states 'List torrents' with optional filter, distinguishing from siblings like qbittorrent_get_torrent (single torrent) and qbittorrent_torrent_files (files within a torrent).
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?
Implied usage by stating the action, but no explicit guidance on when to use this tool vs alternatives (e.g., qbittorrent_get_torrent for details). Lacks when-not-to-use or context for choosing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the files inside a torrent.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | The torrent info-hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits (e.g., side effects, prerequisites, or return format). Assumes a simple query but lacks detail on behavior.
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 could benefit from structured details (e.g., output expectations). No unnecessary words.
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 list tool with one parameter and no output schema, the description is minimally adequate. Lacks contextual details like auth requirements or constraints.
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 100% for the single parameter 'hash'. Description adds no additional meaning beyond what the schema already provides.
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 action (list) and the resource (files inside a torrent), effectively distinguishing from sibling tools like qbittorrent_get_torrent and qbittorrent_list_torrents.
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 (e.g., when to list files vs. get torrent info). Description merely states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get global transfer statistics (current speeds, totals, connection state).
| 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 must carry the full burden. It states that the tool gets speeds, totals, and connection state, which implies a read-only operation. However, it does not disclose potential side effects, authentication needs, or rate limits. For a simple stat tool, this is adequate but 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 with no wasted words. It is front-loaded with the main action and includes relevant examples, making it concise and efficient.
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, no parameters, and no output schema, the description provides a reasonable overview of what the tool returns. It could be more specific about the data format, but it covers the key elements (speeds, totals, connection state).
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 no parameters, and schema description coverage is 100%. According to guidelines, a baseline of 4 is appropriate when there are no parameters, as the description does not need to add parameter information.
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 'Get global transfer statistics (current speeds, totals, connection state)' uses a specific verb and resource, and the examples clarify the scope. It effectively distinguishes the tool from siblings like qbittorrent_version or qbittorrent_list_torrents.
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 when global transfer statistics are needed, which is clear given the tool's name and the lack of parameters. It does not explicitly state when not to use it or mention alternatives, but the context from sibling tools makes this partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get qBittorrent application version.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly implies a read-only operation with no side effects. Since no annotations are provided, the description carries the burden, and it adequately conveys the non-destructive nature of the 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, front-loaded sentence that conveys the essential information without unnecessary words.
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 version retrieval tool with no parameters or output schema, the description is sufficient. It tells the agent what to expect, though it does not specify the exact format of the version string.
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 schema provides all necessary information. The description adds nothing beyond the schema, but per guidelines, 0 parameters yields a baseline of 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?
The description clearly states the verb 'Get' and the resource 'qBittorrent application version'. It is specific and distinguishes from sibling tools like qbittorrent_categories or qbittorrent_list_torrents.
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. While the use case is obvious (retrieving version info), the description provides no context or exclusions, leaving the agent without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured SABnzbd categories.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed beyond the basic action. The description does not mention read-only nature, authentication requirements, or what constitutes a 'configured' category. Since no annotations are provided, the description carries the full burden but fails to add 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?
The description is a single sentence of five words, front-loading the key action and resource. Every word is essential, with no redundancy or filler.
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 low complexity (no parameters, no output schema), the description is mostly complete. It tells the agent what the tool does, though it could be improved by noting that the output is a list of category names or configurations.
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 zero parameters, so baseline is 4 per instructions. The description adds no parameter information, but the schema is empty and coverage is 100%, so no additional meaning is needed.
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 the specific verb 'List' and identifies the resource 'configured SABnzbd categories.' It clearly distinguishes itself from sibling tools like sabnzbd_history and sabnzbd_queue, 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.
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 does not explain the context or trade-offs, such as when to list categories versus other SABnzbd operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent SABnzbd download history (newest first).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Records to return (default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks details on read-only nature, time range for 'recent', or mutation behavior. No annotations exist, so the description should compensate but does not.
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?
One concise sentence that directly conveys the purpose. No unnecessary words, though it could include more detail 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?
Adequate for a simple list tool with one parameter and no output schema. However, lacks behavioral details like time range or pagination beyond the limit.
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 single parameter 'limit' is fully described in the schema (100% coverage), so the description adds no additional meaning beyond the schema. 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 function: retrieving recent SABnzbd download history with newest first ordering. It distinguishes from siblings like sabnzbd_queue (current queue) and sabnzbd_categories.
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 such as sabnzbd_queue or sabnzbd_version. No mention of prerequisites or contextual usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current SABnzbd download queue (in-progress jobs, speeds, ETAs).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must cover behavioral traits. It states the tool returns queue data (in-progress jobs, speeds, ETAs), which is read-only. No mention of authentication needs, rate limits, or side effects, but the operation is simple and safe.
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?
A single sentence that efficiently front-loads the key information (verb, resource, and purpose). Every word earns its place with no redundancy.
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 no parameters, no output schema, and no annotations, the description is mostly complete. It could mention that it retrieves the default server's queue, but the low complexity makes this acceptable.
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 zero parameters, so description coverage is 100% (vacuously). Per guidelines, 0 parameters merits a baseline of 4. The description adds no parameter-specific info beyond 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 uses a specific verb 'Get' and resource 'current SABnzbd download queue', clearly distinguishing it from siblings like sabnzbd_history (completed downloads) and qbittorrent tools (different client).
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 (e.g., sabnzbd_history or qbittorrent_list_torrents). The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SABnzbd version info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It accurately describes a read-only operation with no side effects, rate limits, or other concerns. The behavior is trivial and well communicated.
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?
A single straightforward sentence with no wasted words. The message is front-loaded and perfectly scoped.
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 parameters, no output schema, and a simple operation, the description is fully adequate. No additional information is required.
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, and schema coverage is 100%. The description adds no additional parameter info, but none is needed. 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 'Get SABnzbd version info,' using a specific verb and resource. It distinguishes from sibling tools like qbittorrent_version by the service prefix.
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 versus alternatives. However, the sibling tools are for different services (qbittorrent) or functions (history, queue), so the context is implicitly clear but not explicitly stated.
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.1.0qbittorrent_categoriesqbittorrent_get_torrentqbittorrent_list_torrentsqbittorrent_torrent_filesqbittorrent_transfer_infoqbittorrent_versionsabnzbd_categoriessabnzbd_historysabnzbd_queuesabnzbd_versionScored across 10 tools
Every tool is clearly distinguished by its client prefix (qbittorrent_ vs sabnzbd_) and specific action, with no overlap in functionality between tools.
All tools use a consistent snake_case client_verb_noun pattern, making it easy to predict tool names and purposes.
10 tools is well-scoped for a server supporting two download clients, covering essential query operations without unnecessary bloat.
While query operations are well-covered (list, get, categories, etc.), the server lacks mutation commands like add, remove, or pause torrents/jobs, which are expected for a downloader tool.
A registry of AI agent tools — MCP servers, APIs, CLIs, SDKs — kept current by automated ingestion.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
