Weftly

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 extract_clip. 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 extract_clip or extract_vertical_clip as their source_job_id — within those 72h they cut directly from the stored source: no re-upload, no re-transcribe, just $0.50 per cut. Pass the same source_job_id to as many extract 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

Name	Required	Description
`query`	No	Optional. 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_id`	No	Job 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.
`filename`	No	Filename 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_credential`	No	MPP 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.

TDQS

A4.6/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. It discloses the free transcription byproduct, payment challenge flow, presigned URL expiry, 72-hour source retention, retry behavior, and auto-refund policy. It also explains the three output roles and their schemas—excellent 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 every sentence conveys essential information (flow, pricing, source reuse, retry). It is front-loaded with 'START HERE' and uses bold for key terms, though the single dense paragraph could benefit from clearer sectioning for readability.

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 multi-step payment flow, three distinct output roles, and cross-tool source-reuse contract, the description covers all necessary context: pricing, schemas, timing, retry semantics, and failure handling. It fully prepares an agent to invoke the tool correctly without additional external knowledge.

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

Parameters3/5

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

The schema already provides 100% parameter coverage, and the description adds minimal parameter-level meaning beyond the flow context. It reinforces `query` mode behavior and `job_id` recovery but does not significantly exceed the schema's descriptions.

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 opens with 'START HERE for any clip workflow on a video' and clearly states the tool identifies 'ranked candidate clips in a video — what to cut for highlights, social, or testimonials.' It distinguishes itself from siblings by explicitly warning not to call `transcribe` first and by outlining the extract flow.

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?

Provides explicit when-to-use guidance ('canonical entry point'), a direct alternative exclusion ('Do not call transcribe first'), a step-by-step three-call flow, and a source-reuse contract for `extract_clip`/`extract_vertical_clip`. This is exemplary usage guidance.

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

All Weftly tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0

Disambiguation4/5

Most tools target distinct tasks (transcribe vs. summarize vs. find_clips, extract_clip vs. extract_vertical_clip, create vs. trigger YouTube). Some overlap exists because summarize and find_clips both produce transcripts, and publish_to_youtube and trigger_youtube_publish are sequential steps that could be confused, but descriptions clarify the boundaries well.

Naming Consistency4/5

The majority follow a verb_noun pattern (complete_upload, extract_clip, find_clips, get_job_status), with a few deviations like the bare verbs 'summarize' and 'transcribe', and 'publish_to_youtube' using a preposition. The pattern is still predictable and readable overall.

Tool Count5/5

11 tools is a well-scoped number for a video/audio processing service covering transcription, summarization, clip extraction, YouTube publishing, and payment testing. Each tool has a clear place, and the count is within the ideal range.

Completeness5/5

The tool surface covers the full lifecycle: job creation (transcribe/summarize/find_clips), payment (mpp_smoke_test, payment challenge flows), upload (complete_upload), status polling (get_job_status), clip extraction (two variants), and YouTube publishing (create/publish/status). No critical gaps are apparent for the stated domain.

Resources

Need Help?