Skip to main content
Glama

clips_from_job

Cut one or more clips from any prior video job (find_clips, summarize, or video transcribe). Operates on a parent job — possessing the parent source_job_id is the capability, no upload step. Contrast with clips_from_video, which takes a local filename and uploads a video that has never been in Weftly before; use this tool whenever a video job already exists. Two choices are required on every new job, with no default — if the customer's intent is genuinely ambiguous, ask rather than guess: orientation (horizontal keeps the source framing; vertical crops to 9:16 for TikTok/Reels/Shorts) and output (files delivers one file per clip; reel concatenates every clip into a single file). Two-call flow: (1) call with source_job_id + clips (1+ objects {start, end, title?} in source seconds) + orientation + output to receive {job_id, payment_challenge}; (2) pay via MPP and call again with job_id + payment_credential to start processing. Price: output: "reel" bills a flat $0.50 regardless of segment count; output: "files" bills N × $0.50 for N clips, charged once for the whole batch (Stripe quantity). See /.well-known/mpp.json for the Tempo USDC rate. output: "files" caps a batch at 5 clips; output: "reel" concatenates every clip into one file, capped at 30 minutes of total output for orientation: "horizontal" or, for orientation: "vertical", the selected profile's cap: 240s for tiktok-primary and tiktok-primary-720p, 180s for instagram-reels, 60s for instagram-stories. The 240s ceiling is an encode limit (crop+scale cost per segment against the container's own timeout), not a platform rule; the shorter profile caps are the destination's own limit. orientation: "vertical" accepts profile (default tiktok-primary; also tiktok-primary-720p, instagram-reels, instagram-stories) and subject (center/auto/follow, default follow — switches crop between active speakers across clip and segment boundaries, the mode that makes multi-speaker interview clips usable; manual/subject_id need per-clip data this tool cannot supply — use the REST API's extract_vertical_clip job type directly for those); both are rejected for orientation: "horizontal", which keeps the source framing and has no crop to aim. include_transcript (default true) applies only to output: "reel" — mirrors extract_clip's clipped SRT + word-level transcript outputs — and is rejected for output: "files". Outputs: output: "files" writes roles clip-1-video through clip-N-video plus a clips-manifest (JSON) recording each clip's timing, output role, and any per-clip failure — a batch delivering fewer than N clips is not refunded, only one delivering zero is; output: "reel" writes role clip-video (frame-accurate boundaries, 15ms audio fades at segment joins) plus, when include_transcript is true, roles clip-srt + clip-words. Every output is audio loudness-normalized to -14 LUFS / -1.5 dBTP; vertical output is additionally cropped to the selected profile's dimensions (1080×1920 by default) and burned with word-level captions by default (center-third placement, uppercase, one short line per card) — pass captions: false to render vertical output without them; horizontal output never gets captions. Payment: pay by credit card via the Stripe Checkout link (open the returned payment_url in any browser) or Tempo USDC via mppx; the challenge's WWW-Authenticate header and /.well-known/mpp.json are authoritative for which methods are offered. Source must still be in storage (72h TTL for find_clips parents, 24h elsewhere — check expires_at from get_job_status on the parent). Multiple clips_from_job calls against one parent are independent paid jobs. Retrying with job_id alone recovers the current state. Failed jobs auto-refund.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
clipsNo
job_idNo
outputNo
profileNo
subjectNo
captionsNo
orientationNo
source_job_idNo
include_transcriptNo
payment_credentialNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / captions
      Added value: +{
      +  "type": "boolean"
      +}
  2. Added

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: two mandatory no-default choices, the two-call pay-then-process flow, pricing model, batch caps (5 clips / 30min / profile-specific ceilings), auto-refund on failed jobs, retry semantics, loudness normalization, and storage TTLs. This is unusually complete behavioral disclosure.

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?

Purpose and the sibling contrast are front-loaded, and the density is largely functional for a complex 10-param tool. It is nonetheless a very long single blob with some repetition (payment re-explained, well-known URL referenced twice), which costs it a point.

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?

Complete for a no-output-schema, no-annotation mutation tool: return artifacts (role names like clip-1-video, clips-manifest, clip-srt/clip-words), payment recovery, failure/refund behavior, and constraints are all spelled out. Nothing an agent needs to invoke and interpret it is missing.

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

Parameters5/5

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

Schema coverage is 0% across 10 params, yet the description explains nearly all of them: orientation semantics, output behavior, profile/subject options with defaults and rejection rules, include_transcript applicability, captions default, and the clips object shape and the job_id/source_job_id/payment_credential roles in the flow.

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 ('Cut one or more clips from any prior video job') and immediately scopes it to parent jobs, explicitly contrasting with the sibling `clips_from_video`. An agent can distinguish the two without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit selection rule versus the alternative ('use this tool whenever a video job already exists'), names the sibling it is not, and even routes to the REST API's `extract_vertical_clip` when `manual`/`subject_id` are needed. When-to-use is fully disambiguated.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources