What can you do with this server?

The rqbit Torrent Client MCP server provides a Python API wrapper for managing torrents using the rqbit client. With this server, you can: * List all torrents and their details * Add a torrent using a magnet link * Get detailed information about a specific torrent by ID or infohash * Delete a torrent and its associated files * Start (resume) a paused torrent * Pause an active torrent * Forget/remove a torrent from the list while keeping the downloaded files

Which integrations are available for this server?

Provides containerization for the MCP server with Docker Compose support, including integration with the rqbit torrent client in the same container setup. Reads configuration from .env files, allowing users to set the RQBIT_URL for connecting to the rqbit torrent client instance. Hosts the project repository with CI workflows for package testing and validation. Distributes the rqbit-mcp package through PyPI, enabling easy installation via pip. Provides a Python API wrapper for the rqbit torrent client, allowing direct integration in Python applications.

How do I use rqbit Torrent Client MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rqbit Torrent Client MCP download the latest Ubuntu ISO from this magnet link" 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.

rqbit Torrent Client MCP

by philogicae

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Python API Wrapper & MCP Server for rqbit

Python PyPI Actions status License: MIT Ask DeepWiki

This repository provides a Python API wrapper and an MCP (Model Context Protocol) server for the rqbit torrent client. It allows for easy integration into other applications or services.

Related MCP server: Torrent Search MCP Server

Features

API wrapper for the rqbit torrent client.
MCP server interface for standardized communication (stdio, sse, streamable-http)
Tools:
- list_torrents: List all torrents and their details.
- download_torrent: Download a torrent from a magnet link or a file.
- get_torrent_details: Get detailed information about a specific torrent.
- get_torrent_stats: Get stats/status of a specific torrent.
- pause_torrent: Pause a torrent.
- start_torrent: Start a torrent.
- forget_torrent: Forget a torrent, keeping the files.
- delete_torrent: Delete a torrent and its files.

Setup

Prerequisites

An running instance of rqbit. (Included in docker compose)
Python 3.10+ (required for PyPI install).
uv (for local development)

Configuration

This application requires the URL of your rqbit instance.

Set Environment Variable: Copy .env.example to .env in your project's root directory and edit it with your settings. The application will automatically load variables from .env:

