Weftly

edit_from_multiple_cameras

Assemble one continuous edit from 2 camera files of the same event that started rolling at different moments. It syncs the cameras from their audio (a clap or sharp sound in the first 30 seconds of every file is the fallback), picks the camera that frames each voice by diarization, and renders one video at the main camera's resolution and fps (1080p ceiling). Three calls: (1) call with inputs (array of {filename, name?}, index 0 = the main camera) to receive {job_id, payment_challenge}. (2) After payment, call again with job_id (+ payment_credential on the MPP rail) to receive upload_urls[]: one presigned PUT URL per camera, 1h expiry. (3) PUT every file to its URL, call complete_upload(job_id) once ALL are uploaded (a partial upload is rejected naming the missing indices), then poll get_job_status(job_id). Optional offsets (seconds per camera, offsets[0] = 0, others may be negative) skip clap detection for footage with no clap; optional cuts ({source, start, end} in each camera's own timeline) render exactly the angles you give and skip automatic selection; show (speaker default, or listener) and n_speakers tune automatic selection. Output: role edit, one H.264 video with audio loudness-normalized to -14 LUFS / -1.5 dBTP, as long as the main camera and at most 60 minutes. Flat price for the whole job regardless of camera count: $3.00, see /.well-known/mpp.json for the Tempo USDC rate. Allow about 1.5 minutes of processing per minute of footage, plus upload time. The result is a normal video job: pass its job_id to clips_from_job as source_job_id to cut clips from the finished edit (it stays in storage 72h). Use for multi-camera interviews, podcasts and panels; use clips_from_job instead to cut a single existing video. Voice-based selection only (no gaze). Retrying with job_id alone recovers the current state or fresh upload URLs. Failed jobs auto-refund. 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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "edit_from_multiple_cameras"
  }
}

Input Schema

Name	Required	Description	Default
`cuts`	No
`show`	No
`title`	No
`inputs`	No
`job_id`	No
`offsets`	No
`n_speakers`	No
`payment_credential`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.9/5.0

Behavior5/5

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

No annotations exist, so the description carries the full burden and does: it discloses sync method (audio clap, with the first-30s fallback), the diarization-driven angle selection, the 3-step payment/upload/poll flow, the 1h presigned URL expiry, rejection of partial uploads, retry recovery semantics, auto-refund on failure, $3.00 flat pricing, processing throughput, and the 72h output retention. Output characteristics are quantified (-14 LUFS / -1.5 dBTP, 1080p ceiling, 60-minute max).

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 purpose is front-loaded and the three-call flow is numbered, which makes a dense protocol scannable. The closing payment paragraph restates rail/challenge information already introduced in steps 1-2, and the total length is high, but nearly every clause carries operational information an agent needs.

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 an 8-parameter, multi-phase, asynchronous, paid job with no annotations and no output schema, the description supplies everything needed to invoke it correctly: sequencing, failure modes, retry behavior, cost, latency, and output format/duration limits. Nothing material is left for the agent to guess.

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 8 parameters, so the description must compensate and largely does: it explains `inputs` ordering (index 0 = main camera), `offsets` semantics (seconds per camera, offsets[0]=0, negatives allowed) and why they matter, `cuts` structure and its effect of bypassing auto-selection, `show` default of `speaker`, and `n_speakers`. Only the incidental `title` field goes unmentioned.

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 concrete verb and resource — 'Assemble one continuous edit from 2 camera files of the same event' — and immediately grounds it in the specific scenario (cameras started at different moments). It also names the sibling it is not ('use clips_from_job instead to cut a single existing video'), so an agent can route correctly 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 explicit when-to-use ('multi-camera interviews, podcasts and panels'), an explicit alternative with its selection condition ('use clips_from_job instead to cut a single existing video'), and an explicit limitation ('Voice-based selection only (no gaze)'). Prerequisites and the required three-call sequence are spelled out rather than inferred.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?