⚠️ DESCARGO DE RESPONSABILIDAD POR ESTADO EXPERIMENTAL
Este proyecto se encuentra en fase alfa inicial y es altamente experimental. No se recomienda su uso en producción. Además, ¡probablemente sea un desastre!
Limitaciones actuales:
Es posible que te encuentres con un comportamiento inconsistente
Las funciones avanzadas (empaquetado, conversión, etc.) aún están en desarrollo activo.
La traducción de rutas entre Docker y los entornos del host puede requerir una configuración manual
Espere frecuentes cambios de freno y posible inestabilidad.
Informe cualquier problema que encuentre para ayudarnos a mejorar el proyecto.
Un servidor MCP (Protocolo de contexto de modelo) que integra Shaka Packager con aplicaciones de Claude AI para transcodificación, empaquetado y análisis de video.
Este servidor funciona con el servidor MCP del sistema de archivos para permitir que Claude Desktop acceda y procese archivos de video en su computadora, convirtiendo a Claude en un poderoso asistente para tareas de procesamiento de medios.
Análisis de video : analice archivos de video para extraer información detallada de transmisión, códecs, tasas de bits y más
Empaquetado de medios : Convierta videos para transmisión en formatos HLS y DASH con soporte para VOD y transmisión en vivo
Opciones avanzadas :
Aplicar cifrado DRM (Widevine, PlayReady, FairPlay)
Configurar marcadores de inserción de anuncios
Convertir entre formatos (MP4, TS, etc.)
Manejo inteligente de rutas : traduce automáticamente rutas entre Docker y entornos de host
Gestión robusta de errores : proporciona un análisis de errores significativo con sugerencias para su resolución.
Asistencia de comandos : ayuda a formatear correctamente los comandos de Shaka Packager para obtener resultados óptimos
Documentación interactiva : ayuda y ejemplos integrados para guiar a los usuarios a través de operaciones complejas
Resultados detallados : resúmenes completos y detalles de ejecución de todas las operaciones
Related MCP server: encoding-devops
Python 3.10 o superior
Shaka Packager instalado y disponible en su PATH
O construya desde la fuente siguiendo estas instrucciones
Un cliente compatible con MCP (como Claude Desktop)
Instalar el paquete con pip:
pip install shaka-packager-mcpO con uv:
uv pip install shaka-packager-mcpgit clone https://github.com/coderjun/shaka-packager-mcp.git
cd shaka-packager-mcp
pip install -e .O con uv:
git clone https://github.com/coderjun/shaka-packager-mcp.git
cd shaka-packager-mcp
uv pip install -e .Dado que Claude Desktop no admite directamente la carga de archivos de video, utilizaremos un enfoque de dos servidores:
Un servidor MCP de sistema de archivos simplificado para acceder a archivos de video en su computadora
El servidor MCP de Shaka Packager para analizar y procesar esos vídeos
Utilice el servidor de sistema de archivos MCP oficial para permitir que Claude acceda a sus archivos de video:
Instale el servidor del sistema de archivos oficial con Docker:
docker pull mcp/filesystemAlternativamente, puede compilarlo desde la fuente siguiendo las instrucciones en el repositorio del servidor MCP del sistema de archivos
Localice el archivo de configuración de Claude Desktop:
macOS : ~/Library/Application Support/Claude/claude_desktop_config.json
Ventanas : %APPDATA%\Claude\claude_desktop_config.json
Si el archivo no existe, créelo.
Agregue la siguiente configuración, asegurándose de utilizar rutas absolutas:
{
"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"
}
}
}
}Reemplazar:
/PATH/TO/VIDEOS/DIRECTORY con la ruta al directorio que contiene sus archivos de vídeo
/ABSOLUTE/PATH/TO/uv con la ruta completa a su ejecutable uv
/ABSOLUTE/PATH/TO/shaka_packager_mcp.py con la ruta completa al archivo de script
/PATH/TO/PACKAGER con la ruta completa a su ejecutable Shaka Packager
Por ejemplo:
{
"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"
}
}
}
}Después de editar el archivo de configuración, reinicie Claude Desktop para aplicar los cambios.
Primero, explore sus archivos de video utilizando el servidor de sistema de archivos simplificado:
Pídele a Claude que "enumere los archivos en mi directorio de videos"
Navegue hasta el archivo de vídeo que desea analizar o procesar
Una vez que haya encontrado su archivo de video, use su ruta con las herramientas de Shaka Packager:
Para análisis: "Por favor, analice este vídeo: /Usuarios/nombreusuario/Videos/ejemplo.mp4"
Para procesar: "Por favor, empaquete este video para HLS: /Usuarios/nombreusuario/Videos/ejemplo.mp4"
Si encuentra algún problema:
Asegúrese de que ambos servidores estén configurados correctamente con rutas absolutas
Verifique que Shaka Packager esté instalado y accesible
Asegúrese de que el directorio especificado para el servidor del sistema de archivos exista y contenga videos
Consulte los registros de Claude Desktop para detectar errores en:
macOS: ~/Library/Logs/Claude/mcp*.log
Ventanas: %APPDATA%\Claude\logs\mcp*.log
Una vez que el servidor MCP del sistema de archivos y el servidor MCP de Shaka Packager se estén ejecutando en Claude Desktop:
Accede a tus archivos de vídeo :
Please show me the files in my Videos directoryNavega hasta tu archivo de vídeo :
Please show me the files in the Movies subdirectoryCopia la ruta URI del archivo:// del vídeo que deseas procesar
Utilice las herramientas de Shaka Packager con la ruta del archivo :
Please analyze this video: file:///Users/username/Videos/my_video.mp4o
Please package this video for HLS and DASH streaming: file:///Users/username/Videos/my_video.mp4El servidor ejecutará el comando Shaka Packager apropiado y proporcionará un resumen detallado de los resultados.
También puedes utilizar rutas de archivos directas si conoces la ubicación exacta de tus archivos de vídeo:
Please analyze this video: /Users/username/Videos/my_video.mp4El servidor proporciona estas herramientas:
Analyze_video : examina un archivo de video y proporciona información detallada de la transmisión con manejo inteligente de errores.
run_shaka_packager : ejecuta cualquier comando de Shaka Packager con argumentos personalizados y manejo de ruta adecuado
get_shaka_options : recupera las opciones de comando disponibles y la información de la versión
get_shaka_documentation : Proporciona documentación completa y ejemplos para usar Shaka Packager
El servidor incluye estas plantillas de aviso:
Conversión de MP4 a TS
Empaquetado de VOD en HLS y DASH
Paquete de transmisión en vivo
Cifrado de contenido
Preparación para la inserción de anuncios
Análisis de vídeo
Recordatorio de formato de comando
Guía de interpretación de errores
El servidor se puede configurar mediante variables de entorno:
SHAKA_PACKAGER_PATH : Ruta al ejecutable de Shaka Packager (muy recomendado para Claude Desktop)
VIDEO_PATH : Ruta a su directorio de video local (se utiliza para traducir rutas entre Docker y el host)
DOCKER_PATH : Ruta de montaje del contenedor Docker (predeterminado: "/projects/video-drop")
TEMP_DIR : Directorio temporal personalizado para cargas de archivos
LOG_LEVEL : Nivel de registro (DEBUG, INFO, WARNING, ERROR, CRITICAL)
COMMAND_TIMEOUT : Tiempo de espera en segundos para los comandos de Shaka Packager (valor predeterminado: 300)
Puedes configurarlos en:
Su archivo de configuración de Claude Desktop (preferible para SHAKA_PACKAGER_PATH y VIDEO_PATH )
Sus variables de entorno
Un archivo .env en el mismo directorio que el script
Ejemplo de archivo .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 .Los componentes principales del servidor MCP de Shaka Packager son:
shaka_packager_mcp.py : Implementación del servidor principal con herramientas y avisos MCP
tests/ : Conjunto de pruebas para verificar la funcionalidad
Este servidor está diseñado para funcionar con el servidor del sistema de archivos MCP oficial para acceder a archivos de vídeo.
Manejo robusto de rutas : traduce automáticamente rutas entre Docker y entornos de host
Manejo inteligente de errores : proporciona mensajes de error y sugerencias significativas
Asistencia de sintaxis de comandos : ayuda a formatear correctamente los comandos de Shaka Packager
Integración de documentación : proporciona documentación completa y ejemplos
Este proyecto está licenciado bajo la licencia MIT: consulte el archivo de LICENCIA para obtener más detalles.
Siéntete libre de utilizar un copiloto de código de IA, el autor lo hace.
Si encuentra algún problema o tiene preguntas:
Consulte la sección de solución de problemas en este README
Revise la documentación de Shaka Packager
Utilice la herramienta get_shaka_documentation para obtener ayuda interactiva dentro de Claude
Abrir un problema en GitHub
Shaka Packager para las potentes capacidades de procesamiento de video
Protocolo de Contexto Modelo (MCP) para el marco de comunicación
Claude por las capacidades del asistente de IA
Antrópico para el desarrollo de Claude y el estándar 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.
