⚠️实验状态免责声明
该项目处于早期 Alpha 阶段，高度实验性。不建议用于生产环境。而且它很可能比较混乱！
目前的局限性：
你可能会遇到不一致的行为
高级功能（打包、转换等）仍在积极开发中
Docker 和主机环境之间的路径转换可能需要手动配置
预计频繁的重大变化和潜在的不稳定性
请报告您遇到的任何问题以帮助改进项目。
一个 MCP（模型上下文协议）服务器，将Shaka Packager与 Claude AI 应用程序集成，用于视频转码、打包和分析。
该服务器与文件系统 MCP 服务器配合使用，使 Claude Desktop 能够访问和处理您计算机上的视频文件，使 Claude 成为媒体处理任务的强大助手。
视频分析：分析视频文件以提取详细的流信息、编解码器、比特率等
媒体打包：将视频转换为 HLS 和 DASH 格式的流媒体，支持 VOD 和直播
高级选项：
应用 DRM 加密（Widevine、PlayReady、FairPlay）
配置广告插入标记
在格式之间转换（MP4、TS 等）
智能路径处理：自动转换 Docker 和主机环境之间的路径
强大的错误管理：提供有意义的错误分析和解决建议
命令协助：帮助正确格式化 Shaka Packager 命令以获得最佳结果
交互式文档：内置帮助和示例，指导用户完成复杂的操作
详细输出：所有操作的综合摘要和执行细节
Related MCP server: encoding-devops
Python 3.10 或更高版本
Shaka Packager 已安装并可在您的 PATH 中使用
或者按照这些说明从源代码构建
与 MCP 兼容的客户端（例如 Claude Desktop）
使用 pip 安装包：
pip install shaka-packager-mcp或者使用 uv：
uv pip install shaka-packager-mcpgit clone https://github.com/coderjun/shaka-packager-mcp.git
cd shaka-packager-mcp
pip install -e .或者使用 uv：
git clone https://github.com/coderjun/shaka-packager-mcp.git
cd shaka-packager-mcp
uv pip install -e .由于 Claude Desktop 不直接支持上传视频文件，我们将使用双服务器方法：
简化的**文件系统 MCP 服务器，**用于访问计算机上的视频文件
Shaka Packager MCP 服务器用于分析和处理这些视频
使用官方 MCP 文件系统服务器允许 Claude 访问您的视频文件：
使用 Docker 安装官方文件系统服务器：
docker pull mcp/filesystem或者，您可以按照Filesystem MCP Server 存储库中的说明从源代码构建它
找到您的 Claude Desktop 配置文件：
macOS ： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows ： %APPDATA%\Claude\claude_desktop_config.json
如果该文件不存在，则创建它。
添加以下配置，确保使用绝对路径：
{
"mcpServers": {
"filesystem": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--mount", "type=bind,src=/PATH/TO/VIDEOS/DIRECTORY,dst=/projects/video-drop",
"mcp/filesystem",
"/projects"
]
},
"shaka-packager": {
"command": "/ABSOLUTE/PATH/TO/uv",
"args": [
"run",
"--with",
"mcp[cli]",
"/ABSOLUTE/PATH/TO/shaka_packager_mcp.py"
],
"env": {
"VIDEO_PATH": "/PATH/TO/VIDEOS/DIRECTORY",
"SHAKA_PACKAGER_PATH": "/PATH/TO/PACKAGER"
}
}
}
}代替：
/PATH/TO/VIDEOS/DIRECTORY包含视频文件的目录路径
/ABSOLUTE/PATH/TO/uv为您的 uv 可执行文件的完整路径
/ABSOLUTE/PATH/TO/shaka_packager_mcp.py以及脚本文件的完整路径
/PATH/TO/PACKAGER包含 Shaka Packager 可执行文件的完整路径
例如：
{
"mcpServers": {
"filesystem": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"--mount", "type=bind,src=/Users/username/Videos,dst=/projects/video-drop",
"mcp/filesystem",
"/projects"
]
},
"shaka-packager": {
"command": "/Users/username/.local/bin/uv",
"args": [
"run",
"--with",
"mcp[cli]",
"/Users/username/Development/shaka-packager-mcp/shaka_packager_mcp.py"
],
"env": {
"VIDEO_PATH": "/Users/username/Videos",
"SHAKA_PACKAGER_PATH": "/Users/username/.shaka/packager"
}
}
}
}编辑配置文件后，重新启动 Claude Desktop 以应用更改。
首先，使用简化的文件系统服务器浏览您的视频文件：
要求 Claude“列出我的视频目录中的文件”
导航到您想要分析或处理的视频文件
找到视频文件后，请使用 Shaka Packager 工具的路径：
用于分析：“请分析此视频：/Users/username/Videos/example.mp4”
处理：“请将此视频打包用于 HLS：/Users/username/Videos/example.mp4”
如果您遇到任何问题：
确保两个服务器都正确配置了绝对路径
验证 Shaka Packager 是否已安装并可访问
确保为文件系统服务器指定的目录存在且包含视频
检查 Claude Desktop 日志中的错误：
macOS： ~/Library/Logs/Claude/mcp*.log
Windows： %APPDATA%\Claude\logs\mcp*.log
一旦 Filesystem MCP 服务器和 Shaka Packager MCP 服务器都在 Claude Desktop 中运行：
访问您的视频文件：
Please show me the files in my Videos directory导航到您的视频文件：
Please show me the files in the Movies subdirectory复制要处理的视频的 file:// URI 路径
使用 Shaka Packager 工具和文件路径：
Please analyze this video: file:///Users/username/Videos/my_video.mp4或者
Please package this video for HLS and DASH streaming: file:///Users/username/Videos/my_video.mp4服务器将执行适当的 Shaka Packager 命令并提供详细的结果摘要
如果您知道视频文件的确切位置，您也可以使用直接文件路径：
Please analyze this video: /Users/username/Videos/my_video.mp4服务器提供以下工具：
analyze_video ：检查视频文件并提供详细的流信息以及智能错误处理
run_shaka_packager ：使用自定义参数和适当的路径处理执行任何 Shaka Packager 命令
get_shaka_options ：检索可用的命令选项和版本信息
get_shaka_documentation ：提供使用 Shaka Packager 的全面文档和示例
服务器包含以下提示模板：
MP4 到 TS 转换
HLS 和 DASH 中的 VOD 打包
直播包装
内容加密
广告插入准备
视频分析
命令格式提醒
错误解释指导
可以使用环境变量来配置服务器：
SHAKA_PACKAGER_PATH ：Shaka Packager 可执行文件的路径（强烈推荐用于 Claude Desktop）
VIDEO_PATH ：本地视频目录的路径（用于在 Docker 和主机之间转换路径）
DOCKER_PATH ：Docker 容器挂载路径（默认值：“/projects/video-drop”）
TEMP_DIR ：文件上传的自定义临时目录
LOG_LEVEL ：日志级别（DEBUG、INFO、WARNING、ERROR、CRITICAL）
COMMAND_TIMEOUT ：Shaka Packager 命令的超时时间（秒）（默认值：300）
您可以在以下位置设置这些：
您的 Claude Desktop 配置文件（ SHAKA_PACKAGER_PATH和VIDEO_PATH为首选）
您的环境变量
与脚本位于同一目录中的.env文件
示例.env文件：
SHAKA_PACKAGER_PATH=/usr/local/bin/packager
VIDEO_PATH=/Users/yourusername/Videos
LOG_LEVEL=DEBUG# Clone the repository
git clone https://github.com/coderjun/shaka-packager-mcp.git
cd shaka-packager-mcp
# Install development dependencies with pip
pip install -e ".[dev]"
# Or with uv
uv pip install -e ".[dev]"pytestblack .
isort .Shaka Packager MCP 服务器的主要组件包括：
shaka_packager_mcp.py ：使用 MCP 工具和提示的主服务器实现
tests/ ：用于验证功能的测试套件
该服务器旨在与官方 MCP 文件系统服务器配合使用以访问视频文件。
强大的路径处理：自动转换 Docker 和主机环境之间的路径
智能错误处理：提供有意义的错误消息和建议
命令语法帮助：帮助正确格式化 Shaka Packager 命令
文档集成：提供全面的文档和示例
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
请随意使用 AI 代码副驾驶，作者就是这样做的。
如果您遇到任何问题或有疑问：
查看本自述文件中的故障排除部分
使用get_shaka_documentation工具在 Claude 中获取交互式帮助
在 GitHub 上打开一个问题
Shaka Packager具有强大的视频处理功能
用于通信框架的模型上下文协议 (MCP)
Claude的 AI 助手功能
Anthropic开发了 Claude 和 MCP 标准
Analyze a video file using Shaka Packager.
Args:
file_path: Path to the video file. Can be a local file path or a file:// URI from the filesystem MCP.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool analyzes a video file but doesn't describe what the analysis entails (e.g., format detection, metadata extraction, error checking), how long it might take, whether it modifies the file, or any rate limits. The mention of 'file:// URI from the filesystem MCP' hints at integration but lacks depth. For a tool with no annotations, this is insufficient.
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 appropriately sized and front-loaded, starting with the core purpose. The two sentences are efficient, with the second providing parameter details. There's no wasted text, though it could be slightly more structured (e.g., bullet points). It earns its place but isn't perfectly polished.
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 the tool has an output schema (which handles return values), no annotations, and low parameter complexity (1 param with 0% schema coverage), the description is moderately complete. It covers the purpose and parameter semantics adequately but lacks behavioral details and usage guidelines. For a simple analysis tool, it's acceptable but has clear gaps in guiding the agent.
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 description coverage is 0%, so the description must compensate. It adds meaningful context for the single parameter 'file_path' by explaining it can be a local file path or a file:// URI from the filesystem MCP, which clarifies usage beyond the schema's basic string type. However, it doesn't detail constraints like supported file formats or path examples, keeping it from a perfect score.
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 ('Analyze a video file') and the resource ('video file'), and mentions the specific tool used ('Shaka Packager'). However, it doesn't explicitly differentiate this tool from its siblings (get_shaka_documentation, get_shaka_options, run_shaka_packager), which would require a 5. The purpose is specific but lacks sibling differentiation.
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 versus its siblings. It mentions the tool's capability but doesn't specify contexts, prerequisites, or alternatives. For example, it doesn't explain when to choose analyze_video over run_shaka_packager or how it relates to get_shaka_options. This leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive Shaka Packager documentation, including command structure and examples.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool retrieves documentation but doesn't specify format (e.g., HTML, text), access requirements, rate limits, or error handling. This leaves gaps for a tool with no annotation coverage, though it correctly implies a read-only operation.
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, efficient sentence that front-loads the core purpose ('Get comprehensive Shaka Packager documentation') and adds useful details without waste. Every word earns its place, making it appropriately sized for a simple tool.
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 the tool's simplicity (0 parameters, output schema provided), the description is mostly complete. It clearly states what the tool does, though it lacks behavioral details like output format or usage context. The presence of an output schema reduces the need to explain return values, but more guidance on when to use it would enhance completeness.
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 tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is acceptable here as there are no parameters to explain, aligning with the baseline for zero parameters.
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's purpose with a specific verb ('Get') and resource ('Shaka Packager documentation'), including scope details like 'command structure and examples'. It distinguishes from sibling tools like 'get_shaka_options' by focusing on documentation rather than configuration options, though it doesn't explicitly contrast 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?
The description provides no guidance on when to use this tool versus alternatives like 'get_shaka_options' or 'run_shaka_packager', nor does it mention any prerequisites or exclusions. Usage is implied only by the tool's name and purpose, lacking explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the available options and version information for Shaka Packager.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states what the tool does but fails to describe key traits: it doesn't specify if this is a read-only operation, what the output format looks like (though an output schema exists), or any potential side effects like network calls or authentication needs. This leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly. Every part of the sentence contributes essential information.
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 the tool's low complexity (0 parameters, no annotations, but with an output schema), the description is minimally adequate. It explains what the tool does but lacks context on usage guidelines and behavioral traits. The presence of an output schema mitigates the need to describe return values, but more guidance on when and how to use this tool would improve completeness.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description appropriately doesn't add parameter details, as none are needed, aligning with the baseline for zero parameters. No compensation is required, and it avoids redundancy.
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 verb 'Get' and the resource 'available options and version information for Shaka Packager', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its sibling 'get_shaka_documentation', which might also provide information about Shaka Packager, leaving some ambiguity about differentiation.
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 versus alternatives like 'get_shaka_documentation' or 'run_shaka_packager'. It lacks context about prerequisites, such as whether Shaka Packager needs to be installed or configured, or any exclusions for usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a custom Shaka Packager command.
Args:
file_path: Path to the uploaded video file.
command_args: Additional arguments to pass to the shaka-packager command.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | ||
| command_args | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 states the tool runs a command but doesn't explain what Shaka Packager is, what the command does (e.g., video packaging, transcoding), potential side effects (e.g., file modifications), or any requirements like permissions or rate limits. This leaves significant gaps in understanding 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by a bullet-point list of parameters. It avoids unnecessary words and is front-loaded with the main action. However, it could be slightly more efficient by integrating parameter details into a single sentence without losing clarity.
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 the tool's complexity (running a custom command with two parameters), no annotations, and an output schema (which reduces the need to describe return values), the description is minimally complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines, making it adequate but with clear gaps for effective agent use.
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 description adds basic semantics for both parameters ('file_path' and 'command_args'), explaining their purposes beyond the schema, which has 0% description coverage. However, it lacks details on formats (e.g., what 'command_args' should include) or constraints, providing only minimal value over the bare schema. With two parameters and low schema coverage, this is adequate but not comprehensive.
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's purpose: 'Run a custom Shaka Packager command.' This specifies the verb ('Run') and resource ('Shaka Packager command'), making it understandable. However, it doesn't differentiate from sibling tools like 'analyze_video' or 'get_shaka_options', which prevents a perfect score.
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 versus alternatives. It doesn't mention sibling tools or contexts where this is preferred, such as for custom packaging versus standard analysis or documentation retrieval. This lack of comparative usage information limits its helpfulness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_videoget_shaka_documentationget_shaka_optionsrun_shaka_packagerScored across 4 tools
Each tool has a clearly distinct purpose: analyze_video for file analysis, get_shaka_documentation for documentation retrieval, get_shaka_options for version/options info, and run_shaka_packager for custom command execution. There is no overlap or ambiguity between these functions.
All tools follow a consistent verb_noun pattern (analyze_video, get_shaka_documentation, get_shaka_options, run_shaka_packager) with clear, descriptive names. The naming convention is uniform throughout the set.
Four tools is reasonable for a Shaka Packager server, covering core functions like analysis, documentation, options, and execution. However, it feels slightly thin as it lacks tools for common specific operations like packaging or transmuxing, which might be expected in this domain.
The toolset covers basic Shaka Packager interactions but has notable gaps. It provides analysis, documentation, options, and custom execution, but lacks dedicated tools for standard packaging workflows (e.g., create_manifest, package_video) that would complete the surface for media processing tasks.
MCP server for Wan AI video generation
MCP server for Google Veo AI video generation
MCP server for Grok Imagine AI video generation
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
