ai.weftly/weftly

Weftly

Find & cut horizontal and vertical video clips (Shorts/Reels), transcribe & summarize. Pay per job.

0.35.2
Version
remote
Transport
9
Tools

Security review

Review passed

Reviewed 19h ago.

  • tools: 9 tools scanned
  • metadata: scanned

No findings.

Tools (9)

  • transcribe

    Transcribe audio or video to text, including per-word timestamps for precise editing. Three-call flow: (1) call with `filename` 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 two outputs: role `transcript` (SRT) and role `transcript-words` (JSON matching /.well-known/weftly-transcript-v2.schema.json, with segment-level and per-word timestamps). For other formats, pass `format=srt|txt|vtt|json|words|edit` to get_job_status to receive content inline — `txt` and `vtt` are derived from SRT, `json` is v1 (segments only), `words` is v2 (segments + words), `edit` is a plain-text "[NNNN] words..." paragraph list for editing by hand. Flat price: audio $0.50, video $1.00 — see /.well-known/mpp.json for the authoritative table. Use for podcasts, interviews, meetings, lec

  • summarize

    Summarize an audio or video file — returns both a text summary AND the full transcript (with per-word timestamps). Do not also call transcribe on the same file. Three-call flow: (1) call with `filename` 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 `summary` (plain text), role `transcript` (SRT), and role `transcript-words` (JSON matching /.well-known/weftly-transcript-v2.schema.json, with segment-level and per-word timestamps). For other formats, pass `format=srt|txt|vtt|json|words|edit` to get_job_status to receive transcript content inline — `txt` and `vtt` are derived from SRT, `json` is v1 (segments only), `words` is v2 (segments + words), `edit` is a plain-text "[NNNN] words..." paragraph list for editing by hand. Flat price: audio $

  • 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 can

  • 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

  • edit_from_transcript

    Cut and re-assemble a video from an edited copy of its own word-level transcript — the text-editing counterpart to clips_from_job's timestamp-based cutting. Operates on a parent job (find_clips, summarize, or video transcribe) that has a word-level transcript; possessing the parent `source_job_id` is the capability, no upload step. Get the editable text first via get_job_status(job_id, format: "edit") or the download route — one `[NNNN]`-marked line per sentence — then edit it in any text editor: delete words or whole lines, move whole lines, but do not add or change a word (a marker used twice, or any added/changed word, invalidates the whole edit and is rejected before payment). Two-call flow: (1) call with `source_job_id` + the full edited text as `edited_transcript` (sent inline, max 262144 UTF-8 bytes) + optional `title` to receive {job_id, payment_challenge} — an invalid edit is rejected here, before any charge, with the exact failing lines; (2) pay via MPP (Tempo USDC) or open t

  • complete_upload

    Confirm that the file has been uploaded (via HTTP PUT to the upload_url from transcribe or summarize) and start processing. Verifies that the file is present in storage and that the job has been paid. Returns status "processing". Poll get_job_status to track progress and retrieve download URLs when done.

  • get_job_status

    Check the status of a transcribe or summarize job. Returns the current state and, when completed, an `outputs` array. Each output has either `content` (returned inline) or a presigned, time-limited (1 hour) `download_url`. Small text outputs (e.g. `transcript` SRT, `clip-candidates`, `summary`) come inline as `content`; larger outputs — `transcript-words` JSON for any non-trivial recording, plus video outputs like `clip-video` / `clip-vertical-video` — come as a `download_url` to fetch when needed. Optionally pass `format` (srt, txt, vtt, json, words, edit) to get the transcript content inline in the top-level `transcript` field — `txt` and `vtt` are derived from the stored SRT; `json` is v1 (segments only); `words` is v2 (segments + per-word timestamps matching /.well-known/weftly-transcript-v2.schema.json); `edit` is a plain-text "[NNNN] words..." paragraph list, one line per paragraph, for editing by hand — send the edited text to edit_from_transcript to cut a re-timed video from it

  • mpp_smoke_test

    Smoke-test the MPP payment plumbing end-to-end via this MCP server, for $0.01 USDC. Two-call flow: (1) call with no arguments to receive an MPP `payment_challenge`; (2) pay via MPP and call again with `payment_credential` set to the resulting Authorization header value (e.g. "Payment eyJ...") to receive {paid: true, timestamp, receipt_ref, payment_method}. Uses the exact same `createPayToAddress` + `createMppHandler` verification path as paid product tools (transcribe, summarize), so a green run here means real paid calls will work too. Stateless — no job is created, no database row written. Use this whenever you want to confirm a wallet, the MCP transport, the worker, and the production payment middleware are all healthy without paying a transcribe price. Cost: $0.01 USDC per attempt.

  • clips_from_video

    Find clips in a video AND cut up to 5 of them, under ONE payment. This is the alternative to calling find_clips and then clips_from_job yourself — prefer it whenever the user wants clips delivered end-to-end from a video they have not yet uploaded. CARD PAYMENT ONLY — this chain authorizes a Stripe hold (up to $4.50) before the final price is known (the total depends on how many clips are found and delivered), a shape MPP push settlement cannot express. A caller with no card-checkout capability (a wallet-only MPP agent) should NOT call this tool — call find_clips then clips_from_job instead, paying per step in USDC. Two-call flow: (1) call with `filename` and `content_type` (video only) — and an optional `query` to switch clip discovery from "best clips" to matching specific content (e.g. "the part about pricing") — to receive {job_id, status: "awaiting_payment", checkout_url}; (2) once the user says they have authorized payment, call again with the SAME `job_id` (no other fields neede