Which integrations are available for this server?

Provides a comprehensive set of tools for managing the Transmission torrent client, including capabilities to add torrents via magnet links or URLs, monitor transfer speeds, manage session configurations, and perform torrent lifecycle operations like starting, pausing, and removing.

transmission-mcp

by philogicae

Overview Schema Related Servers Score Discussions

Python

Hybrid

Python API Wrapper & MCP Server for Transmission

Python PyPI Actions status License: MIT Ask DeepWiki

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

Related MCP server: rqbit Torrent Client MCP

Features

API wrapper for the Transmission torrent client using the official transmission-rpc library.
MCP server interface for standardized communication (stdio, sse, streamable-http).
Tools:
- get_session: Get Transmission session configuration and version info.
- get_session_stats: Get session statistics (speeds, torrent counts, cumulative stats).
- free_space: Get free disk space in bytes at the specified path.
- list_torrents: List all torrents and their details.
- get_torrent_details: Get detailed information about a specific torrent.
- get_torrent_stats: Get stats/status of a specific torrent.
- get_recently_active: Get recently active torrents and IDs of recently removed ones.
- add_torrent: Download a torrent from magnet link, HTTP URL, or local file.
- download_torrent: Download a torrent from a magnet link, HTTP URL, or local file.
- start_torrent: Start (resume) a torrent.
- stop_torrent: Stop (pause) a torrent.
- pause_torrent: Pause a torrent.
- verify_torrent: Verify torrent data integrity.
- reannounce_torrent: Reannounce torrent to trackers.
- move_torrent: Move torrent data to a new location.
- set_torrent_labels: Set labels for a torrent.
- remove_torrent: Remove a torrent (optionally delete data).
- delete_torrent: Delete a torrent and its files.
- forget_torrent: Forget a torrent, keeping the files.

Setup

Prerequisites

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

Configuration