MCP Server:
- RQBIT_URL: The URL of the rqbit instance (Default: http://localhost:3030).
- RQBIT_HTTP_BASIC_AUTH_USERPASS: If setup in rqbit instance.
Rqbit Instance:
- RQBIT_HTTP_BASIC_AUTH_USERPASS: The username and password for basic authentication, in the format username:password.
- RQBIT_HTTP_API_LISTEN_ADDR: The listen address for the HTTP API (e.g., 0.0.0.0:3030).
- RQBIT_UPNP_SERVER_ENABLE: Enables or disables the UPnP server (e.g., true or false).
- RQBIT_UPNP_SERVER_FRIENDLY_NAME: The friendly name for the UPnP server (e.g., rqbit-media).
- RQBIT_EXPERIMENTAL_UTP_LISTEN_ENABLE: Enables or disables the uTP listener (Default: false).
- Check rqbit for other variables and more information.

Installation

Choose one of the following installation methods.

Install from PyPI (Recommended)

This method is best for using the package as a library or running the server without modifying the code.

Install the package from PyPI:

pip install rqbit-mcp

Create a .env file in the directory where you'll run the application and add your rqbit URL:

RQBIT_URL=http://localhost:3030

Run the MCP server (default: stdio):

python -m rqbit_client

For Local Development

This method is for contributors who want to modify the source code. Using uv:

Clone the repository:

git clone https://github.com/philogicae/rqbit-mcp.git
cd rqbit-mcp

Install dependencies using uv:

uv sync --locked

Create your configuration file by copying the example and add your settings:

cp .env.example .env

Run the MCP server (default: stdio):

uv run -m rqbit_client

For Docker

This method uses Docker to run the server in a container. compose.yaml includes rqbit torrent client.

Clone the repository (if you haven't already):

git clone https://github.com/philogicae/rqbit-mcp.git
cd rqbit-mcp

Create your configuration file by copying the example and add your settings:

cp .env.example .env

Build and run the container using Docker Compose (default port: 8000):

docker compose up --build -d

Access container logs:

docker logs rqbit-mcp -f

Usage

As Python API Wrapper

import asyncio
from rqbit_client.wrapper import RqbitClient

async def main():
    # Read the RQBIT_URL from the .env file or fallback to default (http://localhost:3030)
    async with RqbitClient() as client:
        # Download a torrent
        magnet_link = "magnet:?xt=urn:btih:..."
        torrent = await client.download_torrent(magnet_link)
        print(torrent)

        # Check status
        status = await client.get_torrent_stats(torrent["id"])
        print(status)

        # List torrents
        torrents = await client.list_torrents()
        print(torrents)

if __name__ == "__main__":
    asyncio.run(main())

As MCP Server

from rqbit_client import RqbitMCP

RqbitMCP.run(transport="sse") # 'stdio', 'sse', or 'streamable-http'

Via MCP Clients

Usable with any MCP-compatible client. Available tools:

list_torrents: List all torrents.
download_torrent: Download a torrent via magnet link or file path.
get_torrent_details: Get details of a specific torrent.
get_torrent_stats: Get stats/status of a specific torrent.
pause_torrent: Pause a torrent.
start_torrent: Start a torrent.
forget_torrent: Forget a torrent, keeping the files.
delete_torrent: Delete a torrent and its files.

Example with Windsurf

Configuration:

{
  "mcpServers": {
    ...
    # with stdio (only requires uv)
    "rqbit-mcp": {
      "command": "uvx",
      "args": [ "rqbit-mcp" ],
      "env": { 
        "RQBIT_URL": "http://localhost:3030", # (Optional) Default rqbit instance URL
        "RQBIT_HTTP_BASIC_AUTH_USERPASS": "username:password" # (Optional) Only if setup in rqbit instance
      }
    },
    # with docker (only requires docker)
    "rqbit-mcp": {
      "command": "docker",
      "args": [ "run", "-i", "-p", "8000:8000", "-e", "RQBIT_URL=http://localhost:3030", "-e", "RQBIT_HTTP_BASIC_AUTH_USERPASS=username:password", "philogicae/rqbit-mcp:latest", "rqbit-mcp" ]
    },
    # with sse transport (requires installation)
    "rqbit-mcp": {
      "serverUrl": "http://127.0.0.1:8000/sse"
    },
    # with streamable-http transport (requires installation)
    "rqbit-mcp": {
      "serverUrl": "http://127.0.0.1:8000/mcp" 
    },
    ...
  }
}

Changelog

See CHANGELOG.md for a history of changes to this project.

Contributing

Contributions are welcome! Please open an issue or submit a pull request.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

8 tools

delete_torrentC

Delete a torrent and its files.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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 states 'delete' implying irreversibility and file removal, but lacks details on authorization requirements, rate limits, or whether it's truly destructive. The description is too minimal to provide full transparency.

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

Conciseness3/5

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

The description is extremely short (5 words), but this is conciseness at the cost of completeness. It is front-loaded but lacks necessary details. Not every sentence earns its place because it misses critical information.

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

Completeness1/5

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

Given that there is an output schema (unseen) and no annotations, the description is very incomplete. It does not specify the tornado_id meaning, what happens to associated data, or any side effects. Completely inadequate for a destructive operation tool.

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

Parameters1/5

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

The input schema has 0% description coverage and only one parameter 'torrent_id'. The description does not explain what the parameter represents, its format, or how to obtain it. The description adds no value beyond the schema's type and required field.

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

Purpose4/5

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 torrent and its files', which is specific and helps differentiate from sibling 'forget_torrent' which might only remove from list. However, it doesn't explicitly contrast with alternatives.

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

Usage Guidelines2/5

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 'forget_torrent'. The description does not mention prerequisites, conditions, or context for use.

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

download_torrentA

Download a torrent from a magnet link, HTTP URL, or local file.

ParametersJSON Schema

Name	Required	Description	Default
`magnet_link_or_url_or_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description lacks disclosure of side effects (e.g., immediate download start) or prerequisites (e.g., running client). For an ingestion tool, more behavioral context is needed.

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

Conciseness5/5

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

The description is a single, efficient sentence that front-loads the core action and resources. No extraneous text.

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

Completeness3/5

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

Despite having an output schema, the description does not mention return values or success/failure behavior. Basic operational context (e.g., whether this adds to a queue) is missing.

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

Parameters3/5

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

Schema coverage is 0%, but the description adds value by naming three input formats (magnet, URL, file). However, it does not provide format details or constraints, leaving some ambiguity.

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

Purpose5/5

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

The description states the action 'Download a torrent' and specifies three source types (magnet link, HTTP URL, or local file), clearly distinguishing it from sibling tools like delete or start.

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

Usage Guidelines3/5

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

The description is clear on what the tool does but provides no guidance on when to use it versus alternatives like start_torrent 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.

forget_torrentA

Forget a torrent, keeping the files.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so the description must carry full weight. It states the effect on files but does not detail what 'forget' entails (e.g., removal from client, stop seeding, etc.). Adequate but lacks depth for a mutation tool with no annotations.

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

Conciseness5/5

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

Single sentence with no extraneous words. Front-loads the action and key information (keeping files). Perfectly concise.

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

Completeness4/5

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

For a simple tool with one parameter and no output schema expectations, the description covers the essential behavior: what it does and what happens to files. It leaves some behavioral details implicit but is largely complete given the tool's simplicity.

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

Parameters3/5

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

Schema coverage is 0%, but the description mentions 'torrent' which clarifies that 'torrent_id' is the identifier of the torrent. This adds minimal meaning beyond the schema. A 3 is appropriate given the low coverage and simple context.

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

Purpose5/5

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

The description clearly states the action ('forget') and the resource ('torrent'), and crucially adds 'keeping the files' which distinguishes it from the sibling tool 'delete_torrent'. This makes the purpose highly specific and unambiguous.

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

Usage Guidelines4/5

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

The description implies when to use this tool by contrasting with the likely alternative 'delete_torrent' through the phrase 'keeping the files'. However, it could be more explicit about when to forget versus delete, hence a 4.

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

get_torrent_detailsA

Get details for a specific torrent by its ID or infohash.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It only says 'Get details' without revealing behavioral traits like error handling, rate limits, or whether it returns full details vs a summary. The existence of an output schema mitigates slightly, but transparency 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.

Conciseness5/5

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

Single sentence, no wasted words. Conveyed purpose and identifier types efficiently. Appropriate length for a simple retrieval tool.

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

Completeness3/5

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

Given the tool's simplicity and the presence of an output schema, the description is adequate but lacks explicit mention of error or not-found cases. It does not elaborate on what 'details' includes, which could be inferred but not guaranteed.

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

Parameters4/5

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

Schema coverage is 0%, but the description adds that torrent_id can be an ID or infohash, which is not evident from the schema's 'type: string' alone. This adds valuable semantic context beyond the schema.

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

Purpose5/5

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

The description clearly states the tool retrieves details for a specific torrent, identifying it by ID or infohash. It distinguishes from sibling tools like list_torrents (list all) and delete_torrent (delete).

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

Usage Guidelines2/5

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 get_torrent_stats. Usage context is implied but not explicitly stated, leaving the agent without clear selection criteria.

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

get_torrent_statsA

Get stats and status for a specific torrent by its ID or infohash.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

Implies read-only operation, but does not explicitly confirm no side effects. With no annotations, a bit more clarity would be beneficial, but the description is adequate for a simple getter.

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

Conciseness5/5

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

Single sentence, front-loaded with key information. No unnecessary words.

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

Completeness4/5

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

Given the simplicity (one param, output schema exists), the description covers the essential purpose and identifier. Minor omission: no mention of what 'stats' includes, but output schema likely covers it.

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

Parameters4/5

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

Description notes that torrent_id can be an ID or infohash, adding meaning beyond the raw schema. However, it does not specify format or examples, which would improve clarity.

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

Purpose4/5

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

Description clearly states the tool retrieves stats/status for a specific torrent by ID or infohash. However, it does not differentiate from sibling 'get_torrent_details', which could be similar.

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

Usage Guidelines2/5

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 'get_torrent_details' or 'list_torrents'. No context on 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.

list_torrentsA

List all torrents.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, and the description only states the action. It lacks disclosure of behavioral traits such as read-only nature, pagination, or authentication requirements. The agent gets minimal behavioral insight.

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

Conciseness5/5

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

The description is a single, clear sentence with no waste. It is appropriately sized for a simple tool with no parameters.

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

Completeness4/5

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

Given the tool's simplicity (no parameters, read-like operation) and the presence of an output schema, the description is largely adequate. It could mention the scope of 'all torrents' (e.g., user-level or global) but is otherwise complete.

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

Parameters4/5

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

The input schema has no parameters, so schema description coverage is 100%. The description does not need to add parameter info; it is sufficient for a parameterless tool.

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

Purpose5/5

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

The description 'List all torrents' uses a specific verb and resource, clearly distinguishing this tool from siblings like delete, download, or get details. It unambiguously states the operation.

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

Usage Guidelines2/5

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 such as get_torrent_details or get_torrent_stats. No context about prerequisites or exclusions is given.

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

pause_torrentC

Pause a torrent.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description must disclose behavioral traits, but it only states the action without mentioning side effects, permission requirements, or reversibility. The agent gains no insight into what happens after pausing.

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

Conciseness3/5

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

The description is extremely concise (one sentence) but lacks detail. While not verbose, it is minimally informative and could benefit from a brief elaboration without losing conciseness.

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

Completeness2/5

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

Given the simplicity of the tool (one parameter), the description is incomplete—it does not mention the output schema or indicate what the response signifies (e.g., success/failure). The agent lacks closure on expected results.

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

Parameters2/5

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

The only parameter 'torrent_id' is not explained beyond its type. With 0% schema description coverage, the description adds no meaning; the agent must infer from context that it identifies the torrent.

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

Purpose4/5

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

The description 'Pause a torrent' clearly states the action and resource, distinguishing it from sibling tools like 'start_torrent' and 'delete_torrent'. However, it lacks nuance about what pausing entails (e.g., stops downloading vs. seeding).

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

Usage Guidelines2/5

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, no prerequisites or conditions mentioned. The description provides no context for optimal usage.

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

start_torrentC

Start (resume) a torrent.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral traits. It only states 'Start (resume) a torrent' without disclosing side effects (e.g., if already running, whether it resets progress, or auth requirements). This is insufficient for a mutation tool.

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

Conciseness2/5

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

The description is extremely short (three words), which sacrifices informativeness for brevity. It lacks structure or any supplementary details that would aid an agent in invoking the tool correctly. Conciseness is not an asset when it omits critical information.

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

Completeness2/5

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

With one parameter and an output schema (content unknown), the description is too vague. It does not specify behavior when the torrent is already running, what constitutes success, or error conditions. Sibling tools provide context but the description fails to leverage or clarify its role.

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

Parameters1/5

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

Schema description coverage is 0% for the only parameter 'torrent_id', and the description adds no explanation of what the ID represents, how to obtain it, or expected format. The description adds zero semantic value beyond the schema's type definition.

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

Purpose4/5

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

The description clearly states the action 'Start (resume)' on the resource 'torrent', which is a specific verb+resource combination. It distinguishes from siblings like 'pause_torrent' (opposite) and 'delete_torrent' (destructive), but lacks any elaboration on scope or state.

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

Usage Guidelines2/5

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. The siblings include 'pause_torrent' and 'download_torrent', but the description does not clarify that it is intended for resuming a paused torrent or starting a newly added one. No exclusion criteria or contextual cues provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.0.0Jan 3, 2026
- Changeddelete_torrent3 fields changed
  - removedInput schema / properties / torrent_id / title
```
Removed value: -"Torrent Id"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changeddownload_torrent3 fields changed
  - removedInput schema / properties / magnet_link_or_url_or_path / title
```
Removed value: -"Magnet Link Or Url Or Path"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changedforget_torrent3 fields changed
  - removedInput schema / properties / torrent_id / title
```
Removed value: -"Torrent Id"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changedget_torrent_details3 fields changed
  - removedInput schema / properties / torrent_id / title
```
Removed value: -"Torrent Id"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changedget_torrent_stats3 fields changed
  - removedInput schema / properties / torrent_id / title
```
Removed value: -"Torrent Id"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changedlist_torrents2 fields changed
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changedpause_torrent3 fields changed
  - removedInput schema / properties / torrent_id / title
```
Removed value: -"Torrent Id"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
- Changedstart_torrent3 fields changed
  - removedInput schema / properties / torrent_id / title
```
Removed value: -"Torrent Id"
```
  - removedOutput schema / properties / result / title
```
Removed value: -"Result"
```
  - removedOutput schema / title
```
Removed value: -"_WrappedResult"
```
8 tool updatesAug 15, 2025
- First observeddelete_torrent
- First observeddownload_torrent
- First observedforget_torrent
- First observedget_torrent_details
- First observedget_torrent_stats
- First observedlist_torrents
- First observedpause_torrent
- First observedstart_torrent

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-04-29 19:45 across 8 tools

Disambiguation4/5

Most tools have distinct purposes, but get_torrent_details and get_torrent_stats could cause confusion as both provide information about a specific torrent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, using 'torrent' as the object throughout.

Tool Count5/5

8 tools cover essential torrent management operations without being excessive; each tool serves a clear purpose.

Completeness4/5

The set covers core operations (add, list, get info, pause/resume, delete/forget), but lacks an update/modify operation for torrent properties.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

smithery-ai-cookbook-python-quickstart
ai.smithery
A simple MCP server built with FastMCP and python
Developer Tools
213
mcp-teslaOAuth
io.github.jlestel
MCP server wrapping the Tesla Fleet API and TeslaMate API
Energy Home Automation & IoT App Automation
23
riveterOAuth
io.github.CodyWatters
MCP server for Riveter's enrichment, scraping, and monitoring API
Web Scraping Monitoring Data Platforms
1
mcp-serverOAuth
com.ffmpeg-micro
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
Multimedia Processing App Automation
21

Related MCP Servers

YggTorrent MCP Server
Web Scraping App Automation Code Execution
philogicae
A
license
B
quality
Not graded
maintenance
A Python MCP server that allows programmatic interaction with YggTorrent, enabling torrent search, details retrieval, and magnet link generation without exposing your Ygg passkey.
Updated 8 months ago (2026-01-12 23:58 UTC)
4
18
MIT
Torrent Search MCP Server
App Automation Code Execution Web Scraping
philogicae
A
license
A
quality
A
maintenance
A Python MCP server that allows programmatic interaction to find torrents programmatically on ThePirateBay, Nyaa and YggTorrent.
Updated 7 days ago (2026-09-09 18:25 UTC)
6
288 PyPI
30
Python
MIT
Fr Torrent Search MCP Server
App Automation Code Execution Web Scraping
philogicae
A
license
B
quality
F
maintenance
A Python MCP server that allows programmatic interaction to find torrents programmatically on YggTorrent and La Cale.
Updated 2 months ago (2026-07-13 20:02 UTC)
4
2
MIT
transmission-mcp
App Automation Entertainment & Media File Systems
philogicae
A
license
B
quality
B
maintenance
Python wrapper & MCP server for transmission
Updated 2 months ago (2026-07-13 19:31 UTC)
19
69 PyPI
5
MIT

Appeared in Searches

Using Python REPL from an MCP server on Windows

Python API Wrapper & MCP Server for rqbit

Table of Contents

Features

Setup

Prerequisites

Configuration

Installation

Install from PyPI (Recommended)

For Local Development

For Docker

Usage

As Python API Wrapper

As MCP Server

Via MCP Clients

Example with Windsurf

Changelog

Contributing

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches