⚠️ 実験段階の免責事項
このプロジェクトはまだ初期アルファ段階であり、非常に実験的なものです。本番環境での使用は推奨されません。また、かなり乱雑になる可能性があります。
現在の制限:
一貫性のない行動に遭遇する可能性がある
高度な機能（パッケージ化、変換など）は現在も開発中です
Dockerとホスト環境間のパス変換には手動設定が必要な場合があります
頻繁に重大な変更が発生し、不安定になる可能性がある
プロジェクトの改善に役立てるため、発生した問題を報告してください。
ビデオのトランスコーディング、パッケージ化、分析のためにShaka Packagerと Claude AI アプリケーションを統合する MCP (Model Context Protocol) サーバー。
このサーバーはファイルシステム MCP サーバーと連携して動作し、Claude Desktop がコンピューター上のビデオ ファイルにアクセスして処理できるようにすることで、Claude をメディア処理タスクの強力なアシスタントに変えます。
ビデオ分析: ビデオファイルを分析して、詳細なストリーム情報、コーデック、ビットレートなどを抽出します。
メディアパッケージング: VODとライブストリーミングをサポートするHLSおよびDASH形式でのストリーミング用にビデオを変換します
詳細オプション:
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 はビデオ ファイルのアップロードを直接サポートしていないため、2 つのサーバーを使用するアプローチを使用します。
コンピュータ上のビデオファイルにアクセスするための簡素化されたファイルシステムMCPサーバー
Shaka Packager MCPサーバーはこれらのビデオを分析して処理します
公式の MCP ファイルシステム サーバーを使用して、Claude がビデオ ファイルにアクセスできるようにします。
Docker を使用して公式ファイルシステム サーバーをインストールします。
docker pull mcp/filesystemあるいは、ファイルシステムMCPサーバーリポジトリの指示に従ってソースからビルドすることもできます。
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 を再起動します。
まず、簡略化されたファイルシステム サーバーを使用してビデオ ファイルを参照します。
クロードに「ビデオディレクトリ内のファイルを一覧表示する」ように依頼します。
分析または処理したいビデオファイルに移動します
ビデオ ファイルが見つかったら、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
Claude Desktop で Filesystem MCP サーバーと Shaka Packager MCP サーバーの両方が実行されたら、次の操作を行います。
ビデオファイルにアクセスします:
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 コード副操縦士を自由に使用してください。著者も使用しています。
問題が発生した場合や質問がある場合は、次の手順に従ってください。
このREADMEのトラブルシューティングセクションを確認してください
Claude内で対話型ヘルプを表示するには、 get_shaka_documentationツールを使用します。
GitHubで問題を開く
強力なビデオ処理機能を備えたShaka Packager
通信フレームワークのモデルコンテキストプロトコル（MCP）
AIアシスタント機能のクロード
ClaudeとMCP標準の開発に貢献したAnthropic
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.
