Weftly

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 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). Flat price: audio $0.75, video $1.25 — see /.well-known/mpp.json for the authoritative table. Use for meetings, long-form interviews, lectures, and podcast episodes; the words output additionally supports creating clips, multicamera edits, or edit-video-from-transcript. Retrying any call with job_id alone returns current state (idempotent). Failed jobs auto-refund.

Input Schema

TableJSON Schema

Name	Required	Description
`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.4/5.0

Behavior5/5

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

With no annotations provided, the description carries full burden and excels: it discloses the three-call payment flow, MPP credential requirements, presigned URL expiry, idempotent retries, auto-refund on failure, and the exact output roles/formats. This is exceptionally thorough for a complex paid tool.

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 front-loaded with the core purpose and a critical warning. Every sentence contributes necessary detail for the complex flow, pricing, and outputs, but the paragraph is long and dense, making it somewhat heavy to parse.

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 no output schema and no annotations, the description covers the full lifecycle: initial call, payment, upload, polling, output formats, use cases, pricing, idempotency, and refunds. It even references relevant JSON schemas and includes authoritative pricing. This is remarkably complete.

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?

Schema coverage is 100% and each parameter already has a rich description covering its purpose and timing. The tool description repeats the flow but adds no semantic meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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 clearly states the tool summarizes audio/video files and returns both a text summary and full transcript with per-word timestamps. It distinguishes itself from the sibling 'transcribe' by explicitly warning 'Do not also call transcribe on the same file', making the scope and differentiation clear.

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

Usage Guidelines4/5

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

It provides explicit use cases ('meetings, long-form interviews, lectures, and podcast episodes') and a clear when-not ('Do not also call transcribe'). However, it does not compare against other relevant siblings like extract_clip or find_clips, so while guidance is strong, it is not fully exhaustive.

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?