AI 숏폼 비디오 자동화 파이프라인을 위한 MCP 서버: ComfyUI 이미지-투-이미지/이미지-투-비디오, FFmpeg 후처리, After Effects 템플릿 패키징, 검토 및 멀티 플랫폼 게시 준비 과정을 연결합니다.
설계 목표: Cursor / Claude Desktop / ChatGPT MCP 클라이언트가 이러한 도구를 호출하여 「생성 → 패키징 → 검토 → 내보내기 → 게시 패키지」 프로세스를 자동으로 완료할 수 있도록 합니다.
로컬 또는 클라우드 ComfyUI 워크플로우 호출
ComfyUI 작업 기록 조회
FFprobe를 사용한 비디오 분석
FFmpeg를 사용한 트랜스코딩, 크롭, 프레임 추출, 병합
AE 자동 소재 교체 JSX 스크립트 생성
aerender를 호출하여 After Effects 템플릿 렌더링
표준화된 비디오 제작 작업 manifest 생성
Douyin / Xiaohongshu / Bilibili / YouTube Shorts / TikTok 게시 패키지 구성 생성
향후 타사 검토 API 연동을 위한 기본 콘텐츠 검토 플레이스홀더 인터페이스 제공
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 예시:
{
"AERENDER_BIN": "C:\\Program Files\\Adobe\\Adobe After Effects 2025\\Support Files\\aerender.exe"
}pipeline_create_job으로 제작 작업 디렉토리 및 manifest 생성
comfy_submit_workflow로 ComfyUI 이미지-투-비디오 워크플로우 제출
comfy_get_history로 결과 조회
media_probe로 비디오 사양 확인
ffmpeg_transcode로 비율, 비트레이트, 프레임 레이트 통일
ae_generate_jsx로 AE 템플릿 교체 스크립트 생성
ae_render_template로 aerender를 호출하여 최종 패키징 비디오 출력
review_video_package로 검토 플레이스홀더 수행
platform_prepare_package로 각 플랫폼 게시 패키지 생성
AE 프로젝트 내에 다음과 같은 플레이스홀더 레이어를 미리 생성하는 것을 권장합니다:
{{MAIN_VIDEO}}
{{TITLE}}
{{SUBTITLE}}
{{LOGO}}
{{CTA}}
그런 다음 본 프로젝트에서 생성된 JSX를 사용하여 소재와 텍스트를 교체하고, aerender를 통해 출력합니다.
이 MCP 서버는 로컬 명령을 실행하므로 기본적으로 다음과 같은 제한이 있습니다:
모든 입출력 파일은 VIDEO_FACTORY_ROOT 디렉토리 내에 있어야 합니다.
FFmpeg 매개변수는 화이트리스트 방식으로 캡슐화되어 있으며, 임의의 셸 명령을 직접 노출하지 않습니다.
AE 렌더링은 dryRun을 지원하므로 명령을 먼저 테스트하는 것을 권장합니다.
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 mainMCP 공식 TypeScript SDK는 서버 생성, 도구 등록을 지원하며 stdio 또는 Streamable HTTP를 통해 MCP 클라이언트에 연결합니다. 여기서는 로컬 자동화 통합에 적합한 stdio를 사용합니다.
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.
