Skip to main content
Glama

Youtube To Mp315 MCP Server

English | 简体中文 | 繁體中文

用于访问 Youtube To Mp315 API 的 MCP 服务器。

🚀 使用 EMCP 平台快速体验

EMCP 是一个强大的 MCP 服务器管理平台,让您无需手动配置即可快速使用各种 MCP 服务器!

快速开始:

  1. 🌐 访问 EMCP 平台

  2. 📝 注册并登录账号

  3. 🎯 进入 MCP 广场,浏览所有可用的 MCP 服务器

  4. 🔍 搜索或找到本服务器(bach-youtube_to_mp315

  5. 🎉 点击 "安装 MCP" 按钮

  6. ✅ 完成!即可在您的应用中使用

EMCP 平台优势:

  • 零配置:无需手动编辑配置文件

  • 🎨 可视化管理:图形界面轻松管理所有 MCP 服务器

  • 🔐 安全可靠:统一管理 API 密钥和认证信息

  • 🚀 一键安装:MCP 广场提供丰富的服务器选择

  • 📊 使用统计:实时查看服务调用情况

立即访问 EMCP 平台 开始您的 MCP 之旅!


Related MCP server: Youtube Mp36 MCP Server

简介

这是一个 MCP 服务器,用于访问 Youtube To Mp315 API。

  • PyPI 包名: bach-youtube_to_mp315

  • 版本: 1.0.0

  • 传输协议: stdio

安装

从 PyPI 安装:

pip install bach-youtube_to_mp315

从源码安装:

pip install -e .

运行

方式 1: 使用 uvx(推荐,无需安装)

# 运行(uvx 会自动安装并运行)
uvx --from bach-youtube_to_mp315 bach_youtube_to_mp315

# 或指定版本
uvx --from bach-youtube_to_mp315@latest bach_youtube_to_mp315

方式 2: 直接运行(开发模式)

python server.py

方式 3: 安装后作为命令运行

# 安装
pip install bach-youtube_to_mp315

# 运行(命令名使用下划线)
bach_youtube_to_mp315

配置

API 认证

此 API 需要认证。请设置环境变量:

export API_KEY="your_api_key_here"

环境变量

变量名

说明

必需

API_KEY

API 密钥

PORT

不适用

HOST

不适用

在 Cursor 中使用

编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:

{
  "mcpServers": {
    "bach-youtube_to_mp315": {
      "command": "uvx",
      "args": ["--from", "bach-youtube_to_mp315", "bach_youtube_to_mp315"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

在 Claude Desktop 中使用

编辑 Claude Desktop 配置文件 claude_desktop_config.json:

{
  "mcpServers": {
    "bach-youtube_to_mp315": {
      "command": "uvx",
      "args": ["--from", "bach-youtube_to_mp315", "bach_youtube_to_mp315"],
      "env": {
        "API_KEY": "your_api_key_here"
      }
    }
  }
}

可用工具

此服务器提供以下工具:

status

Check the status of the file conversion

端点: GET /status/{id}

参数:

  • id (string) 必需: Example value:


download

Convert YouTube video to mp3 async

端点: POST /download

参数:

  • url (string) 必需: Example value: https://www.youtube.com/watch?v=zyG9Nh_PH38

  • endTime (number): Example value:

  • format (string): Example value: mp3

  • quality (number): Example value:

  • startTime (number): Example value:

  • callbackUrl (string): Example value:

  • X-RapidAPI-User (string): Example value:


title

Get the title of YouTube video

端点: GET /title

参数:


技术栈

  • 传输协议: stdio

  • HTTP 客户端: httpx

许可证

MIT License - 详见 LICENSE 文件。

开发

此服务器由 API-to-MCP 工具生成。

版本: 1.0.0

Available Tools

3 tools
downloadDownloadC

Convert YouTube video to mp3 async

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesExample value: https://www.youtube.com/watch?v=zyG9Nh_PH38
formatNoExample value: mp3
endTimeNoExample value: 0
qualityNoExample value:
startTimeNoExample value:
callbackUrlNoExample value:
X-RapidAPI-UserNoExample value:

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of explaining behavior. It mentions 'async' but does not disclose what happens after submission, whether a job ID is returned, how the callback URL is used, or side effects such as storage 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.

Conciseness5/5

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

The description is a single, focused sentence with no redundant words or irrelevant details. It is highly concise.

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

Completeness1/5

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

Given seven parameters, no annotations, and no output schema, this one-line description is far from complete. It omits expected return values, error behavior, callback semantics, parameter constraints, and any relationship to the status and title tools.

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 schema descriptions are mostly example values rather than semantic explanations, and the description adds no parameter detail. Parameter names like url, format, and quality are somewhat self-explanatory, but startTime, endTime, callbackUrl, and X-RapidAPI-User remain unclear.

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 converts YouTube videos to MP3 and is asynchronous, which is a specific action on a specific resource. It is distinguishable from the sibling tools 'status' and 'title', though it does not explicitly contrast with them.

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?

There is no guidance on when to use this tool versus alternatives like 'status' or 'title'. The description does not mention prerequisites, typical use cases, or when another tool would be more appropriate.

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

statusStatusC

Check the status of the file conversion

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesExample value:

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description must disclose side effects or safety. 'Check' implies read-only, but this is not explicit, and no details about rate limits or other behaviors are given.

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, clear sentence with no unnecessary words, making it highly concise and well-structured.

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 lacks context about the output format, what the status values might be, or how the 'id' parameter is used. This is incomplete for a tool with no output schema.

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 'id' parameter has no meaningful description in the schema. The tool description mentions 'file conversion' but does not explicitly explain that 'id' refers to a conversion ID, leaving room for ambiguity.

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 ('check') and the resource ('status of the file conversion'), making it distinct from sibling tools like 'download' or 'title'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/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, nor any conditions or prerequisites for invoking it.

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

titleTitleB

Get the title of YouTube video

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesExample value: https://www.youtube.com/watch?v=zyG9Nh_PH38

TDQS

B3/5.0
Behavior2/5

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

With no annotations available, the description carries the full burden. It implies a read-only operation but does not explicitly state that it has no side effects, requires network access, or any other behavioral 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?

The description is a single, concise sentence that gets straight to the point with no unnecessary words or details.

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?

For a simple getter tool, the description is minimal but adequate. However, it lacks any mention of return format, error behavior, or how it fits relative to sibling tools, leaving some context missing.

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 parameter 'url' has only an example value in the schema, and the description adds no further explanation about URL format or constraints. Semantics are weak despite the example.

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 ('Get') and the specific resource ('title of YouTube video'), making it unambiguous and distinct from the sibling tools 'download' and 'status'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool over its alternatives (download, status), nor any conditions or prerequisites for its use.

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 updatesv1.0.0
    • First observeddownload
    • First observedstatus
    • First observedtitle

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: download initiates conversion, status checks progress, and title retrieves video metadata. No overlap or ambiguity.

Naming Consistency5/5

All tool names are single lowercase verbs that accurately describe their actions, maintaining a consistent and predictable pattern.

Tool Count5/5

With only three tools, the server is tightly scoped to the core workflow of YouTube-to-MP3 conversion, avoiding unnecessary bloat.

Completeness5/5

The tool set covers the essential lifecycle: initiating a download, checking its status, and fetching title info. No critical gaps for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers