Skip to main content
Glama
enesjakozh
coderjun

Shaka Packager MCP Server

by coderjun
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Shaka Packager MCP Server

License: MIT Python Version Status: Alpha

Status: alpha. Analysis is the most exercised path. Treat this as a working prototype rather than a production dependency.

Known limitations:

  • Packaging and conversion are still under active development

  • Path translation between Docker and host environments may need manual configuration

  • Interfaces may change between releases

Issue reports are welcome and genuinely useful.

An MCP (Model Context Protocol) server that integrates Shaka Packager with Claude AI applications for video transcoding, packaging, and analysis.

This server works with the Filesystem MCP Server to enable Claude Desktop to access and process video files on your computer, turning Claude into a powerful assistant for media processing tasks.

Features

  • Video Analysis: Analyze video files to extract detailed stream information, codecs, bitrates, and more

  • Media Packaging: Convert videos for streaming in HLS and DASH formats with support for VOD and live streaming

  • Advanced Options:

    • Apply DRM encryption (Widevine, PlayReady, FairPlay)

    • Configure ad insertion markers

    • Convert between formats (MP4, TS, etc.)

  • Intelligent Path Handling: Automatically translates paths between Docker and host environments

  • Robust Error Management: Provides meaningful error analysis with suggestions for resolution

  • Command Assistance: Helps correctly format Shaka Packager commands for optimal results

  • Interactive Documentation: Built-in help and examples to guide users through complex operations

  • Detailed Outputs: Comprehensive summaries and execution details for all operations

Related MCP server: encoding-devops

Prerequisites

Installation

From source

The package is not published to PyPI yet, so install from a clone.

git clone https://github.com/coderjun/shaka-packager-mcp-server.git
cd shaka-packager-mcp-server
pip install -e .

Or with uv:

git clone https://github.com/coderjun/shaka-packager-mcp-server.git
cd shaka-packager-mcp-server
uv pip install -e .

Claude Desktop Integration

Since Claude Desktop doesn't directly support uploading video files, we'll use a two-server approach:

  1. A simplified filesystem MCP server to access video files on your computer

  2. The Shaka Packager MCP server to analyze and process those videos

Step 1: Set Up the MCP Filesystem Server

Use the official MCP filesystem server to allow Claude to access your video files:

  1. Install the official filesystem server with Docker:

    docker pull mcp/filesystem

  2. Alternatively, you can build it from source following the instructions in the Filesystem MCP Server repository

Step 2: Find the Configuration File

Locate your Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

If the file doesn't exist, create it.

Step 3: Add Both Servers to the Configuration

Add the following configuration, making sure to use absolute paths:

{
  "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"
      }
    }
  }
}

Replace:

  • /PATH/TO/VIDEOS/DIRECTORY with the path to the directory containing your video files

  • /ABSOLUTE/PATH/TO/uv with the full path to your uv executable

  • /ABSOLUTE/PATH/TO/shaka_packager_mcp.py with the full path to the script file

  • /PATH/TO/PACKAGER with the full path to your Shaka Packager executable

For example:

{
  "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-server/shaka_packager_mcp.py"
      ],
      "env": {
        "VIDEO_PATH": "/Users/username/Videos",
        "SHAKA_PACKAGER_PATH": "/Users/username/.shaka/packager"
      }
    }
  }
}

Step 4: Restart Claude Desktop

After editing the configuration file, restart Claude Desktop to apply the changes.

How to Use the Two-Server Approach

  1. First, browse your video files using the simplified filesystem server:

    • Ask Claude to "List the files in my video directory"

    • Navigate to the video file you want to analyze or process

  2. Once you've found your video file, use its path with the Shaka Packager tools:

    • For analysis: "Please analyze this video: /Users/username/Videos/example.mp4"

    • For processing: "Please package this video for HLS: /Users/username/Videos/example.mp4"

Troubleshooting

If you encounter any issues:

  1. Make sure both servers are properly configured with absolute paths

  2. Verify that Shaka Packager is installed and accessible

  3. Ensure the directory specified for the filesystem server exists and contains videos

  4. Check Claude Desktop logs for errors at:

    • macOS: ~/Library/Logs/Claude/mcp*.log

    • Windows: %APPDATA%\Claude\logs\mcp*.log

Usage

Once both the Filesystem MCP server and the Shaka Packager MCP server are running in Claude Desktop:

  1. Access your video files:

    Please show me the files in my Videos directory

  2. Navigate to your video file:

    Please show me the files in the Movies subdirectory

  3. Copy the file:// URI path of the video you want to process

  4. Use the Shaka Packager tools with the file path:

    Please analyze this video: file:///Users/username/Videos/my_video.mp4

    or

    Please package this video for HLS and DASH streaming: file:///Users/username/Videos/my_video.mp4

  5. The server will execute the appropriate Shaka Packager command and provide a detailed summary of the results

You can also use direct file paths if you know the exact location of your video files:

Please analyze this video: /Users/username/Videos/my_video.mp4

Tools

The server provides these tools:

  1. analyze_video: Examines a video file and provides detailed stream information with intelligent error handling

  2. run_shaka_packager: Executes any Shaka Packager command with custom arguments and proper path handling

  3. get_shaka_options: Retrieves available command options and version information

  4. get_shaka_documentation: Provides comprehensive documentation and examples for using Shaka Packager

Prompts

The server includes these prompt templates:

  • MP4 to TS conversion

  • VOD packaging in HLS and DASH

  • Live streaming packaging

  • Content encryption

  • Ad insertion preparation

  • Video analysis

  • Command format reminder

  • Error interpretation guidance

Configuration

The server can be configured using environment variables:

  • SHAKA_PACKAGER_PATH: Path to the Shaka Packager executable (highly recommended for Claude Desktop)

  • VIDEO_PATH: Path to your local video directory (used for translating paths between Docker and host)

  • DOCKER_PATH: Docker container mount path (default: "/projects/video-drop")

  • TEMP_DIR: Custom temporary directory for file uploads

  • LOG_LEVEL: Logging level (DEBUG, INFO, WARNING, ERROR, CRITICAL)

  • COMMAND_TIMEOUT: Timeout in seconds for Shaka Packager commands (default: 300)

You can set these in:

  1. Your Claude Desktop configuration file (preferred for SHAKA_PACKAGER_PATH and VIDEO_PATH)

  2. Your environment variables

  3. A .env file in the same directory as the script

Example .env file:

SHAKA_PACKAGER_PATH=/usr/local/bin/packager
VIDEO_PATH=/Users/yourusername/Videos
LOG_LEVEL=DEBUG

Development

Setting up a development environment

# Clone the repository
git clone https://github.com/coderjun/shaka-packager-mcp-server.git
cd shaka-packager-mcp-server

# Install development dependencies with pip
pip install -e ".[dev]"

# Or with uv
uv pip install -e ".[dev]"

Running tests

pytest

Code formatting

black .
isort .

Understanding the Code Structure

The main components of the Shaka Packager MCP server are:

  • shaka_packager_mcp.py: Main server implementation with MCP tools and prompts

  • tests/: Test suite for verifying functionality

This server is designed to work with the official MCP filesystem server for accessing video files.

Key Features in the Implementation

  • Robust path handling: Automatically translates paths between Docker and host environments

  • Smart error handling: Provides meaningful error messages and suggestions

  • Command syntax assistance: Helps correctly format Shaka Packager commands

  • Documentation integration: Provides comprehensive documentation and examples

License

This project is licensed under the MIT License - see the LICENSE file for details.

Getting Help

Feel free to use an AI code copilot, the author does.

If you encounter any issues or have questions:

  1. Check the troubleshooting section in this README

  2. Review the Shaka Packager documentation

  3. Use the get_shaka_documentation tool for interactive help within Claude

  4. Open an issue on GitHub

Acknowledgements

Available Tools

4 tools
analyze_videoB
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.
ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/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 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_shaka_documentationB

Get comprehensive Shaka Packager documentation, including command structure and examples.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.3/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/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 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_shaka_optionsB

Get the available options and version information for Shaka Packager.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness3/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines2/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 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_shaka_packagerC
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.
ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
command_argsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines2/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 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updates
    • First observedanalyze_video
    • First observedget_shaka_documentation
    • First observedget_shaka_options
    • First observedrun_shaka_packager
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

B3.4/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness3/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches