Skip to main content
Glama
TnZzZHlp

mteam-mcp

by TnZzZHlp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

mteam-mcp

面向 Hermes Agent 的 M-Team MCP Server。通过标准 stdio MCP 提供种子查询、详情查看和 .torrent 文件下载功能。

工具

MCP 工具

功能

search_torrents

按关键词、分区、分类、优惠、编码和存活状态查询种子，返回 AI 易读的 Markdown

get_torrent_detail

根据数字种子 ID 获取详情和做种状态，返回 AI 易读的 Markdown

download_torrent

生成临时下载令牌并将 .torrent 文件保存到本地目录

下载令牌只在进程内部使用，不会返回给模型。M-Team API Key 仅通过环境变量传入。

Related MCP server: Torrent Search MCP Server

API 环境

本项目默认并直接使用 M-Team 正式环境 API：

https://api.m-team.cc/api

除非显式覆盖 MTEAM_API_BASE，客户端始终连接正式环境。

Markdown 输出格式

search_torrents 和 get_torrent_detail 都返回 Markdown 文本，而不是直接把原始 API JSON 交给模型。

搜索结果包含：

  • 查询词、模式、当前页、每页数量、总结果和总页数

  • 种子 ID、名称、大小、做种人数、下载人数、优惠和标签

  • 查看详情、下载以及翻到下一页的明确调用提示

详情结果包含：

  • 基本信息：种子 ID、名称、分类、大小、文件数量、发布时间和标签

  • 简介

  • 活跃状态：做种、下载、完成人次、可见状态和禁用状态

  • 优惠状态

  • IMDb、豆瓣等合法外部链接

  • download_torrent 的调用参数提示

M-Team 返回的标题、简介和标签会进行 Markdown 转义，并标记为外部元数据，避免被误当成系统操作指令。底层客户端仍保留结构化字典，因此不会影响下载和内部处理。

Hermes Agent 配置

需要先安装 uv。将以下内容加入 ~/.hermes/config.yaml：

mcp_servers:
  mteam:
    command: "uvx"
    args:
      - "--from"
      - "git+https://github.com/TnZzZHlp/mteam-mcp.git"
      - "mteam-mcp"
    env:
      MTEAM_API_KEY: "你的 API Key"
      MTEAM_API_BASE: "https://api.m-team.cc/api"
      MTEAM_DOWNLOAD_DIR: "~/.hermes/downloads/mteam"
      MTEAM_TIMEOUT: "30"
      MTEAM_MAX_TORRENT_BYTES: "33554432"
    enabled: true
    timeout: 120
    connect_timeout: 30
    supports_parallel_tool_calls: false
    tools:
      include: [search_torrents, get_torrent_detail, download_torrent]
      resources: false
      prompts: false

修改后执行：

hermes mcp test mteam

然后在 Hermes 会话中运行：

/reload-mcp

Hermes 注册后的工具名为：

mcp_mteam_search_torrents
mcp_mteam_get_torrent_detail
mcp_mteam_download_torrent

本地运行

git clone https://github.com/TnZzZHlp/mteam-mcp.git
cd mteam-mcp
uv sync
MTEAM_API_KEY='你的 API Key' uv run mteam-mcp

也可以复制环境变量模板：

cp .env.example .env

本项目不会自动读取 .env。启动前应由 shell、systemd、容器或 Hermes 的 env 配置注入变量。

环境变量

变量

必填

默认值

说明

MTEAM_API_KEY

是

无

M-Team API Key

MTEAM_API_BASE

否

https://api.m-team.cc/api

正式环境 API 根地址

MTEAM_DOWNLOAD_DIR

否

~/.hermes/downloads/mteam

.torrent 保存目录

MTEAM_TIMEOUT

否

30

HTTP 超时秒数

MTEAM_MAX_TORRENT_BYTES

否

33554432

单个种子文件最大字节数

查询参数示例

Hermes 可调用：

{
  "keyword": "The Dark Knight",
  "mode": "normal",
  "page_number": 1,
  "page_size": 20,
  "visible": 1,
  "categories": [],
  "discount": "FREE"
}

visible：

  • 1：活种

  • 2：死种

  • null：不筛选

开发和测试

uv sync --extra dev
uv run pytest -q

安全说明

  • 不要把真实 API Key 写入仓库、命令历史、日志或聊天内容。

  • download_torrent 不会把临时下载 URL 返回给模型。

  • 临时下载请求不会携带 x-api-key，避免重定向到其他域名时泄露密钥。

  • 下载采用临时文件后原子替换，并限制最大文件大小。

  • 仅用于你有权访问和下载的内容，并遵守站点规则及当地法律。

License

MIT

Available Tools

