Turn a video link into vertical short clips with subtitles: create jobs, poll, get downloads.
Scored across 4 tools
Each tool has a distinct role in a clear create→poll→retrieve pipeline, and descriptions explicitly state which to call when. The only soft overlap is get_job (which returns finished clips with download_url) versus list_clips (which returns only finished clips), a redundancy the descriptions mitigate but don't fully eliminate.
All four tools follow a clean verb_noun convention: create_clips, get_job, get_options, list_clips. Verbs match their semantics (create for mutation, get for single-resource read, list for collection) with no style mixing.
Four tools is lean but well-matched to an async job-based workflow where one entry point, one poller, one results lister and one options helper cover the core loop. It sits at the low end, with little room for ancillary operations.
The full happy path (discover options → start job → poll status → fetch clips) is covered with no dead ends. However, a multi-minute job has no cancel/delete operation and no way to check remaining clip balance despite pricing being mentioned, which are noticeable if recoverable gaps.
Start a job that cuts a video link (YouTube, TikTok, Instagram, Vimeo, Twitch, or a direct file URL) into vertical 9:16 short clips with burned-in subtitles. Returns a job_id immediately; the job runs for a few minutes — poll get_job until status is "completed" or "partial". num_clips is a maximum, not a guarantee. Uses the account's normal clip balance (free plan included).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public https link to the source video. | |
| font | No | Font: montserrat, rubik, russo. | |
| logo | No | Paid plans only: {url|base64, position, size, margin, opacity}. See https://vyexa.net/api-docs#logo. | |
| title | No | Fixed title instead of an AI one. Max 32 characters (70 when constructor.title_style is "newsline"); longer is cut. | |
| layout | No | Framing: auto, full, frame_70, frame_50, frame_40, dual, streaming, lesson. See get_options. | |
| language | No | Spoken language code (en, ru, uk, pl, …) or "auto" (default). | |
| num_clips | No | Maximum number of clips to produce (default 1). | |
| title_style | No | Title style: clean, box, chip, box_accent, newsline, outline, off. | |
| generate_title | No | Generate an AI title for each clip (default true). | |
| subtitle_style | No | Subtitle style, e.g. karaoke, highlighter, glow, punch, none. See get_options. | |
| highlight_color | No | Accent colour as #RRGGBB (or "#RRGGBB+#RRGGBB" for two alternating). | |
| profanity_censor | No | Mask and bleep swear words. | |
| segment_duration | No | Clip length category. 0 (default) = Auto: length picked per clip from content, mixed short/medium/long, every plan. 30 Short and 65 Medium need Creator, 120 Long needs Pro. Legacy 50/90 = 65/120. | |
| subtitle_position | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, idempotent=false, openWorld=true, destructive=false), the description discloses that this is an asynchronous job returning a job_id immediately, that it takes minutes, and that it consumes the account's clip balance including free plans. No contradiction with annotations; failure/retry behavior is the main omission.
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?
Front-loaded with the action and output format in the first sentence, then job semantics, then the num_clips caveat, then billing. Four sentences, each contributing distinct information with no repetition.
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?
Covers the essential lifecycle an agent needs for a 14-parameter async mutation: the returned job_id, expected duration, polling target, and cost model, against a high-coverage schema and no output schema. Minor gaps remain around error handling and what 'partial' means for results.
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 coverage is 93%, so the schema carries nearly all parameter meaning including plan gating and enums. The description only adds the nuance that num_clips is a cap rather than a guarantee, which is already partly implied by the schema's 'Maximum number of clips to produce'.
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?
Specific verb and resource: 'start a job that cuts a video link … into vertical 9:16 short clips with burned-in subtitles', with the supported sources enumerated. It is clearly distinguishable from siblings get_job, get_options, and list_clips.
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?
Explicitly routes the agent to get_job for polling and names the terminal statuses 'completed' or 'partial', and warns that num_clips is a maximum. It doesn't state when to prefer list_clips or when a job would be rejected, but the sequencing guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status of a job created with create_clips: status (pending, processing, completed, partial, failed), progress counters, source info and the list of finished clips with download_url. Poll every 10–15 seconds. "partial" means some clips are usable.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | job_id returned by create_clips. | |
| include_subtitles | No | Include per-clip subtitle text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new context: the poll cadence, the meaning of each terminal state, and that 'partial' still yields usable clips. It does not describe pagination or behavior for very old/expired jobs, but the value added over the annotations is substantial.
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?
Three short sentences, each load-bearing: identity, return contents, and two operational caveats. The status list is inline rather than padded into prose, and nothing is repeated from the structured fields.
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 no output schema, the description must cover return values, and it names status, progress counters, source info, and clips with download_url. The counters' units and the polling stop condition are left implicit, a minor gap for a poll-based job 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?
Schema description coverage is 100% and both parameters are documented there, so the schema carries parameter semantics. The description contributes only an implicit reference to job_id's origin, which the schema already states. Baseline 3 applies.
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?
States a specific verb+resource ('status of a job created with create_clips') and enumerates the full status vocabulary, plus what the response contains. It ties itself explicitly to the create_clips sibling, so an agent can place it in the workflow without opening the schema.
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?
Gives concrete operational guidance ('Poll every 10–15 seconds') and explains the ambiguous 'partial' outcome. It stops short of stating when to use this versus list_clips for retrieving finished clips, which is the one plausible overlap among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All accepted values for layout, subtitle_style, title_style, font, subtitle_position with "when to choose" hints and recommendations by content type (podcast, gaming, humor…). Call once before create_clips to pick styling.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds value beyond that by disclosing it is a one-time prerequisite call and by characterizing the payload ('when to choose' hints and recommendations by content type). It stops short of describing the response structure, but with annotations carrying the safety profile this is solid.
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?
Two tight sentences with no filler, front-loading the resource and value coverage before the imperative usage instruction. Every clause earns its place.
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 zero-parameter, no-output-schema lookup tool, the description does the necessary work by naming the option sets and the type of guidance returned. A brief note on the returned structure (a flat list vs. value-to-hint mapping) would close the remaining gap, but nothing essential is missing.
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 takes zero parameters, so the baseline of 4 applies. The enumerated categories in the description describe output content rather than inputs, which is a reasonable use of the space but does not add parameter meaning.
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?
States a specific verb (List) and resource (styling options), then enumerates the exact value sets it covers (layout, subtitle_style, title_style, font, subtitle_position). It also names the sibling it feeds into, create_clips, so an agent can immediately distinguish it from list_clips or get_job.
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?
Explicit timing and sequencing guidance: 'Call once before create_clips to pick styling.' This tells the agent both when to invoke it in a workflow and why, with the downstream consumer named. No ambiguity about alternatives is left open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only the finished clips of a job (id, title, duration, download_url). Each download_url requires the same Bearer key.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | job_id returned by create_clips. | |
| include_subtitles | No | Include per-clip subtitle text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. Beyond that the description adds two non-obvious traits: the result set is restricted to finished clips only, and fetching each download_url requires the same Bearer key — an auth constraint an agent would otherwise only discover at call time.
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?
Two short sentences with no filler; the response-shape fact comes before the auth caveat. It loses a point only because the opening sentence is a verbless fragment rather than a properly front-loaded statement of the 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?
With no output schema, the description compensates by enumerating the returned fields and flagging the per-clip auth requirement. It is close to sufficient for a 2-parameter read tool, though it stays silent on pagination/result limits and on behavior when no clips have finished.
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 coverage is 100%, with both job_id and include_subtitles documented in the schema itself, so the baseline is 3. The description's field list describes the response payload rather than adding meaning to either parameter.
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 is a noun phrase ('Only the finished clips of a job') that names the resource and scope, and the enumerated fields (id, title, duration, download_url) make the payload concrete. However it lacks an explicit verb and does no work to separate itself from siblings like get_job or create_clips.
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 statement of when to call this versus get_job or create_clips, and no conditions or prerequisites. 'Only the finished clips' hints at a filter but never says what to do when clips are still processing or which tool covers the unfinished case.
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.
create_clips2 fields changedInput schema / properties / segment_duration / descriptionPrevious value: -"Target clip length in seconds. 50 needs Creator, 90 needs Pro; default 30."New value: +"Clip length category. 0 (default) = Auto: length picked per clip from content, mixed short/medium/long, every plan. 30 Short and 65 Medium need Creator, 120 Long needs Pro. Legacy 50/90 = 65/120."Input schema / properties / segment_duration / enumPrevious value: -[
- 30,
- 50,
- 90
-]New value: +[
+ 0,
+ 30,
+ 65,
+ 120
+]create_clips3 fields changedInput schema / properties / title / descriptionPrevious value: -"Fixed title instead of an AI one."New value: +"Fixed title instead of an AI one. Max 32 characters (70 when constructor.title_style is \"newsline\"); longer is cut."Input schema / properties / title / maxLengthPrevious value: -32New value: +70Input schema / properties / title_style / descriptionPrevious value: -"Title style: clean, box, chip, box_accent, outline, off."New value: +"Title style: clean, box, chip, box_accent, newsline, outline, off."create_clipsget_jobget_optionslist_clipsCreate AI-powered short-form video clips from YouTube videos. Supports webhook callbacks.
Turn a long video into short vertical clips: find moments, add captions, reframe, export.
Turn long videos into captioned vertical clips, then render and schedule social posts.
Turn long videos into captioned vertical clips for TikTok, Reels and Shorts.
Add one secure layer between your agents and this server.
