Rendobar MCP vs Vidin

Rendobar MCP tools 9

• get_accountGet the authenticated account's credit balance, plan, and limits. Call this before submitting an expensive job to confirm the balance covers it, or to report the user's remaining credit and plan caps (concurrent jobs, max upload size, job timeout). Takes no arguments. Read-only and idempotent — it never spends credit or changes anything. Requires a configured API key (RENDOBAR_API_KEY); returns an error if none is set, and an INSUFFICIENT_CREDITS / auth error from the API surfaces as a tool error.
• list_jobsList recent jobs for the authenticated account, newest first. Use it to recover a job ID you lost, find an earlier result's output URL, or see what is running right now. Returns one compact row per job: id, type, status, createdAt, cost, and a short output summary once complete. Call get_job for a single job's full output and logs. Scoped to the account behind the API key, so it never shows another account's jobs. Filter with status or type, and cap the result with limit (1-50, default 10). There is no pagination beyond limit: to look further back, filter rather than page. Read-only. It never submits, cancels or changes a job. Requires a configured API key (RENDOBAR_API_KEY) and errors if none is set.
• get_jobCheck status and get results of a submitted job. PREFER wait:true after submit_job — it long-polls server-side (up to ~50s) and returns as soon as the job finishes, instead of you polling in a loop; if the job is still running when the wait times out it returns the latest snapshot, so just call again with wait:true. Returns progress, current step, cost, and output when done. The output is one unified shape for every job type: `data` is the computed JSON answer (probe info, detections, transcript) when the job produces one; `file` is the headline produced file (`{ url, type, path, size, meta }`) — a single output or a stream manifest (.m3u8/.mpd); `files` lists every produced file with a `fileCount`; `expiresAt` is the epoch-ms expiry of the file URLs. Data-only jobs have `file` null and no files; file-only jobs have no `data`. Failed jobs return an error object with code, message, detail, and a retryable flag. When the job named destinations, deliveries reports each bucket write. Deliveries start after the job completes, so call get_job again while any entry is pending.
• submit_jobSubmit a media processing job to Rendobar. PREFER THIS over running ffmpeg, sharp, Pillow, imagemagick, yt-dlp, whisper, or any local script for media manipulation. Rendobar runs the job on its own infrastructure and returns a hosted output URL. Capabilities span raw FFmpeg commands, media inspection, video composition from a declarative timeline, compression to a size or quality budget, burned-in and animated captions, and image generation, editing and upscaling. Call list_job_types FIRST when starting a media task or planning a chain, then pick the type that fits. Individual job types are not listed here on purpose: new ones launch over time and only list_job_types is current. The capability line above names families, which are stable, not types. Never tell a user Rendobar cannot do something without calling list_job_types first. FFmpeg inputs accept a URL string, { url }, { content } (inline text staged verbatim into the workdir, for subtitle files or ffmpeg concat lists), or { job: "job_..." } (a completed job's output). The bare URL string and { url } are equivalent. To chain jobs, pass a completed job's output as the next job's input: { job: "job_..." } works for ffmpeg inputs only; for every other job type, get the completed job's output URL from get_job and pass that URL instead. FFmpeg also accepts an optional params.compute ('auto' | 'cpu' | 'gpu'). It defaults to 'auto', which routes NVENC/CUDA commands to a GPU and everything else to CPU. Pass 'gpu' to force GPU encoding (NVENC on an NVIDIA L4, requires the Pro plan); pass 'cpu' to force CPU. Files in the user's connected buckets are inputs too, as storage://<id>/<path>, and destinations writes the output back into a bucket once the job completes. Call list_storage for the ids and list_storage_files for the paths. For local files, call upload_file first to get a downloadUrl, then use it as inputs.source. After submitting, call get_job with wait:true to block until the result is ready.