Youtube To Mp315 MCP Server
Enables conversion of YouTube videos to MP3 format, retrieval of video titles, and checking the status of file conversions through the Youtube To Mp315 API.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Youtube To Mp315 MCP Serverconvert this YouTube video to MP3: https://www.youtube.com/watch?v=zyG9Nh_PH38"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Youtube To Mp315 MCP Server
用于访问 Youtube To Mp315 API 的 MCP 服务器。
🚀 使用 EMCP 平台快速体验
EMCP 是一个强大的 MCP 服务器管理平台,让您无需手动配置即可快速使用各种 MCP 服务器!
快速开始:
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场,浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器(
bach-youtube_to_mp315)🎉 点击 "安装 MCP" 按钮
✅ 完成!即可在您的应用中使用
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 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
在 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_PH38endTime(number): Example value:format(string): Example value: mp3quality(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
参数:
url(string) 必需: Example value: https://www.youtube.com/watch?v=zyG9Nh_PH38
技术栈
传输协议: stdio
HTTP 客户端: httpx
许可证
MIT License - 详见 LICENSE 文件。
开发
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Available Tools
3 toolsdownloadDownloadC
Convert YouTube video to mp3 async
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.youtube.com/watch?v=zyG9Nh_PH38 | |
| format | No | Example value: mp3 | |
| endTime | No | Example value: | 0 |
| quality | No | Example value: | |
| startTime | No | Example value: | |
| callbackUrl | No | Example value: | |
| X-RapidAPI-User | No | Example value: |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: |
TDQS
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.
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.
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.
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.
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.
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
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.youtube.com/watch?v=zyG9Nh_PH38 |
TDQS
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.
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.
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.
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.
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.
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.
3 tool updates
v1.0.0- First observed
download - First observed
status - First observed
title
TDQS
Scored across 3 tools
Each tool has a clear, distinct purpose: download initiates conversion, status checks progress, and title retrieves video metadata. No overlap or ambiguity.
All tool names are single lowercase verbs that accurately describe their actions, maintaining a consistent and predictable pattern.
With only three tools, the server is tightly scoped to the core workflow of YouTube-to-MP3 conversion, avoiding unnecessary bloat.
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
Related MCP Connectors
Youtube Download API: Download audio and video from YouTube. On the JoJ API marketplace.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
YouTube transcripts, search, channels, playlists and bulk transcript jobs for AI agents. 14 tools.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
Related MCP Servers
- AlicenseNot gradedqualityNot gradedmaintenanceEnables LLMs to search, download, and extract information from YouTube music videos, converting them to high-quality MP3 files.GPL 3.0
- AlicenseBqualityDmaintenanceEnables users to convert YouTube videos to MP3 format with optional trimming capabilities through the Youtube Mp36 API.1MIT
- AlicenseCqualityDmaintenanceEnables downloading MP3 audio files from YouTube videos by providing a YouTube URL through the Youtube Mp310 API.1MIT
- FlicenseAqualityDmaintenanceEnables video metadata extraction and downloading from platforms like TikTok and YouTube via yt-dlp, including direct MP4 links and local downloads with MP3 conversion.3-