Skip to main content
Glama
seocombat

Clipwright

by seocombat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Make a faceless video

make_faceless

Start a paid faceless video from a script or brief: narration over an animated opener and image scenes, with optional captions.

Instructions

Start a paid finished faceless video from a script or brief. You select 30–90 seconds; the video ends with its narration, runs at least 25 seconds and at most 5 seconds past the selection, never beyond 90. The video has an opening animated clip and image scenes. Captions are on by default and can be turned off. Call quote_faceless first and show the user the price. This does NOT wait for the video: it starts the run and returns a run_id IMMEDIATELY. Then poll get_run with that run_id until the state is 'succeeded' (video_url) or 'failed'. Pass attempt=2,3,… to deliberately start a NEW run for the same input.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
briefNoWhat the video is about; the narration is written from it. Required when input_mode is 'brief'; must be absent when it is 'script'.
scriptNoThe narration, read as written. Required when input_mode is 'script'; must be absent when it is 'brief'.
attemptNo
captionsNoBurned-in captions; on by default.
input_modeYes'script' narrates your exact text; 'brief' writes the narration from a short description. Send exactly one of script or brief, matching this mode.
scene_imagesNoOptional images of your own, each placed at a word range or quote of the narration.
style_referenceNoOptional public https image whose visual style the scenes follow.
duration_secondsYesSelected length, 30 to 90 seconds, on a 1/25 s frame boundary. The video ends with its narration, runs at least 25 seconds and may exceed the selection by up to 5 seconds, never beyond 90 seconds. The charge never exceeds the quote. A script must fit this output range.
character_referenceNoOptional public https image of a person or figure to keep consistent across scenes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.21.1

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare it is not read-only and not destructive. The description goes far beyond: it is paid, returns a run_id IMMEDIATELY without waiting, requires polling, captions default on and are toggleable, duration can overshoot by up to 5s but never past 90, and the charge never exceeds the quote.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and dense with actionable content; the async/polling instruction is stated in ALL-CAPS emphasis where it matters. The duration rule is partly repeated from the schema, which is the only mild redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, no-output-schema async job tool, the description supplies everything an agent needs: cost gating, immediate-return contract, the exact follow-up call and terminal states, and retry semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is already 89%, so the baseline is 3. The description adds real meaning beyond the schema for attempt ('deliberately start a NEW run for the same input') and restates duration behavior and the captions default in plain language.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Start a paid finished faceless video from a script or brief') and immediately constrains the artifact (30-90s, narration-ended, captions). It is clearly distinguishable from siblings like make_ugc, quote_faceless and get_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: quote_faceless first, then poll get_run until succeeded/failed, and attempt=2,3 to start a new run. It lacks a direct 'when to use this vs make_ugc' comparison, so it stops short of full when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools