Skip to main content
Glama

find_clips

START HERE for any clip workflow on a video — find_clips is the canonical entry point and includes a full transcription as a free byproduct. Do not call transcribe first: doing so doubles the upload, doubles the spend, and produces the same transcript. Identify ranked candidate clips in a video — what to cut for highlights, social, or testimonials. Three-call flow: (1) call with filename (and optional query) to receive {job_id, payment_challenge}; (2) pay via MPP, then call with job_id + payment_credential to receive {upload_url} (presigned PUT, 1h expiry); (3) PUT the bytes, then complete_upload(job_id), then poll get_job_status(job_id). On completion, get_job_status returns three outputs: role clip-candidates (JSON matching /.well-known/weftly-clips-v1.schema.json — includes source_job_id and source_expires_at), role transcript (SRT, free byproduct), role transcript-words (JSON matching /.well-known/weftly-transcript-v2.schema.json, free byproduct). Each candidate carries transcript_text — the full text of what's in the clip — so callers can preview content before paying for clips_from_job. Optional query parameter switches to query mode (e.g., "they discuss pricing", "the part about hiring") with the same output shape; the mode field in clip-candidates.json indicates which mode produced the result. Flat price: $2.00 video — see /.well-known/mpp.json. Source-reuse contract: the source video stays in storage for 72h after find_clips completes. Hand the find_clips job_id (also returned as source_job_id in the candidates JSON) to clips_from_job as its source_job_id — within those 72h it cuts directly from the stored source: no re-upload, no re-transcribe, just $0.50 per cut (more for a multi-clip output: "files" batch). Pass the same source_job_id to as many clips_from_job calls as you need. Use for interviews, podcasts, sales calls, all-hands recordings. Retrying with job_id alone returns current state. Failed jobs auto-refund.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoOptional. Switches the analyzer from "best clips" discovery mode to query mode — finds segments matching this content (e.g., "they discuss pricing", "the part about hiring"). Same output shape either way; the `mode` field in clip-candidates.json tells consumers how to interpret per-candidate scoring.
job_idNoJob ID returned from a previous call. Include along with payment_credential to confirm payment and receive the presigned upload URL. Also include alone to recover the current challenge/state if the original response was lost.
filenameNoFilename with extension (e.g. "podcast.mp3"). Required on the first call — used to infer media type (audio vs video) and label outputs. Supported extensions: mp3, wav, m4a, ogg, flac, mp4, mov, webm, mkv.
payment_credentialNoMPP payment credential (full Authorization header value, e.g. "Payment eyJ...") obtained by paying the challenge returned from the first call. Include with job_id to verify payment and receive the upload URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the payment challenge workflow, presigned PUT with 1h expiry, three-step upload completion, the three output roles (clip-candidates, transcript, transcript-words), source retention for 72h, flat pricing ($2.00) and auto-refund on failure, plus retry semantics with job_id. This is exceptional transparency.

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?

The description is long but appropriately so for a multi-step, high-stakes workflow. It is front-loaded with 'START HERE' and the critical anti-pattern warning, then follows a logical sequence (call flow, outputs, pricing, reuse). While dense, every sentence contributes essential information—no filler. The length is justified by the tool's complexity.

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?

Given the tool's complexity, lack of annotations, and lack of output schema, the description is remarkably complete. It covers the entire lifecycle: initial call, payment, upload, completion, output schemas (referenced via /.well-known/ endpoints), source-reuse contract, pricing, failure behavior, and retry semantics. An agent has everything needed to correctly invoke and interpret the tool.

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?

While schema coverage is 100% and each parameter has a description, the description adds workflow-specific meaning beyond the schema: it explains that filename is required on the first call, job_id can be used alone to recover state, and payment_credential must accompany job_id to confirm payment. It also clarifies that query switches the analyzer mode. This goes well beyond the schema's basic definitions.

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?

The description states a precise purpose: 'Identify ranked candidate clips in a video — what to cut for highlights, social, or testimonials.' It also clearly positions itself as the canonical entry point ('START HERE for any clip workflow') and explicitly distinguishes itself from transcribe and clips_from_job, so an agent can differentiate it from siblings immediately.

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?

The description is explicit about when to use the tool: 'START HERE' and 'Do not call transcribe first' with a concrete reason (doubles upload and spend). It lays out the exact three-call flow, explains optional query mode, references clips_from_job for subsequent cuts, and even lists applicable use cases (interviews, podcasts, sales calls). No alternatives are left ambiguous.

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