Skip to main content
Glama
Sign In
Upload-Post

Upload-Post

Official
by Upload-Post
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Submit FFmpeg processing job

submit_ffmpeg_job

Process public media URLs with FFmpeg to trim, transcode, resize, watermark, concatenate, or extract thumbnails; returns a job ID for polling and downloading.

Instructions

Process media with FFmpeg on Upload-Post's encoding servers (trim, transcode, resize, watermark, concatenate, extract a thumbnail…). Inputs are public HTTP(S) URLs: input_url for one file, or files for several. They are downloaded into a working directory of their own for this job. full_command is one ffmpeg invocation using the placeholders {input} (or {input0}, {input1}… with several files) and {output}, e.g. ffmpeg -i {input} -ss 5 -t 10 -c copy {output}. It runs without a shell and must start with ffmpeg. Every -i must be an {input}/{inputN} placeholder or a generated -f lavfi source, and {output} is the only output. Rejected with a 400 that names the problem: shell metacharacters (; | & $ ), protocols or URLs anywhere in the command (file:, concat:, subfile,…), the movie=, amovie=andsendcmdfilters, absolute paths other than fonts under /usr/share/fonts,.., and -safe 0. A command that would never end (-stream_loop -1, -loop 1, or a lavfi source without a duration) needs -t, -shortestor-frames; -stream_loopaccepts -1 to 100. Usage is charged at the longer of the input and output durations, so looped or generated outputs count at their full length. The output is not posted anywhere; fetch it with download_ffmpeg_result. Returns ajob_idyou can poll withget_ffmpeg_job`.

Input Schema

NameRequiredDescriptionDefault
filesNoPublic URLs of multiple input media files, when the job needs more than one source.
input_urlNoPublic URL of the input media. Use this for a single source file.
full_commandNoOptional ffmpeg command with `{input}` / `{input0}`… and `{output}` placeholders. Must start with `ffmpeg`; each `-i` is a placeholder or `-f lavfi`. Protocols or URLs inside the command, `movie=`/`sendcmd`, absolute paths (except /usr/share/fonts), `..`, `-safe 0` and shell metacharacters are rejected. Endless inputs need `-t` or `-shortest`; `-stream_loop` is capped at 100.
output_filenameNoOptional preferred output filename, e.g. clip.mp4 or thumbnail.jpg.

Output Schema

NameRequiredDescriptionDefault
resultNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.17.2
    • changedInput schema / properties / full_command / description
      Previous value: -"Optional explicit command. Must start with `ffmpeg`; shell metacharacters are rejected by the API."New value: +"Optional ffmpeg command with `{input}` / `{input0}`… and `{output}` placeholders. Must start with `ffmpeg`; each `-i` is a placeholder or `-f lavfi`. Protocols or URLs inside the command, `movie=`/`sendcmd`, absolute paths (except /usr/share/fonts), `..`, `-safe 0` and shell metacharacters are rejected. Endless inputs need `-t` or `-shortest`; `-stream_loop` is capped at 100."
  2. Changed2 schema fields changedv0.11.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedOutput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
  3. First observedv0.4.0

TDQS

A4.6/5.0
Behavior5/5

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

With annotations only covering readOnly=false/destructive=false/openWorld=true, the description supplies the real behavioral burden: the exact validation rules that trigger a 400 (shell metacharacters, protocols, movie=/sendcmd, absolute paths, .., -safe 0), the no-shell execution model, and the infinite-loop requirement (-t/-shortest/-frames, -stream_loop cap of 100). It even discloses the billing model ('charged at the longer of input and output durations'), which is non-obvious and affects command design.

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?

Front-loaded with purpose, then inputs, then command rules, then billing and follow-up calls — a sensible order with little redundancy. It is a single very dense paragraph and slightly long, but nearly every clause carries load-bearing constraint information.

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?

For a job-submission tool with an output schema, this covers everything an agent needs: input sourcing, command grammar, rejection conditions, loop-avoidance, cost model, and the job_id polling path. No material gap remains for a correct first invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3, but the description adds meaning the schema cannot: a concrete worked example of `full_command` with `{input}`/`{output}` placeholders, the rule that every `-i` must be a placeholder or a `-f lavfi` source, and that `{output}` is the only output. That materially improves correct parameter construction.

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?

Names a specific verb and resource ('Process media with FFmpeg on Upload-Post's encoding servers') and immediately enumerates the operations it covers (trim, transcode, resize, watermark, concatenate, thumbnail). It is clearly distinguishable from the polling/result siblings get_ffmpeg_job and download_ffmpeg_result.

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?

Gives concrete input context (public HTTP(S) URLs, `input_url` for one file vs `files` for several) and routes the agent forward to download_ffmpeg_result and get_ffmpeg_job. It stops short of stating when to prefer this tool over, say, upload_video or a plain media upload, so the alternatives discussion is incomplete for a 50+ sibling toolset.

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

Deploy Server

Other Tools