The ZapCap MCP Server provides tools for automated video processing through the ZapCap API with natural language interaction and type-safe validation.
Upload videos by file path or URL
Retrieve available processing templates from ZapCap
Create customized video processing tasks with extensive options:
Template selection and auto-approval settings
Language and B-roll configuration (enablement and percentage)
Subtitle features: emoji usage, animation, keyword emphasis, punctuation, and word count
Subtitle styling: position, font (uppercase, size, weight, color, shadow), stroke style/color, and highlight colors
Monitor task progress using video and task IDs
Automate API key management with environment-based configuration
Use natural language commands instead of complex API requests
Benefit from type safety and validation through Pydantic integration
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zapcap-mcp-server upload this video and create a task with the trending template"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
NOTE: This is an unofficial implementation of MCP Server for ZapCap.
An MCP (Model Context Protocol) server that provides tools for uploading videos, creating processing tasks, and monitoring their progress through the ZapCap API.
uv
ZapCap API key
You can install uv from here: https://docs.astral.sh/uv/
You can get api key from ZapCap API after registation at https://zapcap.ai/ in their platform here: https://platform.zapcap.ai/dashboard/api-key
Related MCP server: ElevenLabs MCP Server
Add to your MCP client mcp.json configuration (e.g., Claude Desktop, Cursor and etc.):
{
"mcpServers": {
"zapcap": {
"command": "uvx",
"args": ["zapcap-mcp-server"],
"env": {
"ZAPCAP_API_KEY": "your_api_key_here"
}
}
}
}uv tool install zapcap-mcp-serverYou can also run the MCP server in a Docker container using the pre-built image from Docker Hub:
{
"mcpServers": {
"zapcap": {
"command": "docker",
"args": [
"run",
"--rm",
"--init",
"-i",
"--net=host",
"-v", "/home/$USER:/host/home/$USER",
"-e", "ZAPCAP_API_KEY=your_api_key_here",
"bogdan01m/zapcap-mcp-server:latest"
],
"env": {
"DOCKER_CLI_HINTS": "false"
}
}
}
}Set your ZapCap API key as an environment variable:
export ZAPCAP_API_KEY="your_api_key_here"How to use:
Results:
The server provides the following tools:
Upload a video file to ZapCap.
Parameters:
file_path: Path to the video file
Upload a video by URL to ZapCap.
Parameters:
url: URL to the video file
Get available processing templates from ZapCap.
Create a video processing task with full customization options.
Parameters:
video_id: Video ID from upload
template_id: Template ID
auto_approve: Auto approve the task (default: true)
language: Language code (default: "en")
enable_broll: Enable B-roll (default: false)
broll_percent: B-roll percentage 0-100 (default: 30)
Subtitle options:
emoji: Enable emoji in subtitles (default: true)
emoji_animation: Enable emoji animation (default: true)
emphasize_keywords: Emphasize keywords (default: true)
animation: Enable subtitle animation (default: true)
punctuation: Include punctuation (default: true)
display_words: Number of words to display (default: 1)
Style options:
position_top: Subtitle position from top (default: 60)
font_uppercase: Use uppercase font (default: true)
font_size: Font size (default: 30)
font_weight: Font weight (default: 900)
font_color: Font color (default: "#ffffff")
font_shadow: Font shadow s/m/l (default: "l")
stroke: Stroke style (default: "s")
stroke_color: Stroke color (default: "#000000")
highlight_color_1: First highlight color (default: "#2bf82a")
highlight_color_2: Second highlight color (default: "#fdfa14")
highlight_color_3: Third highlight color (default: "#f01916")
Monitor task progress.
Parameters:
video_id: Video ID
task_id: Task ID
Unlike using curl or direct API calls where you need to manually include your API key in every request:
# Traditional curl approach - token needed every time
curl -X POST "https://api.zapcap.ai/upload" \
-H "Authorization: Bearer your_token_here" \
-F "file=@video.mp4"With this MCP server, your API key is configured once in the environment and automatically used for all operations:
{
"env": {
"ZAPCAP_API_KEY": "your_api_key_here"
}
}Instead of constructing complex API requests with parameters, you can describe what you want:
Traditional API:
curl -X POST "https://api.zapcap.ai/tasks" \
-H "Authorization: Bearer token" \
-d '{
"video_id": "abc123",
"template_id": "viral",
"font_size": 30,
"highlight_color_1": "#00ff00",
"enable_broll": true,
"broll_percent": 40
}'MCP Server:
"Add green highlighted subtitles with 40% B-roll using viral template"Pydantic Integration: All parameters are validated automatically with type checking
We're planning to add basic testing capabilities:
API Integration Tests: Verify that ZapCap API calls work correctly
MCP Tool Tests: Ensure all MCP tools respond properly to requests
Named configurations: Save frequently used parameter combinations ("my_brand", "youtube_style")
Template enhancement: Override template defaults with consistent brand colors/fonts
MIT licence
Create video processing task with full customization options
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| 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 'Create' implies a write operation but lacks details on permissions, side effects, rate limits, or what 'full customization options' entails beyond the schema. This is insufficient for a mutation tool with complex parameters.
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 is front-loaded with the core action. There is no wasted verbiage, making it highly concise and well-structured for quick comprehension.
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 complexity (many parameters with 0% schema coverage, no annotations, but an output schema exists), the description is inadequate. It doesn't explain the customization options, prerequisites, or behavioral traits, leaving significant gaps despite the output schema handling return values.
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?
Schema description coverage is 0%, meaning all parameters are undocumented in the schema. The description only mentions 'full customization options' without explaining any parameters, failing to compensate for the lack of schema documentation and leaving the agent with no semantic understanding of inputs.
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 ('Create') and resource ('video processing task'), making the purpose evident. However, it doesn't differentiate from sibling tools like 'zapcap_mcp_upload_video' or 'zapcap_mcp_monitor_task', which handle different aspects of the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an uploaded video or template), dependencies on sibling tools, or scenarios where it's appropriate, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available templates from ZapCap
| 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 full burden for behavioral disclosure. The description only states what the tool does ('Get available templates') without explaining what 'templates' are, how they're returned, whether this is a read-only operation, or any rate limits or authentication requirements. For a tool with zero annotation coverage, this is insufficient behavioral context.
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 states the core purpose without unnecessary words. It's appropriately sized for a simple tool with no parameters. However, it could be slightly more structured by front-loading key information about what 'templates' represent.
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 no parameters, an output schema exists, and annotations are absent, the description is minimally complete. It identifies the resource ('templates') but doesn't explain what templates are or their format. The output schema will handle return values, but the description could better contextualize what 'available templates' means in this system.
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. The description doesn't need to explain parameters since none exist. The baseline for 0 parameters is 4, as the description appropriately doesn't waste space on non-existent 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 states the tool's purpose as 'Get available templates from ZapCap', which is a clear verb+resource combination. However, it doesn't differentiate this tool from its siblings (create_task, monitor_task, upload_video, upload_video_by_url), which all involve different operations. The purpose is understandable but lacks sibling context.
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 prerequisites, timing considerations, or relationships to sibling tools. Without any usage context, the agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Monitor task progress
| Name | Required | Description | Default |
|---|---|---|---|
| request | 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 full burden for behavioral disclosure. 'Monitor task progress' gives no indication of whether this is a read-only operation, how it handles errors, what the monitoring interval might be, or what the output looks like. For a tool with no annotation coverage, this is a significant gap in behavioral context.
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 extremely concise at just three words, with no wasted language. It's front-loaded with the core purpose, though this brevity comes at the cost of completeness. Every word earns its place by conveying the essential action.
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 apparent complexity (monitoring implies ongoing status checks), lack of annotations, and 0% schema description coverage, the description is incomplete. While an output schema exists (which helps), the description doesn't provide enough context about how monitoring works, what 'progress' means, or how this tool fits into the workflow with siblings like create_task.
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?
Schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters beyond what's implied by the tool name. It doesn't explain what 'video_id' or 'task_id' represent, their format, or how they relate to monitoring. This fails to compensate for the schema's lack of descriptions.
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 'Monitor task progress' states a general purpose but lacks specificity. It mentions the verb 'monitor' and resource 'task progress', but doesn't distinguish this tool from potential siblings like 'zapcap_mcp_create_task' or clarify what type of monitoring it performs. It's better than a tautology but remains vague about what monitoring entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a task_id from create_task), exclusions, or relationships with sibling tools like 'zapcap_mcp_create_task'. This leaves the agent with no context for appropriate tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload video file to ZapCap
| Name | Required | Description | Default |
|---|---|---|---|
| request | 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 full burden. It states 'Upload video file' which implies a write/mutation operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, file size restrictions, or what happens after upload (e.g., processing, storage location). The description is minimal and lacks important operational context for a mutation tool.
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 extremely concise at just 5 words. It's front-loaded with the core action and resource. There's zero wasted language or redundancy. For such a simple statement, it's maximally efficient in word count.
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 this is a mutation tool with no annotations, 0% schema description coverage, but with an output schema, the description is inadequate. It doesn't explain what the upload accomplishes, what happens after upload, file requirements, or how this differs from the URL-based sibling. The output schema existence means return values are documented elsewhere, but the description should still provide more operational context.
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?
Schema description coverage is 0%, so the description must compensate. The description doesn't mention any parameters at all. While there's only one parameter ('file_path'), the description provides no information about it - no format expectations, path requirements, or what constitutes a valid video file. The schema alone documents the parameter, but with 0% coverage, the description adds no value.
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 states the verb ('Upload') and resource ('video file to ZapCap'), which gives a basic understanding of what the tool does. However, it's vague about the specific action - it doesn't clarify if this uploads for processing, storage, or another purpose. It doesn't distinguish from its sibling 'zapcap_mcp_upload_video_by_url', which handles URL-based uploads versus this file-based approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description doesn't mention the sibling tool 'zapcap_mcp_upload_video_by_url' for URL uploads or other tools like 'zapcap_mcp_create_task' that might be related. No context is provided about prerequisites, file format requirements, or when this upload method is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload video by URL to ZapCap
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
| 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 but fails to do so. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, if there are rate limits, or what the expected outcome is (e.g., success/failure response, video processing). For a mutation tool ('Upload'), this lack of transparency is a critical gap.
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 with zero wasted words, front-loading the core action ('Upload video by URL'). It's appropriately sized for a simple tool, making it easy to parse quickly without unnecessary elaboration.
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 (a mutation operation with no annotations) and the presence of an output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, authentication needs, or error handling, which are crucial for safe invocation. While the output schema may cover return values, the description fails to provide enough context for the agent to understand the tool's full implications.
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 implies a 'url' parameter but doesn't add any semantic details beyond what the input schema provides. With 0% schema description coverage, the schema only documents the parameter name and type, and the description doesn't compensate by explaining URL formats, supported protocols, or validation rules. However, since there's only one parameter, the baseline is 4, but the lack of added value reduces it to 3.
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 'Upload video by URL to ZapCap' clearly states the verb ('Upload'), resource ('video'), and mechanism ('by URL'), making the purpose immediately understandable. It distinguishes from the sibling 'zapcap_mcp_upload_video' by specifying the URL-based approach, though it doesn't explicitly contrast them. However, it lacks specificity about what ZapCap is or what happens after upload, keeping it from 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 like 'zapcap_mcp_upload_video' or other siblings. It doesn't mention prerequisites, constraints, or typical scenarios for URL-based uploads, leaving the agent to infer usage from the name alone. This minimal guidance is insufficient for informed tool selection.
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. Dates show when Glama detected each change.
zapcap_mcp_create_taskzapcap_mcp_get_templateszapcap_mcp_monitor_taskzapcap_mcp_upload_videozapcap_mcp_upload_video_by_urlEach tool has a clearly distinct purpose: create_task for task creation, get_templates for template retrieval, monitor_task for progress tracking, and two upload tools differentiated by source (file vs. URL). No ambiguity exists between these operations.
All tools follow a consistent verb_noun pattern with the prefix 'zapcap_mcp_' (e.g., create_task, get_templates, monitor_task, upload_video, upload_video_by_url). This uniformity makes the set predictable and easy to navigate.
With 5 tools, this server is well-scoped for video processing tasks, covering essential operations like uploading, creating, monitoring, and template retrieval. Each tool earns its place without bloat or thin coverage.
The toolset covers core workflows (upload, create, monitor, templates) effectively, but lacks explicit update or delete operations for tasks or videos. Agents can likely work around this, but the absence is a minor gap in lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for the FFmpeg Micro video transcoding API — create, monitor, download transcodes.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
Hosted MCP tools for FFmpeg-style video and audio processing through FFMPEG API.
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bogdanminko/zapcap-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
