Skip to main content
Glama
philogicae

Torrent Search MCP Server

by philogicae
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Forward Torrent

forward_torrent

Send a torrent (filename + magnet) to the user's Telegram chat.

Instructions

Send a torrent (filename + magnet) to the user's Telegram chat.

The forward goes through the Torrent Search REST API, which owns the Telegram bot token; when PRUNE_MAGNET_LINKS is enabled the magnet is pruned to 'magnet:?xt=urn:btih:HASH&dn=' before sending. Requires TORRENT_SEARCH_API_KEY (same value as the API server) and TORRENT_SEARCH_API_URL. Forwards are rate-limited per chat (20/min).

Input Schema

NameRequiredDescriptionDefault
sizeNoOptional human-readable size (e.g. '1.2 GiB').
chat_idYesThe owner's Telegram chat id the torrent is sent to.
seedersNoOptional seeder count.
filenameYesExact torrent filename shown in the search results.
magnet_linkYesMagnet link of the torrent (from get_torrent, or from a search run with INCLUDE_LINKS=true), as the bare magnet: drop the untrusted-data notice and tag lines, they are not part of the link and would break the forward.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv4.6.1
    • changedInput schema / properties / magnet_link / description
      Previous value: -"Magnet link of the torrent (from get_torrent, or from a search run with INCLUDE_LINKS=true)."New value: +"Magnet link of the torrent (from get_torrent, or from a search run with INCLUDE_LINKS=true), as the bare magnet: drop the untrusted-data notice and tag lines, they are not part of the link and would break the forward."
    • changedInput schema / properties / seeders / anyOf
      Previous value: -[
-  {
-    "anyOf": [
-      {
-        "type": "integer"
-      },
-      {
-        "type": "null"
-      }
-    ],
-    "description": "Optional seeder count."
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / seeders / description
      Added value: +"Optional seeder count."
    • changedInput schema / properties / size / anyOf
      Previous value: -[
-  {
-    "anyOf": [
-      {
-        "type": "string"
-      },
-      {
-        "type": "null"
-      }
-    ],
-    "description": "Optional human-readable size (e.g. '1.2 GiB')."
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / size / description
      Added value: +"Optional human-readable size (e.g. '1.2 GiB')."
  2. Addedv4.5.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does it well: it discloses the REST API dependency, bot-token ownership, required TORRENT_SEARCH_API_KEY and TORRENT_SEARCH_API_URL, the per-chat rate limit of 20/min, and — importantly — that PRUNE_MAGNET_LINKS may rewrite the magnet payload before sending. It omits failure behavior (e.g. what happens when the rate limit is hit) and whether forwards are persisted or deduplicated.

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 action is front-loaded in the first sentence, followed by tightly packed operational detail (API dependency, pruning, credentials, rate limit). No sentence is filler, though the environment-variable clause is slightly dense and could be trimmed for an agent-facing reader.

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?

An output schema exists, so return values need not be explained, and the description covers the prerequisites, the rate limit, and the payload-mutation behavior an agent must know before calling. It is nearly complete for a 5-parameter side-effecting tool, with only error/retry semantics left unspecified.

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 description coverage is 100%, so the schema already documents all five parameters including the optional size and seeders fields and the bare-magnet requirement. The description adds only the 'filename + magnet' pairing, which the schema already implies; baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource — 'Send a torrent (filename + magnet) to the user's Telegram chat' — which immediately tells an agent this is a delivery/forwarding action rather than a lookup. It does not explicitly contrast itself with siblings like get_torrent, search_torrents, or torrent_webapp, so the boundary is inferred rather than stated.

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?

Usage context is implied through the mention that the magnet comes 'from get_torrent, or from a search run with INCLUDE_LINKS=true', which routes the agent to the right sibling for input gathering. However there is no explicit when-to-use vs when-not statement (e.g. forwarding vs opening the webapp), so the guidance is indirect.

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

Deploy Server

Other Tools