Torrent Search MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v4.3.3
Disambiguation5/5
The two tools have clearly distinct purposes: one for searching torrents and one for retrieving a specific torrent by ID. There is no overlap in functionality.
Naming Consistency5/5
Both tools follow a consistent verb_noun pattern: 'search_torrents' and 'get_torrent'. The singular/plural difference is minor and the pattern is uniform.
Tool Count2/5
With only two tools, the server feels underdeveloped for a torrent search service. A typical implementation would include more tools (e.g., list providers, get categories) to cover basic workflows.
Completeness2/5
The server lacks tools for browsing categories, getting detailed metadata, or configuring providers. The search tool returns results but there is no way to iterate or filter without additional tool support.
Average 4.1/5 across 2 of 2 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on August 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates a read action ('Get the list') and gives no detail about whether the source list is dynamic, cached, requires authorization, or has other side effects. It is not contradictory, but it is very thin.
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, focused sentence that front-loads the action and resource. There is no repetition, filler, or unnecessary detail.
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 parameterless tool with an output schema present, this description is sufficient to invoke the tool correctly. It could say more about how available sources relate to the sibling search/torrent tools, but nothing essential for the actual call is missing.
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 tool has zero parameters, and the schema is empty with 100% coverage. There is nothing for the description to add about input semantics, so the zero-parameter baseline of 4 is appropriate.
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 uses a clear action verb ('Get') and a specific resource ('list of available torrent sources'), which distinguishes it reasonably from sibling tools like search_torrents and get_torrent. However, it does not define what a 'source' is in this context.
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 given about when to use this tool versus the sibling tools, such as search_torrents or popular_torrents. The intended relationship between 'available sources' and the other torrent operations is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly details ranking criteria (quality, efficiency, health, size, language), response requirements (top 3-5 results with specific fields), and fallback behavior for poor results (suggest keywords). This tells the agent exactly how the tool behaves and what to do with outputs, making the behavior highly transparent.
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 well-structured with a clear opening sentence followed by organized ranking and response sections. It is longer than a minimal description, but every section contributes actionable guidance for the agent. The use of headings and bullets improves scanability, though the ranking rules could be tightened without losing meaning.
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?
The description covers the full workflow: performing the search, analyzing and ranking results, formatting recommendations, and providing fallback keyword suggestions. Even if the output schema exists, the description specifies exactly what the agent should deliver, which is more than enough for correct invocation and use. Nothing critical is missing for an agent to handle this tool effectively.
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 provides 100% coverage, with a detailed description for 'query' that includes optimization rules and a clear explanation for 'user_intent'. Since schema coverage is high, the description does not need to add parameter semantics. The main description adds no further parameter-level meaning, so the baseline of 3 is appropriate.
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 opens with 'Perform an advanced torrent search across multiple providers,' which clearly identifies the tool's function as a search across torrent providers. It differentiates from siblings like popular_torrents and get_torrent by the nature of the operation, but it does not explicitly name or contrast alternatives. The core purpose is clear, though sibling differentiation is implicit.
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 provides extensive guidance on how to rank and present results, but it does not state when to use this tool versus alternatives like popular_torrents or available_sources. The usage is implied by the search-oriented name and description, yet there is no explicit exclusions or 'use this when' context. It offers strong procedural guidance inside the tool but not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses that output is grouped per source, limited by per_source, pre-ranked by swarm health, and that the tool is expected to return a curated recommendation subset. This goes beyond the bare schema and gives the agent useful expectations about the tool's behavior.
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 purpose is front-loaded in a single clear sentence, followed by compact grouping/ranking detail and a structured bullet list of response requirements. Every section earns its place; it is slightly longer than minimal but remains focused and scannable.
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 optional parameter and no annotations, the description covers the essential invocation context: source list, per_source limit, ranking behavior, and required response shape. It does not explain when to prefer this over search_torrents, but that gap is minor and does not prevent correct invocation.
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 per_source with a default and minimum, so schema coverage is 100%. The description reinforces the parameter's meaning by saying results are kept 'per source', but it adds no new format or syntax details beyond what the schema already provides. Baseline 3 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 opens with a clear verb-resource statement: 'Get the most popular torrents right now across providers.' It then specifies the exact sources and grouping behavior, which distinguishes it from sibling tools like search_torrents, available_sources, and get_torrent. An agent can immediately understand what this tool does and how it differs.
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 does not explicitly say 'use this instead of search_torrents when...', but it strongly implies the intended use case: browsing current popular releases from official top listings. The response requirements about recommending top 5-10 latest releases add practical guidance. It provides clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly signals a read-only retrieval operation and states the exact output (a magnet link) for a given torrent id. It does not mention error behavior or authorization requirements, but for a simple getter tool the core behavior is transparent enough.
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 clean sentence with the verb and object front-loaded: 'Get the magnet link for a specific torrent by id.' There is no filler, repetition, or unnecessary detail, and 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 the tool's simplicity, one fully documented parameter, and the presence of an output schema, the definition is largely complete: an agent knows what action is performed, what input is required, where that input comes from, and what result to expect. The only slight gap is the absence of any explicit note about prerequisites or when not to use this tool.
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%; the single parameter torrent_id is already fully described, including its provenance from earlier search_torrents or popular_torrents calls. The description adds only the phrase 'by id', which provides no meaningful meaning beyond the schema, so it stays at the baseline.
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'), names the exact resource ('magnet link'), and scopes it to 'a specific torrent by id'. This makes it clearly distinct from the sibling search_torrents and popular_torrents tools, which serve to find or list torrents rather than retrieve a magnet link.
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 itself does not name alternatives, but the input schema provides strong context: torrent_id is described as 'returned by a previous search_torrents or popular_torrents call,' which tells an agent this is the follow-up retrieval step after a search or popular-list call. It stops short of explicit when-not-to-use or alternative routing, so it misses a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the full user-facing flow, the QR code and Telegram fallback options, the exact prompt format, and the 5-minute code expiration. This gives the agent enough behavioral context to execute and to inform the user accurately.
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 longer than a simple one-liner, but every sentence carries necessary procedural information: URL delivery, pairing dialog options, user actions, code extraction, and expiration. It is front-loaded with the purpose and remains structured without redundancy.
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?
The description completely covers the tool's role in the authorization flow, including fallback mechanisms and the subsequent authorize_webapp call. Since an output schema exists, return-value details are not required, and nothing essential for correctly invoking this tool is missing.
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 tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics to explain. The baseline of 4 applies, and the description appropriately focuses on behavior rather than inputs.
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 a specific verb-resource pair: present the Torrent Search webapp and its Telegram pairing access system, and it clarifies the deliverable (webapp URL and authorization instructions). It also distinguishes this from the sibling authorize_webapp by explicitly routing to it as the next step.
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 tool's role in the pairing flow is clearly implied: it is the initial presentation step, and the description says the next step is to call authorize_webapp with the extracted code and chat id. It does not explicitly list exclusions or alternatives, but the context makes when-to-use unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It goes beyond the schema by explaining that codes are single-use, expire in 5 minutes, that the browser must return to the webapp to complete authentication, and that access is then unlocked permanently. This is meaningful behavioral context, though it omits failure/error behavior.
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 well-structured: purpose first, then source context, then the exact action to take, then important constraints, then what must happen afterward. Every sentence earns its place and the critical operational details are front-loaded.
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?
For a two-parameter authorization tool with no annotations, this is complete. It tells the agent how to obtain the code, what chat id to use, the expiry and single-use behavior, and the required follow-up step on the webapp. Nothing essential for correct invocation is missing.
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 100%, so the baseline is 3. The description adds value by explaining where the code comes from (parsing it from the user's 'Authorize' message) and clarifying that chat_id is the owner's Telegram chat id the access is bound to. This enriches the schema's terse property descriptions.
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 verb and resource: 'Authorize a browser on the Torrent Search webapp via its pairing code.' This clearly identifies the action, the target, and the mechanism, and it is immediately distinguishable from the search/list sibling tools.
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 gives an explicit trigger: the user sends 'Authorize <CODE> for Torrent Search' to the bot, and the agent should take the code from that message and call this tool with the code and chat id. It also notes that codes are single-use and expire after 5 minutes. It does not explicitly name alternatives or state when not to use the tool, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![torrent-search-mcp MCP server](https://glama.ai/mcp/servers/philogicae/torrent-search-mcp/badges/card.svg)](https://glama.ai/mcp/servers/philogicae/torrent-search-mcp)

Score Badge

Copy to your README.md:

[![torrent-search-mcp MCP server](https://glama.ai/mcp/servers/philogicae/torrent-search-mcp/badges/score.svg)](https://glama.ai/mcp/servers/philogicae/torrent-search-mcp)

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/torrent-search-mcp'

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