3 tools
download_torrentA

Download a .torrent file after the user explicitly requests it.

The temporary M-Team token remains internal. The result contains only the local saved path, torrent ID, and number of bytes written.

ParametersJSON Schema
NameRequiredDescriptionDefault
torrent_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description discloses that the temporary token remains internal (privacy) and that the result contains only local path, torrent ID, and bytes written. This provides useful behavioral context beyond basic functionality.

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 extremely concise: two sentences, the first states the purpose, the second adds constraints and output details. No wasted words.

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's simplicity (one parameter, output schema exists), the description is complete. It explains the output fields and the condition for use, leaving no major gaps.

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 description does not mention the 'torrent_id' parameter, and the input schema provides no description (0% coverage). The agent receives no guidance on what this parameter represents or how to obtain it.

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 'Download a .torrent file' with the condition 'after the user explicitly requests it,' distinguishing it from sibling tools like get_torrent_detail and search_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 specifies that the tool should only be used when the user explicitly requests a download, providing clear context. However, it does not explicitly mention when not to use it or alternative tools.

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

get_torrent_detailC

Get one torrent's metadata as compact, AI-readable Markdown.

ParametersJSON Schema
NameRequiredDescriptionDefault
torrent_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

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

No annotations provided, so description must disclose behavioral traits. It only states output format but omits whether it's read-only, auth needed, error handling (e.g., torrent not found), or rate limits.

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?

One sentence with no waste, but could include more essential info without being verbose. Efficient but borderline too terse.

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 no annotations and low schema coverage, description is incomplete. It mentions output format but lacks parameter guidance, use-cases, and behavioral context. With only one param, more detail is expected.

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 has 1 parameter (torrent_id, string) with 0% description coverage. Description adds no meaning beyond what schema provides; does not explain what torrent_id is or how to obtain it.

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 clearly states verb 'Get', resource 'one torrent's metadata', and format 'compact, AI-readable Markdown'. Differentiates from siblings: download_torrent (downloads) and search_torrents (searches).

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. Missing context like 'use search_torrents to find torrent_id first' or prerequisites.

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

search_torrentsA

Search M-Team torrents and return compact, AI-readable Markdown.

Args: keyword: Keyword, IMDb URL, or Douban URL. Empty text lists matching items. mode: M-Team search mode, normally normal or adult. page_number: One-based result page. page_size: Number of results, from 1 to 100. visible: 1 for active torrents, 2 for dead torrents, or null for no filter. categories: Optional M-Team category IDs. discount: Optional discount such as FREE, PERCENT_50, or PERCENT_70. video_codecs: Optional video codec filters. audio_codecs: Optional audio codec filters.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNonormal
keywordNo
visibleNo
discountNo
page_sizeNo
categoriesNo
page_numberNo
audio_codecsNo
video_codecsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

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

No annotations provided, so description must disclose behavior. It only states return format, but does not mention read-only nature, caching, rate limits, or any side effects. For a search tool, read-only is typical but not confirmed.

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?

Front-loaded with purpose and output format, followed by a well-organized Args list. Slightly lengthy due to many parameters but each line is necessary and concise.

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?

Covers parameter semantics well, but lacks behavioral details (e.g., read-only, real-time vs cached) and any prerequisites or output format details. Output schema exists so return values are covered, but overall completeness is moderate.

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

Parameters5/5

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

Despite 0% schema coverage, the description provides detailed explanations for all 9 parameters, including allowed values and defaults. This adds substantial meaning beyond the schema's type and default definitions.

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 clearly states verb 'Search' and resource 'M-Team torrents', and specifies return format 'compact, AI-readable Markdown'. This distinguishes it from sibling tools 'download_torrent' and 'get_torrent_detail'.

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?

Provides context for when to use (searching torrents) but lacks explicit guidance on when not to use or alternatives. The hint 'Empty text lists matching items' is useful but no sibling differentiation.

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.

  1. 3 tool updatesv0.1.0
    • First observeddownload_torrent
    • First observedget_torrent_detail
    • First observedsearch_torrents
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

A3.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: searching for torrents, viewing torrent details, and downloading torrent files. There is no overlap or ambiguity.

Naming Consistency5/5

All three tool names follow a consistent verb_noun pattern (search_torrents, get_torrent_detail, download_torrent) using snake_case, making it predictable and easy to understand.

Tool Count4/5

With 3 tools, the set is minimal but covers the core functionality of a torrent client (search, detail, download). It is at the lower end of the typical range but still appropriate for a focused server.

Completeness4/5

The tools cover the essential workflow of searching, inspecting, and downloading torrents. Minor gaps like torrent removal or user-specific features are absent, but the core operations are fully covered.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers