Provides tools for video transcoding, cutting, frame extraction, and concatenation using FFmpeg.
Generates publish-ready packages for TikTok.
Generates publish-ready packages for YouTube.
Generates publish-ready packages for YouTube Shorts.
Click on "Deploy 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., "@comfy-ae-video-factory-mcp create a video from image.jpg and prepare for TikTok"
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.
An MCP Server for AI short video automation pipelines: connecting ComfyUI image-to-image/image-to-video, FFmpeg post-processing, After Effects template packaging, review, and multi-platform publishing preparation.
Design Goal: Enable Cursor / Claude Desktop / ChatGPT MCP clients to call these tools to automatically complete the "Generate → Package → Review → Export → Publishing Package" workflow.
Invoke local or cloud ComfyUI workflows
Query ComfyUI task history
Analyze videos using FFprobe
Transcode, crop, extract frames, and concatenate using FFmpeg
Generate JSX scripts for automatic After Effects asset replacement
Invoke aerender to render After Effects templates
Create standardized video production task manifests
Generate publishing package configurations for Douyin / Xiaohongshu / Bilibili / YouTube Shorts / TikTok
Provide basic content review placeholder interfaces for future integration with third-party review APIs
Related MCP server: Media-infrastructure
npm install
npm run buildnpm start{
"mcpServers": {
"comfy-ae-video-factory": {
"command": "node",
"args": ["/absolute/path/comfy-ae-video-factory-mcp/dist/index.js"],
"env": {
"COMFY_LOCAL_URL": "http://127.0.0.1:8188",
"VIDEO_FACTORY_ROOT": "/absolute/path/workspace",
"FFMPEG_BIN": "ffmpeg",
"FFPROBE_BIN": "ffprobe",
"AERENDER_BIN": "/Applications/Adobe After Effects 2025/aerender"
}
}
}
}Windows Example:
{
"AERENDER_BIN": "C:\\Program Files\\Adobe\\Adobe After Effects 2025\\Support Files\\aerender.exe"
}pipeline_create_job to create production task directory and manifest
comfy_submit_workflow to submit ComfyUI image-to-video workflow
comfy_get_history to query results
media_probe to check video specifications
ffmpeg_transcode to unify aspect ratio, bitrate, and frame rate
ae_generate_jsx to generate AE template replacement scripts
ae_render_template to invoke aerender and output the final packaged video
review_video_package for review placeholder
platform_prepare_package to generate publishing packages for various platforms
It is recommended to pre-create these placeholder layers in your AE project:
{{MAIN_VIDEO}}
{{TITLE}}
{{SUBTITLE}}
{{LOGO}}
{{CTA}}
Then use the JSX generated by this project to replace assets and text, and output via aerender.
This MCP Server executes local commands, so the following restrictions are applied by default:
All input and output files must be within the VIDEO_FACTORY_ROOT directory
FFmpeg parameters are encapsulated via a whitelist rather than directly exposing arbitrary shell commands
AE rendering supports dryRun; it is recommended to test commands first
git init
git add .
git commit -m "init comfy ae video factory mcp"
git branch -M main
git remote add origin git@github.com:YOUR_NAME/comfy-ae-video-factory-mcp.git
git push -u origin mainThe official MCP TypeScript SDK supports creating servers, registering tools, and connecting to MCP clients via stdio or Streamable HTTP. This implementation uses stdio, which is suitable for local automation integration.
Generate an ExtendScript JSX file that opens an AE template and replaces footage/text layers.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | AEP path under VIDEO_FACTORY_ROOT | |
| outputJsxPath | Yes | JSX output path under VIDEO_FACTORY_ROOT | |
| mainCompName | No | MAIN | |
| replacements | No | Map: AE layer name -> asset path under VIDEO_FACTORY_ROOT | |
| textLayers | No | Map: AE text layer name -> new text | |
| saveAsPath | No | Optional new AEP path under VIDEO_FACTORY_ROOT |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool generates a JSX file (a side effect) but does not mention file overwriting behavior, required permissions, or any destructive actions. The description is adequate but lacks depth.
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?
Single sentence that is front-loaded with the core action. No wasted words, efficient and clear.
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?
Despite 6 parameters including nested objects and no output schema, the description is very minimal. It omits important context such as that the AEP file must exist, that the JSX is generated on disk, and any return behavior. The tool's complexity demands more detail.
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?
Input schema covers 83% of parameters with descriptions. The description adds minimal value beyond the schema; it mentions replacing footage/text layers which maps to the replacements and textLayers parameters. Given high schema coverage, a baseline of 3 is appropriate.
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 generates an ExtendScript JSX file that opens an After Effects template and replaces footage/text layers. This is specific and distinguishes it from siblings like ae_render_template.
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 on when to use this tool vs alternatives like ae_render_template. The description does not mention prerequisites, exclusions, or preferred contexts. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke aerender to render an AE comp. Use dryRun first to verify command.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | ||
| compName | Yes | ||
| outputPath | Yes | ||
| aerenderBin | No | ||
| dryRun | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions dryRun and does not describe side effects (e.g., disk writes, external command execution), permission needs, or error 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 very concise, but it sacrifices necessary detail. The instruction about dryRun is front-loaded, but overall the brevity leads to under-specification.
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?
For a tool with 5 parameters, an external dependency, and no output schema, the description is grossly incomplete. It fails to cover prerequisites, return values, or potential errors.
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%, yet the description only addresses one parameter (dryRun) indirectly. projectPath, compName, outputPath, and aerenderBin are left unexplained.
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 'Invoke aerender to render an AE comp', which gives a specific verb-resource-action combination. It distinguishes from sibling ae_generate_jsx (which generates scripts) by focusing on rendering.
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?
It provides the directive 'Use dryRun first to verify command,' which is a clear usage hint. However, it lacks comparison to sibling tools or guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read ComfyUI generation history by prompt id.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | local | |
| promptId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Read' implying non-destructive behavior, but no annotations are provided. It lacks details about authentication, rate limits, or what the returned history contains. As a simple read operation, more context could be helpful.
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 sentence, six words, front-loaded with the verb and resource. It is very concise but may sacrifice necessary details. Every word earns its place, but it could be slightly longer for 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 simplicity (2 params, no output schema), the description is incomplete. It does not clarify the 'target' parameter or the format/content of the returned history. The agent would need to infer these details.
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 input schema has two parameters, but the description only addresses 'promptId' implicitly. The 'target' parameter (enum local/cloud) is not explained. With 0% schema description coverage, the description should compensate but does not add semantic 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 clearly states the verb 'Read' and resource 'ComfyUI generation history', and specifies the key parameter 'by prompt id'. It distinguishes from siblings like comfy_submit_workflow or ffmpeg_transcode, which perform different actions.
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. There is no mention of when not to use it or any contextual hints about its place among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a ComfyUI workflow JSON to local or cloud ComfyUI /prompt endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | local | |
| workflowPath | Yes | Path under VIDEO_FACTORY_ROOT to ComfyUI workflow JSON | |
| clientId | No | mcp-video-factory | |
| extraData | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only mentions submission to an endpoint without explaining if it is asynchronous, what the response looks like, side effects, or required permissions. This is insufficient for an agent to understand 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 sentence, which is concise but lacks necessary detail. It is front-loaded with the action, but does not earn its place fully due to missing critical information. A longer description with more context would be more valuable.
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 4 parameters (including a nested object) and no output schema, the description is far from complete. It does not explain return values, error handling, or operational behavior, leaving significant gaps for an agent to use the tool correctly.
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 only 25% (only workflowPath has a description). The description adds minimal meaning beyond the schema; it mentions 'local or cloud' which corresponds to the target enum but does not elaborate on the other parameters like clientId or extraData, failing to compensate for the low coverage.
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 (submit) and the resource (ComfyUI workflow JSON to /prompt endpoint). It specifies the target options (local or cloud), distinguishing it from sibling tools like comfy_get_history which retrieves history.
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 implies usage context (submitting a workflow to run) but does not explicitly state when to use or when not to use. No alternatives or exclusions are mentioned, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcode or resize a video using safe preset options.
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes | ||
| outputPath | Yes | ||
| aspect | No | keep | |
| fps | No | ||
| crf | No | ||
| width | No | ||
| height | No | ||
| overwrite | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'safe preset options' without explaining what 'safe' entails or disclosing potential side effects like overwriting files, resource usage, or authentication needs.
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 short (one sentence), which is too terse for a tool with 8 parameters. It sacrifices necessary detail for brevity, making it insufficient for an agent to use correctly.
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 (8 parameters, no annotations, no output schema), the description is grossly incomplete. It fails to explain transcoding options, aspect ratio behavior, or the meaning of technical parameters like CRF and FPS.
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?
With 0% schema description coverage, the description adds no meaning to the 8 parameters. The vague phrase 'safe preset options' does not clarify the purpose of inputPath, outputPath, aspect, fps, crf, width, height, or overwrite.
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 (transcode or resize) and the resource (video). It effectively distinguishes this tool from its siblings, which are focused on other tasks like After Effects scripts, ComfyUI workflows, or media analysis.
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. There is no mention of prerequisites, exclusions, or context for using FFmpeg transcoding over other media tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use ffprobe to inspect a video/audio/image file under VIDEO_FACTORY_ROOT.
| Name | Required | Description | Default |
|---|---|---|---|
| inputPath | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose side effects (it is read-only), output format, or limitations. Minimal 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?
One sentence, no fluff. Efficient but could be more informative without breaking conciseness.
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 no output schema and no annotations, the description should provide more details on expected output and usage context. Currently insufficient for a single-parameter probing tool.
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 has 0% description coverage. The description adds that inputPath is relative to VIDEO_FACTORY_ROOT, but does not specify format or constraints.
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 uses ffprobe to inspect video/audio/image files under a specific root directory, distinguishing it from sibling tools like ffmpeg_transcode.
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 on when to use this tool vs alternatives, nor when not to use it. Lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a structured job folder and manifest for an AI video production pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| title | Yes | ||
| prompt | Yes | ||
| platforms | No | ||
| style | No | ||
| durationSeconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'creates' something, implying a write operation, but gives no details on side effects, required permissions, or whether it overwrites existing data. The behavioral insight is minimal.
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 sentence, which is concise but too brief to be informative. It is front-loaded with the main action, but lacks necessary details, sacrificing completeness for brevity.
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 6 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the manifest structure, return values, or how the job folder is organized. This is insufficient for correct invocation.
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 has 0% description coverage, meaning no parameter descriptions exist. The tool description does not explain the purpose of parameters like jobId, title, prompt, platforms, style, or durationSeconds. It adds no value to understanding what each parameter controls.
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 creates a 'structured job folder and manifest' for an AI video production pipeline. The verb 'create' and resource 'job folder and manifest' are specific. However, it does not explicitly differentiate from sibling tools, though the siblings are distinct enough that confusion is unlikely.
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 like comfy_submit_workflow or ae_render_template. The description lacks context about prerequisites, constraints, or scenarios where 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.
Generate publishing metadata for different short video platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | ||
| finalVideoPath | Yes | ||
| title | Yes | ||
| description | No | ||
| tags | No | ||
| platforms | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, authentication needs, or rate limits. The agent is left unaware of what 'generating metadata' entails beyond the schema.
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 very concise with a single sentence, which is front-loaded but lacks necessary detail. It is appropriate in length but could benefit from expanding on key aspects.
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 no annotations, no output schema, and minimal parameter documentation, the description is incomplete. It does not explain what the output is, how it interacts with other tools, or the behavior of the job lifecycle.
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?
Input schema has 0% description coverage, and the tool description adds no meaning to the parameters. Six parameters are listed without any explanation of their roles or constraints, leaving the agent to guess.
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 'generate' and the resource 'publishing metadata for different short video platforms,' distinguishing it from sibling tools like rendering or transcoding. However, 'publish package' is not fully explained.
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 on when to use this tool versus alternatives, nor any prerequisites or conditions. The description only states the general purpose without context for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Basic placeholder review for video metadata. Replace with real moderation APIs later.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| description | No | ||
| videoPath | Yes | ||
| strict | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as what the review checks, whether it modifies data, or its limitations beyond being a placeholder.
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?
Extremely concise at one sentence, but it omits necessary details. Conciseness is not beneficial when substance is lacking.
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?
With 4 parameters, no output schema, and no annotations, the description provides minimal help. It fails to explain the tool's behavior, return values, or how to use parameters correctly.
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%, and the description adds no meaning beyond the parameter names ('title', 'description', 'videoPath', 'strict'). The purpose of 'strict' is undefined.
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 'review for video metadata' which identifies a verb and resource, but it is vague and labeled as a placeholder. It does not clearly distinguish from sibling tools like media_probe, which could also inspect media.
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 on when to use this tool versus alternatives like media_probe. The description does not specify context, prerequisites, or when not to use it.
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.
v0.1.0ae_generate_jsxae_render_templatecomfy_get_historycomfy_submit_workflowffmpeg_transcodemedia_probepipeline_create_jobplatform_prepare_packagereview_video_packageScored across 9 tools
Each tool clearly targets a distinct domain: AE scripts vs rendering, ComfyUI submission vs history, media probing vs transcoding, pipeline job creation, platform packaging, and review. No overlapping purposes.
Names mostly follow a consistent verb_noun pattern with domain prefixes (ae_, comfy_, ffmpeg_, media_, pipeline_, platform_, review_). The only minor inconsistency is 'media_probe' which reverses the order (noun_verb) compared to others like 'ffmpeg_transcode'.
9 tools cover the key operations for a video factory: AE template generation and rendering, ComfyUI workflow management, media processing, pipeline orchestration, and platform publishing. The count is well-scoped without unnecessary bloat.
Covers essential workflows: AE template manipulation, ComfyUI interaction, media transcoding/probing, pipeline job creation, and platform packaging. Minor gap: the review tool is a placeholder, and there is no explicit tool for asset management or user input validation, but core functionality is present.
Transform video, audio and images, and generate media from prompts. FFmpeg, captions, models.
Build, run, schedule, and publish AI video pipelines to YouTube and TikTok from any MCP client.
FFmpeg as a service for AI agents: typed video editing tools, async jobs, downloadable outputs.
AI video editing + publishing: turn clips into vertical shorts, post to TikTok/Instagram/YouTube.
