ffpipe — video conversion, probe & frames

convert_video

Queue an asynchronous video conversion: fetches sourceUrl (or, with upload: true, waits for you to PUT the bytes to the returned uploadUrl), converts to MP4 scaled to fit maxWidth x maxHeight (defaults 1920x1080, cap 4096). Returns { jobId, status: "queued" | "awaiting_upload", statusUrl, uploadUrl?, uploadExpiresAt? } - poll with get_job_status (jobId + the t token from statusUrl) until finished/error. Download results within 24 hours. Paid: $0.05 USDC via x402 (base mainnet), or a convert-kind retryVoucher.

Input Schema

TableJSON Schema

Name	Required	Description
`upload`	No	Set true to upload the bytes yourself instead of giving a sourceUrl (exactly one of the two). The paid result then returns status awaiting_upload plus uploadUrl and uploadExpiresAt: HTTP PUT the raw bytes to uploadUrl before the deadline (201 -> queued). You are charged at acceptance; an abandoned upload window errors with no refund, while a pipeline failure after your upload earns a retryVoucher.
`maxWidth`	No	Max output width, default 1920
`maxHeight`	No	Max output height, default 1080
`sourceUrl`	No	https URL of the input media (<= 100 MiB). Fetched from datacenter IP ranges - prefer a presigned URL from storage you control; no IP literals, no localhost/.internal/.local. Provide EXACTLY ONE of sourceUrl or upload.
`retryVoucher`	No	Retry-voucher credential (`uuid.hmac`) from a failed paid job's status - pays for this call instead of x402. Single use, kind-matched.

TDQS

A4.9/5.0

Behavior5/5

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

Description fully discloses async behavior, payment details ($0.05, x402 or retryVoucher), upload workflow (PUT bytes before deadline, no refund on abandoned upload), result structure, polling via get_job_status, and 24-hour download window. Annotations only provide readOnlyHint=false, idempotentHint=false, destructiveHint=false, which are consistent; description adds all critical behavioral context beyond annotations.

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?

Description is well-structured and efficient, covering purpose, workflow, constraints, and payment in a few sentences. Slightly dense but not verbose; all information is necessary. Could be slightly more scannable with bullet points, but still effective.

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?

Description is complete for a complex tool with 5 parameters, no output schema, and rich behavioral context. It explains async lifecycle, payment, upload vs source, dimension limits, polling mechanism, and error handling. Leaves no major gaps for agent invocation.

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 100% with detailed descriptions, but the tool description adds high-level context: default dimensions (1920x1080), cap (4096), upload vs sourceUrl choice, payment via voucher, and the overall workflow. Description enhances understanding beyond individual parameter 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?

Description clearly states the tool queues an asynchronous video conversion, specifies source URL or upload mode, output format (MP4), scaling constraints with defaults and cap, and payment model. It distinguishes itself from siblings by covering conversion, not extraction, probing, or status polling.

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?

Description explicitly covers when to use (to convert video), async workflow (queue then poll), and mentions sibling tool get_job_status for polling. Includes constraints (max 100 MiB, no IP literals, etc.) and alternatives for payment (x402 vs retryVoucher). Does not list explicit exclusion scenarios, but the detailed async flow and payment options provide strong guidance.

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

All ffpipe — video conversion, probe & frames 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.6/5.0

Disambiguation4/5

Each tool targets a distinct capability: convert_video, extract_frames, probe_media, get_job_status, get_balance, and leave_feedback are clearly separated. However, there is a minor overlap potential between convert_video and extract_frames for users wanting to get video stills, but descriptions clarify the difference well.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (convert_video, extract_frames, get_balance, get_job_status, leave_feedback, probe_media). The verbs are descriptive and the nouns clearly indicate the resource or action, making them predictable and easy to navigate.

Tool Count5/5

With 6 tools, the set is well-scoped for a video processing service. Each tool serves a core function: two for processing (convert, extract), one for analysis (probe), one for status tracking, one for account management, and one for feedback. No tool is superfluous, and the count feels proportional to the domain.

Completeness4/5

The toolset covers essential video operations: conversion, frame extraction, media probing, with robust status tracking and account management. Obvious gaps include the lack of a cancel_job tool for stopping queued jobs and no explicit download management tool beyond the 24-hour window, but the core lifecycle is well-covered.

Resources

Need Help?