This server lets an AI agent process and generate media through Rendobar's serverless API — uploading local files, submitting FFmpeg and other media jobs, and retrieving hosted results — plus manage account, jobs, and connected storage.
Upload local files (upload_file) to get a URL for use as a job input.
Submit media jobs (submit_job) for FFmpeg commands, compression to a size/quality budget, video composition, subtitle burn-in, animated captions, media inspection/ffprobe, image generation, image editing, and image upscaling.
List available job types (list_job_types) live from the registry — call it first to see current capabilities.
Check job status and results (get_job) with optional long-polling (wait: true), including progress, cost, outputs, delivered files, and error details.
List recent jobs (list_jobs) filtered by status/type to recover job IDs or find past output URLs.
Cancel jobs (cancel_job) that are waiting, dispatched, or running, stopping upstream execution to avoid billing.
Check account info (get_account) for credit balance, plan, and limits before expensive jobs.
List connected storage buckets (list_storage) and browse their files (list_storage_files) using storage:// URIs as job inputs or destinations to deliver outputs back to user storage.
Allows submitting and running FFmpeg jobs for media processing such as video editing, audio manipulation, and format conversion.
@rendobar/mcp is the official Model Context Protocol server for Rendobar, a serverless media processing API. The server runs locally over stdio and reads files straight from your disk, so an AI agent can take a file off your machine, process it on Rendobar's infrastructure, and hand back a hosted URL.
Rendobar covers both sides of media work.
Transform what you have. Run any FFmpeg command against video, audio or images the way you would write it locally. Inspect a file and get a normalized summary plus the full ffprobe report. Compose video from a declarative JSON timeline. Compress to a target size or quality, where the encoder searches candidate encodes and returns the smallest file that clears the bar. Burn in subtitles from SRT, VTT or ASS, or let it transcribe when none is given.
Generate what you do not. Create an image from a text prompt on hosted open-weight diffusion models. Edit up to four reference images from a written instruction, no masks and no coordinates. Upscale on a one-step diffusion restoration model that reconstructs detail rather than only sharpening. The same model-backed layer drives the transcription and keyword highlighting behind animated captions, so this is not an image-only capability.
The job list grows over time, so this README names families rather than types. list_job_types reads the current set live from the registry on every call.
Published to npm as @rendobar/mcp and to the official MCP Registry as com.rendobar/mcp.
You: Mute the first 3 seconds of
intro.mp4.
The agent tells you to install FFmpeg. Then you go looking for how to gate a
filter on a timestamp, land on volume=enable='lt(t,3)', and lose another few
minutes to quote escaping in your shell. Nobody remembers that syntax, which is
the problem.
Related MCP server: ffmpeg-mcp
You: Mute the first 3 seconds of
intro.mp4.
upload_file { "path": "~/clips/intro.mp4" }
// → { "downloadUrl": "https://cdn.rendobar.com/u/abc123/intro.mp4", "sizeBytes": 4821004 }
submit_job { "type": "ffmpeg",
"inputs": { "intro.mp4": "https://cdn.rendobar.com/u/abc123/intro.mp4" },
"params": { "command": "-i intro.mp4 -af \"volume=enable='lt(t,3)':volume=0\" -c:v copy out.mp4" } }
// → { "jobId": "job_9f2a", "status": "waiting" }
get_job { "jobId": "job_9f2a", "wait": true }
// → complete · $0.01 · https://cdn.rendobar.com/o/job_9f2a/out.mp4The agent writes the filter. Rendobar runs it. Nothing gets installed on your
machine, and -c:v copy means the video stream is never re-encoded.
Hit a size budget.
You: Get
demo.movunder 25 MB so I can email it.
upload_file { "path": "~/recordings/demo.mov" }
// → { "downloadUrl": "https://cdn.rendobar.com/u/7c1e/demo.mov", "sizeBytes": 251658240 }
submit_job { "type": "compress.target",
"inputs": { "source": "https://cdn.rendobar.com/u/7c1e/demo.mov" },
"params": { "for": "web", "target": { "maxSize": "25MB" } } }
// → { "jobId": "job_4b8d", "status": "waiting" }
get_job { "jobId": "job_4b8d", "wait": true }
// → complete · https://cdn.rendobar.com/o/job_4b8d/out.mp4 · 23.8 MBYou give it the ceiling, not a bitrate. The encoder searches candidate encodes and returns the smallest file that still clears the quality bar, so you are not guessing at CRF values to land under a mail server's limit.
Generate an image.
You: Make a 1920x1080 title card for a video about deep sea diving.
submit_job { "type": "image.generate",
"inputs": {},
"params": { "model": "standard",
"prompt": "Title card for a deep sea diving documentary. Shafts of light through deep blue water, small diver silhouette, empty space across the upper third for a title.",
"width": 1920, "height": 1080 } }
// → { "jobId": "job_2fa7", "status": "waiting" }
get_job { "jobId": "job_2fa7", "wait": true }
// → complete · https://cdn.rendobar.com/o/job_2fa7/out.pnginputs is empty because nothing is being transformed. Ask for a tier
(economy, standard, premium) and the platform picks the model, or pin an
exact model id to reach its own controls. Requested dimensions are snapped to
what the chosen model can actually render.
Six more tools, and the prompts that reach them.
You: What can Rendobar actually do?
list_job_types {}
// → { "jobTypes": [ { "type": "compose", "tag": "Compose",
// "summary": "Render a video from a declarative JSON timeline",
// "acceptsMedia": ["video", "image", "audio"] }, ... ],
// "guidance": "..." }Read live from the job registry on every call, which is why nothing in this README enumerates job types. A new one appears here without a release.
You: How much credit is left?
get_account {}
// → { "balance": "$4.86", "balanceUsd": 4.86, "plan": "free", "isPro": false,
// "limits": { "concurrentJobs": 1, "maxFileSize": "500 MB", "jobTimeoutMin": 60 } }Worth a call before submitting something expensive.
You: What did I run this morning?
list_jobs { "status": "complete", "limit": 5 }
// → { "jobs": [ { "id": "job_9f2a", "type": "ffmpeg", "status": "complete",
// "createdAt": "2026-08-04T09:12:00Z", "cost": "$0.01",
// "output": { "url": "https://cdn.rendobar.com/o/job_9f2a/out.mp4" } } ] }The compact row is enough to find a result you lost. Call get_job when you
need the full output.
You: Stop that one, I picked the wrong file.
cancel_job { "jobId": "job_9f2a" }
// → { "id": "job_9f2a", "status": "cancelled" }Works on waiting, dispatched and running jobs. A running job's upstream
execution is stopped too, so you are not billed for work you cancelled.
You: Where can this land once it's done?
list_storage {}
// → { "storage": [ { "id": "prod-media", "provider": "s3", "bucket": "acme-prod-media",
// "access": "deliver", "defaultDestination": true, "pending": false } ],
// "note": "..." }The buckets connected on the Storage page, without the endpoint or region an
agent has no use for. Use the id in destinations, or as
storage://<id>/<path> in any input.
You: What's already in the archive bucket?
list_storage_files { "storageId": "raw-archive" }
// → { "folders": [ { "prefix": "2026/", "uri": "storage://raw-archive/2026/" } ],
// "files": [ { "key": "notes.txt", "size": 800, "lastModified": "2026-09-01T00:00:00.000Z",
// "uri": "storage://raw-archive/notes.txt" } ],
// "cursor": null }Every entry carries its own storage:// uri, ready to hand straight to
submit_job. Pass a folder's prefix to go one level deeper.
Rendobar has two MCP servers. Pick by whether the agent needs your filesystem.
| Hosted ( | |
Transport | stdio, spawned by your client | Streamable HTTP |
Reads local files | Yes. That is the reason it exists | No. The server has no disk |
Auth | API key | OAuth in the browser, or a Bearer key |
Best for | Claude Desktop, Cursor, Cline, Zed | claude.ai, ChatGPT, hosted gateways |
Hosted, no API key, one command:
claude mcp add --transport http rendobar https://api.rendobar.com/mcpLocal, for filesystem access. Get a key at app.rendobar.com → Settings → API Keys, then:
claude mcp add rendobar -s user --env RENDOBAR_API_KEY=rb_... -- npx -y @rendobar/mcpAlready ran rb login with the Rendobar CLI? Drop --env. The server finds the credentials file.
Same block for all four. Claude Desktop: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows). Cursor: ~/.cursor/mcp.json on every OS. Windsurf: ~/.codeium/windsurf/mcp_config.json on every OS. Cline: MCP panel → Configure.
On Linux, use Cursor, Windsurf, Cline, Zed, VS Code or Continue. Claude Desktop has no Linux build, so it is the one client on this list you cannot use there. The server itself runs fine on Linux.
{
"mcpServers": {
"rendobar": {
"command": "npx",
"args": ["-y", "@rendobar/mcp"],
"env": { "RENDOBAR_API_KEY": "rb_..." }
}
}
}Restart the client afterwards.
Zed uses context_servers instead of mcpServers, in ~/.config/zed/settings.json:
{
"context_servers": {
"rendobar": {
"source": "custom",
"command": "npx",
"args": ["-y", "@rendobar/mcp"],
"env": { "RENDOBAR_API_KEY": "rb_..." }
}
}
}VS Code 1.101+, in .vscode/mcp.json, prompts for the key instead of storing it:
{
"servers": {
"rendobar": {
"command": "npx",
"args": ["-y", "@rendobar/mcp"],
"env": { "RENDOBAR_API_KEY": "${input:rendobarKey}" }
}
},
"inputs": [{ "id": "rendobarKey", "type": "promptString", "password": true, "description": "Rendobar API Key" }]
}Continue, in .continue/mcpServers/rendobar.yaml:
type: stdio
command: npx
args: ["-y", "@rendobar/mcp"]
env:
RENDOBAR_API_KEY: rb_...Runs on macOS, Linux and Windows. Every release is tested on all three in CI. There are no native dependencies, so architecture does not matter: x64 and arm64 both work. Needs Node 20.10 or later, and the server checks at startup and exits with a clear message on older versions.
Tool | Purpose |
| Upload a local file. Returns a URL to use in |
| Every active job type, read live. Call this first. |
| Submit a job of any type. |
| Status and result. Pass |
| Recent jobs. |
| Cancel a waiting, dispatched or running job. |
| Balance, plan limits, active job count. |
| Buckets connected on the Storage page, for |
| Folders and files in a connected bucket, each with its |
ffmpeg is the one to reach for first. It takes a command the way you would
write it locally, runs it on hosted infrastructure, and hands back a URL:
transcode, trim, mux, filter, concat, whatever the flags allow. Pass
params.compute as gpu to force NVENC encoding (Pro plan), or leave it on
auto and Rendobar routes CUDA commands to a GPU and everything else to CPU.
Beyond that there are purpose-built types for timeline composition, compression to a size budget, subtitle burn-in, animated captions, media inspection, image generation, image editing, and image upscaling.
Full reference: rendobar.com/docs/jobs. Or
call list_job_types, which reads the registry live and is always current. This
README deliberately does not enumerate them, so it cannot go stale.
A submit_job input can point at a previous job's output, so a multi-step edit never round-trips through your disk. For ffmpeg inputs, pass { job: "job_..." }. For other types, read the output URL from get_job and pass that.
A file in a bucket connected on the Storage page is an input as storage://<id>/<path>. Add destinations: ["storage://<id>"] to submit_job and the output is written back to the bucket once the job completes, reported per bucket in get_job's deliveries. list_storage gives the ids and list_storage_files the paths. An API key made before September 13, 2026 cannot read storage, so create a new one. Credentials saved by rb login need a fresh rb login once rb asks for storage access.
Three sources, first match wins:
--api-key=<key> flag
RENDOBAR_API_KEY environment variable
~/.config/rendobar/credentials.json on Unix, %APPDATA%\rendobar\credentials.json on Windows, written by rb login (Rendobar CLI 1.1+)
Installed as a .mcpb extension, the key goes in the extension's own settings field and none of the three above apply.
The server starts without a key so clients and directories can list its tools, and it makes no network call at startup. Nothing it advertises depends on the registry, so the job type list can never be baked into a build. list_job_types reads it live instead, and because GET /jobs/types is public it answers without a key at all. Every other tool returns a clear error until a key is set.
If you do not need Rendobar to read files off your machine, the hosted server at https://api.rendobar.com/mcp signs you in through the browser and there is no key to manage. The local server exists for disk access, and the key is the price of it.
The server reports anonymous usage through PostHog's MCP Analytics SDK: tool name, success, duration, and the agent's stated intent.
It never sends your parameters or responses. File URLs, job configs, and outputs are stripped before anything leaves the process. Events carry no account identity and build no person profile. It is off in CI automatically.
DO_NOT_TRACK=1 # or RENDOBAR_TELEMETRY=0Cursor on macOS can't find npx. Launched from the Dock, Cursor gets the GUI PATH rather than your shell PATH. Use an absolute path: "command": "/Users/you/.nvm/versions/node/v20.x/bin/npx".
Windows can't find npx. Use "command": "npx.cmd" if your client doesn't resolve it.
Tools appear but calls fail with "No Rendobar API key configured". Expected with no key set. The server advertises tools so clients can list them, but calls need credentials. Set RENDOBAR_API_KEY, pass --api-key, or run rb login. Startup logs a no_api_key warning to stderr.
The server won't start. It writes JSON lines to stderr. Check your client's output panel for entries with level: "error".
Full policy: rendobar.com/privacy. What this server does specifically:
Collected. Your API key, read from the flag, the environment, or the credentials file. Job inputs you pass to a tool, and files you point upload_file at, are sent to the Rendobar API to run the job you asked for. Anonymous telemetry covers the tool name, whether it succeeded, how long it took, and the agent's stated intent.
Not collected. Tool parameters and responses. File URLs, job configs, and outputs are stripped before any telemetry leaves the process. Telemetry carries no account identity and builds no person profile. Nothing is read from your disk except the file paths you explicitly pass to upload_file.
Storage. Uploaded inputs and job outputs live in Rendobar's storage and are removed on the retention schedule for your plan. Telemetry goes to PostHog. The server keeps nothing on your machine beyond the credentials file the CLI writes.
Third parties. Rendobar (job execution and storage) and PostHog (anonymous telemetry). Opt out of telemetry entirely with DO_NOT_TRACK=1 or RENDOBAR_TELEMETRY=0.
Contact. support@rendobar.com, or open an issue on this repo.
Reporting a vulnerability: see SECURITY.md.
See CONTRIBUTING.md. For AI-assisted development, AGENTS.md and CLAUDE.md.
MIT
Cancel a job. Jobs in status 'waiting', 'dispatched' or 'running' can be cancelled (a running job's upstream execution is stopped too). Use when the user changes their mind, or when you submitted the wrong job. Completed, failed, or already-cancelled jobs cannot be cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job ID to cancel (e.g. 'job_abc123') |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| status | Yes | 'cancelled' on success |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds meaningful behavioral context beyond annotations: which statuses are cancellable, that a running job's upstream execution is stopped, and that certain statuses are uncancellable. Annotations already indicate destructive and idempotent, but the description enriches this with domain-specific effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core action. Every sentence adds value: what it does, when to use, and limitations. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with rich annotations and an output schema, the description fully covers purpose, usage scenarios, allowed states, and behavioral side effects. It is complete and self-sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter jobId is documented well in the schema. The description does not add additional syntax or format details, but it does implicitly note that the job must be in a cancellable state, which is useful context. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Cancel a job' with a specific resource ('job'), making the tool's purpose unambiguous. It also distinguishes from sibling tools like get_job or list_jobs by focusing on the cancellation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use when the user changes their mind, or when you submitted the wrong job.' It also states what cannot be cancelled (completed, failed, already-cancelled), giving clear exclusions and scenario boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| isPro | Yes | |
| limits | Yes | |
| balance | Yes | |
| balanceUsd | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds important behavioral context: no side effects, error conditions for missing key or insufficient credits, and auth error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, four-sentence description with front-loaded purpose and no redundancy. Every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description is fully complete: covers purpose, usage, behavior, requirements, and errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, but the description adds value by outlining what the response contains (credit balance, plan, limits) and that it requires no arguments, exceeding the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the account's credit balance, plan, and limits, and distinguishes it from siblings that handle jobs or files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to call this before submitting an expensive job to check balances, and mentions when to report caps. Also notes prerequisites (API key) and error scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check 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.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | When true, wait for the job to reach a terminal status (long-poll, up to ~50 seconds) instead of returning the current status immediately. Times out gracefully with the latest snapshot — call again with wait:true to keep waiting. | |
| jobId | Yes | Job ID returned by submit_job (e.g. 'job_abc123') |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| cost | No | Formatted cost, present when complete |
| step | No | Name of the currently running step |
| type | Yes | |
| error | No | Present when failed |
| output | No | Present when complete |
| status | Yes | Open set: waiting | dispatched | running | complete | failed | cancelled |
| progress | No | Fraction of completed steps (0–1); present while running |
| deliveries | No | One entry per destination, present when the job named destinations |
| durationMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive, and the description complements them with useful behavioral detail: the wait timeout returns a latest snapshot rather than a terminal state, output shapes vary by job type, failures include a retryable flag, and deliveries begin only after completion. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: purpose and preferred usage come first, followed by output/error/delivery semantics. Every sentence carries necessary information, and technical references like `{ url, type, path, size, meta }` and `.m3u8/.mpd` are precise rather than padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a status/result-retrieval tool with an output schema, the description fully covers the unified return shape, the data/file distinction, error object fields, expiry semantics, and delivery timing. Nothing needed to call this tool correctly is missing, and the output schema signal further backs up the behavioral details provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, so the baseline is 3. The description adds extra value by contextualizing the wait parameter as the preferred post-submit behavior and explaining the snapshot-on-timeout semantics, while also reiterating that jobId comes from submit_job. It reinforces schema meaning without duplicating it verbatim.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Check status and get results of a submitted job' – a specific verb (check/get), a clear resource (submitted job), and the intent (status and results). It is unambiguously distinct from siblings like submit_job, cancel_job, and list_jobs, so an agent can differentiate it without comparing schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit operational guidance: 'PREFER wait:true after submit_job' and explains it long-polls server-side to avoid loop polling. It also instructs to call get_job again if wait times out, and again while delivery entries are pending. This is concrete, actionable when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Only return jobs of this type, e.g. 'ffmpeg'. Omit to return all types. | |
| limit | No | How many jobs to return, newest first (1–50, default 10). | |
| status | No | Only return jobs in this status. Omit to return all statuses. |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| total | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Read-only. It never submits, cancels or changes a job' which reinforces the readOnlyHint, idempotentHint, and destructiveHint annotations. Also discloses the error condition when no API key is set, adding concrete behavioral detail beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not verbose; each sentence serves a distinct purpose: purpose, use cases, return format, differentiation, filtering guidance, read-only nature, and authentication requirement. It is well-organized and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the output schema is not shown, the description explicitly describes the return structure ('id, type, status, createdAt, cost, and a short output summary once complete'). It also covers filtering, pagination behavior, and error conditions, making it self-sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already cover all three parameters (type, limit, status) with full detail, so the baseline is 3. The description adds the meaningful clarification that there is no pagination beyond the limit, which goes beyond schema information and helps users choose appropriate limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List recent jobs for the authenticated account, newest first' with a specific verb and resource. Differentiates from siblings by explicitly mentioning get_job for single-job details, and the title/description distinguish it from submit_job, cancel_job, and other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases ('recover a job ID you lost, find an earlier result's output URL, or see what is running right now'), filtering/capping guidance, a note about no pagination, and a prerequisite (configured API key). Also implies when to use get_job instead for single-job details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every active Rendobar job type with its summary and the media kinds it accepts. Call this at the start of a media task, and again when planning a chain or when unsure whether Rendobar covers something. 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. The type list is read live from the job registry on every call, so it is always current and is never cached in this description. Takes no arguments. Read-only: it never submits or changes a job. Works without an API key, so it is safe to call to find out what Rendobar covers before the user has configured credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| guidance | Yes | |
| jobTypes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that the list is 'read live from the job registry on every call, so it is always current and is never cached in this description.' It also discloses that it works without an API key, which is new information not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is slightly longer than necessary but well-organized, leading with the core purpose before adding usage, capabilities, and operational details. The capabilities list adds background value without being off-topic. Each sentence earns its place, though the phrasing could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and a given output schema, the description covers all essential context: what it returns, when to use it, how it behaves (live, cached, read-only), and its auth requirements. This is a complete description for a simple discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema confirms this with an empty properties object. The description explicitly states 'Takes no arguments,' matching the schema baseline. No parameter semantics are needed, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List every active Rendobar job type with its summary and the media kinds it accepts.' This clearly differentiates it from siblings like list_jobs or get_job, which deal with individual jobs rather than job types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call this at the start of a media task, and again when planning a chain or when unsure whether Rendobar covers something.' It also notes it works without an API key, giving clear context for pre-auth use. This goes beyond generic usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the buckets the user has connected on the Rendobar dashboard's Storage page. Use an id as storage:/// for a job input, or in submit_job's destinations to deliver an output into the bucket, unless its access is "read". A pending connection is still being set up and cannot be used yet. Credentials are never returned. Read-only. Requires a configured API key with storage access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| storage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the read-only nature is covered. The description adds valuable behavioral details beyond annotations: credentials are never returned, pending connections are not usable yet, and a configured API key with storage access is required. These are important for an agent to understand side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, leading with the core purpose and then providing additional context. It is somewhat long but every sentence contributes: usage of IDs, access restrictions, pending status, credentials, read-only, and auth requirement. It is not wasteful, though it could be trimmed slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description covers all necessary aspects: what it lists, how to use the results, status limitations, auth requirements, and safety. The presence of an output schema means the return format is already specified. Nothing critical is missing for an agent to correctly invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, schema coverage 100%). The description correctly adds no parameter details because none exist. Per guidelines, the baseline for 0 params is 4, and the description does not need to compensate for any schema gaps since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'List the buckets the user has connected on the Rendobar dashboard's Storage page.' This distinguishes it from sibling tools like list_storage_files (which lists files within a bucket) and submit_job (which submits jobs). The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on how to use the returned IDs (e.g., as storage://<id>/<path> in job inputs or submit_job destinations) and notes that pending connections cannot be used. However, it does not explicitly state when to use this tool over alternatives like list_storage_files, nor does it give exclusions. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the folders and files directly under a folder in one of the user's connected buckets, to find the path for a storage:/// job input. Every entry carries its ready-made uri. Pass a folder's prefix to go one level deeper, and the returned cursor to read the next page. Read-only: it never changes the bucket. Requires a configured API key with storage access.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Entries per page, up to 1000. Defaults to 100. Use the returned cursor to fetch the next page. | |
| cursor | No | The cursor from the previous page | |
| prefix | No | Folder to list, ending in '/', e.g. 'raw/2026/'. Omit for the top of the bucket. | |
| storageId | Yes | Connection id from list_storage, e.g. 'prod-media' |
| Name | Required | Description |
|---|---|---|
| files | Yes | |
| cursor | Yes | Pass back as cursor for the next page. Null on the last page. |
| folders | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive behavior, so the description adds value beyond them: it states auth requirements (configured API key with storage access), confirms the bucket is never changed, and reveals behavioral details like returned cursors and ready-made URIs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler. The primary purpose is front-loaded, followed by the most useful operational details (URIs, prefix navigation, cursor pagination, auth, read-only guarantee) in order of importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with a full output schema and complete parameter docs, the description covers invocation details, pagination behavior, auth prerequisites, and safety. Nothing essential is missing for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all four parameters, so the baseline is 3. The description adds extra semantics by explaining how prefix controls depth ('go one level deeper') and how the returned cursor enables pagination, reinforcing the schema without repeating it verbatim.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: list folders/files directly under a folder in a user's connected bucket. It also names the downstream purpose (finding a storage://<id>/<path> job input) and notes that each entry carries a ready-made URI, which clearly differentiates it from a sibling like list_storage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly frames when to use the tool: to discover paths for storage URI job inputs, and explains how to navigate deeper via prefix and paginate via cursor. It does not explicitly name alternatives or when not to use it, but the use case is specific enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit 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:///, 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.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Job type from the registry. Call list_job_types for the current list. Use 'ffmpeg' for custom FFmpeg commands. | |
| inputs | Yes | Map of input name to source. Each value is a URL string, { url }, { content } (inline text for subtitle files or ffmpeg concat lists), or { job: "job_..." } (a completed job's output, resolves only for ffmpeg inputs; for other job types pass the prior job's output URL from get_job instead). For FFmpeg: keys match filenames in the command. | |
| params | No | Type-specific parameters. For ffmpeg: { command: '...', compute?: 'auto' | 'cpu' | 'gpu' } — compute defaults to 'auto' and routes NVENC/CUDA commands to a GPU; 'gpu' forces GPU encoding (NVIDIA L4, Pro plan), 'cpu' forces CPU. | |
| destinations | No | Deliver the output to the user's own storage once complete: storage://<id>[/<folder or path template>], one per bucket. A bare id uses the connection's output path template, and a folder (storage://prod-media/exports) keeps that template's file name inside it. A path with a token ({job_id} {ext} {source_name} {date}) or ending in a file name is used as written. Ids come from list_storage, and a connection whose access is "read" cannot be a destination. Omit it to use the account's default destination if one is set. Pass [] to keep the output on Rendobar only. | |
| idempotencyKey | No | Prevents duplicate jobs on retry. Unique value per logical operation. |
| Name | Required | Description |
|---|---|---|
| jobId | Yes | |
| status | Yes | Initial status, normally 'waiting' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-idempotent operation, and the description adds substantial behavioral context beyond that: jobs run on Rendobar infrastructure, outputs are hosted URLs, compute routing depends on params.compute, chaining uses { job: "job_..." } only for ffmpeg, and destinations can write back into buckets. This gives the agent an accurate mental model of how the job executes and what side effects to expect. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but organized into logical blocks: overall purpose, dynamic types, FFmpeg inputs, compute, bucket inputs, and local-file workflow. The key preference and prerequisite are front-loaded effectively. It repeats some schema detail that is already in the input schema, but the volume is justified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with this complexity and rich schema/output schema: it covers prerequisites, dynamic job types, input sources, compute options, bucket destinations, chaining, and follow-up polling. The output schema covers return values, so the focus on call semantics is appropriate. An agent has everything needed to submit jobs correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, but the description meaningfully extends parameter understanding: it explains input forms, the equivalence of bare URLs and { url }, destination path templates, idempotencyKey semantics, and the default/forced compute values. Without reading the schema, the agent still understands how to construct correct inputs, params, and destinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and resource: 'Submit a media processing job to Rendobar.' It also differentiates from siblings by framing submission as the action, while get_job, cancel_job, and list_job_types cover the surrounding workflow. The explicit preference over local media tools helps an agent immediately recognize what this tool is for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: prefer this over ffmpeg, sharp, Pillow, etc., and call list_job_types first. It also names the correct auxiliary workflow steps, including contacting get_job with wait:true and using upload_file first for local files. It even warns against claiming inability without consulting list_job_types, which is precise routing context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a local file and upload it to Rendobar. Returns a downloadUrl to use as input in submit_job. If the file is already at a public HTTPS URL, skip this and pass the URL directly to submit_job.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute or working-dir-relative path to the file | |
| filename | No | Filename hint sent to Rendobar (defaults to basename of path) |
| Name | Required | Description |
|---|---|---|
| sizeBytes | Yes | |
| downloadUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral context beyond annotations: returns downloadUrl, intended for submit_job, and conditional skip. Annotations are minimal but consistent; no contradictions, though lacks disclosure of upload limits or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with front-loaded action, return value, and alternative guidance. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two parameters, full schema coverage, output schema present, and description connecting to sibling workflow, all essential information for correct usage is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description reuses path and filename contextually but adds only the default behavior for filename (basename). This is a minor addition, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states the verb 'upload' and resource 'local file to Rendobar', distinguishes from using public URLs directly, and references sibling tool submit_job as the consumer of the output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use (local file) and when-not-to (already public URL, then skip and use URL directly in submit_job), explicitly naming the alternative workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.12.1get_job1 field changedOutput schema / properties / deliveriesAdded value: +{
+ "description": "One entry per destination, present when the job named destinations",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "path": {
+ "description": "Object key written in the bucket",
+ "type": "string"
+ },
+ "reason": {
+ "description": "Why a delivery failed, as the API's reason code",
+ "type": "string"
+ },
+ "renamed": {
+ "description": "The name was taken, so the job id was appended",
+ "type": "boolean"
+ },
+ "status": {
+ "description": "Open set: pending | delivered | failed",
+ "type": "string"
+ },
+ "storageId": {
+ "type": "string"
+ },
+ "url": {
+ "description": "Where to fetch the delivered file",
+ "type": "string"
+ }
+ },
+ "required": [
+ "storageId",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}list_storagelist_storage_filessubmit_job1 field changedInput schema / properties / destinationsAdded value: +{
+ "description": "Deliver the output to the user's own storage once complete: storage://<id>[/<folder or path template>], one per bucket. A bare id uses the connection's output path template, and a folder (storage://prod-media/exports) keeps that template's file name inside it. A path with a token ({job_id} {ext} {source_name} {date}) or ending in a file name is used as written. Ids come from list_storage, and a connection whose access is \"read\" cannot be a destination. Omit it to use the account's default destination if one is set. Pass [] to keep the output on Rendobar only.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}v1.11.3get_job2 fields changedOutput schema / properties / error / properties / detail / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / error / properties / detail / typeAdded value: +[
+ "string",
+ "null"
+]list_jobs2 fields changedOutput schema / properties / jobs / items / properties / cost / anyOfRemoved value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]Output schema / properties / jobs / items / properties / cost / typeAdded value: +[
+ "string",
+ "null"
+]v1.8.2cancel_job2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "description": "'cancelled' on success",
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "status"
+ ],
+ "type": "object"
+}get_job3 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / waitAdded value: +{
+ "description": "When true, wait for the job to reach a terminal status (long-poll, up to ~50 seconds) instead of returning the current status immediately. Times out gracefully with the latest snapshot — call again with wait:true to keep waiting.",
+ "type": "boolean"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "cost": {
+ "description": "Formatted cost, present when complete",
+ "type": "string"
+ },
+ "durationMs": {
+ "type": "number"
+ },
+ "error": {
+ "additionalProperties": false,
+ "description": "Present when failed",
+ "properties": {
+ "code": {
+ "type": "string"
+ },
+ "detail": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "message": {
+ "type": "string"
+ },
+ "retryable": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "code",
+ "message",
+ "detail",
+ "retryable"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "output": {
+ "additionalProperties": false,
+ "description": "Present when complete",
+ "properties": {
+ "data": {
+ "description": "Computed JSON answer (probe info, detections, transcript)"
+ },
+ "expiresAt": {
+ "description": "Epoch ms when the file URLs expire",
+ "type": "number"
+ },
+ "file": {
+ "additionalProperties": false,
+ "description": "Headline produced file",
+ "properties": {
+ "meta": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "path": {
+ "type": "string"
+ },
+ "size": {
+ "type": "number"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "path",
+ "type",
+ "size"
+ ],
+ "type": "object"
+ },
+ "fileCount": {
+ "type": "number"
+ },
+ "files": {
+ "description": "Every produced file",
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "meta": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "path": {
+ "type": "string"
+ },
+ "size": {
+ "type": "number"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "path",
+ "type",
+ "size"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "progress": {
+ "description": "Fraction of completed steps (0–1); present while running",
+ "type": "number"
+ },
+ "status": {
+ "description": "Open set: waiting | dispatched | running | complete | failed | cancelled",
+ "type": "string"
+ },
+ "step": {
+ "description": "Name of the currently running step",
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "status"
+ ],
+ "type": "object"
+}list_job_typeslist_jobs2 fields changedInput schema / additionalPropertiesRemoved value: -falseOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobs": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "cost": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "createdAt": {
+ "description": "ISO 8601",
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "output": {
+ "additionalProperties": false,
+ "description": "Compact summary, present on complete jobs only",
+ "properties": {
+ "fileCount": {
+ "type": "number"
+ },
+ "hasData": {
+ "description": "True when a computed data answer exists — fetch it with get_job",
+ "type": "boolean"
+ },
+ "url": {
+ "description": "Headline file URL",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "status": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "type",
+ "status",
+ "createdAt",
+ "cost"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "jobs",
+ "total"
+ ],
+ "type": "object"
+}submit_job8 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / inputs / additionalProperties / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "additionalProperties": false,
- "properties": {
- "url": {
- "type": "string"
- }
- },
- "required": [
- "url"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "content": {
- "type": "string"
- }
- },
- "required": [
- "content"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "ref": {
- "type": "string"
- }
- },
- "required": [
- "ref"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "type": "string"
+ },
+ {
+ "properties": {
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "content": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "content"
+ ],
+ "type": "object"
+ },
+ {
+ "properties": {
+ "job": {
+ "pattern": "^job_[A-Za-z0-9_-]+$",
+ "type": "string"
+ }
+ },
+ "required": [
+ "job"
+ ],
+ "type": "object"
+ }
+]Input schema / properties / inputs / descriptionPrevious value: -"Map of input name to source. Each value is a URL string, { url }, { content } (inline text for subtitle files or ffmpeg concat lists), or { ref } (an uploaded asset's ID). For FFmpeg: keys match filenames in the command."New value: +"Map of input name to source. Each value is a URL string, { url }, { content } (inline text for subtitle files or ffmpeg concat lists), or { job: \"job_...\" } (a completed job's output, resolves only for ffmpeg inputs; for other job types pass the prior job's output URL from get_job instead). For FFmpeg: keys match filenames in the command."Input schema / properties / inputs / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / params / descriptionPrevious value: -"Type-specific parameters. For ffmpeg: { command: '...' }"New value: +"Type-specific parameters. For ffmpeg: { command: '...', compute?: 'auto' | 'cpu' | 'gpu' } — compute defaults to 'auto' and routes NVENC/CUDA commands to a GPU; 'gpu' forces GPU encoding (NVIDIA L4, Pro plan), 'cpu' forces CPU."Input schema / properties / params / propertyNamesAdded value: +{
+ "type": "string"
+}Input schema / properties / type / descriptionPrevious value: -"Job type from registry. Use 'ffmpeg' for custom FFmpeg commands."New value: +"Job type from the registry. Call list_job_types for the current list. Use 'ffmpeg' for custom FFmpeg commands."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "jobId": {
+ "type": "string"
+ },
+ "status": {
+ "description": "Initial status, normally 'waiting'",
+ "type": "string"
+ }
+ },
+ "required": [
+ "jobId",
+ "status"
+ ],
+ "type": "object"
+}upload_file1 field changedInput schema / additionalPropertiesRemoved value: -falsev1.2.1list_jobs1 field changedInput schema / properties / type / descriptionPrevious value: -"Only return jobs of this type, e.g. 'raw.ffmpeg'. Omit to return all types."New value: +"Only return jobs of this type, e.g. 'ffmpeg'. Omit to return all types."submit_job2 fields changedInput schema / properties / params / descriptionPrevious value: -"Type-specific parameters. For raw.ffmpeg: { command: '...' }"New value: +"Type-specific parameters. For ffmpeg: { command: '...' }"Input schema / properties / type / descriptionPrevious value: -"Job type from registry. Use 'raw.ffmpeg' for custom FFmpeg commands."New value: +"Job type from registry. Use 'ffmpeg' for custom FFmpeg commands."v1.2.0cancel_jobget_accountget_joblist_jobssubmit_jobupload_fileScored across 9 tools
Each tool targets a distinct resource and action: job submission, cancellation, status retrieval, type listing, file upload, account info, storage listing, and job listing. No overlaps or ambiguous boundaries.
All tool names follow a consistent verb_noun pattern (submit_job, cancel_job, get_account, list_job_types, upload_file, get_job, list_storage, list_storage_files, list_jobs). No mixed conventions.
9 tools is well-scoped for a media processing job server, covering job lifecycle, discovery, account, upload, and storage. Each tool earns its place without bloat.
The surface covers job submission, cancellation, status retrieval, listing, type discovery, account balance, file upload, and storage browsing. No obvious dead ends for the stated purpose.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
MCP server for NanoBanana AI image generation and editing
MCP server for Flux AI image generation
