Skip to main content
Glama
philogicae

Torrent Search MCP Server

by philogicae

Forward Torrent

forward_torrent

Send torrent filename and magnet link to a specified Telegram chat via the Torrent Search REST API.

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

TableJSON Schema
NameRequiredDescriptionDefault
sizeNo
chat_idYesThe owner's Telegram chat id the torrent is sent to.
seedersNo
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).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.5.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does well by explaining the API routing, the API key/URL requirements, the conditional PRUNE_MAGNET_LINKS behavior, and the per-chat rate limit. It does not describe error behavior or side effects beyond sending, but the core behavioral traits are well covered.

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 main purpose is front-loaded in the first sentence, and each subsequent sentence adds necessary operational detail: API routing, environment-dependent pruning, required configuration, and rate limiting. The text is dense but not redundant, though the technical details could be slightly better organized.

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?

The description covers the essential calling context: prerequisites, rate limits, configuration variables, and conditional magnet transformation. Since an output schema is present, return-value details are not needed. Minor gaps remain around explicit integration with sibling tools, but the description is strong enough for an agent to invoke the tool correctly.

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 input schema already describes each parameter, so the description only adds moderate value. It clarifies the filename+magnet relationship and the magnet pruning format, but it does not enrich the meaning of chat_id, size, or seeders beyond what the schema already states. With schema coverage around 60%, the description partially compensates but is not exceptional.

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 opens with a specific action verb and resource: 'Send a torrent (filename + magnet) to the user's Telegram chat.' This clearly distinguishes the tool from sibling search/retrieval tools such as search_torrents and get_torrent, which do not send messages to Telegram.

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 context of use is clear: this tool is for delivering a torrent to a Telegram chat, and the description provides prerequisites and rate limits. However, it does not explicitly state when to use this tool versus alternatives like get_torrent or search_torrents, nor does it provide any when-not-to-use guidance.

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