This application requires the URL of your Transmission 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:
- TRANSMISSION_URL: The URL of the Transmission instance (Default: http://localhost:9091).
- TRANSMISSION_USER: The username for Transmission authentication (optional).
- TRANSMISSION_PASS: The password for Transmission authentication (optional).
Transmission Instance (for docker-compose setup):
- TRANSMISSION_DOWNLOAD_DIR: The download directory for torrents (e.g., /downloads).
- TRANSMISSION_WATCH_DIR: The watch directory for torrent files (e.g., /watch).
- TRANSMISSION_RPC_URL: The RPC URL for the Transmission API (e.g., http://localhost:9091/transmission/rpc).
- TRANSMISSION_PEER_PORT: The peer port for BitTorrent connections (e.g., 51413).
- TRANSMISSION_SPEED_LIMIT_DOWN: Download speed limit in KB/s (e.g., 100).
- TRANSMISSION_SPEED_LIMIT_UP: Upload speed limit in KB/s (e.g., 100).
- Check Transmission 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 transmission-mcp

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

TRANSMISSION_URL=http://localhost:9091

Run the MCP server (default: stdio):

python -m transmission_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/transmission-mcp.git
cd transmission-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 transmission_client

For Docker

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

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

git clone https://github.com/philogicae/transmission-mcp.git
cd transmission-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 transmission-mcp -f

Usage

As Python API Wrapper

import asyncio
from transmission_client import TransmissionClient

async def main():
    # Initialize client (reads TRANSMISSION_URL, TRANSMISSION_USER, and TRANSMISSION_PASS from env)
    client = TransmissionClient()

    # Use as context manager for automatic cleanup
    async with TransmissionClient() as client:
        # Get session info
        session = await client.get_session()
        print(f"Transmission version: {session['version']}")

        # Get session statistics
        stats = await client.get_session_stats()
        print(f"Download speed: {stats['downloadSpeed']} bytes/s")

        # Check free space
        free_space = await client.free_space("/downloads")
        print(f"Free space: {free_space} bytes")

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

    # Add a torrent
    await client.add_torrent("magnet:?xt=urn:btih:...")

    # Get torrent details
        details = await client.get_torrent("1")  # Use ID or hash

    # Control torrents
        await client.stop_torrent("1")  # Pause
        await client.start_torrent("1")  # Resume

        # Verify torrent data
        await client.verify_torrent("1")

        # Move torrent data
        await client.move_torrent("1", "/new/location", move=True)

        # Set torrent labels
        await client.set_torrent_labels("1", ["movies", "4k"])

        # Remove torrent (keep files)
        await client.remove_torrent("1", delete_data=False)

        # Delete torrent and files
        await client.remove_torrent("1", delete_data=True)

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

As MCP Server

from transmission_client import TransmissionMCP

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

Via MCP Clients

Usable with any MCP-compatible client. Available tools:

get_session: Get Transmission session configuration and version info.
get_session_stats: Get session statistics (speeds, torrent counts, cumulative stats).
free_space: Get free disk space in bytes at the specified path.
list_torrents: List all torrents and their details.
get_torrent_details: Get details of a specific torrent by ID or hash.
get_torrent_stats: Get stats/status of a specific torrent by ID or hash.
get_recently_active: Get recently active torrents and IDs of recently removed ones.
add_torrent: Add a torrent from magnet link, HTTP URL, or local file path.
download_torrent: Download a torrent via magnet link, HTTP URL, or local file.
start_torrent: Start (resume) a torrent by ID or hash.
stop_torrent: Stop (pause) a torrent by ID or hash.
pause_torrent: Pause a torrent by ID or hash.
verify_torrent: Verify torrent data integrity by ID or hash.
reannounce_torrent: Reannounce torrent to trackers by ID or hash.
move_torrent: Move torrent data to a new location by ID or hash.
set_torrent_labels: Set labels for a torrent by ID or hash.
remove_torrent: Remove a torrent (optionally delete data) by ID or hash.
delete_torrent: Delete a torrent and its files by ID or hash.
forget_torrent: Forget a torrent, keeping the files, by ID or hash.

Example with Windsurf

Configuration:

{
  "mcpServers": {
    ...
    # with stdio (only requires uv)
    "transmission-mcp": {
      "command": "uvx",
      "args": [ "transmission-mcp" ],
      "env": {
        "TRANSMISSION_URL": "http://localhost:9091", # (Optional) Default Transmission instance URL
        "TRANSMISSION_USER": "username", # (Optional) Transmission username
        "TRANSMISSION_PASS": "password" # (Optional) Transmission password
      }
    },
    # with docker (only requires docker)
    "transmission-mcp": {
      "command": "docker",
      "args": [ "run", "-i", "-p", "8000:8000", "-e", "TRANSMISSION_URL=http://localhost:9091", "-e", "TRANSMISSION_USER=username", "-e", "TRANSMISSION_PASS=password", "philogicae/transmission-mcp:latest", "transmission-mcp" ]
    },
    # with sse transport (requires installation)
    "transmission-mcp": {
      "serverUrl": "http://127.0.0.1:8000/sse"
    },
    # with streamable-http transport (requires installation)
    "transmission-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

12 tools

add_torrentB

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

ParametersJSON Schema

Name	Required	Description	Default
`paused`	No
`torrent`	Yes
`download_dir`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

Description lacks behavioral details beyond the basic action. No annotations exist, so the description should disclose side effects, like whether adding a torrent starts downloading immediately (hinted by 'paused' param) or validation behavior for the input types.

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 extraneous words. Efficiently communicates core purpose.

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?

Despite an existing output schema, the description is incomplete for a tool with 3 parameters and no annotations. Fails to explain parameter meanings, return values, or behavioral context like error conditions.

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?

With 0% schema description coverage, the description only partially explains the 'torrent' parameter by listing valid input types. No explanation is given for 'paused' (default false meaning?) or 'download_dir' (null meaning?).

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?

Description explicitly states the tool's function: adding a torrent, and lists three specific sources (magnet link, HTTP URL, local file path). This clearly differentiates it from sibling tools like remove_torrent or pause_torrent.

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 or when to prefer alternatives. Lacks mention of prerequisites, such as whether the torrent URL must be accessible or if the local path must exist.

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

forget_torrentC

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

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only reveals that files are kept, but omits what 'forget' entails (e.g., removal from list, tracker status) and fails to disclose side effects, permissions, or response behavior.

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 a single short sentence with no wasted words, which is appropriate, but it could be more informative without sacrificing conciseness (e.g., including parameter hint or usage note).

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?

Despite having an output schema and only one parameter, the description is too sparse. It fails to clarify how 'forget' differs from the sibling 'remove_torrent,' and does not leverage the output schema to describe return values, leaving the agent underinformed.

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%, and the description does not mention the 'torrent_id' parameter at all. The schema only provides a type, so the description adds zero semantic value for parameter usage.

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 'Forget' on the resource 'torrent' and adds the key behavioral note 'keeping the files.' This makes the basic purpose unambiguous, but it does not differentiate from the sibling tool 'remove_torrent,' which may perform a similar action with file deletion.

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 is provided on when to use this tool versus alternatives like 'remove_torrent.' The description lacks any usage context, prerequisites, or exclusions, forcing the agent to guess based on tool names alone.

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

free_spaceA

Get free disk space in bytes at the specified path.

ParametersJSON Schema

Name	Required	Description	Default
`path`	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 are provided, so the description carries full burden. It accurately describes a read operation returning disk space, but lacks details on error handling, performance implications, or permissions needed. For a simple tool, this is minimally adequate.

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 sentence with no wasted words. It is front-loaded with the core action and ends with the parameter, making it easy to parse quickly.

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 an output schema (not shown but present), the description is sufficient. It covers the essential behavior and parameter. However, it could optionally mention valid paths or error states, but the output schema likely handles return info.

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?

With 0% schema description coverage, the description must compensate. It adds that the path parameter specifies where to get free space, and clarifies the result is in bytes. This provides necessary context beyond the raw 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 verb 'Get' and the resource 'free disk space', specifying the return unit (bytes) and the required parameter (path). It distinguishes from all sibling tools which are torrent-related, so no confusion.

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?

No explicit guidance on when to use this tool vs alternatives. The purpose is distinct from siblings, but the description does not provide context or prerequisites, only an implied use case.

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

get_recently_activeA

Get recently active torrents and IDs of recently removed ones.

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?

With no annotations, the description carries full burden. It states basic functionality but lacks details: time window for 'recently', read-only nature, or any side effects. A query tool should disclose if it's non-destructive.

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

Conciseness4/5

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

Single sentence covering the core functionality, no fluff. Could be slightly improved by separating the two outputs (active vs removed) for clarity, but overall efficient.

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?

Has an output schema (present but not shown), so return values need not be described. However, missing details like time window for 'recently' and whether results are sorted. Adequate for a simple tool but incomplete for production use.

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?

No parameters exist (schema coverage 100% via empty object). The description adds meaning beyond the schema by explaining what data is returned, but no param details needed. Baselines at 4.

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 two functions: retrieving recently active torrents and IDs of recently removed ones. It uses specific verbs and resources, distinguishing it from siblings that manage torrents.

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?

No explicit guidance on when to use this tool versus alternatives like get_torrent_details or get_torrent_stats. The context implies it's for historical activity, but no when-not or alternative mentioned.

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

get_session_statsA

Get session statistics (speeds, torrent counts, cumulative stats).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It clearly indicates a read-only operation ('Get'), and the examples suggest no side effects. However, it could mention that no parameters are needed and that it returns aggregate stats. Still, the lack of contradiction and clear read nature support a high score.

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?

A single, well-structured sentence that provides all necessary information without any fluff. Every word earns its place.

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

Completeness5/5

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

Given the tool has no parameters and an output schema presumably documents return details, the description is complete. It tells the agent exactly what the tool does and what data it provides (speeds, counts, stats).

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

Parameters4/5

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

There are no parameters (0), so schema coverage is 100%. The description adds value by listing the kinds of statistics returned, which is useful beyond the empty schema. Baseline 4 is appropriate.

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

Purpose5/5

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

The description uses a specific verb ('Get') and resource ('session statistics'), and provides concrete examples (speeds, torrent counts, cumulative stats), clearly distinguishing it from sibling tools like get_torrent_stats which operate on individual torrents.

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 usage for overall session-level data, but lacks explicit when-to-use or when-not-to-use guidance, such as mentioning that get_torrent_stats is for per-torrent stats. Still clear enough for correct selection.

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

get_torrent_detailsB

Get detailed info for a specific torrent by its ID or hash.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond being a read operation. There is no information about auth requirements, rate limits, or side effects, which is insufficient for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is a single, front-loaded sentence that conveys the core purpose with no extraneous information. Every word earns its place.

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 that an output schema exists (not shown), the description does not need to explain return values. However, for a tool with one parameter and no other context, the description is adequate but could briefly summarize the kind of details returned.

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?

The description adds meaning to the torrent_id parameter by stating it can be an ID or hash, which the schema (only 'type: string') does not specify. However, it does not provide examples or clarify format, and schema coverage is 0%, so it partially compensates.

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 (get detailed info) and resource (specific torrent by ID or hash). It distinguishes from sibling tools like add_torrent or remove_torrent, but it could be more specific about what 'detailed info' includes.

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 (e.g., get_torrent_stats). There is no mention of prerequisites, context, or exclusions, 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.

get_torrent_statsC

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

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/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 says 'Get stats and status.' It does not disclose read-only nature, side effects, or error handling (e.g., if torrent not found). The description carries the full burden but fails to provide these details.

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. Front-loaded with action and resource. Efficient for the purpose.

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?

Despite having an output schema, the description lacks completeness for a non-trivial tool. No mention of prerequisites, error scenarios, or behavioral context. Minimal given the complexity and no annotations.

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

Parameters3/5

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

The description adds meaning by stating the parameter can be an ID or hash, which is not obvious from the schema (type string). However, it does not specify format or validation, and schema coverage was 0%, so this is the only documentation.

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 tool gets stats and status for a specific torrent, using the verb 'Get' and specifying the resource. It distinguishes from siblings like 'get_torrent_details' by focusing on stats/status, but could be more specific about what stats are included.

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 'get_recently_active'. No exclusions or context provided.

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

move_torrentC

Move torrent data to a new location.

ParametersJSON Schema

Name	Required	Description	Default
`move`	No
`location`	Yes
`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?

With no annotations, the description must disclose behavioral traits. It only says 'move torrent data to a new location' without specifying if it's a move or copy, what happens to the old location, or any side effects. Minimal behavioral transparency.

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 just one sentence, which is concise, but it underspecifies the tool. It lacks necessary details to be useful, thus a 2 for being too sparse.

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 3 parameters with no descriptions and a file-moving operation, the description is incomplete. While an output schema exists, the description still fails to cover behavioral aspects and parameter context.

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%, so the description should explain parameters. It does not mention the 'move' boolean, 'location' string, or 'torrent_id' at all. The parameter semantics are entirely lacking.

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 is clear: 'Move torrent data to a new location.' It states the verb and resource, but doesn't differentiate from siblings like remove_torrent or start_torrent which are clearly different, so a 4 is appropriate.

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 add_torrent or set_torrent_labels. There's no context about prerequisites or typical scenarios.

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.7/5.0

Behavior2/5

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

The description only says 'Pause a torrent', implying a state change, but gives no details about side effects, permissions, reversibility, or impact on downloads. No annotations are provided to supplement.

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 a single sentence, which is concise, but it lacks necessary detail to be informative. It is efficient but insufficient.

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?

The description provides no information about return values (output schema exists but is not explained) or other contextual cues. For a simple one-parameter tool, it is minimally adequate but leaves gaps.

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 single parameter torrent_id is not described at all. With 0% schema description coverage, the description fails to add meaning beyond the bare schema.

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

Purpose5/5

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

The description clearly states the action ('Pause') and the resource ('a torrent'). It distinguishes from sibling tools like start_torrent and remove_torrent by indicating a different 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?

No guidance on when to use this tool versus alternatives, such as stop_torrent or remove_torrent. No when-not or context provided.

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

remove_torrentC

Remove a torrent. Set delete_data=True to also delete downloaded files.

ParametersJSON Schema

Name	Required	Description	Default
`torrent_id`	Yes
`delete_data`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/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 bear the full burden. It does not disclose if removal is reversible, requires authentication, or triggers side effects beyond file deletion. Minimal behavioral context is given.

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

Conciseness4/5

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

The description is two sentences, front-loaded, and contains no extraneous words. It is efficiently structured, though it could be expanded slightly 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?

The tool has an output schema, so return values are covered. However, the description omits critical context like how to obtain torrent_id or whether the operation is soft/hard removal. Low complexity but insufficient detail for correct agent invocation.

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?

Schema description coverage is 0%. The description explains the delete_data parameter but does not describe torrent_id (required). With two parameters, only partial meaning is added.

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 states 'Remove a torrent' which clearly identifies the action and resource. It distinguishes from siblings like pause_torrent or start_torrent, but doesn't differentiate from forget_torrent, which may have similar behavior.

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 guidance on when to set delete_data=true, but lacks any indication of when to use this tool versus alternatives (e.g., forget_torrent) or any prerequisites.

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

set_torrent_labelsC

Set labels for a torrent.

ParametersJSON Schema

Name	Required	Description	Default
`labels`	Yes
`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?

No annotations exist, so the description bears full responsibility for behavioral disclosure. It fails to mention side effects such as overwriting existing labels, authentication needs, or rate limits. The lack of detail limits an agent's understanding of the tool's impact.

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 concise at a single sentence, but conciseness should not come at the expense of completeness. It is minimally viable but could be restructured to include key details while remaining brief.

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?

For a simple tool with 2 parameters and an output schema, the description is incomplete. It does not explain the effect on existing labels (overwrite vs merge), expected return values, or error conditions. A more complete description would aid correct invocation.

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?

Schema description coverage is 0%, yet the description adds no meaning beyond parameter names. It does not explain the format of torrent_id, what values labels can take, or constraints (e.g., maximum label length). The output schema exists but is not leveraged for parameter 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?

The description clearly states 'Set labels for a torrent' which identifies the action and resource. It distinguishes from sibling tools like add_torrent or remove_torrent. However, it could be more specific by clarifying whether labels are overwritten or appended.

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 is provided on when to use this tool versus alternatives. For example, there is no indication of whether labels are replaced or merged, nor any context about required permissions or constraints.

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.5/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. It says 'Start (resume) a torrent' but doesn't explain what starting implies (e.g., begins downloading, requires the torrent to exist, what happens if already active). 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.

Conciseness2/5

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

The description is extremely concise but at the cost of missing critical information. It does not provide enough detail to be useful on its own.

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 that there is an output schema but no details about return values or errors, and the tool has one required parameter, the description should explain what happens on success/failure. It fails to do so.

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?

Schema coverage is 0%, meaning the description must add meaning to parameters. However, it does not describe what 'torrent_id' is, how to obtain it, or what formats are accepted. The parameter is left entirely to the schema.

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 tool starts or resumes a torrent. It uses a specific verb and resource, and it distinguishes from related sibling tools like pause_torrent or add_torrent.

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. It doesn't mention that this is typically used after pausing a torrent, or that it should only be called on existing but inactive torrents.

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. Dates show when Glama detected each change.

14 tool updatesv1.1.0Jul 21, 2026
- Addedadd_torrent
- Removeddelete_torrent
- Removeddownload_torrent
- Addedforget_torrent
- Addedget_recently_active
- Removedget_session
- Addedget_torrent_details
- Addedget_torrent_stats
- Addedmove_torrent
- Addedpause_torrent
- Removedreannounce_torrent
- Addedremove_torrent
- Addedstart_torrent
- Removedverify_torrent
19 tool updatesv1.1.0Jul 21, 2026
- Removedadd_torrent
- Changeddelete_torrent1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changeddownload_torrent1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Removedforget_torrent
- Changedfree_space1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Removedget_recently_active
- Changedget_session1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Changedget_session_stats1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Removedget_torrent_details
- Removedget_torrent_stats
- Removedlist_torrents
- Removedmove_torrent
- Removedpause_torrent
- Changedreannounce_torrent1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Removedremove_torrent
- Changedset_torrent_labels1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
- Removedstart_torrent
- Removedstop_torrent
- Changedverify_torrent1 field changed
  - addedInput schema / additionalProperties
```
Added value: +false
```
19 tool updatesJan 15, 2026
- First observedadd_torrent
- First observeddelete_torrent
- First observeddownload_torrent
- First observedforget_torrent
- First observedfree_space
- First observedget_recently_active
- First observedget_session
- First observedget_session_stats
- First observedget_torrent_details
- First observedget_torrent_stats
- First observedlist_torrents
- First observedmove_torrent
- First observedpause_torrent
- First observedreannounce_torrent
- First observedremove_torrent
- First observedset_torrent_labels
- First observedstart_torrent
- First observedstop_torrent
- First observedverify_torrent

Install Server

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

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between pause_torrent/stop_torrent (both pause) and delete_torrent/remove_torrent (both remove with file deletion options). The descriptions clarify differences, but an agent might initially confuse these pairs.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case, such as add_torrent, delete_torrent, and get_session. The naming is predictable and uniform across the entire set.

Tool Count4/5

With 19 tools, the count is slightly high but reasonable for a Transmission client covering torrent management, session info, and file operations. It includes essential actions without being overly bloated.

Completeness5/5

The tool set provides comprehensive coverage for torrent management, including CRUD operations (add, list, get, delete), lifecycle control (start, pause, verify), and auxiliary functions (free space, session stats). No obvious gaps exist for the domain.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-serverOAuth
com.ffmpeg-micro
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
Multimedia Processing App Automation
2
Home Automation Mcp D
io.github.varvararatta
MCP server for Home Automation
Home Automation & IoT
2
Cite CaddyOAuth
dk.herbertkokholm.citecaddy
Remote MCP server for full read/write access to a Zotero library
Research & Data Knowledge & Memory
1
mcp-teslaOAuth
io.github.jlestel
MCP server wrapping the Tesla Fleet API and TeslaMate API
Energy Home Automation & IoT App Automation
23

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
-
rqbit Torrent Client MCP
App Automation Code Execution
philogicae
A
license
B
quality
C
maintenance
Python wrapper & MCP server for the rqbit API
Updated 8 months ago (2026-01-15 07:06 UTC)
8
3
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-server
App Automation
dgoo2308
F
license
Not graded
quality
D
maintenance
Enables controlling a Transmission torrent daemon, allowing adding, listing, controlling torrents and checking free space, with support for SOCKS5 proxy for remote access.
Updated 7 months ago (2026-02-01 04:35 UTC)
-

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/philogicae/transmission-mcp'

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

Python API Wrapper & MCP Server for Transmission

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

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API