How do I use Bannerbear MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Bannerbear MCP Server create an image from my Bannerbear template with the headline 'Launch Day'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Bannerbear MCP Server

by thenavidm

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Bannerbear MCP Server & CLI

npm License YouTube LinkedIn

Bannerbear V5 MCP server and CLI for Codex and AI agents. 75 shared tools for templates, images, animations, media jobs, workflows, assets, publications, webhooks and Instant URLs, with explicit mutation approval and isolated private workspace profiles.

One package gives you a task CLI, local stdio MCP and versioned desktop bundle. Built and maintained by Navid Moazzez. Complete setup: navid.me.

The terminal is an illustration of shipped command names and review/confirmation. It is not a recorded paid render. The official MCP already exists and is compared fairly below. Provider outcomes, desktop GUI and matched token/task measurements remain separately pending.

Two ways to use it

Command line

bannerbear-cli tools
bannerbear-cli get-account --agent
bannerbear-cli get-image-template --uid YOUR_TEMPLATE_UID --agent
bannerbear-cli preview-render-batch --payload-file /absolute/private/approved-batch.json --agent
bannerbear-cli create-image --payload-file /absolute/private/approved-image.json --confirm --agent

MCP server, for your AI app

codex mcp add bannerbear --env BANNERBEAR_TOKEN_FILE=/absolute/private/bannerbear.txt -- npx -y @thenavidm/bannerbear-mcp-cli@latest

Which one

Where you work	Route
Codex/Cursor/agents with a shell	CLI, local MCP or both
Claude Desktop	Bundled custom extension or local stdio
Scripts / cron / CI	Same task CLI and shared policies
Remote-only chat client	Official hosted Bannerbear OAuth MCP

Related MCP server: indesign-mcp-server

Features

Capability	CLI command	MCP tool
Templates / layers	get-image-template / get-layer-schema	get_image_template / get_layer_schema
Explicit render / batch	create-image / create-batch	create_image / create_batch
Exact batch review	preview-render-batch / apply-render-batch	preview_render_batch / apply_render_batch
Workflows / media	get-workflow / run-workflow / poll-job	get_workflow / run_workflow / poll_job
Confirmed local upload	upload-asset	upload_asset
Private creation keys	create-webhook / create-instant-url	create_webhook / create_instant_url
Schema / profiles	get-operation-schema / list-accounts	get_operation_schema / list_accounts

Number	Section	What it covers
1	What you can ask it	What you can ask it
2	Quick install	Quick install
3	Set up Bannerbear access	Set up Bannerbear access
4	Connect your client	Connect your client
5	Check it works	Check it works
6	Output, flags and exit codes	Output, flags and exit codes
7	MCP or CLI and token cost	MCP or CLI and token cost
8	Every tool and argument	Every tool and argument
9	Image, animation and workflow tasks	Image, animation and workflow tasks
10	Jobs, batches and local files	Jobs, batches and local files
11	Several private workspaces	Several private workspaces
12	Writing safely	Writing safely
13	How the two surfaces work	How the two surfaces work
14	Your data	Your data
15	Environment variables	Environment variables
16	Updates and removal	Updates and removal
17	Troubleshooting	Troubleshooting
18	API coverage and comparisons	API coverage and comparisons
19	Versions and migration	Versions and migration
20	FAQ	FAQ

1. What you can ask it

Find the intended image template and inspect every layer before changing text.
Preview the exact image body and approve one render.
Review an ordered image batch, then submit only the same profile and body.
Read workflow inputs and trigger only the requested run after approval.
Resume an existing image, animation, batch, media job or workflow run without submitting again.
Upload the chosen local asset only after approval.
Create a webhook/instant URL and save its one-time signing key privately.

Actual stdio discovery provides 75 shared tools: 33 reads/helpers and 42 confirmed mutations. Sixty-seven native operations derive from a pinned V5 OpenAPI snapshot; eight helpers add local profiles/schema/layers/preview, bounded pages/job polling and exact image-batch review/apply. This is a V5 refresh, not a V2 request-body rename.

2. Quick install

npm install -g @thenavidm/bannerbear-mcp-cli@latest
bannerbear-cli --version
bannerbear-cli tools
bannerbear-cli schema create-image
bannerbear-cli login

Node 22+ is required for manual installs. Discovery and local previews work without keys. Provider calls need a private V5 key; see INSTALL.md for every client/OS and desktop setup. Use the versioned source and desktop release linked below.

3. Set up Bannerbear access

Private V5 workspace keys

Sign in to the intended Bannerbear workspace and open V5 API Keys. Create a key restricted to the resource/action scopes needed for your task.
Store the secret outside all repositories. Set BANNERBEAR_TOKEN_FILE to an absolute owner-only token-only file, or configure BANNERBEAR_API_KEY privately. A V2 key cannot authenticate V5.
Run bannerbear-cli doctor for local presence/settings, then deliberately run doctor --network to read GET /v5/account. This prints current scope/quota metadata and proves only that account read, not every operation.
Read the actual template/workflow, inspect its layers/inputs and save the exact requested native body privately. Preview it locally and approve only the intended render or change.

A key belongs to a workspace. It is not scoped to an individual template; separate workspaces are the provider isolation route when an integration must reach only a subset. Provider template/workflow ownership and api_write_access locks still apply. READ_ONLY is an additional local control, not a replacement for restricted provider scopes.

The 22 current scopes pair :read and :write for images, image_templates, animations, animation_templates, tools, workflows, batches, webhooks, instant_urls, publications and assets. An empty returned scopes array means full access. allowed_origins restricts browser-origin use; it does not make a local CLI key template-scoped. Request only the necessary grants. This wrapper does not create/roll keys, implement OAuth/refresh, load .env automatically or reuse official saved sessions. login prints instructions only.

On macOS/Linux, use an existing 0700 directory and a regular 0600 token file owned by your user. It must be absolute, non-symlink and at most 64 KiB. File credentials override environment keys and are cached until restart. On Windows, restrict the file/directory ACL to your user; POSIX mode checks do not validate Windows ACLs. GUI apps can have different environments from your shell.

Plans, credits and limits

The AGPL wrapper is free; Bannerbear subscriptions, render/AI credits, storage and workspace permissions remain separate. The provider currently advertises a 30-credit trial without a credit card. Check the current dashboard and pricing before approval; do not infer that every model or operation has the same cost. A workflow charges for its individual steps; a batch reduces request count, not render credits.

The current V5 reference states 60 POST requests per ten-second window. Official 0.13.0 source still uses a conservative 28-POST window and older 30-request wording. This package's default 200 ms spacing is per profile/process across calls, not a reservation or globally coordinated quota. Other clients using the key share provider limits. No request retries automatically after 429, 5xx, network failures or timeouts.

Native image batches are 1–100 items. This package limits JSON bodies/files to 1 MiB, raw uploads to 5,000,000 bytes and each response to 5 MiB; these are separate caps. Source describes a 20-asset trial allowance and content-hash deduplication within a workspace; check returned provider policy. Supported upload Content-Types come from the pinned V5 schema, including image/video/audio/PDF/JSON types. The provider validates actual media and MIME compatibility.

Rotation and revocation

Create/rotate/revoke the intended V5 key in Bannerbear, update private settings and restart clients. Uninstalling npm does not revoke a key or undo a queued render. Keep account records, render metadata, media URLs, signing keys and private output files out of public issues.

4. Connect your client

Codex is the primary documented agent. Use private file paths rather than placing keys in shell history:

codex mcp add bannerbear --env BANNERBEAR_TOKEN_FILE=/absolute/private/bannerbear.txt -- npx -y @thenavidm/bannerbear-mcp-cli@latest
codex mcp list

INSTALL.md includes private env_vars TOML, separate Windows paths, Claude Desktop bundled/manual setup, Claude Code, Cursor, VS Code/Copilot, Windsurf, Zed, Gemini CLI, Cline/other stdio clients and Docker. GUI environment forwarding and an actual installed desktop extension are different from protocol discovery. A remote-only chat client can use official hosted OAuth; this package exposes no public HTTP listener.

5. Check it works

bannerbear-cli doctor
bannerbear-cli doctor --network
bannerbear-cli list-accounts --agent
bannerbear-cli get-account --agent --select quota,api_key.scopes
bannerbear-cli list-image-templates --page 1 --agent

Local doctor checks settings/presence. Network doctor checks the selected V5 account response. Then inspect the exact template/workflow you intend to use. Do not render/upload/delete merely to test installation. Full discovery returns 75; read-only returns 33 and direct confirmed mutation calls still refuse.

6. Output, flags and exit codes

MCP uses underscore names; CLI uses hyphens from the same catalogue. Path/query flags are top-level; native JSON bodies use --payload or --payload-file exclusively. Output retains provider shapes: list endpoints return arrays, creates return queued objects and helper wrappers report their explicit bounds.

Flag / command	Contract
tools / no command	Actual current commands, writes marked
COMMAND --help / schema COMMAND	Derived flags / complete JSON Schema
--agent	--json --compact --no-input --no-color --yes; never confirmation
--select a,b.c	Local selection only; does not change upstream quota or fields
--account NAME	Exact private workspace profile label
--confirm	Exact selected mutation approval
--payload / --payload-file	Native V5 body / regular local JSON file
--asset-file / --content-type	Confirmed raw bytes and declared provider MIME type
--secret-result-file	Exclusive private result for creation signing keys

Exit	Meaning
0	Success
2	Invalid input or refused mutation
3	Not found
4	Authentication/permission failure
5	Provider/transport failure
7	Rate limit or exhausted credit quota
10	Missing/invalid private configuration

A queued UID is not a completed render. A failed media result is retained for inspection. No formatting or --yes flag changes the WriteGuard policy.

7. MCP or CLI and token cost

Mode	What reaches the agent	Evidence
MCP	Names, instructions and schemas according to client loading policy; selected results	Actual client/model loading and successful task usage
CLI	Available skill/help and selected command output	Actual successful matched task usage
Official workflow profile	Eight local fixture tools and provider workflow results	Official composition already reduces manual steps; no claimed token winner
--select / bounded reads	Locally selected fields and capped pages	Proven output bounds; no measured saving percentage

Measure Codex first with actual API usage, identical tasks/resources/permissions/results and pinned client/model/package/date. Tool discovery characters divided by four, another repo's measurements and tool counts are not token evidence. No fresh matched Codex measurements are published for this release. Claude Code benchmarks are deferred at Navid's instruction.

8. Every tool and argument

All 75 sections below come from actual stdio discovery. Payload validation also applies when a body is loaded from a file. Mandatory confirmation is enforced outside the ordinary required-key list. Native nested shapes, allowed values, references and local limits follow the tool tables.

MCP tool	CLI command	Policy
`get_account`	`bannerbear-cli get-account`	Read / local helper
`list_image_templates`	`bannerbear-cli list-image-templates`	Read / local helper
`create_image_template`	`bannerbear-cli create-image-template`	Explicit confirmation required
`get_image_template`	`bannerbear-cli get-image-template`	Read / local helper
`update_image_template`	`bannerbear-cli update-image-template`	Explicit confirmation required
`delete_image_template`	`bannerbear-cli delete-image-template`	Explicit confirmation required
`list_images`	`bannerbear-cli list-images`	Read / local helper
`create_image`	`bannerbear-cli create-image`	Explicit confirmation required
`get_image`	`bannerbear-cli get-image`	Read / local helper
`list_batches`	`bannerbear-cli list-batches`	Read / local helper
`create_batch`	`bannerbear-cli create-batch`	Explicit confirmation required
`get_batch`	`bannerbear-cli get-batch`	Read / local helper
`list_webhooks`	`bannerbear-cli list-webhooks`	Read / local helper
`create_webhook`	`bannerbear-cli create-webhook`	Explicit confirmation required
`get_webhook`	`bannerbear-cli get-webhook`	Read / local helper
`update_webhook`	`bannerbear-cli update-webhook`	Explicit confirmation required
`delete_webhook`	`bannerbear-cli delete-webhook`	Explicit confirmation required
`list_assets`	`bannerbear-cli list-assets`	Read / local helper
`upload_asset`	`bannerbear-cli upload-asset`	Explicit confirmation required
`get_asset`	`bannerbear-cli get-asset`	Read / local helper
`check_assets`	`bannerbear-cli check-assets`	Read / local helper
`list_publications`	`bannerbear-cli list-publications`	Read / local helper
`get_publication`	`bannerbear-cli get-publication`	Read / local helper
`install_publication`	`bannerbear-cli install-publication`	Explicit confirmation required
`list_instant_urls`	`bannerbear-cli list-instant-urls`	Read / local helper
`create_instant_url`	`bannerbear-cli create-instant-url`	Explicit confirmation required
`get_instant_url`	`bannerbear-cli get-instant-url`	Read / local helper
`update_instant_url`	`bannerbear-cli update-instant-url`	Explicit confirmation required
`delete_instant_url`	`bannerbear-cli delete-instant-url`	Explicit confirmation required
`list_animations`	`bannerbear-cli list-animations`	Read / local helper
`create_animation`	`bannerbear-cli create-animation`	Explicit confirmation required
`get_animation`	`bannerbear-cli get-animation`	Read / local helper
`list_animation_templates`	`bannerbear-cli list-animation-templates`	Read / local helper
`create_animation_template`	`bannerbear-cli create-animation-template`	Explicit confirmation required
`get_animation_template`	`bannerbear-cli get-animation-template`	Read / local helper
`update_animation_template`	`bannerbear-cli update-animation-template`	Explicit confirmation required
`delete_animation_template`	`bannerbear-cli delete-animation-template`	Explicit confirmation required
`animate_template`	`bannerbear-cli animate-template`	Explicit confirmation required
`remove_bg`	`bannerbear-cli remove-bg`	Explicit confirmation required
`generate_ai_image`	`bannerbear-cli generate-ai-image`	Explicit confirmation required
`generate_ai_video`	`bannerbear-cli generate-ai-video`	Explicit confirmation required
`video_thumbnails`	`bannerbear-cli video-thumbnails`	Explicit confirmation required
`subtitle_video`	`bannerbear-cli subtitle-video`	Explicit confirmation required
`generate_voiceover`	`bannerbear-cli generate-voiceover`	Explicit confirmation required
`create_pdf`	`bannerbear-cli create-pdf`	Explicit confirmation required
`trim_video`	`bannerbear-cli trim-video`	Explicit confirmation required
`concat_videos`	`bannerbear-cli concat-videos`	Explicit confirmation required
`resize_video`	`bannerbear-cli resize-video`	Explicit confirmation required
`crop_video`	`bannerbear-cli crop-video`	Explicit confirmation required
`overlay_video`	`bannerbear-cli overlay-video`	Explicit confirmation required
`overlay_image`	`bannerbear-cli overlay-image`	Explicit confirmation required
`add_audio`	`bannerbear-cli add-audio`	Explicit confirmation required
`add_cover_art`	`bannerbear-cli add-cover-art`	Explicit confirmation required
`create_video_slideshow`	`bannerbear-cli create-video-slideshow`	Explicit confirmation required
`apply_color_filter`	`bannerbear-cli apply-color-filter`	Explicit confirmation required
`soften_video`	`bannerbear-cli soften-video`	Explicit confirmation required
`create_gif_preview`	`bannerbear-cli create-gif-preview`	Explicit confirmation required
`list_tool_jobs`	`bannerbear-cli list-tool-jobs`	Read / local helper
`get_tool_job`	`bannerbear-cli get-tool-job`	Read / local helper
`list_workflows`	`bannerbear-cli list-workflows`	Read / local helper
`create_workflow`	`bannerbear-cli create-workflow`	Explicit confirmation required
`update_workflow`	`bannerbear-cli update-workflow`	Explicit confirmation required
`delete_workflow`	`bannerbear-cli delete-workflow`	Explicit confirmation required
`get_workflow`	`bannerbear-cli get-workflow`	Read / local helper
`list_workflow_runs`	`bannerbear-cli list-workflow-runs`	Read / local helper
`run_workflow`	`bannerbear-cli run-workflow`	Explicit confirmation required
`get_workflow_run`	`bannerbear-cli get-workflow-run`	Read / local helper
`list_accounts`	`bannerbear-cli list-accounts`	Read / local helper
`get_operation_schema`	`bannerbear-cli get-operation-schema`	Read / local helper
`get_layer_schema`	`bannerbear-cli get-layer-schema`	Read / local helper
`preview_operation`	`bannerbear-cli preview-operation`	Read / local helper
`query_pages`	`bannerbear-cli query-pages`	Read / local helper
`poll_job`	`bannerbear-cli poll-job`	Read / local helper
`preview_render_batch`	`bannerbear-cli preview-render-batch`	Read / local helper
`apply_render_batch`	`bannerbear-cli apply-render-batch`	Explicit confirmation required

get_account

bannerbear-cli get-account

GET /v5/account. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/account. No JSON request body.

list_image_templates

bannerbear-cli list-image-templates

GET /v5/image_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/image_templates. No JSON request body.

create_image_template

bannerbear-cli create-image-template

POST /v5/image_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/image_templates. Native JSON body is required via payload/payload_file.

get_image_template

bannerbear-cli get-image-template

GET /v5/image_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/image_templates/{uid}. No JSON request body.

update_image_template

bannerbear-cli update-image-template

PATCH /v5/image_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: PATCH /v5/image_templates/{uid}. Native JSON body is required via payload/payload_file.

delete_image_template

bannerbear-cli delete-image-template

DELETE /v5/image_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

Native operation: DELETE /v5/image_templates/{uid}. No JSON request body.

list_images

bannerbear-cli list-images

GET /v5/images. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/images. No JSON request body.

create_image

bannerbear-cli create-image

POST /v5/images. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	ImageCreateRequest	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/images. Native JSON body is required via payload/payload_file.

get_image

bannerbear-cli get-image

GET /v5/images/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/images/{uid}. No JSON request body.

list_batches

bannerbear-cli list-batches

GET /v5/batches. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/batches. No JSON request body.

create_batch

bannerbear-cli create-batch

POST /v5/batches. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/batches. Native JSON body is required via payload/payload_file.

get_batch

bannerbear-cli get-batch

GET /v5/batches/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/batches/{uid}. No JSON request body.

list_webhooks

bannerbear-cli list-webhooks

GET /v5/webhooks. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/webhooks. No JSON request body.

create_webhook

bannerbear-cli create-webhook

POST /v5/webhooks. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.
`secret_result_file`	Yes	string	New absolute JSON file in an existing private directory; exclusive 0600 creation before the API request. No overwrite; signing key never appears in output. minLength: `1`.

Native operation: POST /v5/webhooks. Native JSON body is required via payload/payload_file.

get_webhook

bannerbear-cli get-webhook

GET /v5/webhooks/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/webhooks/{uid}. No JSON request body.

update_webhook

bannerbear-cli update-webhook

PATCH /v5/webhooks/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: PATCH /v5/webhooks/{uid}. Native JSON body is required via payload/payload_file.

delete_webhook

bannerbear-cli delete-webhook

DELETE /v5/webhooks/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

Native operation: DELETE /v5/webhooks/{uid}. No JSON request body.

list_assets

bannerbear-cli list-assets

GET /v5/assets. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/assets. No JSON request body.

upload_asset

bannerbear-cli upload-asset

POST /v5/assets. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`asset_file`	Yes	string	Regular non-symlink local file, at most 5,000,000 bytes. Uploaded only after confirmation. minLength: `1`.
`content_type`	Yes	string	Exact documented Content-Type for these raw file bytes. Values: `image/jpeg`, `image/png`, `image/webp`, `image/gif`, `image/svg+xml`, `video/mp4`, `video/webm`, `video/quicktime`, `audio/mpeg`, `audio/wav`, `audio/mp4`, `audio/webm`, `audio/ogg`, `application/pdf`, `application/json`.

Native operation: POST /v5/assets. Raw local bytes required.

get_asset

bannerbear-cli get-asset

GET /v5/assets/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/assets/{uid}. No JSON request body.

check_assets

bannerbear-cli check-assets

POST /v5/assets/check. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/assets/check. Native JSON body is required via payload/payload_file.

list_publications

bannerbear-cli list-publications

GET /v5/publications. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`kind`	No; body and guard rules apply	string	See the full input schema. Values: `image`, `animation`, `workflow`.
`category`	No; body and guard rules apply	string	See the full input schema. Values: `announcements & news`, `beauty & fashion`, `business & finance`, `education & coaching`, `employee highlights`, `events & weddings`, `film & movies`, `food & drinks`, `gaming & e-sports`, `home & real estate`, `marketing & sales`, `motivational quotes`, `podcasts & publishing`, `product showcase`, `reviews & testimonials`, `social media`, `tech & crypto`, `travel & nature`.
`q`	No; body and guard rules apply	string	See the full input schema.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/publications. No JSON request body.

get_publication

bannerbear-cli get-publication

GET /v5/publications/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/publications/{uid}. No JSON request body.

install_publication

bannerbear-cli install-publication

POST /v5/publications/{uid}/install. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

Native operation: POST /v5/publications/{uid}/install. No JSON request body.

list_instant_urls

bannerbear-cli list-instant-urls

GET /v5/instant_urls. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/instant_urls. No JSON request body.

create_instant_url

bannerbear-cli create-instant-url

POST /v5/instant_urls. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.
`secret_result_file`	Yes	string	New absolute JSON file in an existing private directory; exclusive 0600 creation before the API request. No overwrite; signing key never appears in output. minLength: `1`.

Native operation: POST /v5/instant_urls. Native JSON body is required via payload/payload_file.

get_instant_url

bannerbear-cli get-instant-url

GET /v5/instant_urls/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/instant_urls/{uid}. No JSON request body.

update_instant_url

bannerbear-cli update-instant-url

PATCH /v5/instant_urls/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: PATCH /v5/instant_urls/{uid}. Native JSON body is required via payload/payload_file.

delete_instant_url

bannerbear-cli delete-instant-url

DELETE /v5/instant_urls/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

Native operation: DELETE /v5/instant_urls/{uid}. No JSON request body.

list_animations

bannerbear-cli list-animations

GET /v5/animations. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/animations. No JSON request body.

create_animation

bannerbear-cli create-animation

POST /v5/animations. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/animations. Native JSON body is required via payload/payload_file.

get_animation

bannerbear-cli get-animation

GET /v5/animations/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/animations/{uid}. No JSON request body.

list_animation_templates

bannerbear-cli list-animation-templates

GET /v5/animation_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/animation_templates. No JSON request body.

create_animation_template

bannerbear-cli create-animation-template

POST /v5/animation_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/animation_templates. Native JSON body is required via payload/payload_file.

get_animation_template

bannerbear-cli get-animation-template

GET /v5/animation_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/animation_templates/{uid}. No JSON request body.

update_animation_template

bannerbear-cli update-animation-template

PATCH /v5/animation_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: PATCH /v5/animation_templates/{uid}. Native JSON body is required via payload/payload_file.

delete_animation_template

bannerbear-cli delete-animation-template

DELETE /v5/animation_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

Native operation: DELETE /v5/animation_templates/{uid}. No JSON request body.

animate_template

bannerbear-cli animate-template

POST /v5/animation_templates/{uid}/animate. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/animation_templates/{uid}/animate. Native JSON body is required via payload/payload_file.

remove_bg

bannerbear-cli remove-bg

POST /v5/tools/remove_bg. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/remove_bg. Native JSON body is required via payload/payload_file.

generate_ai_image

bannerbear-cli generate-ai-image

POST /v5/tools/generate_ai_image. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/generate_ai_image. Native JSON body is required via payload/payload_file.

generate_ai_video

bannerbear-cli generate-ai-video

POST /v5/tools/generate_ai_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/generate_ai_video. Native JSON body is required via payload/payload_file.

video_thumbnails

bannerbear-cli video-thumbnails

POST /v5/tools/video_thumbnails. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/video_thumbnails. Native JSON body is required via payload/payload_file.

subtitle_video

bannerbear-cli subtitle-video

POST /v5/tools/subtitle_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/subtitle_video. Native JSON body is required via payload/payload_file.

generate_voiceover

bannerbear-cli generate-voiceover

POST /v5/tools/generate_voiceover. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/generate_voiceover. Native JSON body is required via payload/payload_file.

create_pdf

bannerbear-cli create-pdf

POST /v5/tools/create_pdf. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/create_pdf. Native JSON body is required via payload/payload_file.

trim_video

bannerbear-cli trim-video

POST /v5/tools/trim_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/trim_video. Native JSON body is required via payload/payload_file.

concat_videos

bannerbear-cli concat-videos

POST /v5/tools/concat_videos. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/concat_videos. Native JSON body is required via payload/payload_file.

resize_video

bannerbear-cli resize-video

POST /v5/tools/resize_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/resize_video. Native JSON body is required via payload/payload_file.

crop_video

bannerbear-cli crop-video

POST /v5/tools/crop_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/crop_video. Native JSON body is required via payload/payload_file.

overlay_video

bannerbear-cli overlay-video

POST /v5/tools/overlay_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/overlay_video. Native JSON body is required via payload/payload_file.

overlay_image

bannerbear-cli overlay-image

POST /v5/tools/overlay_image. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/overlay_image. Native JSON body is required via payload/payload_file.

add_audio

bannerbear-cli add-audio

POST /v5/tools/add_audio. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/add_audio. Native JSON body is required via payload/payload_file.

add_cover_art

bannerbear-cli add-cover-art

POST /v5/tools/add_cover_art. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/add_cover_art. Native JSON body is required via payload/payload_file.

create_video_slideshow

bannerbear-cli create-video-slideshow

POST /v5/tools/create_video_slideshow. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/create_video_slideshow. Native JSON body is required via payload/payload_file.

apply_color_filter

bannerbear-cli apply-color-filter

POST /v5/tools/apply_color_filter. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/apply_color_filter. Native JSON body is required via payload/payload_file.

soften_video

bannerbear-cli soften-video

POST /v5/tools/soften_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/soften_video. Native JSON body is required via payload/payload_file.

create_gif_preview

bannerbear-cli create-gif-preview

POST /v5/tools/create_gif_preview. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/tools/create_gif_preview. Native JSON body is required via payload/payload_file.

list_tool_jobs

bannerbear-cli list-tool-jobs

GET /v5/tool_jobs. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/tool_jobs. No JSON request body.

get_tool_job

bannerbear-cli get-tool-job

GET /v5/tool_jobs/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/tool_jobs/{uid}. No JSON request body.

list_workflows

bannerbear-cli list-workflows

GET /v5/workflows. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/workflows. No JSON request body.

create_workflow

bannerbear-cli create-workflow

POST /v5/workflows. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/workflows. Native JSON body is required via payload/payload_file.

update_workflow

bannerbear-cli update-workflow

PATCH /v5/workflows/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: PATCH /v5/workflows/{uid}. Native JSON body is required via payload/payload_file.

delete_workflow

bannerbear-cli delete-workflow

DELETE /v5/workflows/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

Native operation: DELETE /v5/workflows/{uid}. No JSON request body.

get_workflow

bannerbear-cli get-workflow

GET /v5/workflows/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/workflows/{uid}. No JSON request body.

list_workflow_runs

bannerbear-cli list-workflow-runs

GET /v5/workflow_runs. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/workflow_runs. No JSON request body.

run_workflow

bannerbear-cli run-workflow

POST /v5/workflow_runs. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

Native operation: POST /v5/workflow_runs. Native JSON body is required via payload/payload_file.

get_workflow_run

bannerbear-cli get-workflow-run

GET /v5/workflow_runs/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

Native operation: GET /v5/workflow_runs/{uid}. No JSON request body.

list_accounts

bannerbear-cli list-accounts

Local profile labels, default and auth method only; no keys, paths or provider identity. No network.

Argument	Required	Type	Details
None	No	None	No arguments

get_operation_schema

bannerbear-cli get-operation-schema

Return the complete current path/query/body schema for a selected operation. Local only.

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `get_account`, `list_image_templates`, `create_image_template`, `get_image_template`, `update_image_template`, `delete_image_template`, `list_images`, `create_image`, `get_image`, `list_batches`, `create_batch`, `get_batch`, `list_webhooks`, `create_webhook`, `get_webhook`, `update_webhook`, `delete_webhook`, `list_assets`, `upload_asset`, `get_asset`, `check_assets`, `list_publications`, `get_publication`, `install_publication`, `list_instant_urls`, `create_instant_url`, `get_instant_url`, `update_instant_url`, `delete_instant_url`, `list_animations`, `create_animation`, `get_animation`, `list_animation_templates`, `create_animation_template`, `get_animation_template`, `update_animation_template`, `delete_animation_template`, `animate_template`, `remove_bg`, `generate_ai_image`, `generate_ai_video`, `video_thumbnails`, `subtitle_video`, `generate_voiceover`, `create_pdf`, `trim_video`, `concat_videos`, `resize_video`, `crop_video`, `overlay_video`, `overlay_image`, `add_audio`, `add_cover_art`, `create_video_slideshow`, `apply_color_filter`, `soften_video`, `create_gif_preview`, `list_tool_jobs`, `get_tool_job`, `list_workflows`, `create_workflow`, `update_workflow`, `delete_workflow`, `get_workflow`, `list_workflow_runs`, `run_workflow`, `get_workflow_run`.

get_layer_schema

bannerbear-cli get-layer-schema

Return a complete selected native layer or animation keyframe schema from the pinned V5 definitions. No network.

Argument	Required	Type	Details
`layer`	Yes	string	See the full input schema. Values: `Layer`, `LayerSvgShape`, `LayerBarCode`, `LayerLottie`, `LayerQrCode`, `LayerAnimatedBackground`, `LayerCircle`, `LayerCircleImageContainer`, `LayerImage`, `LayerRectangleImageContainer`, `LayerGroup`, `LayerText`, `LayerRating`, `LayerRectangle`, `LayerAudioWave`, `Keyframes`.

preview_operation

bannerbear-cli preview-operation

Validate and preview an exact local named request. No authentication, provider validation or quota estimate. Raw asset previews reveal only byte count/hash.

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `get_account`, `list_image_templates`, `create_image_template`, `get_image_template`, `update_image_template`, `delete_image_template`, `list_images`, `create_image`, `get_image`, `list_batches`, `create_batch`, `get_batch`, `list_webhooks`, `create_webhook`, `get_webhook`, `update_webhook`, `delete_webhook`, `list_assets`, `upload_asset`, `get_asset`, `check_assets`, `list_publications`, `get_publication`, `install_publication`, `list_instant_urls`, `create_instant_url`, `get_instant_url`, `update_instant_url`, `delete_instant_url`, `list_animations`, `create_animation`, `get_animation`, `list_animation_templates`, `create_animation_template`, `get_animation_template`, `update_animation_template`, `delete_animation_template`, `animate_template`, `remove_bg`, `generate_ai_image`, `generate_ai_video`, `video_thumbnails`, `subtitle_video`, `generate_voiceover`, `create_pdf`, `trim_video`, `concat_videos`, `resize_video`, `crop_video`, `overlay_video`, `overlay_image`, `add_audio`, `add_cover_art`, `create_video_slideshow`, `apply_color_filter`, `soften_video`, `create_gif_preview`, `list_tool_jobs`, `get_tool_job`, `list_workflows`, `create_workflow`, `update_workflow`, `delete_workflow`, `get_workflow`, `list_workflow_runs`, `run_workflow`, `get_workflow_run`.
`arguments`	Yes	object	See the full input schema.

query_pages

bannerbear-cli query-pages

Read 1–5 pages of a selected native paginated read. Stop at an empty page; report a resume page at the cap. No completeness assumption from a short page.

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `list_image_templates`, `list_images`, `list_batches`, `list_webhooks`, `list_assets`, `list_publications`, `list_instant_urls`, `list_animations`, `list_animation_templates`, `list_tool_jobs`, `list_workflows`, `list_workflow_runs`.
`arguments`	Yes	object	See the full input schema.
`max_pages`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `5`. default: `1`.

poll_job

bannerbear-cli poll-job

Read only an existing image, animation, batch, tool job or workflow run. At most 20 GETs, no create/resubmit. Completed/failed terminal states stop; missing/unrecognised state stops as unknown.

Argument	Required	Type	Details
`resource`	Yes	string	See the full input schema. Values: `images`, `animations`, `batches`, `tool_jobs`, `workflow_runs`.
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	See the full input schema.
`max_polls`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `20`. default: `3`.
`interval_ms`	No; body and guard rules apply	integer	See the full input schema. minimum: `100`. maximum: `5000`. default: `1000`.

preview_render_batch

bannerbear-cli preview-render-batch

Local schema-validated 1–100 native image payload review. Digest binds exact order, method/path, profile label and body. No provider state or price validation.

Argument	Required	Type	Details
`payload`	No; body and guard rules apply	object	See the full input schema.
`payload_file`	No; body and guard rules apply	string	See the full input schema. minLength: `1`.
`account`	No; body and guard rules apply	string	See the full input schema.

apply_render_batch

bannerbear-cli apply-render-batch

Validate the same reviewed digest plus explicit confirmation, then submit one native batch. Direct create_batch also needs confirmation but does not require a digest. No retry.

Argument	Required	Type	Details
`payload`	No; body and guard rules apply	object	See the full input schema.
`payload_file`	No; body and guard rules apply	string	See the full input schema. minLength: `1`.
`account`	No; body and guard rules apply	string	See the full input schema.
`preview_sha256`	Yes	string	See the full input schema. pattern: `^[0-9a-f]{64}$`.
`confirm`	No; body and guard rules apply	boolean	See the full input schema.

Nested native input definitions

Identical object shapes appear once. Complete union/reference validation remains available through schema COMMAND and get_operation_schema. Root/native declared objects reject unknown keys. Dynamic workflow inputs and keyframe maps retain their documented open structure. Provider validation, ownership locks and credit decisions still apply.

get_account

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

list_image_templates

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

create_image_template

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_image_template.payload

Argument	Required	Type	Details
`name`	Yes	string	See the full input schema.
`description`	No; body and guard rules apply	string/null	See the full input schema.
`tags`	No; body and guard rules apply	array	See the full input schema. Items: string.
`width`	No; body and guard rules apply	integer	See the full input schema.
`height`	No; body and guard rules apply	integer	See the full input schema.
`config`	No; body and guard rules apply	object	See the full input schema.

create_image_template.payload.config

Argument	Required	Type	Details
`objects`	No; body and guard rules apply	array	See the full input schema. Items: Layer.

get_image_template

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

update_image_template

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

update_image_template.payload

Argument	Required	Type	Details
`name`	No; body and guard rules apply	string	See the full input schema.
`description`	No; body and guard rules apply	string/null	See the full input schema.
`tags`	No; body and guard rules apply	array	See the full input schema. Items: string.
`width`	No; body and guard rules apply	integer	See the full input schema.
`height`	No; body and guard rules apply	integer	See the full input schema.
`config`	No; body and guard rules apply	object	See the full input schema.

delete_image_template

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.

create_image

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	ImageCreateRequest	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_batch

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_batch.payload

Argument	Required	Type	Details
`type`	Yes	string	See the full input schema. Values: `images`.
`items`	Yes	array	See the full input schema. minItems: `1`. maxItems: `100`. Items: ImageCreateRequest.

create_webhook

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.
`secret_result_file`	Yes	string	New absolute JSON file in an existing private directory; exclusive 0600 creation before the API request. No overwrite; signing key never appears in output. minLength: `1`.

create_webhook.payload

Argument	Required	Type	Details
`name`	Yes	string	See the full input schema.
`url`	Yes	string	See the full input schema. format: `uri`.
`resource`	No; body and guard rules apply	string	See the full input schema. Values: `image`, `batch`, `tool_job`, `workflow_run`, `animation`.
`event`	No; body and guard rules apply	string	See the full input schema. Values: `all_events`, `completed`, `failed`.
`status`	No; body and guard rules apply	string	See the full input schema. Values: `active`, `disabled`.

update_webhook

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

upload_asset

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`asset_file`	Yes	string	Regular non-symlink local file, at most 5,000,000 bytes. Uploaded only after confirmation. minLength: `1`.
`content_type`	Yes	string	Exact documented Content-Type for these raw file bytes. Values: `image/jpeg`, `image/png`, `image/webp`, `image/gif`, `image/svg+xml`, `video/mp4`, `video/webm`, `video/quicktime`, `audio/mpeg`, `audio/wav`, `audio/mp4`, `audio/webm`, `audio/ogg`, `application/pdf`, `application/json`.

check_assets

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

check_assets.payload

Argument	Required	Type	Details
`content_hashes`	Yes	array	See the full input schema. maxItems: `100`. Items: string.

list_publications

Argument	Required	Type	Details
`page`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `1000000`.
`kind`	No; body and guard rules apply	string	See the full input schema. Values: `image`, `animation`, `workflow`.
`category`	No; body and guard rules apply	string	See the full input schema. Values: `announcements & news`, `beauty & fashion`, `business & finance`, `education & coaching`, `employee highlights`, `events & weddings`, `film & movies`, `food & drinks`, `gaming & e-sports`, `home & real estate`, `marketing & sales`, `motivational quotes`, `podcasts & publishing`, `product showcase`, `reviews & testimonials`, `social media`, `tech & crypto`, `travel & nature`.
`q`	No; body and guard rules apply	string	See the full input schema.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.

create_instant_url

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.
`secret_result_file`	Yes	string	New absolute JSON file in an existing private directory; exclusive 0600 creation before the API request. No overwrite; signing key never appears in output. minLength: `1`.

create_instant_url.payload

Argument	Required	Type	Details
`name`	Yes	string	See the full input schema.
`template`	Yes	string	See the full input schema.
`mode`	No; body and guard rules apply	string	See the full input schema. Values: `encoded`, `named_params`.
`security`	No; body and guard rules apply	string	See the full input schema. Values: `signed`, `open`.
`status`	No; body and guard rules apply	string	See the full input schema. Values: `active`, `disabled`.
`scale`	No; body and guard rules apply	integer	See the full input schema. Values: `1`, `2`, `3`, `4`.
`rate_limit`	No; body and guard rules apply	boolean	See the full input schema.
`template_version`	No; body and guard rules apply	integer/null	See the full input schema.
`max_renders`	No; body and guard rules apply	integer/null	See the full input schema.
`expires_at`	No; body and guard rules apply	string/null	See the full input schema. format: `date-time`.

update_instant_url

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_animation

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_animation.payload

Argument	Required	Type	Details
`template`	Yes	string	See the full input schema.
`formats`	No; body and guard rules apply	array	See the full input schema. default: `['mp4']`. Items: string.
`modifications`	Yes	object	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

create_animation.payload.modifications

Argument	Required	Type	Details
`objects`	No; body and guard rules apply	array	See the full input schema. Items: Layer.
`template`	No; body and guard rules apply	object	See the full input schema.

create_animation.payload.modifications.template

Argument	Required	Type	Details
`width`	No; body and guard rules apply	integer	See the full input schema.
`height`	No; body and guard rules apply	integer	See the full input schema.
`fps`	No; body and guard rules apply	integer	See the full input schema. Values: `24`, `30`, `60`.
`transparent`	No; body and guard rules apply	boolean	See the full input schema.

create_animation_template

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_animation_template.payload

Argument	Required	Type	Details
`name`	Yes	string	See the full input schema.
`description`	No; body and guard rules apply	string/null	See the full input schema.
`tags`	No; body and guard rules apply	array	See the full input schema. Items: string.
`width`	No; body and guard rules apply	integer	See the full input schema. minimum: `100`. maximum: `5000`.
`height`	No; body and guard rules apply	integer	See the full input schema. minimum: `100`. maximum: `5000`.
`frame_rate`	No; body and guard rules apply	integer	See the full input schema. Values: `24`, `30`, `60`.
`config`	No; body and guard rules apply	object	See the full input schema.

create_animation_template.payload.config

Argument	Required	Type	Details
`objects`	No; body and guard rules apply	array	See the full input schema. Items: Layer.
`keyframes`	No; body and guard rules apply	Keyframes	See the full input schema.

update_animation_template

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

update_animation_template.payload

Argument	Required	Type	Details
`name`	No; body and guard rules apply	string	See the full input schema.
`description`	No; body and guard rules apply	string/null	See the full input schema.
`tags`	No; body and guard rules apply	array	See the full input schema. Items: string.
`width`	No; body and guard rules apply	integer	See the full input schema. minimum: `100`. maximum: `5000`.
`height`	No; body and guard rules apply	integer	See the full input schema. minimum: `100`. maximum: `5000`.
`frame_rate`	No; body and guard rules apply	integer	See the full input schema. Values: `24`, `30`, `60`.
`config`	No; body and guard rules apply	object	See the full input schema.

animate_template

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

animate_template.payload

Argument	Required	Type	Details
`preset`	Yes	string	See the full input schema. Values: `FadeIn`, `FadeOut`, `ZoomIn`, `ZoomOut`, `GetBigger`, `GetSmaller`, `ScaleIn`, `ScaleOut`, `PopIn`, `PopOut`.
`objects`	No; body and guard rules apply	array	See the full input schema. Items: string.
`duration`	No; body and guard rules apply	integer	See the full input schema. default: `400`.
`stagger`	No; body and guard rules apply	integer	See the full input schema. default: `0`.
`easing`	No; body and guard rules apply	string	See the full input schema.
`merge`	No; body and guard rules apply	boolean	See the full input schema. default: `False`.

remove_bg

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

remove_bg.payload

Argument	Required	Type	Details
`image_url`	Yes	string	See the full input schema. format: `uri`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

generate_ai_image

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

generate_ai_image.payload

Argument	Required	Type	Details
`prompt`	Yes	string	See the full input schema.
`model`	Yes	string	See the full input schema. Values: `flux_schnell`, `flux_1_1_pro`, `nano_banana`, `gpt_image_2`. default: `flux_schnell`.
`aspect_ratio`	No; body and guard rules apply	string	See the full input schema. Values: `1:1`, `16:9`, `9:16`, `4:3`, `3:4`. default: `1:1`.
`reference_image_url`	No; body and guard rules apply	string	See the full input schema. format: `uri`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

generate_ai_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

generate_ai_video.payload

Argument	Required	Type	Details
`prompt`	Yes	string	See the full input schema.
`model`	Yes	string	See the full input schema. Values: `seedance_1_lite`, `seedance_2`, `kling_2_5_turbo_pro`, `veo_3_1_fast`. default: `seedance_1_lite`.
`duration`	No; body and guard rules apply	integer	See the full input schema. Values: `4`, `5`, `6`, `8`, `10`. default: `5`.
`resolution`	No; body and guard rules apply	string	See the full input schema. Values: `480p`, `720p`, `1080p`. default: `720p`.
`aspect_ratio`	No; body and guard rules apply	string	See the full input schema. Values: `16:9`, `9:16`, `1:1`, `4:3`, `3:4`. default: `16:9`.
`image_url`	No; body and guard rules apply	string	See the full input schema. format: `uri`.
`audio`	No; body and guard rules apply	string	See the full input schema. Values: `on`, `off`. default: `on`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

video_thumbnails

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

video_thumbnails.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`count`	No; body and guard rules apply	integer	See the full input schema. default: `3`.
`interval`	No; body and guard rules apply	number	See the full input schema. default: `1`.
`start`	No; body and guard rules apply	number	See the full input schema. default: `0`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

subtitle_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

subtitle_video.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`language`	No; body and guard rules apply	string	See the full input schema. Values: ``, `en`, `es`, `fr`, `de`, `it`, `pt`, `nl`, `ru`, `pl`, `tr`, `ar`, `hi`, `zh`, `ja`, `ko`, `id`, `vi`, `th`.
`words_per_segment`	No; body and guard rules apply	integer/null	See the full input schema. Values: `1`, `2`, `3`, `4`, `5`, `6`, `7`, `8`, `9`, `10`.
`font`	No; body and guard rules apply	string	See the full input schema. Values: `inter`, `roboto`, `open-sans`, `noto-sans`, `montserrat`, `poppins`, `bebas-neue`, `anton`, `oswald`, `playfair-display`. default: `inter`.
`font_size`	No; body and guard rules apply	integer	See the full input schema.
`color`	No; body and guard rules apply	string	See the full input schema. default: `#ffffff`.
`bold`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `on`.
`italic`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `on`.
`alignment`	No; body and guard rules apply	string	See the full input schema. Values: `2`, `1`, `3`, `5`, `4`, `6`, `8`, `7`, `9`.
`outline_width`	No; body and guard rules apply	integer	See the full input schema. default: `0`.
`outline_color`	No; body and guard rules apply	string	See the full input schema. default: `#000000`.
`shadow_size`	No; body and guard rules apply	integer	See the full input schema. default: `0`.
`shadow_color`	No; body and guard rules apply	string	See the full input schema. default: `#000000`.
`background_style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `box`. default: `none`.
`background_color`	No; body and guard rules apply	string	See the full input schema.
`background_opacity`	No; body and guard rules apply	integer	See the full input schema. default: `100`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

generate_voiceover

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

generate_voiceover.payload

Argument	Required	Type	Details
`text`	Yes	string	See the full input schema.
`voice`	Yes	string	See the full input schema. Values: `rachel`, `adam`, `antoni`, `bella`, `domi`, `elli`, `josh`, `arnold`, `charlie`, `freya`. default: `rachel`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

create_pdf

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_pdf.payload

Argument	Required	Type	Details
`urls`	Yes	array	See the full input schema. Items: string.
`metadata`	No; body and guard rules apply	string	See the full input schema.

trim_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

trim_video.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`start`	Yes	number	See the full input schema.
`end`	Yes	number	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

concat_videos

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

concat_videos.payload

Argument	Required	Type	Details
`video_urls`	Yes	array	See the full input schema. Items: string.
`transition`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `fade`, `dissolve`, `wipeleft`, `slideleft`.
`transition_duration`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	integer	See the full input schema.
`height`	No; body and guard rules apply	integer	See the full input schema.
`fps`	No; body and guard rules apply	integer	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

resize_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

resize_video.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`width`	Yes	integer	See the full input schema.
`height`	Yes	integer	See the full input schema.
`fit`	No; body and guard rules apply	string	See the full input schema. Values: `cover`, `contain`, `blur`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

crop_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

crop_video.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`x`	Yes	integer	See the full input schema.
`y`	Yes	integer	See the full input schema.
`width`	Yes	integer	See the full input schema.
`height`	Yes	integer	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

overlay_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

overlay_video.payload

Argument	Required	Type	Details
`base_video_url`	Yes	string	See the full input schema. format: `uri`.
`overlay_video_url`	Yes	string	See the full input schema. format: `uri`.
`position`	No; body and guard rules apply	string	See the full input schema. Values: `top_left`, `top_center`, `top_right`, `center`, `bottom_left`, `bottom_center`, `bottom_right`.
`margin`	No; body and guard rules apply	integer	See the full input schema.
`x`	No; body and guard rules apply	integer	See the full input schema.
`y`	No; body and guard rules apply	integer	See the full input schema.
`scale`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	integer	See the full input schema.
`shape`	No; body and guard rules apply	string	See the full input schema. Values: `rectangle`, `circle`. default: `rectangle`.
`border_width`	No; body and guard rules apply	integer	See the full input schema.
`border_color`	No; body and guard rules apply	string	See the full input schema. default: `#ffffff`.
`shadow`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `on`. default: `off`.
`audio`	No; body and guard rules apply	string	See the full input schema. Values: `base`, `overlay`, `mix`. default: `base`.
`start`	No; body and guard rules apply	number	See the full input schema.
`when_finished`	No; body and guard rules apply	string	See the full input schema. Values: `freeze`, `hide`, `loop`. default: `freeze`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

overlay_image

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

overlay_image.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`image_url`	Yes	string	See the full input schema. format: `uri`.
`position`	No; body and guard rules apply	string	See the full input schema. Values: `top_left`, `top_center`, `top_right`, `center`, `bottom_left`, `bottom_center`, `bottom_right`.
`margin`	No; body and guard rules apply	integer	See the full input schema.
`x`	No; body and guard rules apply	integer	See the full input schema.
`y`	No; body and guard rules apply	integer	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

add_audio

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

add_audio.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`audio_url`	Yes	string	See the full input schema. format: `uri`.
`mode`	Yes	string	See the full input schema. Values: `mix`, `replace`. default: `mix`.
`volume`	No; body and guard rules apply	number	See the full input schema. default: `1`.
`loop`	No; body and guard rules apply	string	See the full input schema. Values: `on`, `off`. default: `on`.
`ducking`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `subtle`, `medium`, `heavy`. default: `off`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

add_cover_art

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

add_cover_art.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`image_url`	Yes	string	See the full input schema. format: `uri`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

create_video_slideshow

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_video_slideshow.payload

Argument	Required	Type	Details
`image_urls`	Yes	array	See the full input schema. Items: string.
`slide_duration`	No; body and guard rules apply	number	See the full input schema.
`transition`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `fade`, `dissolve`, `wipeleft`, `slideleft`.
`transition_duration`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	integer	See the full input schema.
`height`	No; body and guard rules apply	integer	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

apply_color_filter

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

apply_color_filter.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`filter`	Yes	string	See the full input schema. Values: `black-and-white`, `sepia`, `invert`, `warm`, `cool`, `vivid`, `muted`, `dark-and-moody`, `faded`, `vintage`, `cross-process`, `teal-and-orange`, `bleach-bypass`. default: `vintage`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

soften_video

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

soften_video.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`strength`	Yes	string	See the full input schema. Values: `subtle`, `medium`, `strong`. default: `medium`.
`metadata`	No; body and guard rules apply	string	See the full input schema.

create_gif_preview

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_gif_preview.payload

Argument	Required	Type	Details
`video_url`	Yes	string	See the full input schema. format: `uri`.
`fps`	No; body and guard rules apply	integer	See the full input schema.
`width`	No; body and guard rules apply	integer	See the full input schema.
`duration`	No; body and guard rules apply	number	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

create_workflow

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

create_workflow.payload

Argument	Required	Type	Details
`name`	Yes	string	See the full input schema.
`description`	No; body and guard rules apply	string/null	See the full input schema.
`tags`	No; body and guard rules apply	array	See the full input schema. Items: string.
`inputs`	No; body and guard rules apply	object	See the full input schema.
`steps`	No; body and guard rules apply	array	See the full input schema. Items: object.

create_workflow.payload.inputs.*

Argument	Required	Type	Details
`type`	No; body and guard rules apply	string	See the full input schema. Values: `string`, `url`, `number`, `boolean`.
`required`	No; body and guard rules apply	boolean	See the full input schema.

create_workflow.payload.steps[]

Argument	Required	Type	Details
`key`	Yes	string	See the full input schema. pattern: `^[a-z0-9_]+$`.
`type`	Yes	string	See the full input schema. Values: `tool`, `image`, `animation`.
`ref`	Yes	string	See the full input schema.
`inputs`	No; body and guard rules apply	object	See the full input schema.

update_workflow

Argument	Required	Type	Details
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

update_workflow.payload

Argument	Required	Type	Details
`name`	No; body and guard rules apply	string	See the full input schema.
`description`	No; body and guard rules apply	string/null	See the full input schema.
`tags`	No; body and guard rules apply	array	See the full input schema. Items: string.
`inputs`	No; body and guard rules apply	object	See the full input schema.
`steps`	No; body and guard rules apply	array	See the full input schema. Items: object.

run_workflow

Argument	Required	Type	Details
`account`	No; body and guard rules apply	string	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No; body and guard rules apply	boolean	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No; body and guard rules apply	object	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No; body and guard rules apply	string	Regular non-symlink local JSON file, at most 1 MiB. minLength: `1`.

run_workflow.payload

Argument	Required	Type	Details
`workflow`	Yes	string	See the full input schema.
`inputs`	No; body and guard rules apply	object	See the full input schema.
`metadata`	No; body and guard rules apply	string	See the full input schema.

get_operation_schema

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `get_account`, `list_image_templates`, `create_image_template`, `get_image_template`, `update_image_template`, `delete_image_template`, `list_images`, `create_image`, `get_image`, `list_batches`, `create_batch`, `get_batch`, `list_webhooks`, `create_webhook`, `get_webhook`, `update_webhook`, `delete_webhook`, `list_assets`, `upload_asset`, `get_asset`, `check_assets`, `list_publications`, `get_publication`, `install_publication`, `list_instant_urls`, `create_instant_url`, `get_instant_url`, `update_instant_url`, `delete_instant_url`, `list_animations`, `create_animation`, `get_animation`, `list_animation_templates`, `create_animation_template`, `get_animation_template`, `update_animation_template`, `delete_animation_template`, `animate_template`, `remove_bg`, `generate_ai_image`, `generate_ai_video`, `video_thumbnails`, `subtitle_video`, `generate_voiceover`, `create_pdf`, `trim_video`, `concat_videos`, `resize_video`, `crop_video`, `overlay_video`, `overlay_image`, `add_audio`, `add_cover_art`, `create_video_slideshow`, `apply_color_filter`, `soften_video`, `create_gif_preview`, `list_tool_jobs`, `get_tool_job`, `list_workflows`, `create_workflow`, `update_workflow`, `delete_workflow`, `get_workflow`, `list_workflow_runs`, `run_workflow`, `get_workflow_run`.

get_layer_schema

Argument	Required	Type	Details
`layer`	Yes	string	See the full input schema. Values: `Layer`, `LayerSvgShape`, `LayerBarCode`, `LayerLottie`, `LayerQrCode`, `LayerAnimatedBackground`, `LayerCircle`, `LayerCircleImageContainer`, `LayerImage`, `LayerRectangleImageContainer`, `LayerGroup`, `LayerText`, `LayerRating`, `LayerRectangle`, `LayerAudioWave`, `Keyframes`.

preview_operation

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `get_account`, `list_image_templates`, `create_image_template`, `get_image_template`, `update_image_template`, `delete_image_template`, `list_images`, `create_image`, `get_image`, `list_batches`, `create_batch`, `get_batch`, `list_webhooks`, `create_webhook`, `get_webhook`, `update_webhook`, `delete_webhook`, `list_assets`, `upload_asset`, `get_asset`, `check_assets`, `list_publications`, `get_publication`, `install_publication`, `list_instant_urls`, `create_instant_url`, `get_instant_url`, `update_instant_url`, `delete_instant_url`, `list_animations`, `create_animation`, `get_animation`, `list_animation_templates`, `create_animation_template`, `get_animation_template`, `update_animation_template`, `delete_animation_template`, `animate_template`, `remove_bg`, `generate_ai_image`, `generate_ai_video`, `video_thumbnails`, `subtitle_video`, `generate_voiceover`, `create_pdf`, `trim_video`, `concat_videos`, `resize_video`, `crop_video`, `overlay_video`, `overlay_image`, `add_audio`, `add_cover_art`, `create_video_slideshow`, `apply_color_filter`, `soften_video`, `create_gif_preview`, `list_tool_jobs`, `get_tool_job`, `list_workflows`, `create_workflow`, `update_workflow`, `delete_workflow`, `get_workflow`, `list_workflow_runs`, `run_workflow`, `get_workflow_run`.
`arguments`	Yes	object	See the full input schema.

query_pages

Argument	Required	Type	Details
`operation`	Yes	string	See the full input schema. Values: `list_image_templates`, `list_images`, `list_batches`, `list_webhooks`, `list_assets`, `list_publications`, `list_instant_urls`, `list_animations`, `list_animation_templates`, `list_tool_jobs`, `list_workflows`, `list_workflow_runs`.
`arguments`	Yes	object	See the full input schema.
`max_pages`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `5`. default: `1`.

poll_job

Argument	Required	Type	Details
`resource`	Yes	string	See the full input schema. Values: `images`, `animations`, `batches`, `tool_jobs`, `workflow_runs`.
`uid`	Yes	string	See the full input schema. minLength: `1`. maxLength: `128`. pattern: `^[A-Za-z0-9_-]+$`.
`account`	No; body and guard rules apply	string	See the full input schema.
`max_polls`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `20`. default: `3`.
`interval_ms`	No; body and guard rules apply	integer	See the full input schema. minimum: `100`. maximum: `5000`. default: `1000`.

preview_render_batch

Argument	Required	Type	Details
`payload`	No; body and guard rules apply	object	See the full input schema.
`payload_file`	No; body and guard rules apply	string	See the full input schema. minLength: `1`.
`account`	No; body and guard rules apply	string	See the full input schema.

preview_render_batch.payload

Argument	Required	Type	Details
`type`	Yes	string	See the full input schema. Values: `images`.
`items`	Yes	array	See the full input schema. minItems: `1`. maxItems: `100`. Items: ImageCreateRequest.

apply_render_batch

Argument	Required	Type	Details
`payload`	No; body and guard rules apply	object	See the full input schema.
`payload_file`	No; body and guard rules apply	string	See the full input schema. minLength: `1`.
`account`	No; body and guard rules apply	string	See the full input schema.
`preview_sha256`	Yes	string	See the full input schema. pattern: `^[0-9a-f]{64}$`.
`confirm`	No; body and guard rules apply	boolean	See the full input schema.

LayerSvgShape

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `svg_shape`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-color-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient-direction`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `right`, `top`, `bottom`.
`basic-shape`	No; body and guard rules apply	string	See the full input schema. Values: `triangle`, `scalene`, `pentagon`, `right`, `trapeze`, `kite`, `polygon`, `parallelogram`, `ellipse`, `trefoil`, `star`, `semicircle`, `hexagon`, `crescent`, `octagon`, `cross`, `ring`, `heart`, `arrow`, `rhombus`, `custom`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`fill`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`stroke`	No; body and guard rules apply	string	See the full input schema.
`stroke-width`	No; body and guard rules apply	number	See the full input schema.
`svg-url`	No; body and guard rules apply	string	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerBarCode

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `bar_code`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`barcode-color`	No; body and guard rules apply	string	See the full input schema.
`barcode-data`	No; body and guard rules apply	string	See the full input schema.
`barcode-format`	No; body and guard rules apply	string	See the full input schema. Values: `CODE128`, `EAN13`, `UPC`, `EAN8`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerLottie

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `lottie`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`lottie-delay`	No; body and guard rules apply	number	See the full input schema.
`lottie-loop`	No; body and guard rules apply	boolean	See the full input schema.
`lottie-url`	No; body and guard rules apply	string	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerQrCode

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `qr_code`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`qr-color`	No; body and guard rules apply	string	See the full input schema.
`qr-target`	No; body and guard rules apply	string	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerAnimatedBackground

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `animated_background`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-image`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`motion-blur`	No; body and guard rules apply	number	See the full input schema.
`motion-color`	No; body and guard rules apply	string	See the full input schema.
`motion-cycle`	No; body and guard rules apply	number	See the full input schema.
`motion-hue`	No; body and guard rules apply	number	See the full input schema.
`motion-preset`	No; body and guard rules apply	string	See the full input schema. Values: `aurora`, `mesh`, `conic`, `pulse`.
`motion-spread`	No; body and guard rules apply	number	See the full input schema.
`motion-travel`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerCircle

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `circle`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-color-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient-direction`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `right`, `top`, `bottom`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerCircleImageContainer

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `circle_image_container`.
`name`	No; body and guard rules apply	string	See the full input schema.
`ai-background-generate`	No; body and guard rules apply	string	See the full input schema. Values: `disabled`, `enabled`.
`ai-background-remove`	No; body and guard rules apply	string	See the full input schema. Values: `disabled`, `enabled`.
`ai-detect`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `face`, `subject`.
`ai-detect-anchor`	No; body and guard rules apply	string	See the full input schema.
`ai-detect-focus`	No; body and guard rules apply	string	See the full input schema. Values: `first`, `largest`, `group`.
`ai-detect-on-fail`	No; body and guard rules apply	string	See the full input schema. Values: `fallback_cover`, `fallback_contain`.
`ai-detect-zoom`	No; body and guard rules apply	string	See the full input schema. Values: `auto`, `50%`, `60%`, `70%`, `80%`, `90%`.
`ai-model`	No; body and guard rules apply	string	See the full input schema. Values: `flux_schnell`, `flux_1_1_pro`, `nano_banana`, `gpt_image_2`.
`ai-prompt`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`background-blend-mode`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `multiply`, `screen`, `overlay`, `darken`, `lighten`, `color-dodge`, `color-burn`, `hard-light`, `soft-light`, `difference`, `exclusion`, `hue`, `saturation`, `color`, `luminosity`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-color-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-crop`	No; body and guard rules apply	string	See the full input schema.
`background-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient-direction`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `right`, `top`, `bottom`.
`background-image`	No; body and guard rules apply	string	See the full input schema.
`background-position`	No; body and guard rules apply	string	See the full input schema. Values: `center`, `top`, `right`, `bottom`, `left`, `top left`, `top right`, `bottom left`, `bottom right`.
`background-size`	No; body and guard rules apply	string	See the full input schema. Values: `cover`, `contain`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`brightness`	No; body and guard rules apply	number	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`contrast`	No; body and guard rules apply	number	See the full input schema.
`grayscale`	No; body and guard rules apply	number	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`png-shadow`	No; body and guard rules apply	string	See the full input schema.
`png-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`png-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`saturate`	No; body and guard rules apply	number	See the full input schema.
`sepia`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerImage

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `image`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`background-blend-mode`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `multiply`, `screen`, `overlay`, `darken`, `lighten`, `color-dodge`, `color-burn`, `hard-light`, `soft-light`, `difference`, `exclusion`, `hue`, `saturation`, `color`, `luminosity`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-crop`	No; body and guard rules apply	string	See the full input schema.
`background-image`	No; body and guard rules apply	string	See the full input schema.
`background-size`	No; body and guard rules apply	string	See the full input schema. Values: `cover`, `contain`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`brightness`	No; body and guard rules apply	number	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`contrast`	No; body and guard rules apply	number	See the full input schema.
`grayscale`	No; body and guard rules apply	number	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`png-shadow`	No; body and guard rules apply	string	See the full input schema.
`png-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`png-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`saturate`	No; body and guard rules apply	number	See the full input schema.
`sepia`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerRectangleImageContainer

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `rectangle_image_container`.
`name`	No; body and guard rules apply	string	See the full input schema.
`ai-background-generate`	No; body and guard rules apply	string	See the full input schema. Values: `disabled`, `enabled`.
`ai-background-remove`	No; body and guard rules apply	string	See the full input schema. Values: `disabled`, `enabled`.
`ai-detect`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `face`, `subject`.
`ai-detect-anchor`	No; body and guard rules apply	string	See the full input schema.
`ai-detect-focus`	No; body and guard rules apply	string	See the full input schema. Values: `first`, `largest`, `group`.
`ai-detect-on-fail`	No; body and guard rules apply	string	See the full input schema. Values: `fallback_cover`, `fallback_contain`.
`ai-detect-zoom`	No; body and guard rules apply	string	See the full input schema. Values: `auto`, `50%`, `60%`, `70%`, `80%`, `90%`.
`ai-model`	No; body and guard rules apply	string	See the full input schema. Values: `flux_schnell`, `flux_1_1_pro`, `nano_banana`, `gpt_image_2`.
`ai-prompt`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-blend-mode`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `multiply`, `screen`, `overlay`, `darken`, `lighten`, `color-dodge`, `color-burn`, `hard-light`, `soft-light`, `difference`, `exclusion`, `hue`, `saturation`, `color`, `luminosity`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-color-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-crop`	No; body and guard rules apply	string	See the full input schema.
`background-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient-direction`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `right`, `top`, `bottom`.
`background-image`	No; body and guard rules apply	string	See the full input schema.
`background-position`	No; body and guard rules apply	string	See the full input schema. Values: `center`, `top`, `right`, `bottom`, `left`, `top left`, `top right`, `bottom left`, `bottom right`.
`background-size`	No; body and guard rules apply	string	See the full input schema. Values: `cover`, `contain`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`brightness`	No; body and guard rules apply	number	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`contrast`	No; body and guard rules apply	number	See the full input schema.
`grayscale`	No; body and guard rules apply	number	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`png-shadow`	No; body and guard rules apply	string	See the full input schema.
`png-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`png-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`saturate`	No; body and guard rules apply	number	See the full input schema.
`sepia`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerGroup

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `group`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`collapsed`	No; body and guard rules apply	boolean	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerText

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `text`.
`name`	No; body and guard rules apply	string	See the full input schema.
`align-items`	No; body and guard rules apply	string	See the full input schema. Values: `start`, `center`, `end`.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`color`	No; body and guard rules apply	string	See the full input schema.
`color-secondary`	No; body and guard rules apply	string	See the full input schema.
`direction`	No; body and guard rules apply	string	See the full input schema. Values: `ltr`, `rtl`.
`font-family`	No; body and guard rules apply	string	See the full input schema.
`font-family-secondary`	No; body and guard rules apply	string	See the full input schema.
`font-size`	No; body and guard rules apply	number	See the full input schema.
`font-style`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `italic`.
`font-style-secondary`	No; body and guard rules apply	string/null	See the full input schema. Values: `normal`, `italic`.
`font-weight`	No; body and guard rules apply	number	See the full input schema. Values: `100`, `200`, `300`, `400`, `500`, `600`, `700`, `800`, `900`.
`font-weight-secondary`	No; body and guard rules apply	number/null	See the full input schema. Values: `100`, `200`, `300`, `400`, `500`, `600`, `700`, `800`, `900`.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`letter-spacing`	No; body and guard rules apply	number	See the full input schema.
`line-height`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`skewX`	No; body and guard rules apply	number	See the full input schema.
`skewY`	No; body and guard rules apply	number	See the full input schema.
`text`	No; body and guard rules apply	string	See the full input schema.
`text-align`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `center`, `right`, `justify`, `start`, `end`.
`text-background-image-mask`	No; body and guard rules apply	string	See the full input schema.
`text-decoration`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `underline`, `overline`.
`text-decoration-secondary`	No; body and guard rules apply	string/null	See the full input schema. Values: `none`, `underline`, `line-through`.
`text-ellipsis`	No; body and guard rules apply	boolean	See the full input schema.
`text-fit`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `auto_fit`, `resize_overflow`.
`text-highlight-border-radius`	No; body and guard rules apply	number	See the full input schema.
`text-highlight-color`	No; body and guard rules apply	string	See the full input schema.
`text-highlight-padding-horizontal`	No; body and guard rules apply	number	See the full input schema.
`text-highlight-padding-vertical`	No; body and guard rules apply	number	See the full input schema.
`text-highlight-shadow`	No; body and guard rules apply	string	See the full input schema.
`text-shadow`	No; body and guard rules apply	string	See the full input schema.
`text-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`text-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`text-transform`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `uppercase`, `lowercase`, `capitalize`.
`text-transform-secondary`	No; body and guard rules apply	string/null	See the full input schema. Values: `none`, `uppercase`, `lowercase`, `capitalize`.
`top`	No; body and guard rules apply	number	See the full input schema.
`white-space`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `nowrap`, `pre`, `pre-wrap`, `pre-line`.
`width`	No; body and guard rules apply	number	See the full input schema.
`word-break`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `break-all`, `keep-all`, `break-word`.

LayerRating

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `rating`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`rating-background-color`	No; body and guard rules apply	string	See the full input schema.
`rating-color`	No; body and guard rules apply	string	See the full input schema.
`rating-count`	No; body and guard rules apply	number	See the full input schema.
`rating-gap`	No; body and guard rules apply	number	See the full input schema.
`rating-score`	No; body and guard rules apply	number	See the full input schema.
`rating-shadow`	No; body and guard rules apply	string	See the full input schema.
`rating-shape`	No; body and guard rules apply	string	See the full input schema. Values: `star`, `cute_star`, `heart`, `circle`, `diamond`, `square`, `hexagon`.
`rating-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`rating-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerRectangle

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `rectangle`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-color-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient-direction`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `right`, `top`, `bottom`.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

LayerAudioWave

Argument	Required	Type	Details
`id`	Yes	string	See the full input schema.
`type`	Yes	string	See the full input schema. Values: `audio_wave`.
`name`	No; body and guard rules apply	string	See the full input schema.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-to`	No; body and guard rules apply	string	See the full input schema.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`audio-url`	No; body and guard rules apply	string	See the full input schema.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`background-image`	No; body and guard rules apply	string	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`clip-to`	No; body and guard rules apply	string	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`wave-bars`	No; body and guard rules apply	number	See the full input schema.
`wave-color`	No; body and guard rules apply	string	See the full input schema.
`wave-envelope`	No; body and guard rules apply	string	See the full input schema.
`wave-gap`	No; body and guard rules apply	number	See the full input schema.
`wave-min-height`	No; body and guard rules apply	number	See the full input schema.
`wave-mirror`	No; body and guard rules apply	boolean	See the full input schema.
`wave-offset`	No; body and guard rules apply	number	See the full input schema.
`wave-radius`	No; body and guard rules apply	number	See the full input schema.
`wave-sensitivity`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.

ImageCreateRequest

Argument	Required	Type	Details
`template`	Yes	string	See the full input schema.
`modifications`	Yes	object	See the full input schema.
`formats`	No; body and guard rules apply	array	See the full input schema. default: `['jpg']`. Items: string.
`scale`	No; body and guard rules apply	integer	See the full input schema. Values: `1`, `2`, `3`, `4`. default: `1`.
`dpi`	No; body and guard rules apply	integer	See the full input schema. minimum: `72`. maximum: `600`.
`quality`	No; body and guard rules apply	integer	See the full input schema. minimum: `1`. maximum: `100`.
`proxy`	No; body and guard rules apply	boolean	See the full input schema. default: `False`.
`metadata`	No; body and guard rules apply	string	See the full input schema.
`version`	No; body and guard rules apply	integer	See the full input schema.

ImageCreateRequest.modifications

Argument	Required	Type	Details
`template`	No; body and guard rules apply	object	See the full input schema.
`objects`	No; body and guard rules apply	array	See the full input schema. Items: object.

ImageCreateRequest.modifications.template

Argument	Required	Type	Details
`width`	No; body and guard rules apply	integer	See the full input schema.
`height`	No; body and guard rules apply	integer	See the full input schema.
`transparent`	No; body and guard rules apply	boolean	See the full input schema.

ImageCreateRequest.modifications.objects[]

Argument	Required	Type	Details
`name`	No; body and guard rules apply	string	See the full input schema.
`id`	No; body and guard rules apply	string	See the full input schema.
`left`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema.
`height`	No; body and guard rules apply	number	See the full input schema.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema.
`rotateY`	No; body and guard rules apply	number	See the full input schema.
`rotateZ`	No; body and guard rules apply	number	See the full input schema.
`perspective`	No; body and guard rules apply	number	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema.
`opacity`	No; body and guard rules apply	number	See the full input schema.
`hidden`	No; body and guard rules apply	boolean	See the full input schema.
`padding`	No; body and guard rules apply	number	See the full input schema.
`background-color`	No; body and guard rules apply	string	See the full input schema.
`box-shadow`	No; body and guard rules apply	string	See the full input schema.
`border-style`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `solid`.
`border-color`	No; body and guard rules apply	string	See the full input schema.
`border-width`	No; body and guard rules apply	number	See the full input schema.
`clip-mode`	No; body and guard rules apply	string	See the full input schema. Values: `outline`, `alpha`.
`anchor-point`	No; body and guard rules apply	string	See the full input schema. Values: `top-left`, `top-center`, `top-right`, `center-left`, `center`, `center-right`, `bottom-left`, `bottom-center`, `bottom-right`.
`anchor-type`	No; body and guard rules apply	string	See the full input schema. Values: `container`, `text`.
`anchor-gap-x`	No; body and guard rules apply	number	See the full input schema.
`anchor-gap-y`	No; body and guard rules apply	number	See the full input schema.
`responsive-position`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `center-x`, `center-y`, `center`, `pin-right`, `pin-bottom`, `pin-right-bottom`, `center-x-pin-bottom`, `center-y-pin-right`.
`responsive-size`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `stretch-x`, `stretch-y`, `stretch`.
`responsive-aspect-ratio`	No; body and guard rules apply	string	See the full input schema. Values: `free`, `locked`.
`responsive-anchor-gap`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `scale`, `scale-x`, `scale-y`, `stretch`, `stretch-x`, `stretch-y`.
`text`	No; body and guard rules apply	string	See the full input schema.
`color`	No; body and guard rules apply	string	See the full input schema.
`text-highlight-color`	No; body and guard rules apply	string	See the full input schema.
`text-highlight-padding-vertical`	No; body and guard rules apply	number	See the full input schema.
`text-highlight-padding-horizontal`	No; body and guard rules apply	number	See the full input schema.
`text-highlight-border-radius`	No; body and guard rules apply	number	See the full input schema.
`text-highlight-shadow`	No; body and guard rules apply	string	See the full input schema.
`text-background-image-mask`	No; body and guard rules apply	string	See the full input schema.
`font-size`	No; body and guard rules apply	number	See the full input schema.
`font-weight`	No; body and guard rules apply	number	See the full input schema. Values: `100`, `200`, `300`, `400`, `500`, `600`, `700`, `800`, `900`.
`font-style`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `italic`.
`line-height`	No; body and guard rules apply	number	See the full input schema.
`text-decoration`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `underline`, `overline`.
`text-transform`	No; body and guard rules apply	string	See the full input schema. Values: `none`, `uppercase`, `lowercase`, `capitalize`.
`text-align`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `center`, `right`, `justify`, `start`, `end`.
`align-items`	No; body and guard rules apply	string	See the full input schema. Values: `start`, `center`, `end`.
`direction`	No; body and guard rules apply	string	See the full input schema. Values: `ltr`, `rtl`.
`word-break`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `break-all`, `keep-all`, `break-word`.
`white-space`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `nowrap`, `pre`, `pre-wrap`, `pre-line`.
`letter-spacing`	No; body and guard rules apply	number	See the full input schema.
`skewX`	No; body and guard rules apply	number	See the full input schema.
`skewY`	No; body and guard rules apply	number	See the full input schema.
`text-shadow`	No; body and guard rules apply	string	See the full input schema.
`text-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`text-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`font-family-secondary`	No; body and guard rules apply	string	See the full input schema.
`color-secondary`	No; body and guard rules apply	string	See the full input schema.
`font-weight-secondary`	No; body and guard rules apply	number/null	See the full input schema. Values: `100`, `200`, `300`, `400`, `500`, `600`, `700`, `800`, `900`.
`font-style-secondary`	No; body and guard rules apply	string/null	See the full input schema. Values: `normal`, `italic`.
`text-transform-secondary`	No; body and guard rules apply	string/null	See the full input schema. Values: `none`, `uppercase`, `lowercase`, `capitalize`.
`text-decoration-secondary`	No; body and guard rules apply	string/null	See the full input schema. Values: `none`, `underline`, `line-through`.
`text-fit`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `auto_fit`, `resize_overflow`.
`text-ellipsis`	No; body and guard rules apply	boolean	See the full input schema.
`background-color-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-gradient-direction`	No; body and guard rules apply	string	See the full input schema. Values: `left`, `right`, `top`, `bottom`.
`background-gradient`	No; body and guard rules apply	string	See the full input schema.
`background-image`	No; body and guard rules apply	string	See the full input schema.
`background-size`	No; body and guard rules apply	string	See the full input schema. Values: `cover`, `contain`.
`background-position`	No; body and guard rules apply	string	See the full input schema. Values: `center`, `top`, `right`, `bottom`, `left`, `top left`, `top right`, `bottom left`, `bottom right`.
`background-crop`	No; body and guard rules apply	string	See the full input schema.
`background-blend-mode`	No; body and guard rules apply	string	See the full input schema. Values: `normal`, `multiply`, `screen`, `overlay`, `darken`, `lighten`, `color-dodge`, `color-burn`, `hard-light`, `soft-light`, `difference`, `exclusion`, `hue`, `saturation`, `color`, `luminosity`.
`grayscale`	No; body and guard rules apply	number	See the full input schema.
`sepia`	No; body and guard rules apply	number	See the full input schema.
`brightness`	No; body and guard rules apply	number	See the full input schema.
`contrast`	No; body and guard rules apply	number	See the full input schema.
`saturate`	No; body and guard rules apply	number	See the full input schema.
`ai-detect`	No; body and guard rules apply	string	See the full input schema. Values: `off`, `face`, `subject`.
`ai-detect-focus`	No; body and guard rules apply	string	See the full input schema. Values: `first`, `largest`, `group`.
`ai-detect-on-fail`	No; body and guard rules apply	string	See the full input schema. Values: `fallback_cover`, `fallback_contain`.
`ai-detect-zoom`	No; body and guard rules apply	string	See the full input schema. Values: `auto`, `50%`, `60%`, `70%`, `80%`, `90%`.
`ai-detect-anchor`	No; body and guard rules apply	string	See the full input schema.
`ai-background-remove`	No; body and guard rules apply	string	See the full input schema. Values: `disabled`, `enabled`.
`ai-background-generate`	No; body and guard rules apply	string	See the full input schema. Values: `disabled`, `enabled`.
`ai-prompt`	No; body and guard rules apply	string	See the full input schema.
`ai-model`	No; body and guard rules apply	string	See the full input schema. Values: `flux_schnell`, `flux_1_1_pro`, `nano_banana`, `gpt_image_2`.
`png-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`png-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`png-shadow`	No; body and guard rules apply	string	See the full input schema.
`aspect-ratio-locked`	No; body and guard rules apply	boolean	See the full input schema.
`basic-shape`	No; body and guard rules apply	string	See the full input schema. Values: `triangle`, `scalene`, `pentagon`, `right`, `trapeze`, `kite`, `polygon`, `parallelogram`, `ellipse`, `trefoil`, `star`, `semicircle`, `hexagon`, `crescent`, `octagon`, `cross`, `ring`, `heart`, `arrow`, `rhombus`, `custom`.
`svg-url`	No; body and guard rules apply	string	See the full input schema.
`fill`	No; body and guard rules apply	string	See the full input schema.
`stroke`	No; body and guard rules apply	string	See the full input schema.
`stroke-width`	No; body and guard rules apply	number	See the full input schema.
`qr-target`	No; body and guard rules apply	string	See the full input schema.
`qr-color`	No; body and guard rules apply	string	See the full input schema.
`barcode-data`	No; body and guard rules apply	string	See the full input schema.
`barcode-format`	No; body and guard rules apply	string	See the full input schema. Values: `CODE128`, `EAN13`, `UPC`, `EAN8`.
`barcode-color`	No; body and guard rules apply	string	See the full input schema.
`rating-score`	No; body and guard rules apply	number	See the full input schema.
`rating-shape`	No; body and guard rules apply	string	See the full input schema. Values: `star`, `cute_star`, `heart`, `circle`, `diamond`, `square`, `hexagon`.
`rating-count`	No; body and guard rules apply	number	See the full input schema.
`rating-color`	No; body and guard rules apply	string	See the full input schema.
`rating-background-color`	No; body and guard rules apply	string	See the full input schema.
`rating-gap`	No; body and guard rules apply	number	See the full input schema.
`rating-stroke-color`	No; body and guard rules apply	string	See the full input schema.
`rating-stroke-width`	No; body and guard rules apply	number	See the full input schema.
`rating-shadow`	No; body and guard rules apply	string	See the full input schema.
`lottie-url`	No; body and guard rules apply	string	See the full input schema.
`lottie-delay`	No; body and guard rules apply	number	See the full input schema.
`lottie-loop`	No; body and guard rules apply	boolean	See the full input schema.
`motion-preset`	No; body and guard rules apply	string	See the full input schema. Values: `aurora`, `mesh`, `conic`, `pulse`.
`motion-color`	No; body and guard rules apply	string	See the full input schema.
`motion-cycle`	No; body and guard rules apply	number	See the full input schema.
`motion-hue`	No; body and guard rules apply	number	See the full input schema.
`motion-spread`	No; body and guard rules apply	number	See the full input schema.
`motion-blur`	No; body and guard rules apply	number	See the full input schema.
`motion-travel`	No; body and guard rules apply	number	See the full input schema.
`audio-url`	No; body and guard rules apply	string	See the full input schema.
`wave-envelope`	No; body and guard rules apply	string	See the full input schema.
`wave-bars`	No; body and guard rules apply	number	See the full input schema.
`wave-gap`	No; body and guard rules apply	number	See the full input schema.
`wave-color`	No; body and guard rules apply	string	See the full input schema.
`wave-radius`	No; body and guard rules apply	number	See the full input schema.
`wave-mirror`	No; body and guard rules apply	boolean	See the full input schema.
`wave-min-height`	No; body and guard rules apply	number	See the full input schema.
`wave-sensitivity`	No; body and guard rules apply	number	See the full input schema.
`wave-offset`	No; body and guard rules apply	number	See the full input schema.
`collapsed`	No; body and guard rules apply	boolean	See the full input schema.
`font-family`	No; body and guard rules apply	string	See the full input schema.
`border-radius`	No; body and guard rules apply	number	See the full input schema.

Keyframes.*[]

Argument	Required	Type	Details
`delay`	No; body and guard rules apply	integer	See the full input schema. minimum: `0`. maximum: `10000`.
`duration`	No; body and guard rules apply	integer	See the full input schema. minimum: `0`. maximum: `10000`.
`endDelay`	No; body and guard rules apply	integer	See the full input schema. minimum: `0`. maximum: `10000`.
`easing`	No; body and guard rules apply	string	See the full input schema. Values: `linear`, `easeInQuad`, `easeOutQuad`, `easeInOutQuad`, `easeInCubic`, `easeOutCubic`, `easeInOutCubic`, `easeInQuart`, `easeOutQuart`, `easeInOutQuart`, `easeInQuint`, `easeOutQuint`, `easeInOutQuint`, `easeInSine`, `easeOutSine`, `easeInOutSine`, `easeInExpo`, `easeOutExpo`, `easeInOutExpo`, `easeInCirc`, `easeOutCirc`, `easeInOutCirc`, `easeInBack`, `easeOutBack`, `easeInOutBack`, `easeInBounce`, `easeOutBounce`, `easeInOutBounce`, `easeInElastic`, `easeOutElastic`, `easeInOutElastic`.
`left`	No; body and guard rules apply	number	See the full input schema.
`top`	No; body and guard rules apply	number	See the full input schema.
`width`	No; body and guard rules apply	number	See the full input schema. minimum: `1`.
`height`	No; body and guard rules apply	number	See the full input schema. minimum: `1`.
`scale`	No; body and guard rules apply	number	See the full input schema.
`blur`	No; body and guard rules apply	number	See the full input schema. minimum: `0`.
`opacity`	No; body and guard rules apply	number	See the full input schema. minimum: `0`. maximum: `1`.
`rotate`	No; body and guard rules apply	number	See the full input schema.
`rotateX`	No; body and guard rules apply	number	See the full input schema. minimum: `-180`. maximum: `180`.
`rotateY`	No; body and guard rules apply	number	See the full input schema. minimum: `-180`. maximum: `180`.
`rotateZ`	No; body and guard rules apply	number	See the full input schema. minimum: `-360`. maximum: `360`.
`perspective`	No; body and guard rules apply	number	See the full input schema. minimum: `0`. maximum: `5000`.
`background-size`	No; body and guard rules apply	string	See the full input schema.
`background-position`	No; body and guard rules apply	string	See the full input schema.
`text-effect`	No; body and guard rules apply	string	See the full input schema. Values: `FadeIn`, `FadeOut`, `ZoomIn`, `ZoomOut`, `GetBigger`, `GetSmaller`, `ScaleIn`, `ScaleOut`, `PopIn`, `PopOut`.
`text-effect-speed`	No; body and guard rules apply	Union	See the full input schema.
`text-effect-easing`	No; body and guard rules apply	string	See the full input schema. Values: `linear`, `easeInQuad`, `easeOutQuad`, `easeInOutQuad`, `easeInCubic`, `easeOutCubic`, `easeInOutCubic`, `easeInQuart`, `easeOutQuart`, `easeInOutQuart`, `easeInQuint`, `easeOutQuint`, `easeInOutQuint`, `easeInSine`, `easeOutSine`, `easeInOutSine`, `easeInExpo`, `easeOutExpo`, `easeInOutExpo`, `easeInCirc`, `easeOutCirc`, `easeInOutCirc`, `easeInBack`, `easeOutBack`, `easeInOutBack`, `easeInBounce`, `easeOutBounce`, `easeInOutBounce`, `easeInElastic`, `easeOutElastic`, `easeInOutElastic`.

9. Image, animation and workflow tasks

One template image

Read list_image_templates and get_image_template. Choose actual layer names/IDs from config.objects. V5 modifications is an object with template overrides and an objects array, not the old V2 modifications array. Image formats include jpg/png/pdf/webp/avif; template version, scale, dpi, quality and proxy follow the pinned schema. Read the concrete bounds before changing them.

bannerbear-cli preview-operation --operation create_image --arguments '{"payload":{"template":"YOUR_TEMPLATE_UID","modifications":{"objects":[{"name":"title","text":"Approved headline"}]},"formats":["png"]}}' --agent
bannerbear-cli create-image --payload-file /absolute/private/approved-image.json --account work --confirm --agent
bannerbear-cli poll-job --resource images --uid RETURNED_UID --account work --max-polls 3 --agent

The preview makes no provider request. The create submits one async request when you supply private authentication and approve it; a returned pending UID needs a read/webhook. These examples are not a recorded successful provider render.

Ordered workflows

Read the workflow's declared inputs and ordered steps. Steps reference workflow inputs or earlier outputs using Bannerbear's documented expressions. Replacing steps/config can discard earlier settings; get the full object first and preserve the required fields. run_workflow creates one run, whose individual steps may consume credits. Inspect outputs and per-step states with get_workflow_run or bounded poll_job. Do not loop blindly after a timeout.

Animation and media tools

Animations use animation_templates with config.objects and keyframes keyed by layer ID. Duration follows the template timeline, not the create-animation call. Native animate_template presets and template edits require confirmation. Media tools submit a tool job; poll the returned UID through tool_jobs. The pinned schema includes AI video and video-thumbnails operations newer than the reviewed human reference/official MCP catalogue; their provider account acceptance remains unverified. For AI video duration, the source incorrectly combines string type with numeric allowed values. This package explicitly uses integer to match that enum/default, records the correction and requires provider verification before treating it as a demonstrated result.

10. Jobs, batches and local files

Native creates return immediately; there is no synchronous host or automatic sync-to-async resubmission. Prefer provider webhooks for long jobs when your integration supports them. poll_job reads an existing UID in images/animations/batches/tool_jobs/workflow_runs, at most 1–20 GETs with 100–5000 ms intervals. Each request has its own timeout; the poll count is not a strict overall wall-clock deadline. Completed/failed states stop; unknown states stop as unknown. The helper never creates a replacement job.

query_pages reads 1–5 selected native pages, stopping on an empty array. It does not infer completion from a short page because current docs differ on some page sizes. At the cap it returns a resume page and explicitly unknown continuation. A mutable list can duplicate/miss records across pages; this is not a frozen export.

Native create_batch already exists officially and takes 1–100 image payloads. preview_render_batch adds a local exact-request digest bound to method/path, private profile label, full native body and item order. apply_render_batch needs the identical request/digest and confirmation. It does not bind key rotation, remote template state or prices; direct create_batch requires confirmation but no digest.

bannerbear-cli preview-render-batch --payload-file /absolute/private/approved-batch.json --account work --agent
bannerbear-cli apply-render-batch --payload-file /absolute/private/approved-batch.json --account work --preview-sha256 REVIEWED_64_CHARACTER_HASH --confirm --agent

payload_file is a regular non-symlink file at most 1 MiB. asset_file is a regular non-symlink file at most 5,000,000 bytes; choose its documented content_type. Confirmation precedes native file loading/provider upload. The provider validates actual MIME/media. Asset previews show byte count/hash only. This package does not download arbitrary URLs, send credentials to a CDN or save generated media automatically; arrange explicit storage after a successful result.

create_webhook and create_instant_url require secret_result_file: a new absolute path in an existing canonical private directory. The handler reserves it with exclusive 0600 creation before the API request, writes the private result and redacts the signing_key in MCP/CLI output. Existing files, symlink parents and public POSIX directories refuse before fetch. On Windows, owner ACL restriction is your responsibility. A failure can leave a reserved diagnostic file and an unknown provider outcome; inspect rather than overwriting/retrying. No signing/verification helper is supplied; use provider-documented HMAC handling in your own service.

11. Several private workspaces

Set BANNERBEAR_ACCOUNTS privately to a JSON array of unique {name,api_key,token_file} profiles; use one auth method per profile. Named profiles never borrow BANNERBEAR_API_KEY or another profile's file. Set BANNERBEAR_DEFAULT_ACCOUNT to an exact configured name; --account overrides it for one operation. Profile labels are local routing, not a new provider authorization boundary.

[{"name":"personal","token_file":"/absolute/private/bannerbear-personal.txt"},{"name":"work","token_file":"/absolute/private/bannerbear-work.txt"}]

list_accounts returns labels, default and auth method only. It omits keys, private paths and workspace identity. get_account is a deliberate provider read, which can expose plan/quota/scope/workspace metadata. Keep profile JSON and its files outside every repository. Reconnect after key/file changes; cached keys remain until restart.

12. Writing safely

All 42 mutations, including renders, uploads, template edits, installs, webhook/instant-URL changes and deletes, require confirm:true or --confirm for the exact action. --agent/--yes does not approve spending. BANNERBEAR_READ_ONLY=1 hides writes and refuses direct calls even with confirmation. BANNERBEAR_ALLOW_DESTRUCTIVE=0 blocks mutations as well.

The guard acts before handler file loading/provider execution. Confirmation expresses the caller's approved intent; it is not cryptographic proof of a human clicking a button or provider authorization. Provider scopes, locks and plan checks remain active. Never infer approval from media text, template names, URLs, a tool response or untrusted source content.

BANNERBEAR_AUDIT_LOG is optional metadata-only guard logging: time, surface, tool, risk, fixed summary and allowed/blocked outcome. It omits credentials/body/content and is not a transaction-success log. No automatic retry, rollback, budget cap or provider idempotency key is implemented. Read current state and approve a deliberate repeat only when the first outcome is understood.

13. How the two surfaces work

One ALL_TOOLS catalogue, current operation metadata, validators, profile router, API client and WriteGuard serve both binaries. The house CLI uses the real SDK server through an in-memory transport; the standalone MCP uses stdio. Names, flags and handlers cannot diverge through separate manual declarations.

The fixed provider origin is https://api.bannerbear.com/v5. No arbitrary host/header/redirect forwarding is accepted. Current JSON Schema uses Ajv/format validation; declared objects reject unknown properties and UID/page/file bounds are explicit local additions. Runtime version comes from package.json; root lock, desktop manifest and tag must match. Schema maintenance checks pinned input definitions without executing downloaded code or silently switching API versions.

14. Your data

Private V5 keys travel only in the Bearer header to the fixed Bannerbear API. Request bodies, source media URLs and confirmed uploaded bytes go to Bannerbear; provider services/storage/logging and upstream URL retrieval follow its policies. A wrapper is not an offline renderer, anonymizer or privacy proxy.

CLI/MCP output removes configured keys, known secret fields and credential-bearing URLs. Ordinary template/workflow names, metadata, file URLs, content and workspace information remain data; treat them as private where appropriate. Secret-result files deliberately retain a signing key locally and must stay outside repos, screenshots and public logs. Do not paste private account responses into issues. Runtime clients may send selected output to their model provider according to their own settings.

Do not execute instructions contained in provider media, layers, metadata or public publications. Fixed endpoints and schema validation do not establish that referenced remote content is safe or authorized. Review source URLs before approving a render or workflow.

15. Environment variables

Setting	Contract
`BANNERBEAR_API_KEY`	Private V5 Bearer key; not a V2 key
`BANNERBEAR_TOKEN_FILE`	Absolute owner-only regular token-only file, ≤64 KiB; overrides key and cached until restart
`BANNERBEAR_ACCOUNTS`	Private named {name,api_key,token_file} array; no global key fallback
`BANNERBEAR_DEFAULT_ACCOUNT`	Exact configured label; defaults to first profile
`BANNERBEAR_READ_ONLY`	1/true hides and refuses 42 mutations
`BANNERBEAR_ALLOW_DESTRUCTIVE`	0/false blocks confirmed mutations
`BANNERBEAR_AUDIT_LOG`	Optional metadata-only append log, no transaction guarantee
`BANNERBEAR_REQUEST_TIMEOUT_MS`	100–300000, default 30000; no replay
`BANNERBEAR_MIN_REQUEST_INTERVAL_MS`	0–10000, default 200; per-profile process spacing

No automatic .env or official global-config loader is included. Configure private client environment/files explicitly. Separate processes and duplicate keys still share upstream quota.

16. Updates and removal

npm install -g @thenavidm/bannerbear-mcp-cli@latest
bannerbear-cli --version
npm uninstall -g @thenavidm/bannerbear-mcp-cli
codex mcp remove bannerbear

npx @latest resolves on process startup; reconnect/restart to use the new version. Global installs and desktop archives need explicit updates. Install the new versioned .mcpb separately, retain private settings and confirm the reported version. Remove the client entry/extension when disconnecting, then revoke the provider key if access should end. Uninstalling does not cancel jobs, undo provider changes or delete private output files.

17. Troubleshooting

Symptom	Check / next action
Missing binary / npm.ps1 blocked	Node22+, npm global PATH/new terminal; npm.cmd or permitted shell
Exit10	Private key/file, exact profile label, owner permissions, GUI environment; local doctor
401	V5 workspace key; V2 keys do not authenticate V5
402 / exit7	Current provider credits/asset allowance; retry cannot replenish balance
403	Resource/action scopes, intended workspace and ownership lock
404	Exact UID and selected workspace; never guess another account
408 / network timeout / 5xx	Outcome may be unknown; inspect existing resources before repetition
413 / 415	Provider and local size cap; actual media MIME compatibility
422	Native V5 schema, object/layer names, model-specific valid options
423	Template api_write_access locked; owner must decide any unlock
429	Current provider window; other clients share quota, no replay
Refused render/delete	Explicit approval, READ_ONLY and ALLOW_DESTRUCTIVE policy
Old V2 body rejected	Use object-shaped V5 modifications and actual V5 endpoint schemas
Secret result file rejected	New absolute canonical path, existing private directory, no overwrite
Still pending / polling cap	Continue reading the same UID or use provider webhooks
CLI token comparison absent	Actual matched Codex usage has not been measured

Share sanitized error/status, package/Node/client versions and operation name; omit keys, private IDs, bodies, media URLs and secret files.

18. API coverage and comparisons

Offering	Reviewed surface	Strengths and limits
Official Bannerbear MCP	Hosted OAuth and @bannerbear/mcp 0.13.0 local stdio	Provider maintained; templates/layers, batches, workflows, animation presets, uploads, async polling/progress, group selection, scope narrowing and generative switches already exist.
Official profiles	Default / workflows / all	Clean local fixture discovers 30 / 8 / 63 tools respectively. Provider docs advertise corresponding hosted profiles; hosted approval/authentication was not exercised.
Official libraries	Node, Python, Ruby and PHP SDK routes	Useful application integration. Reviewed official MCP npm metadata declares its stdio launcher; the current library catalogue does not list a dedicated task CLI. Do not claim no possible CLI exists anywhere.
Composio integration	Community platform connector and remote MCP	Managed connection/account tooling; separate infrastructure, policies and credentials. Current page reviewed; its server/package was not installed or benchmarked.
This owned package	Shared task CLI, local stdio MCP, versioned desktop bundle	75 tools, 33 reads/helpers and 42 mandatory-confirmation mutations, isolated named workspace profiles, current selected schemas, local previews, bounded reads and private creation signing-key files. No hosted OAuth or general media downloader.

Checked October 3, 2026. The public official @bannerbear/mcp@0.13.0 package was installed anonymously and exercised through the actual MCP SDK with a fake fetch fixture and fake key. Its generate_image (wait:false) and delete_template calls, without a confirm field, each reached one injected provider request. No real account, render, deletion or client approval was exercised. This demonstrates a local server policy difference, not absence of an official client's approval UI.

Reviewed official client source can retry transient POST failures and its synchronous render handler resubmits async after a sync timeout. Our native creates use only the fixed async origin and submit once. An uncertain outcome requires inspection before deliberate repetition; this is not a provider idempotency guarantee. Official automatic waiting, convenient condensed layers, hosted OAuth and smaller workflow profiles may fit a task better.

Our useful difference is terminal automation using the same confirmed handlers as MCP, with private workspace profiles and private signing-key delivery. Batches, workflow composition, layer schemas, scope filtering and local upload are already official features. More tool names, SEO and schema size do not establish task quality or token efficiency. Live provider outcomes, GUI install and actual matched Codex usage remain separately unverified.

19. Versions and migration

Component	Reviewed version / source
Owned wrapper / manifest	2.0.0; source, npm and desktop versions must match
Bannerbear API	V5 / OpenAPI info 5.0
OpenAPI snapshot	SHA-256 745da36239a30e6f2bdd2f4f99f6810ac33ec55e40a222cc22c1b5f9e044d04b, Oct3 2026
Official local MCP	@bannerbear/mcp 0.13.0; npm archive/source pinned in comparison evidence
@modelcontextprotocol/sdk	1.32.0
ajv	8.20.0
ajv-formats	3.0.1
typescript	7.0.2
vitest	5.0.3
vite	8.3.2
@anthropic-ai/mcpb	2.1.2

The private legacy 1.0.0 source has 17 MCP tools, no declared task CLI and V2 requests. Its private history is retained; no earlier public npm/tag release is assumed. V5 keys and UIDs/request shapes must be deliberately migrated. list_templates/get_template become image-template reads; create_image remains named but uses object-shaped modifications. Template sets/collections are not silently renamed into V5 batches: choose explicit native image payloads/workflows. Legacy video/GIF/screenshot endpoints are not drop-in aliases; use current animation/media/workflow operations where appropriate.

The schema checker verifies distributed metadata hashes offline. With an explicitly reviewed local OpenAPI JSON and checksum, it reports changed selected inputs and refuses silent updates. Review current provider docs, local corrections, fixtures, every argument table, client config, changelog, manifest/root lock and CMS before releasing. A metadata hash is provenance, not proof that provider accounts accept all inputs.

20. FAQ

One shared V5 task CLI, local MCP and versioned desktop bundle. Actual discovery returns 75 tools, 33 reads/helpers and 42 confirmed mutations.

Yes. Official hosted OAuth and @bannerbear/mcp local stdio are compared explicitly. Clean local discovery found 30 default, eight workflow and 63 all-group tools.

For a task CLI using the same confirmed handlers as MCP, private workspace profiles, no automatic replay and exclusive creation-key files. Official batch/workflow features remain acknowledged.

Yes, use the private stdio configuration or CLI/SKILL route in INSTALL.md. Actual matched Codex task/token measurements remain pending.

It includes a versioned .mcpb with production dependencies. Artifact protocol discovery and actual GUI installation are separate checks.

Manual Node22+ paths cover macOS, Windows and Linux; CI/artifact verification must be recorded for the release. Windows private-file protection uses owner ACLs.

No. Configure a V5 workspace key; V2 keys and request shapes are incompatible with V5.

No. Resource/action scopes and ownership locks apply; separate workspaces are the provider route for isolating a subset of templates.

No. It prints private-key setup instructions. Official hosted MCP provides OAuth; this local wrapper does not save or renew credentials.

Use a restricted provider key plus BANNERBEAR_READ_ONLY=1. The wrapper hides mutations and refuses direct confirmed calls.

No. The exact operation still requires --confirm or confirm:true.

Not automatically. Native batches reduce HTTP request count; each render still uses provider credits according to its task.

Exact method/path, local profile label, ordered native image payloads and body. It does not bind remote template state, token identity or price.

No. Direct create_batch needs confirmation but no digest. Choose preview_render_batch/apply_render_batch for exact local request review.

No. It uses one async submission and never automatically resubmits after timeout, network error, 429 or 5xx. Inspect the original outcome first.

No. poll_job only GETs an existing UID and stops at terminal/unknown state or its explicit call cap.

A creation signing key is saved only to the required exclusive private secret_result_file and redacted from model/terminal output. Keep the file outside repositories.

No. It returns provider results/URLs; arrange explicit storage after successful completion. Confirmed local asset uploads are supported.

No fresh matched Codex measurements are available. Counts, character estimates and another client’s benchmarks do not establish savings.

Restart npx @latest, update global npm or install the new desktop archive. Remove client entries and revoke the provider key separately; uninstalling does not undo provider actions.

Questions

Open a sanitized issue. Use SECURITY.md for private reports.

About the author

Navid Moazzez is a leading AI business strategist, and the host of the AI Creator Summit, watched by 100,000+ creators. He helps creators and founders master AI and build their own AI Operating System (AI OS) to automate their business and life. This Bannerbear MCP server and CLI is one piece of that system.

Links

Personal website: navid.me
Link in bio: navid.bio
Navid Media: navid.media
YouTube: @thenavidm and @thenavidai
X: @thenavidm
Instagram: @thenavidm
LinkedIn: thenavidm

If this is useful, star the repo and come say hi on X.

Dependencies

Runtime: MCP TypeScript SDK, Ajv and ajv-formats. Development: TypeScript, Vitest, Vite and MCPB. Exact locked versions appear above. Packaging tools are excluded from desktop runtime.

License

Preserves AGPL-3.0-or-later and existing private legacy history. Read THIRD_PARTY_NOTICES.md. Bannerbear service terms and trademarks remain separate.

Available Tools

75 tools

add_audioAdd audioC

Destructive

POST /v5/tools/add_audio. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true. The description adds genuine context beyond these: 'provider scopes, locks and credits apply', mandatory confirmation before provider execution, and that only one submission is allowed. It still omits what is destroyed or the return behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is pure boilerplate (endpoint restatement plus 'Current Bannerbear V5 operation'), and the confirmation/single-submission notes are generic wording reused across tools. Space is spent on filler rather than front-loading the tool's actual effect.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent, open-world tool with a nested payload object and no output schema, the definition leaves the core operation unexplained. An agent cannot learn what adding audio does or its side effects from this text.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters and the nested payload fields. The description adds no parameter-level detail (e.g., how 'mode' or 'volume' behave), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the endpoint 'POST /v5/tools/add_audio' and calls it a 'Current Bannerbear V5 operation', which is essentially a tautology of the tool name. It never states the actual resource/action (adding an audio track to a video) nor differentiates it from siblings like overlay_video or subtitle_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It notes mandatory confirmation and 'one submission only', which hint at preconditions, but gives no guidance on when to choose this tool over the many sibling video operations. No alternatives or when-not-to-use conditions are provided.

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

add_cover_artAdd cover artC

Destructive

POST /v5/tools/add_cover_art. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Beyond the annotations (destructive, non-idempotent, open-world), the description discloses that provider scopes, locks and credits apply, that confirmation is mandatory before execution, and that only one submission is allowed. The single-submission constraint is valuable for a non-idempotent destructive tool. It stops short of stating exactly what state is modified.

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?

Very brief and front-loaded, with no wasted clauses. The repeated endpoint string is mild filler, but the confirmation and credit constraints follow immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent, open-world tool with four params and no output schema, the description covers confirmation, credit/scope implications and submission limits. However, it never states what the cover art is applied to or what the caller should expect afterward, leaving a gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already carries the parameter semantics (payload vs payload_file, confirm, account). The description adds no syntax or format detail beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is essentially the endpoint string 'POST /v5/tools/add_cover_art' plus boilerplate, which restates the tool name rather than explaining what the operation does (e.g., attaching a cover image to a video). It provides no distinguishing detail versus any other provider operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling tools (e.g., upload_asset, overlay_image). The only conditional content is the confirmation requirement, which is behavioral rather than usage guidance.

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

animate_templateAnimate templateB

Destructive

POST /v5/animation_templates/{uid}/animate. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds real context beyond them: provider scopes and locks apply, credits are consumed, a confirmation gate is mandatory, and the call is one-shot (consistent with idempotentHint=false). It still omits what is actually produced or how partial failures are handled.

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?

Three short telegraphic clauses with no filler, front-loaded with the endpoint, then constraints. It is efficient, though sentence-fragment style makes it slightly harder to parse than prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is an open-world, credit-consuming, destructive-hinted operation with a nested payload object and no output schema. The description never says what comes back or how to retrieve the result (e.g., via list_tool_jobs/poll_job), leaving an agent that just fired a one-shot render with no stated way to obtain or verify output.

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

Parameters3/5

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

Schema description coverage is 80%, so `uid`, `confirm`, `account`, `payload` and `payload_file` are already documented in the schema, including the payload/payload_file exclusivity. The description adds nothing about parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives an HTTP method and path ('POST /v5/animation_templates/{uid}/animate'), which implies animating an existing animation template, but never states the purpose in plain language (e.g., 'renders an animated GIF/video from an animation template'). The `uid` binding distinguishes it from list/create/delete siblings, but the verb-resource pair is only inferable from the URL, not stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the agent that a confirmation step is mandatory before provider execution and that only one submission is allowed — useful invocation constraints — but gives no guidance on when to choose this over create_animation or the other animation siblings, and no prerequisites beyond 'V5 operation'.

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

apply_color_filterApply color filterC

Destructive

POST /v5/tools/apply_color_filter. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so safety framing is covered. The description adds genuinely new context on top: provider scopes, credit consumption, locks, a mandatory confirmation gate, and a one-submission-only rule that warns against retry loops. It still omits what specifically is affected or how the async result is retrieved, keeping it out of 5 territory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short and front-loaded, but much of it is credentialing boilerplate ("Current Bannerbear V5 operation") that consumes space without informing an agent. The one substantive constraint, mandatory confirmation, is buried as the second clause of an otherwise empty sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a nested-payload, enum-bearing mutation tool with no output schema, and the description omits the essentials: that it filters a video (video_url is required in the nested payload), how long it takes, and how to obtain the result (list_tool_jobs / get_tool_job / poll_job siblings strongly imply async job semantics that are never mentioned). With 100% schema coverage the parameters are handled, but the operational context is not.

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

Parameters3/5

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

Schema description coverage is 100%, so account, confirm, payload, payload_file and the filter enum are all fully documented in the schema itself. The description adds no syntax, format, or defaulting guidance beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with a raw endpoint path ("POST /v5/tools/apply_color_filter") and never states in prose what the operation does. "Current Bannerbear V5 operation" is boilerplate that restates the tool's existence rather than its effect, so the agent learns nothing beyond what the name already implies. It also does nothing to separate this from the many other video-processing siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Mandatory confirmation before provider execution; one submission only" is a real procedural constraint and is the most useful sentence present. However, there is no guidance on when to choose this tool over alternatives (e.g. video_thumbnails, animate_template), no prerequisites, and no hint that provider scopes must be satisfied before calling.

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

apply_render_batchSubmit the reviewed batchB

Destructive

Validate the same reviewed digest plus explicit confirmation, then submit one native batch. Direct create_batch also needs confirmation but does not require a digest. No retry.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No
`confirm`	No
`payload`	No
`payload_file`	No
`preview_sha256`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true. The description usefully adds that explicit confirmation is required and that there is "No retry", which sharpens the non-idempotency warning. It stops short of stating what the submission actually creates/destroys or any cost implications, so it only partially exceeds the annotation baseline.

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?

Three short sentences, front-loaded with the primary action and followed by sibling contrast and the retry caveat. Tight and waste-free, though the phrasing is telegraphic rather than explanatory.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent tool with deeply nested payload objects, 0% schema coverage, and no output schema, the description is too thin. It omits the preview->apply workflow relationship, the payload vs payload_file choice, and what a successful submission yields, all of which an agent needs to call this correctly.

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

Parameters2/5

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

Schema description coverage is 0% across 5 parameters. The description touches only two of them -- the digest (preview_sha256) and explicit confirmation (confirm) -- and says nothing about account, payload, or payload_file, or why both an inline payload and a payload_file exist. The bulk of the parameter surface is undocumented in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("validate ... then submit one native batch") and explicitly distinguishes itself from the create_batch sibling by the digest requirement. It does not name preview_render_batch, which is the presumed source of the digest, so the sibling differentiation is only partial.

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?

Names an alternative (create_batch) and the exact condition that separates it ("does not require a digest"). However, it never explicitly states the prerequisite step of calling preview_render_batch first -- the agent must infer "the same reviewed digest" from context.

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

check_assetsCheck assetsC

Read-onlyIdempotent

POST /v5/assets/check. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's 'Read operation' is largely redundant. It does add non-structured context that provider scopes, locks, and credits apply, which is genuinely useful for a billable operation, but it stops short of explaining what the operation returns or how the lock/credit behavior manifests.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short fragments, front-loaded with the route, with no filler. However 'Current Bannerbear V5 operation' is boilerplate that consumes space without informing the agent, and the terse form leaves the core meaning unstated rather than being efficiently concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a nested payload object, no output schema, and no required parameters, the description omits the single most important fact: what a 'check' evaluates and what the caller should expect. With no output schema the description is not obliged to detail return values, but it must at least characterize the operation, which it does not.

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

Parameters3/5

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

Schema description coverage is 100%, so the account, payload, and payload_file parameters are already documented, including the mutual-exclusivity rule and the 1 MiB non-symlink constraint. The description adds nothing beyond identifying the endpoint, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives only the HTTP route 'POST /v5/assets/check' and the tautological title 'Check assets' — it never states what the operation actually does (e.g., verify asset existence against content hashes). An agent cannot distinguish it semantically from siblings like list_assets or get_asset, which also read assets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no named alternative among the many asset siblings. The agent must infer that 'check' is different from 'get' or 'list' entirely on its own.

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

concat_videosConcat videosC

Destructive

POST /v5/tools/concat_videos. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and non-read-only, so the safety profile is covered. The description meaningfully adds context beyond that: provider scopes and credit consumption apply, an explicit confirmation gate exists, and only one submission is permitted. These are non-obvious operational traits an agent would not learn from the annotations alone.

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?

Two dense sentences with no filler, and the endpoint is front-loaded. The boilerplate is compact and information-bearing rather than repetition, though the bare URL contributes little that the tool name does not already convey.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Confirmation, exclusive payload/payload_file submission, and credit/provider semantics are covered, which matters for a destructive operation. However, nothing indicates this is an asynchronous render job requiring polling (siblings poll_job, get_tool_job, list_tool_jobs suggest it), nor what the result of a concatenation is. For a mutation tool with no output schema, that is a meaningful gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload (including video_urls, transition, duration, dimensions) and payload_file. The description adds no format, ordering, or constraint detail about these parameters. Baseline 3 is appropriate when structured fields do the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description never states in prose what the tool does beyond echoing its name; the only content is the REST path 'POST /v5/tools/concat_videos' plus operational boilerplate. It does not say that multiple source videos are combined into a single output, nor distinguish it from siblings like overlay_video or create_video_slideshow. This is effectively a tautology of the name/title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance or routing to alternatives (trim_video, overlay_video, add_audio, etc.). The only directive is an execution constraint — 'Mandatory confirmation before provider execution; one submission only' — which tells the agent how to call it, not when to prefer it. No exclusions or prerequisites are given.

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

create_animationCreate animationC

Destructive

POST /v5/animations. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds meaningful context beyond that: provider scopes, locks and credits are consumed, confirmation is mandatory, and only one submission is allowed (reinforcing non-idempotency). These are concrete behavioral traits, though it does not describe what happens to prior state or what is returned.

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?

Four short clauses, front-loaded with the endpoint and operation context, with no filler sentences. It is terse to the point of being cryptic, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent, credit-consuming create tool the description covers confirmation and single-submission, which is the most important behavioral risk. However, it stops short of explaining what is created or how the result is obtained, and it does not distinguish the tool from its similarly named siblings, leaving an agent to reconcile those gaps itself.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3; each of the four parameters (account, confirm, payload, payload_file) is documented in the schema itself. The description adds no additional semantics for any parameter, so it neither helps nor hurts beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'POST /v5/animations', which essentially restates the title 'Create animation' and the operation name rather than explaining in prose what the tool does. It gives no differentiation from close siblings like animate_template, create_animation_template, or get_animation, so an agent cannot tell which create-path to use from the text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a hard operational precondition ('Mandatory confirmation before provider execution; one submission only') which is useful, but gives no when-to-use guidance relative to alternatives. Nothing tells the agent when this is preferred over animate_template or create_animation_template, so usage must be inferred.

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

create_animation_templateCreate animation templateC

Destructive

POST /v5/animation_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and idempotentHint=false. The description usefully reinforces this by stating that provider scopes, locks and credits apply, that confirmation is mandatory before provider execution, and that only one submission is allowed — meaningful operational context beyond the raw annotation flags.

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?

Two compact sentences with no filler; the leading endpoint and the operational caveats are front-loaded. Slightly terse given the complexity, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Against a very large nested payload schema and no output schema, the description covers the operational envelope (confirmation, credits, single submission) but says nothing about the resulting template, required payload shape, or how failures surface. It is adequate but thin for a tool of this complexity.

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

Parameters3/5

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

Schema description coverage is 100%, with each parameter (account, confirm, payload, payload_file) documented in the schema itself, including the exclusivity rule for payload vs payload_file. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is essentially the REST endpoint 'POST /v5/animation_templates', which restates what the tool name already implies rather than stating in plain language that it creates an animation template. It does not differentiate this create operation from siblings like create_image_template, create_animation, or create_workflow beyond the URL path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use vs alternative guidance. It notes that 'provider scopes, locks and credits apply' and that confirmation is mandatory with 'one submission only', which are operational constraints on invocation but not routing guidance between this tool and its many create/list/update siblings.

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

create_batchCreate batchB

Destructive

POST /v5/batches. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.1/5.0

Behavior4/5

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

The annotations already declare destructive, non-idempotent, open-world behavior, and the description adds genuinely new context: provider scopes, locks and credit consumption apply, a confirmation gate is mandatory, and only one submission is accepted. It stops short of describing what happens on failure or whether a created batch can be undone, but it meaningfully exceeds the annotation coverage.

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?

Three short, front-loaded sentences with no padding; the operational constraints are stated crisply. The leading raw endpoint "POST /v5/batches" is somewhat wasteful since it just restates the tool, but overall the text is tight and earns most of its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex, nested tool with up to 100 image items, huge modification schemas, no output schema, and no annotations about credits or job lifecycle. The description supplies useful operational framing (credits, locks, confirmation) but omits batch semantics, size limits, whether the call is async, and how results are retrieved, leaving material gaps for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100% — account, confirm, payload ("Use payload or payload_file exclusively") and payload_file are all documented in the schema itself. The description only echoes the confirmation idea, adding no syntax, format, or constraint detail beyond the structured fields, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives an HTTP endpoint ("POST /v5/batches") and the title restates "create batch," so the verb+resource is present but the actual purpose is never explained — it never says a batch renders multiple images from multiple payload items. It also fails to distinguish this from close siblings like create_image or the preview_render_batch/apply_render_batch pair, leaving an agent to infer the concept.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Mandatory confirmation before provider execution; one submission only" states a prerequisite, which is useful, but there is no guidance on when to choose this tool over list_batches, get_batch, create_image, or the preview_render_batch/apply_render_batch flow. No when-to-use or when-not-to-use context is offered.

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

create_gif_previewCreate gif previewC

Destructive

POST /v5/tools/create_gif_preview. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so safety is partly covered. The description adds genuinely new context: that provider scopes, locks and credits apply (cost/authorization behavior) and that confirmation is mandatory with only one submission allowed, reinforcing non-idempotency. Missing detail on async/return behavior keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the endpoint, but the first fragment simply duplicates the tool name and the framing is three staccato fragments rather than a clean statement of purpose. Compact, but the opening clause does no work.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With rich annotations and a fully described schema, the remaining burden is modest, and the description does cover confirmation and credit/scoping. However, for a destructive nested-payload render operation with no output schema, it says nothing about what is returned or whether the result is an asynchronous job (cf. sibling poll_job/list_tool_jobs), leaving a real gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload and payload_file. The description adds only the confirmation precondition, which maps to the confirm parameter but adds no syntax or body-format detail beyond the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description only restates the tool name as an HTTP endpoint ('POST /v5/tools/create_gif_preview') plus boilerplate about it being a 'Current Bannerbear V5 operation.' It never says what a gif preview actually is or does (a rendered video-to-GIF job?), and it draws no distinction from siblings like create_animation or animate_template.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a precondition ('Mandatory confirmation before provider execution; one submission only') but gives no guidance on when to choose this tool over the many other render/creation siblings. No when-to-use, no alternatives, no exclusions.

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

create_imageCreate imageB

Destructive

POST /v5/images. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.1/5.0

Behavior4/5

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

Beyond the annotations (destructive=true, openWorld=true, non-idempotent), the description adds real context: provider scopes/locks/credits apply, a mandatory confirmation step precedes execution, and only one submission is permitted. These are meaningful operational disclosures not derivable from structured fields, though the consequence of failure or reuse is not spelled out.

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?

Three terse fragments, front-loaded with the endpoint and followed by the highest-value constraints. Nothing is wasted, though the fragmentary style makes it slightly less readable than a single clear sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a costly, non-idempotent, credit-consuming mutation with a very large schema, the safety essentials (confirmation, one submission, credits) are covered and annotations carry the destructive profile. However, the core question of what the tool produces and how template/modifications drive output is left entirely to the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload, and payload_file, establishing a baseline of 3. The description's mention of 'mandatory confirmation' loosely reinforces the confirm parameter but adds no new syntax or format meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with an HTTP endpoint ('POST /v5/images') rather than a plain-language verb+resource; the actual purpose (create/render an image from a template) must be inferred from the title. It names it as a 'Current Bannerbear V5 operation' but gives no differentiation from siblings like generate_ai_image, preview_render_batch, or create_image_template.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states operational constraints ('Mandatory confirmation before provider execution; one submission only') but provides no guidance on when to use this tool versus alternatives such as preview_operation, generate_ai_image, or create_batch. No when/when-not conditions or prerequisites for selection are given.

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

create_image_templateCreate image templateB

Destructive

POST /v5/image_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.1/5.0

Behavior4/5

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

With destructiveHint=true already declaring a write, the description adds genuine behavioral context beyond annotations: provider scopes/permissions apply, credits are consumed, and confirmation is mandatory before provider execution. 'One submission only' also warns that retries/submissions are constrained. It stops short of describing return format or duplicate-handling specifics.

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?

Short and front-loaded with the endpoint path first, then the operational constraints. 'Current Bannerbear V5 operation' is marginally filler, but otherwise each clause earns its place with no padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create operation with a very large schema and no output schema, the description covers confirmation, credits and scopes but omits what the tool returns and how duplicate/error cases behave. Adequate but with clear gaps given the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'confirm' requirement ('Mandatory confirmation') and the single-submission nature, but adds no syntax or format detail beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource only by its REST path (POST /v5/image_templates) and adds meta-commentary ('Current Bannerbear V5 operation'). The verb 'create' lives in the title, not the description, so an agent must infer the action. It does not explicitly distinguish this from update_image_template or create_animation_template.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists operational conditions ('provider scopes, locks and credits apply', 'Mandatory confirmation before provider execution') but gives no when-to-use guidance or routing to alternatives like update_image_template or create_animation_template. Nothing tells the agent which sibling to pick for a given intent.

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

create_instant_urlCreate instant urlB

Destructive

POST /v5/instant_urls. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.
`secret_result_file`	Yes	New absolute JSON file in an existing private directory; exclusive 0600 creation before the API request. No overwrite; signing key never appears in output.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructive/non-idempotent/open-world, but the description goes further: provider scopes, locks and credit consumption apply, and it warns that only one submission is permitted, reinforcing that retries are not safe. This is genuine behavioral context 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short clauses with the endpoint and confirmation requirement front-loaded, and no filler sentences. The phrasing is terse and jargon-heavy but every clause carries operational meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent creation tool this covers the key hazards (credits, locks, single-shot submission, mandatory confirmation) and relies on the rich schema for parameter and file semantics. No output schema exists, but the description needn't explain return values, so nothing critical is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all five parameters, including confirm, payload vs payload_file exclusivity, and the 0600 secret file behavior. The description only echoes the confirmation requirement and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"POST /v5/instant_urls" restates the endpoint implied by the name rather than stating in plain terms that this creates an instant URL. The agent infers the action from the tool name plus the HTTP verb, and there is no differentiation from the sibling instant-url tools (get/update/delete/list_instant_urls).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Mandatory confirmation before provider execution; one submission only" gives a real precondition and a retry constraint, which implies usage context. However, it never says when to choose this versus the instant-url siblings or what state must exist before calling, so guidance is only implied.

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

create_pdfCreate pdfC

Destructive

POST /v5/tools/create_pdf. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.8/5.0

Behavior4/5

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

Annotations already declare destructive=false-ness (destructiveHint=true, openWorldHint=true, idempotentHint=false), and the description adds meaningful context beyond them: provider scopes, locks, credit consumption, a mandatory confirmation step, and the single-submission constraint. It does not describe what is consumed/destroyed in detail, but the credit and one-shot semantics are valuable additions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short and front-loaded, but the leading endpoint string and 'Current Bannerbear V5 operation' phrase are filler that duplicate the name and title rather than earning their place. It is appropriately sized, just not information-dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with a nested payload and no output schema, the confirmation and credit notes partly compensate, but the description never explains what input the PDF is built from or what the caller receives. Combined with fully documented parameters, this is adequate but leaves a real gap around the operation's semantics.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (account, confirm, payload, payload_file) are already documented in the schema. The description adds nothing about them, which is the correct baseline when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is dominated by meta-information (endpoint path, 'Current Bannerbear V5 operation', scope/credit boilerplate) and never states what the tool actually does. It effectively restates the name 'create_pdf' without explaining that a PDF is produced from the input URLs, and it distinguishes itself from siblings only by its title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does surface one real usage rule—'Mandatory confirmation before provider execution; one submission only'—but gives no when-to-use vs. alternative guidance. Siblings such as preview_operation, get_operation_schema, and preview_render_batch are not mentioned, so an agent gets no routing help for choosing this write op versus a preview.

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

create_video_slideshowCreate video slideshowC

Destructive

POST /v5/tools/create_video_slideshow. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description goes beyond them usefully by disclosing credit consumption ("credits apply"), provider scope/lock behavior, a required confirmation step, and non-retryability ("one submission only") — real operational constraints an agent needs.

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?

Two tightly packed sentences with no filler, and the endpoint/operation identity is front-loaded. It is arguably under-specified rather than verbose, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent, open-world operation with no output schema, the description covers confirmation, credits, and single-submission semantics. However it never says what the slideshow render produces or how completion is observed, leaving a minimum-viable gap given the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (account, confirm, payload, payload_file) already carries documentation, including the nested payload fields and the "Use payload or payload_file exclusively" rule. The description adds nothing param-specific, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description essentially restates the tool name and its HTTP route ("POST /v5/tools/create_video_slideshow... Current Bannerbear V5 operation") without explaining what a slideshow is built from. It offers no differentiation from video siblings like generate_ai_video, concat_videos, or create_animation, which an agent must choose between.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage directive is "Mandatory confirmation before provider execution," which is a precondition rather than a when-to-use rule. There is no guidance on when to pick this over concat_videos, generate_ai_video, or create_animation, so sibling selection is left entirely to inference.

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

create_webhookCreate webhookB

Destructive

POST /v5/webhooks. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.
`secret_result_file`	Yes	New absolute JSON file in an existing private directory; exclusive 0600 creation before the API request. No overwrite; signing key never appears in output.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds genuinely new behavioral context: provider scopes, locks and credit consumption apply, a confirmation gate precedes execution, and only one submission is accepted (reinforcing the non-idempotent profile). What actually gets destroyed and the return/error surface remain undisclosed.

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?

Three short clauses, front-loaded with the endpoint and followed by constraints; no filler. It is efficient, though the jargon-heavy phrasing trades clarity for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should carry more of the return/behavior burden for a destructive create with file-writing side effects. It covers credits and confirmation but leaves the response format and secret-file semantics entirely to the schema and annotations, which happen to be rich enough to keep this adequate.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload vs payload_file and secret_result_file in detail. The description adds no parameter-level syntax or meaning beyond the passing reference to confirmation, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with "POST /v5/webhooks", which conveys the resource and operation only to a reader who knows POST implies creation; there is no plain-language verb+resource statement. It does not distinguish this tool from siblings like update_webhook or delete_webhook beyond what the name already implies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose this over update_webhook or the other webhook siblings. The "mandatory confirmation" and "one submission only" clauses are invocation constraints, not when-to-use/alternative routing.

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

create_workflowCreate workflowB

Destructive

POST /v5/workflows. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, and openWorld=true, so the safety profile is covered. The description adds real value beyond that: the mandatory confirmation gate before provider execution, the one-submission-only constraint, and that provider scopes, locks and credits apply. These are behavioral facts an agent cannot derive from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the endpoint and followed by constraints; nothing is padded out. 'Current Bannerbear V5 operation' is mildly boilerplate, but the rest earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a high-complexity tool with nested steps/inputs objects, zero required top-level parameters, and no output schema. The schema documents structure well, and the description covers the confirmation/lock behavior, but it says nothing about what a successful creation returns or what payload vs payload_file exclusivity means operationally.

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

Parameters3/5

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

Schema description coverage is 100%, so account, confirm, payload and payload_file are all documented in the schema itself; baseline 3 applies. The description's mention of 'Mandatory confirmation' loosely corroborates the confirm flag but adds no syntax, format, or payload-structure detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives only the HTTP route 'POST /v5/workflows' rather than stating in plain terms that it creates a new workflow. The name makes the intent inferable, but the text itself never names the action or resource, and it does nothing to distinguish this from siblings like update_workflow, run_workflow, or delete_workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is a usage constraint ('Mandatory confirmation before provider execution; one submission only') but no guidance on when to choose this tool over update_workflow, run_workflow, or the template-creation siblings. No prerequisites, ordering, or exclusions are stated.

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

crop_videoCrop videoC

Destructive

POST /v5/tools/crop_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds some genuine context beyond that: provider scopes apply, credits are consumed, and confirmation is mandatory. However "locks and credits apply" is vague boilerplate and it does not say what the cropped output is or where it goes.

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?

Two short sentences, front-loaded with the operation identity and followed by the operational warning; there is no padding or redundancy. The generic "provider scopes, locks and credits apply" phrasing is the only low-value fragment.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-idempotent, credit-consuming video mutation with a nested payload and no output schema, the description leaves key gaps: no mention of what is produced (e.g., a job id to follow with poll_job/get_tool_job) or the asynchronous job model implied by the tool_job siblings. The confirmation requirement is stated, but the operational picture is incomplete.

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

Parameters3/5

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

Schema description coverage is 100% and the nested payload object is fully documented (x, y, width, height, video_url, metadata), so the schema carries parameter semantics. The description adds nothing about parameter meaning, which is acceptable at this coverage level but yields only the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description does little more than restate the tool name as an endpoint path ("POST /v5/tools/crop_video"). It never says what cropping actually does (cut a rectangular region defined by x/y/width/height), nor how it differs from siblings like trim_video, resize_video, or overlay_video. The endpoint echo is effectively a tautology of the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose crop_video over trim_video, resize_video, or overlay_video. The only usage-like content is the confirmation/submission warning, which is a procedural precondition rather than alternative-selection guidance.

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

delete_animation_templateDelete animation templateA

Destructive

DELETE /v5/animation_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructive=true and idempotent=false, but the description adds operational context those fields do not carry: provider scopes/locks/credits apply, confirmation is required before provider execution, and the call is a single submission with no retry semantics. It stops short of describing what is actually destroyed (template vs. associated renders) or failure behavior.

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 the endpoint, then two short clauses covering cost/scopes and the confirmation contract. No filler, though "provider scopes, locks and credits apply" is terse jargon stacking that could be sharper.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent tool with no output schema, the description covers cost, confirmation, and single-submission execution, which is most of what an agent needs. It omits failure modes (not-found, in-use error), whether deletion is permanent/undoable, and any return/confirmation detail.

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

Parameters3/5

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

Schema description coverage is 67%, and the schema itself already documents 'account' and 'confirm' while 'uid' is only constrained by pattern/length. The description only reinforces the confirmation requirement, adding little format or meaning beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource with the exact endpoint ("DELETE /v5/animation_templates/{uid}"), so an agent immediately knows this removes an animation template. It does not explicitly distinguish itself from the other delete siblings (delete_image_template, delete_workflow, delete_webhook), but the named resource disambiguates it in practice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage context ("Current Bannerbear V5 operation") and states that confirmation is mandatory before execution, which guides the confirm parameter. However, it never says when to delete vs. update/leave a template alone, nor any prerequisite about the template being unused, so the guidance is only partial.

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

delete_image_templateDelete image templateA

Destructive

DELETE /v5/image_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds genuinely new behavior: provider scopes, locks and credits apply, a mandatory confirmation gate before provider execution, and 'one submission only'. This meaningfully extends beyond the structured hints, though 'scopes, locks and credits apply' stays vague about which scopes or how credits are consumed.

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?

Three compact clauses with the endpoint front-loaded, and the most operationally important constraint (mandatory confirmation) placed before the trailing 'one submission only' note. No filler, though the middle clause is somewhat boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema, the description covers the confirmation gate and one-shot semantics, and annotations cover the safety profile. It stops short of stating irreversibility consequences or failure modes, but an agent has enough to call it correctly.

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

Parameters3/5

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

With 67% schema description coverage, the schema already explains 'account' and 'confirm' in detail. The description only indirectly gestures at the confirm flag via 'Mandatory confirmation before provider execution' and says nothing about the uid format or the account fallback rule, so it adds little parameter-level value.

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?

The description leads with 'DELETE /v5/image_templates/{uid}', giving a specific verb (delete), resource (image template) and identifier. This is immediately distinguishable from siblings like delete_animation_template, delete_workflow and delete_webhook, which target other resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the operation is the 'Current Bannerbear V5 operation' and that confirmation is mandatory before execution, implying usage context, but never names when to prefer this over fetch/update alternatives or what precondition (e.g. verifying the template exists or has no active publications) should be checked first.

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

delete_instant_urlDelete instant urlA

Destructive

DELETE /v5/instant_urls/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing that provider scopes, locks and credits apply and that confirmation is required before execution with only one submission allowed -- real operational constraints the annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact clauses with the method and path front-loaded, then the operational constraints. Every sentence carries information and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent delete with no output schema, the description covers the confirmation requirement, single-submission rule, and that scopes/credits apply. It is nearly complete, though it does not state what happens on success or failure, or permissions required for the account parameter.

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

Parameters3/5

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

Schema coverage is 67%, and the description maps {uid} to the DELETE path and ties 'mandatory confirmation' to the confirm flag, adding some meaning. The account parameter's role (workspace profile selection) is left entirely to the schema and is not reinforced in the description.

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?

It states a specific verb and resource via the HTTP route 'DELETE /v5/instant_urls/{uid}', immediately distinguishing it from siblings like get_instant_url and update_instant_url. An agent knows exactly what is deleted without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It adds a real usage constraint -- mandatory confirmation before provider execution and one submission only -- which tells the agent this is a single-shot operation requiring an explicit confirm flag. However, it names no alternatives and gives no explicit when-not-to-use guidance versus get_instant_url or update_instant_url.

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

delete_webhookDelete webhookA

Destructive

DELETE /v5/webhooks/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds genuine operational context beyond that: provider scopes/locks/credits apply, confirmation is mandatory before execution, and only one submission is accepted, reinforcing the non-idempotent/irreversible nature.

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?

Two terse sentences front-loaded with the endpoint identifier, with no filler. The confirmation warning is placed after the operation identity, which is reasonable, though phrasing is slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive delete with no output schema, the description covers the required acknowledgment (confirm), the one-shot submission rule, and financial/safety implications well. It stops slightly short of describing failure or error behavior, but is broadly complete.

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

Parameters3/5

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

Schema coverage is 67%; uid carries a pattern/length constraint and account and confirm have their own schema descriptions. The description adds no parameter-level meaning beyond the structured fields, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource via the REST endpoint 'DELETE /v5/webhooks/{uid}', which unambiguously identifies it as a webhook deletion operation. It distinguishes itself from the get/list/create/update_webhook siblings by the distinct verb, though it doesn't name alternatives explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the destructive verb and the note that confirmation is mandatory, but there is no explicit guidance on when to delete a webhook versus updating it or which sibling to prefer. An agent can infer the context but gets no stated conditions or exclusions.

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

delete_workflowDelete workflowA

Destructive

DELETE /v5/workflows/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (destructiveHint=true, readOnlyHint=false, openWorldHint=true, idempotentHint=false). The description adds genuinely new context beyond those: provider scopes, locks and credits apply, and the mandatory confirmation / one-submission-only behavior. It stops short of describing what is destroyed or return behavior.

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?

Three tight clauses with the operation front-loaded first. The 'Current Bannerbear V5 operation' phrasing is mildly filler, but nothing else is wasted and the key constraints follow immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive single-parameter deletion with no output schema, the description covers confirmation, credit/lock implications, and single-submission behavior. It omits what the deletion does to dependent workflow runs, but the destructive annotation carries much of that burden.

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

Parameters3/5

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

Schema description coverage is 67%; uid has no prose description (only pattern/length constraints) while account and confirm are documented. The description's 'mandatory confirmation' clause echoes the confirm parameter but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource via the endpoint 'DELETE /v5/workflows/{uid}', which clearly identifies it as deleting a workflow. Among many delete siblings (delete_image_template, delete_webhook, delete_instant_url, delete_animation_template), the resource name differentiates it implicitly, though no sibling is called out by name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states a confirmation requirement ('Mandatory confirmation before provider execution') and a constraint ('one submission only'), but gives no guidance on when to choose this tool over alternatives or any explicit when-not condition. Usage context is left to inference.

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

generate_ai_imageGenerate ai imageB

Destructive

POST /v5/tools/generate_ai_image. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds context beyond that: provider scopes and credit consumption apply, confirmation is mandatory before execution, and only one submission is permitted (reinforcing non-idempotency in practice). These are genuinely useful operational facts.

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?

Two tight sentences with the endpoint front-loaded and constraints packed densely behind it. No filler, though the phrasing is somewhat terse and jargon-laden ('provider scopes, locks and credits apply') rather than explanatory.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless-required mutation tool with no output schema, the description covers the critical behavioral facts an agent needs: confirmation requirement, credit/scope implications, and single-submission semantics. It is fairly complete, with the main gap being no mention of what the call returns or how jobs are polled.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload and payload_file thoroughly (including the payload_file size limit and payload/payload_file exclusivity). The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the HTTP endpoint (POST /v5/tools/generate_ai_image) and labels it a 'Current Bannerbear V5 operation,' but never states in words what the tool does beyond the self-evident name. It does not distinguish it from siblings like generate_ai_video or generate_voiceover. Purpose is inferable from the name but the prose adds little.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives real usage constraints — 'Mandatory confirmation before provider execution; one submission only' — which tells the agent a confirm flag is required and retries are not allowed. However, it never states when to choose this tool over the many sibling generation tools, nor any preconditions. Usage is partially implied rather than routed.

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

generate_ai_videoGenerate ai videoB

Destructive

POST /v5/tools/generate_ai_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: provider scopes and locks apply, credits are consumed, confirmation is mandatory, and it is a one-shot submission — exactly the kind of cost/non-retry context an agent needs before invoking an expensive render.

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?

Three compact clauses with the endpoint and the confirmation rule front-loaded; nothing is padded. It is efficient, though the endpoint restatement is low-value filler for an agent that already knows the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an expensive, non-idempotent generation tool with no output schema and a nested payload, the description covers cost, locks and the confirmation gate but omits what happens after submission — async job handling, where results are retrieved (poll_job/list_tool_jobs exist as siblings) — and any payload_file vs payload selection guidance.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload and payload_file, including the payload/payload_file exclusivity. The description only reinforces the confirm requirement and adds no new parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives the HTTP method and endpoint plus the V5 lineage, but the actual function is only implied by the name 'generate_ai_video' — it never states that it produces a video from a prompt using a chosen model. It does not differentiate itself from close siblings like generate_ai_image or generate_voiceover, so the agent must infer the capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It surfaces a critical procedural rule — 'Mandatory confirmation before provider execution; one submission only' — which tells the agent the confirm flag matters and that retries are not allowed. However it gives no when-to-use context, no prerequisites beyond confirmation, and no routing guidance against sibling generation tools.

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

generate_voiceoverGenerate voiceoverB

Destructive

POST /v5/tools/generate_voiceover. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already carry destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered without the description. The description nonetheless adds genuine context: provider scopes/locks/credits apply, confirmation is mandatory before execution, and only one submission is accepted. These are meaningful operational behaviors beyond the structured fields.

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?

Roughly three short, front-loaded statements with no filler. The endpoint-path sentence is somewhat redundant with the name, but the operational warnings are packed tightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent, open-world generation tool with no output schema, the description covers the critical preconditions (confirmation, single submission, credit/lock implications). It does not address failure/retry behavior, but the essentials an agent needs to avoid misuse are present.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload/payload_file exclusivity, and the text/voice fields. The description adds no syntax, format, or defaulting detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence restates the tool as an endpoint path ("POST /v5/tools/generate_voiceover") and adds only metadata ("Current Bannerbear V5 operation"). The verb+resource is inferable from the name, but the description does nothing to distinguish this from siblings like generate_ai_video or generate_ai_image. Purpose is only weakly stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Mandatory confirmation before provider execution; one submission only" gives real invocation constraints, which is useful. However, there is no guidance on when to choose this tool over the many media-generation siblings (video, image, animation), so usage is only implied.

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

get_accountGet accountC

Read-onlyIdempotent

GET /v5/account. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so 'Read operation' adds nothing. The one genuinely additive clause is 'provider scopes, locks and credits apply', which hints at auth scope and cost implications not captured by annotations. It does not explain what happens when the optional account is omitted.

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?

It is short and front-loaded, with the leading sentence identifying the endpoint. Some fragments ('Current Bannerbear V5 operation') are boilerplate that don't earn their place, but there is no padding or verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read with full annotation coverage, the essentials are covered, but the description omits what the call returns and how behavior changes when the optional 'account' parameter is absent, which matters given the 'no fallback' note in the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the single 'account' parameter (exact private workspace profile label, no fallback) is already fully documented in the schema. The description adds no additional semantics about this parameter, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (account) via the REST path 'GET /v5/account', which implies a retrieve operation, so the agent can infer intent. However, it never states in prose what the tool returns or how it differs from the sibling list_accounts. It reads largely as a restatement of the name and title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus list_accounts or any other sibling. The agent must infer that 'GET a single account' is the singular counterpart to 'list_accounts', with no explicit routing or exclusions provided.

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

get_animationGet animationB

Read-onlyIdempotent

GET /v5/animations/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond that: provider scopes, locks, and credit consumption apply to this operation, which an agent needs to know before invoking. 'Read operation' merely repeats readOnlyHint.

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?

Three short sentences with the operation path front-loaded, then the operational caveats. No filler or redundancy beyond the slightly redundant 'Read operation' closer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read with rich annotations, the description covers the endpoint and cost/scope implications. However, with no output schema it says nothing about what an animation record contains or what the response looks like, and it does not explain how to obtain the required uid.

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

Parameters3/5

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

Schema description coverage is 50%: account is documented in the schema, uid is not. The description only surfaces uid via the path template and adds no format or sourcing detail beyond the schema's pattern/length constraints. Baseline 3 is appropriate given the schema carries the parameter definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb (GET) and resource path (/v5/animations/{uid}), making clear this retrieves a single animation by identifier. It distinguishes itself implicitly from list_animations via the {uid} path, though it never explicitly names that sibling or states 'retrieve one'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus list_animations or get_animation_template. The {uid} in the path implies single-record retrieval, but nothing states preconditions (e.g., needing a uid obtained from list_animations) or exclusions.

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

get_animation_templateGet animation templateB

Read-onlyIdempotent

GET /v5/animation_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so 'Read operation' is redundant. The genuinely additive detail is that 'provider scopes, locks and credits apply', which tells the agent about auth context and cost not captured by annotations, though it is boilerplate-level and does not quantify or qualify it.

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?

Three compact clauses with the endpoint front-loaded and zero filler. The fragmentary style and template boilerplate keep it from being exemplary, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool whose annotations already cover the safety profile, the essentials for invocation are present. Still, with no output schema the description could say what a returned template contains or how missing/unknown uids are handled, and it leaves the account parameter's role unaddressed.

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

Parameters2/5

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

Schema coverage is only 50%: the account parameter carries a description but uid does not document its format or semantics. The description adds nothing about either parameter beyond echoing {uid} in the URL, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The endpoint 'GET /v5/animation_templates/{uid}' states a specific verb and resource, and the {uid} path segment distinguishes it from list_animation_templates by implying a single-item fetch. However it does not name or differentiate from the sibling get_image_template / update_animation_template family in plain language.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of when to prefer this over list_animation_templates or how to obtain a uid. 'Read operation' is the only usage-relevant statement and it is a restatement of the annotation, not routing guidance.

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

get_assetGet assetC

Read-onlyIdempotent

GET /v5/assets/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds valuable context beyond the annotations — provider scopes, locks and credits apply, and it is a current V5 operation — but says nothing about error behavior or what happens on a missing/foreign uid.

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?

Three short clauses, front-loaded with the operation. The trailing 'Read operation' is redundant against readOnlyHint=true, but overall the text is tight and wastes little space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description is the only place to describe what get_asset returns, and it says nothing about the asset object or its fields. Combined with the undocumented uid and the missing usage guidance, an agent has an incomplete picture for a retrieval tool.

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

Parameters2/5

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

Schema coverage is 50%: the account parameter is documented in-schema, but uid has only pattern/length constraints. The description merely echoes the uid as a path template without explaining what an asset uid is or where it comes from, so it does not compensate for the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete verb+resource (GET an asset by uid) and gives the exact endpoint, so an agent can tell it apart from list_assets, upload_asset, and check_assets. It stops short of explicitly differentiating from siblings, but retrieval of one asset by uid is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance: nothing tells the agent when to fetch a single asset versus list_assets or check_assets, and no prerequisites are stated. 'Read operation' restates the obvious rather than routing the caller.

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

get_batchGet batchB

Read-onlyIdempotent

GET /v5/batches/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the note that 'provider scopes, locks and credits apply,' which hints at operational constraints, but it is boilerplate-vague and does not explain scope requirements or credit implications concretely.

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?

Two short sentences, front-loaded with the endpoint, with no wasted preamble. The second sentence is generic boilerplate but does not bloat the definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description could describe what a batch response contains (status, counts, etc.), and it does not. For a simple read tool whose annotations carry the safety profile, this is adequate but leaves the agent guessing about return contents and scope prerequisites.

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

Parameters2/5

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

Schema coverage is only 50%: account is documented in the schema, but uid has no description. The description merely embeds {uid} in the path without explaining its meaning, format, or where to obtain it, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource via the endpoint 'GET /v5/batches/{uid}', making it clear this retrieves one batch identified by uid, distinct from list_batches. However it offers no explicit sibling differentiation or statement of what a 'batch' is, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance: nothing tells the agent to prefer this over list_batches, or when a batch uid is known versus discovered. 'Read operation.' restates a safety fact rather than describing usage context.

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

get_imageGet imageC

Read-onlyIdempotent

GET /v5/images/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds context not in the annotations - provider scopes, locks and credits apply - which flags auth and cost implications, but it stays generic (no specific scope name or credit count) and says nothing about return shape or error behavior.

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?

Two short clauses, endpoint front-loaded, no filler. Efficient, though the brevity contributes to the gaps rather than being purely a virtue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-by-identifier tool with no output schema and no annotations describing the payload, the description should indicate what an image record contains or how it relates to get_image_template / list_images. It omits all of that, leaving the agent to infer the response entirely.

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

Parameters2/5

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

Schema coverage is only 50%: the 'account' parameter is documented in the schema, but 'uid' has no description there, only a pattern and length bounds. The description merely echoes '{uid}' as a path segment and adds no meaning about what the identifier is (image uid vs. template uid) or what 'account' scoping does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact endpoint 'GET /v5/images/{uid}', which is a specific verb+resource and clearly identifies a single-image fetch. It does not differentiate itself from siblings such as list_images or get_image_template, but the endpoint path makes the target resource unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives like list_images for enumerating images. The only usage signal is the trailing 'Read operation', which is implied by the annotations rather than the text.

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

get_image_templateGet image templateB

Read-onlyIdempotent

GET /v5/image_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already cover readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is known. The description goes beyond them by disclosing that provider scopes, locks and credits apply, which signals auth requirements and a credit cost associated with the call.

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?

Three short clauses, endpoint front-loaded, no filler or repetition. The 'provider scopes, locks and credits apply' clause is somewhat boilerplate but carries real cost/auth information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-resource read with no output schema, an agent still lacks any indication of the returned object's shape or error behavior. Annotations plus description cover safety and auth, but the definition stops at minimum viable.

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

Parameters3/5

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

Schema description coverage is 50%: the 'account' param is documented in the schema, while 'uid' is only constrained (pattern, length) without prose. The description surfaces uid's role indirectly through the path template but adds no syntax, format, or meaning beyond what the schema already encodes. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource via the endpoint 'GET /v5/image_templates/{uid}', making it clearly the single-record fetch in the image_template family (vs list_image_templates, create/update/delete_image_template). It does not explicitly contrast itself with those siblings, but the '{uid}' path and family naming make the distinction inferable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance is given, and no alternatives are named. The agent must infer usage purely from the HTTP verb and sibling naming.

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

get_instant_urlGet instant urlB

Read-onlyIdempotent

GET /v5/instant_urls/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context with 'provider scopes, locks and credits apply' and 'Current Bannerbear V5 operation', hinting at credential scoping, locking and version currency, but it never explains what those locks or credits mean for a read call.

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?

Three compact fragments with the endpoint front-loaded, so the essential fact is read first. The middle clause about scopes, locks and credits is generic boilerplate that borders on filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries no return-shape burden, and the annotations cover the read-only safety profile. However, it leaves an agent unclear on what an instant URL object is, what identifiers are valid, or what failure modes (missing uid, wrong workspace profile) to expect.

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

Parameters3/5

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

Schema description coverage is 50%: the account parameter is documented in the schema while uid is not. The only parameter signal in the description is the {uid} path placeholder, which confirms uid identifies the resource but adds no format or constraint detail beyond the schema pattern. This warrants the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (GET) and resource path (/v5/instant_urls/{uid}), which reads clearly as a single-resource retrieval and is distinguishable from list_instant_urls, create_instant_url, update_instant_url and delete_instant_url. It never states in plain language what an 'instant URL' is or what is returned, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no alternatives are named. An agent must infer from the REST path and the singular uid that this fetches one existing instant URL rather than listing or mutating them.

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

get_layer_schemaInspect a layer schemaB

Read-onlyIdempotent

Return a complete selected native layer or animation keyframe schema from the pinned V5 definitions. No network.

ParametersJSON Schema

Name	Required	Description	Default
`layer`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds useful context beyond that: the schemas come from 'pinned V5 definitions' and require 'No network,' reinforcing the static/local nature. It does not, however, describe the return shape or size of the schema payload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the verb and resource, then a scoping clause. No filler, no redundancy with the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param read-only tool with no output schema, the description covers what the tool does and where the data comes from. It is nearly complete, with the only gap being the absence of any hint about the returned schema's format or how to use it.

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

Parameters3/5

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

Schema description coverage is 0%, so the schema provides only the enum list with no per-value meaning. The description partially compensates by framing the output as either a 'native layer' or 'animation keyframe' schema, which implicitly groups the enum (including Keyframes) into two categories, but it never explains what the individual layer types represent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Return a complete selected native layer or animation keyframe schema.' An agent understands it fetches a schema definition. However, it doesn't differentiate itself from the sibling get_operation_schema, leaving the boundary between the two schema-lookup tools to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no named alternative. With get_operation_schema and preview_operation as siblings, the agent gets no signal about when this layer-schema lookup is the right call versus those other inspection tools.

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

get_operation_schemaInspect native schemaB

Read-onlyIdempotent

Return the complete current path/query/body schema for a selected operation. Local only.

ParametersJSON Schema

Name	Required	Description	Default
`operation`	Yes

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds 'Local only' and 'current', implying the schema is fetched from local state rather than the live API, which is mild added context but largely overlaps the openWorldHint=false annotation.

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?

Two short sentences, front-loaded with the return value and ending with the local-only constraint, with no wasted text. It is efficient, though minimal enough that brevity shades into under-specification.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only inspection tool with one enum parameter and no output schema, the safety and scope picture is reasonably covered by annotations plus the brief description. However it never explains what the returned path/query/body schema is for or how it relates to calling the selected operation, leaving the agent to infer its purpose.

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

Parameters2/5

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

Schema description coverage is 0% for the single required 'operation' parameter, and the description only says 'a selected operation' without explaining how enum values map to endpoints or what the returned schema applies to. The self-describing enum names carry the load, but the description does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (return) and resource (path/query/body schema for a selected operation), which is concrete and distinguishable from write/execution siblings like preview_operation or run_workflow. It does not explicitly differentiate itself from the nearby get_layer_schema sibling, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is the terse 'Local only' note; there is no statement of when to call this versus get_layer_schema or preview_operation, nor any prerequisite or context. Usage is implied by the name but not described.

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

get_publicationGet publicationC

Read-onlyIdempotent

GET /v5/publications/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds some value beyond that by noting 'provider scopes, locks and credits apply', but it stays generic — it names no specific scope, lock behavior, or credit cost, so the added context is thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The endpoint is front-loaded, which is good, and the description is short. However, 'Current Bannerbear V5 operation' is largely filler and 'Read operation' duplicates readOnlyHint=true, so not every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing what a fetched publication contains or returns. It offers nothing about the response shape, and the two-parameter surface is only partially explained, leaving the definition thin for a lookup tool.

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

Parameters2/5

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

Schema description coverage is only 50%: the account parameter is documented in the schema while uid is not. The description only echoes the '{uid}' path placeholder and adds no meaning, format, or constraint for uid, and never addresses the account parameter, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the REST endpoint 'GET /v5/publications/{uid}', which implies retrieval of a single publication, but it leans on a path template rather than a natural-language verb+resource statement. It gives no differentiation from the sibling list_publications, so an agent must infer that this returns one publication versus many.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage cue is the trailing 'Read operation', which merely restates the readOnly annotation. There is no guidance on when to use this versus list_publications, install_publication, or any other sibling, and no prerequisites or exclusions are stated.

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

get_tool_jobGet tool jobB

Read-onlyIdempotent

GET /v5/tool_jobs/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description does add that 'provider scopes, locks and credits apply', a useful hint about authorization and credit consumption for this read, though it is vague and stops short of specifics like rate limits or failure modes.

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?

It is short and front-loads the endpoint, which is the most useful signal. The clause 'Current Bannerbear V5 operation' is filler that does not earn its place, slightly weakening an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only getter with full annotation coverage and no output schema, the description is broadly adequate, but it omits any explanation of the account parameter and does not clarify what a 'tool job' represents. Enough to call correctly in the common case, incomplete on the multi-account dimension.

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

Parameters2/5

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

Schema description coverage is only 50%: the account parameter is documented in the schema but not in the description, and the uid parameter has no schema description. The description only mirrors '{uid}' from the path, adding no new meaning, and says nothing about the account profile parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The endpoint notation 'GET /v5/tool_jobs/{uid}' makes the verb+resource clear: fetch a single tool job identified by uid. However, it never differentiates itself from the sibling list_tool_jobs, leaving the agent to infer the singular-vs-list distinction from the path pattern alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like list_tool_jobs, nor any stated preconditions beyond the generic 'read operation'. The agent must infer usage entirely from the path.

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

get_webhookGet webhookC

Read-onlyIdempotent

GET /v5/webhooks/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds marginal context ('provider scopes, locks and credits apply') indicating scope/auth and locking constraints, but 'Read operation' duplicates readOnlyHint and the vague 'credits apply' is not elaborated for a read call.

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?

Three compact fragments, front-loaded with the endpoint, no wasted prose. It is efficient, though the trailing 'Read operation' is redundant filler that earns nothing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should ideally hint at what a webhook record contains or error behavior on a missing uid, but it does not. For a simple read tool whose annotations carry the safety profile it is adequate, but the vague 'scopes, locks and credits' clause leaves behavior under-specified.

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

Parameters2/5

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

Schema coverage is only 50%: the 'account' parameter has a schema description, but 'uid' does not, and the description only echoes the uid via the URL path template. It adds no meaning about the uid pattern, length bounds, or how 'account' scoping interacts with the lookup, leaving the coverage gap uncompensated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the REST endpoint 'GET /v5/webhooks/{uid}', which conveys a specific verb (fetch) and resource (single webhook by uid), so an agent can infer it is a single-resource retrieve. However, it offers no differentiation from its direct siblings list_webhooks, create_webhook, update_webhook, and delete_webhook beyond the HTTP path, making it only minimally viable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no mention of the alternative (list_webhooks for enumeration) or prerequisites. The only usage signal is the bare 'Read operation' phrase, which provides no decision context for an agent choosing between this and its siblings.

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

get_workflowGet workflowC

Read-onlyIdempotent

GET /v5/workflows/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint, so the safety profile is covered. The description adds 'provider scopes, locks and credits apply,' which hints at auth/scope requirements and possible credit consumption beyond the annotations, but it names these categories generically without saying which scope is needed or what 'locks' means, and 'Read operation' duplicates the readOnly annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the endpoint, which is good. But 'Current Bannerbear V5 operation' and 'Read operation' are filler clauses that consume space without adding actionable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain what a workflow record looks like or at least what the call returns, and it should fill the gap on the undocumented 'uid' parameter. It does neither, leaving an agent without knowledge of the response shape or parameter meaning.

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

Parameters2/5

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

Schema coverage is only 50%: 'account' is documented in the schema but 'uid' has no description at all. The description contributes nothing beyond the path template implying {uid} is the workflow identifier; format, constraints, and the meaning of 'account' (workspace profile) are left to the schema or unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The endpoint string 'GET /v5/workflows/{uid}' does encode a specific verb and resource, so the agent can infer this fetches one workflow by UID. However it never states that in plain language and gives no differentiation from close siblings like list_workflows or get_workflow_run, both of which could be confused with a single-record fetch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no named alternative. 'Read operation' only restates the obvious; nothing tells the agent when to pick this over list_workflows or get_workflow_run.

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

get_workflow_runGet workflow runC

Read-onlyIdempotent

GET /v5/workflow_runs/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds non-trivial context that 'provider scopes, locks and credits apply', which the agent would not otherwise know, though it remains vague about exactly how scopes, locks, or credit consumption manifest.

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?

Three short fragments with no redundancy and the resource identified up front. It is lean, though the endpoint-path restatement does little work for an agent and the terse style borders on under-specification rather than genuine conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description is not obligated to explain return values, and the annotations carry the safety profile. Still, for a read tool with one undocumented parameter and no return-shape or scoping detail, the description is only minimally sufficient to invoke it correctly.

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

Parameters2/5

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

Schema description coverage is only 50%: the 'account' parameter is documented in the schema, but 'uid' has no description beyond its pattern and length constraints. The description adds nothing about either parameter, so it does not compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description effectively restates the endpoint path 'GET /v5/workflow_runs/{uid}', from which the resource (a workflow run, retrieved by uid) can be inferred. However, it never articulates the purpose in prose and offers no differentiation from sibling tools like list_workflow_runs or get_workflow, leaving the agent to infer the distinction from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no named alternative. The only hint is the bare label 'Read operation', which is already conveyed by the readOnlyHint annotation and does not tell the agent when this tool is preferable to list_workflow_runs or get_workflow.

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

install_publicationInstall publicationB

Destructive

POST /v5/publications/{uid}/install. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: provider scopes, locks and credits apply, confirmation is mandatory before provider execution, and the submission is single-shot. It omits any statement of what state is created or whether the install can be undone.

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?

Three tight clauses with the endpoint front-loaded and no filler. It is compact and scannable, though the semicolon-joined fragment style pushes some meaning into implicit phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema, the description covers credits/locks/confirmation but never describes what the install produces or how success or failure is surfaced. Adequate but leaves the agent guessing about the operation's material effect.

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

Parameters3/5

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

Schema coverage is 67% and the description adds nothing on uid or account, leaving the regex-constrained uid undocumented. Its only parameter-adjacent content is the mandatory-confirmation note, which loosely reinforces the existing confirm schema description. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (install a publication) and pins it to the endpoint POST /v5/publications/{uid}/install, so the agent knows exactly which operation is invoked. It does not differentiate from siblings or explain what 'installing' a publication actually does operationally, keeping it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives procedural constraints ('mandatory confirmation before provider execution; one submission only') but never says when to use this tool versus alternatives such as get_publication or list_publications, nor what preconditions make an install valid. No when-not guidance at all.

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

list_accountsList private profilesA

Read-onlyIdempotent

Local profile labels, default and auth method only; no keys, paths or provider identity. No network.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: it is local-only ('No network') and it discloses data minimization ('no keys, paths or provider identity'), telling the agent what sensitive fields are deliberately excluded.

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?

A single dense clause-pack with no filler; the exclusions and the local-only constraint are front-loaded. It is a sentence fragment rather than a well-formed sentence, which slightly hurts readability but not efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param, read-only list tool with no output schema, the description covers what is returned (labels, default, auth method), what is not returned, and the local-only nature — enough 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.

Parameters4/5

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

The tool takes zero parameters, so the baseline is 4. The description sensibly spends its words on the return payload rather than phantom parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource (local profiles) and precisely scopes the payload — 'labels, default and auth method only'. It never uses an explicit verb like 'list', and it does not differentiate from the sibling get_account, so it is clear but not sibling-aware.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of when to prefer this over get_account or any list_* sibling. The only usage-adjacent signal is 'No network', which describes behavior rather than selection criteria.

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

list_animationsList animationsC

Read-onlyIdempotent

GET /v5/animations. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered without the description. The description does add real context beyond them by noting that provider scopes, locks and credits apply - useful for knowing the call consumes credits and requires auth - but it remains vague about what those constraints concretely mean.

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?

Two short, front-loaded sentences with no filler. Nothing is wasted, though the leading REST path is arguably more implementation detail than useful signal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description says nothing about what an animation entry contains, result ordering, or pagination behavior for a tool whose whole purpose is retrieving a list. With a 2-param schema and no return documentation, an agent lacks enough to call this confidently.

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

Parameters2/5

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

Only 50% of the schema has descriptions (account is documented, page is not, including no explanation of what 'page' paginates). The description adds nothing about either parameter, so it fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and endpoint 'GET /v5/animations' imply fetching a collection of animations, but the description never states this in words - it only exposes a REST path. It also does nothing to distinguish this listing operation from siblings like get_animation, create_animation, or animate_template.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to call this versus get_animation or animate_template, nor any note on pagination expectations for a list endpoint. The only usage signal is the bare label 'Read operation'.

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

list_animation_templatesList animation templatesC

Read-onlyIdempotent

GET /v5/animation_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured fields. The description adds only marginal extra context — "provider scopes, locks and credits apply" hints at auth/scope and metering concerns, though it stays vague and unspecified. "Read operation" merely repeats readOnlyHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short fragments with minimal waste, and the endpoint is front-loaded. However, "Read operation" is redundant with the readOnlyHint annotation, so not every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list tool with two parameters, no output schema, and only 50% schema coverage, the description leaves important gaps: pagination behavior of `page` and the shape/nature of the returned template list are unexplained. The mention of provider scopes, locks, and credits is the only substantive context provided.

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

Parameters2/5

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

Schema description coverage is 50%: the `account` parameter is documented in the schema, but `page` (pagination, min 1, max 1000000) has no description anywhere. The tool description adds nothing about parameters, so it fails to compensate for the uncovered `page` semantics or explain pagination behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource via the raw endpoint "GET /v5/animation_templates", and the tool name implies listing animation templates, so the purpose is inferable. But it never states in prose what the tool does (list/retrieve available animation templates), and it gives no differentiation from siblings like list_animations or list_image_templates. This is closer to a restatement of the name/path than a specific verb+resource statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus list_animations, get_animation_template, or create_animation_template. No prerequisites, no exclusions, no alternative-selection guidance. The agent must infer usage from the name alone.

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

list_assetsList assetsC

Read-onlyIdempotent

GET /v5/assets. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds 'provider scopes, locks and credits apply', which does flag auth/cost considerations beyond the structured fields, but it is boilerplate-level and gives no specifics on pagination or credit consumption.

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?

Three short clauses with the endpoint front-loaded and no filler sentences. It is efficient, though its brevity flirts with under-specification rather than richly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should help describe the returned collection or pagination, but it does not. Combined with the missing 'page' semantics and no usage context for a two-parameter listing tool, the definition is thin relative to what an agent needs to call it correctly.

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

Parameters2/5

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

Schema description coverage is only 50%; 'page' has no schema description and the prose adds nothing about it, so pagination behavior is undocumented anywhere. The description explicitly compensates for nothing here, leaving half the parameters unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives the resource and HTTP verb ('GET /v5/assets') plus a generic 'Read operation' label, which confirms list/read semantics for assets. However, it does not differentiate this from sibling tools like list_images, get_asset, check_assets, or upload_asset, so the agent must infer the distinction from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no alternatives named. It never tells the agent when to prefer this over get_asset (single asset) or check_assets, nor any prerequisites for calling it, so selection among the sibling asset tools is left entirely to inference.

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

list_batchesList batchesC

Read-onlyIdempotent

GET /v5/batches. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds that provider scopes, locks, and credits apply, which is useful behavioral context, but it remains vague and does not detail rate limits, pagination, or response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the endpoint, but 'Read operation' repeats the readOnlyHint annotation and 'Current Bannerbear V5 operation' is boilerplate. Those lines do not earn their place as much as missing pagination or usage details would.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description should explain return values or pagination, but it does not mention either. For a list tool with an undocumented page parameter and no usage guidance, it leaves important agent-relevant context unaddressed even though annotations cover the safety profile.

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

Parameters2/5

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

Schema description coverage is 50%: the account parameter is documented in the schema, but the page parameter is not. The tool description mentions neither parameter, so it fails to compensate for the undocumented page argument or add any parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the specific HTTP verb and resource with 'GET /v5/batches', making clear this is a read endpoint for batches. It does not explicitly differentiate from siblings such as get_batch or list_publications, but the plural resource name provides some distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance or mention of alternatives. The only contextual sentence is a generic note that provider scopes, locks, and credits apply, which does not help the agent choose this tool over others.

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

list_imagesList imagesC

Read-onlyIdempotent

GET /v5/images. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds some non-obvious context — provider scopes, locks, and credits apply — which goes beyond the structured fields. But it never specifies how pagination behaves or what the credit/lock constraints concretely mean, leaving the value shallow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the endpoint, with no filler sentences. But the three fragments are essentially a path plus two boilerplate clauses, so brevity comes at the cost of substance rather than being efficient information delivery.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and one of two parameters undocumented, the description should carry more weight than it does. It omits return format, pagination behavior, and what the mentioned locks/credits actually restrict, leaving an agent short of what it needs to call the tool confidently.

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

Parameters2/5

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

Schema description coverage is 50%: account is documented in-schema, but page has no description at all. The tool description says nothing about pagination, page limits, or the account scoping parameter, so it fails to compensate for the undocumented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description anchors the tool to an endpoint, "GET /v5/images", which conveys a read/list operation on the images resource. However, it offers no differentiation from siblings like get_image (single image) or list_image_templates (a different resource), and "Current Bannerbear V5 operation" adds nothing an agent can act on. Purpose is identifiable but essentially restates the tool name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives such as get_image or list_image_templates. "Read operation" is a restatement rather than a routing cue, so the agent must infer context from the name alone.

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

list_image_templatesList image templatesC

Read-onlyIdempotent

GET /v5/image_templates. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so 'Read operation' is redundant. The description does add genuine context beyond them — provider scopes, locks and credit consumption apply — but says nothing about pagination despite the page parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short clauses, front-loaded with the endpoint, which is efficient. But 'Current Bannerbear V5 operation' is filler and 'Read operation' restates the annotation, so not every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema the description should explain what is returned and how paging works, but it omits both. For a listing endpoint with a pagination parameter, this leaves the agent guessing about result shape and traversal.

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

Parameters2/5

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

At 50% schema coverage the description must compensate, and it does not: neither the pagination parameter nor the account/workspace scoping is explained. 'Provider scopes' only vaguely hints at the account parameter's profile semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The HTTP route GET /v5/image_templates plus the title signal a list operation on image templates, and the sibling set makes list vs get/create/update meaningful. However the description never actually says 'lists templates' or what a template is; it leans on the path string to carry the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance and no routing to alternatives such as get_image_template (single template) or list_animation_templates. 'Current Bannerbear V5 operation' is a version note, not usage guidance.

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

list_instant_urlsList instant urlsC

Read-onlyIdempotent

GET /v5/instant_urls. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that 'provider scopes, locks and credits apply,' which signals permission requirements and a credit cost, but leaves these terms unexplained and says nothing about pagination behavior for a list endpoint.

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?

Three short clauses, front-loaded with the endpoint, with no filler or repetition. It is efficient, though the terseness contributes to the informational gaps noted elsewhere.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a list operation with no output schema, the description should convey at least the shape of the result and the pagination model implied by the 'page' parameter. Instead it offers generic boilerplate about scopes, locks and credits, leaving the agent unable to predict the response or how to page through it.

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

Parameters2/5

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

Schema description coverage is only 50% — 'account' is documented in the schema while 'page' has no description at all. The tool description adds no information about either parameter, so the undocumented pagination parameter remains unexplained in both places, below the baseline 3 that full schema coverage would warrant.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the HTTP endpoint GET /v5/instant_urls, which implies retrieval of instant URLs, and the name confirms the resource. However, it never says explicitly that it returns a collection of instant URLs, and it does not distinguish itself from the sibling get_instant_url (single item) beyond the endpoint string. Purpose is inferable but not stated in plain language.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus get_instant_url or the other instant-url siblings. 'Read operation' is the only hint about usage context, and it is redundant with the readOnlyHint annotation.

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

list_publicationsList publicationsC

Read-onlyIdempotent

GET /v5/publications. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description
`q`	No
`kind`	No
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`category`	No

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description does add value with "provider scopes, locks and credits apply," signaling that scopes are required and credits are consumed — context the annotations do not provide. It does not mention pagination behavior or return format, so it stops short of rich disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loads the endpoint, so nothing is padded. But it is under-specified rather than genuinely concise — the boilerplate ("Current Bannerbear V5 operation") occupies space that could carry substantive guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a filtered-list tool with five parameters, no output schema, and low schema coverage, the description omits return shape, pagination, and parameter meaning. The annotations cover safety, but an agent still lacks what it needs to call this correctly.

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

Parameters2/5

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

Schema description coverage is only 20% (only 'account' is documented), leaving q, kind, page, and category unexplained. The description supplies no parameter meaning whatsoever, so it fails to compensate for the coverage gap despite having five parameters to clarify.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a raw endpoint ("GET /v5/publications") plus the title/name convey that it lists publications, so the basic purpose is inferable. However, the body text adds no explanation of what a publication is or how this differs from siblings like get_publication or list_instant_urls. It is adequate but uninformative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no statement of when to prefer this over get_publication or other list tools, and no prerequisites. The only hint is the terse "Read operation" tag, which does not route the agent among alternatives.

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

list_tool_jobsList tool jobsC

Read-onlyIdempotent

GET /v5/tool_jobs. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so 'Read operation' adds nothing. The description does add genuinely new context — that provider scopes, locks, and credits apply — which is useful for a metered operation. It still says nothing about result volume or rate/credit cost specifics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded, but 'Current Bannerbear V5 operation' is filler and 'Read operation' duplicates the readOnlyHint annotation, so not every fragment earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a listing endpoint with no output schema, the description omits pagination behavior, what a returned tool job contains, and how results relate to get_tool_job. The only substantive addition is the credits/scopes note.

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

Parameters2/5

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

Schema coverage is 50%: the 'account' parameter is documented in the schema, but 'page' has no description anywhere. The description says nothing about either parameter, so it fails to compensate for the undocumented pagination parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives an endpoint ('GET /v5/tool_jobs') and the name states the verb+resource, so the general purpose is inferable. However, it provides no differentiation from the sibling get_tool_job, and the endpoint string largely restates the tool name rather than explaining the operation in plain language.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus get_tool_job or any of the other listing tools (list_workflows, list_batches, etc.). No prerequisites, pagination guidance, or conditions for selecting it are given.

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

list_webhooksList webhooksC

Read-onlyIdempotent

GET /v5/webhooks. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds marginal context ('provider scopes, locks and credits apply') hinting at auth/quota constraints, but it is boilerplate that doesn't specify what those scopes are or how pagination behaves.

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?

Three short fragments, front-loaded with the endpoint, with no wasted prose. 'Read operation' is redundant with readOnlyHint=true, which slightly dilutes the otherwise tight structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations covering return shape, the description should explain what a listing returns and how paging works, but it does neither. Combined with the undocumented 'page' param, an agent cannot call this confidently.

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

Parameters2/5

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

Schema coverage is only 50%: the 'account' param has a schema description while 'page' is undocumented. The description contains no parameter guidance at all, so it fails to compensate for the undocumented pagination parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the HTTP endpoint (GET /v5/webhooks) and labels it a 'Read operation', which confirms the name/title but adds no scope or result detail. It gives a resource but no distinction from the sibling get_webhook (single resource) — the agent must infer 'list' is an enumeration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no mention of alternatives like get_webhook, and nothing about pagination or filtering. The agent is told the operation is a read but not when to prefer it over other webhook tools.

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

list_workflow_runsList workflow runsC

Read-onlyIdempotent

GET /v5/workflow_runs. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds real but vague context beyond that: provider scopes, locks and credits apply, implying permission requirements and credit consumption, but it names no scopes, cost, or concurrency details. 'Read operation' merely repeats readOnlyHint.

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?

Three short clauses with no filler and the endpoint front-loaded. The final sentence 'Read operation' is redundant with readOnlyHint=true and is the one line that does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should describe what a workflow run listing returns and how pagination works via the 'page' parameter. Neither is covered, and with no usage guidance the definition is too thin for an agent to call this list endpoint confidently.

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

Parameters2/5

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

Schema description coverage is only 50%: 'account' is documented in the schema while 'page' has no description of default, pagination bounds, or ordering. The description contributes nothing about either parameter, so the undocumented half of the surface remains unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact endpoint (GET /v5/workflow_runs) and the read nature of the call, so the resource and operation are identifiable, but it never states the purpose in plain terms (listing workflow runs) and offers no differentiation from close siblings such as list_workflows or get_workflow_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no pointer to alternatives like get_workflow_run or list_workflows. The only contextual cue is the bare endpoint path, leaving selection between siblings entirely to inference.

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

list_workflowsList workflowsC

Read-onlyIdempotent

GET /v5/workflows. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Read operation.

ParametersJSON Schema

Name	Required	Description	Default
`page`	No
`account`	No	Exact private workspace profile label; no fallback to another profile key.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds that provider scopes, locks and credits apply, which is genuine behavioral context, but it is boilerplate-generic and omits return shape or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short, but a large share of its wording ('Current Bannerbear V5 operation; provider scopes, locks and credits apply') is generic boilerplate that adds little. Front-loading the endpoint is reasonable but value-per-sentence is low.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-param list tool with annotations covering the safety profile and no output schema, the absence of return/pagination description is a real gap but not fatal. The definition is minimally complete rather than thorough.

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

Parameters2/5

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

Schema coverage is only 50% – 'account' is documented but 'page' has no description. The description contributes no parameter meaning at all, so it does not compensate for the undocumented pagination parameter or clarify iteration behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description reduces to the raw endpoint 'GET /v5/workflows', which implies retrieval of workflows, and the title/name carry the actual meaning. It does not articulate purpose in natural language or distinguish this from siblings like get_workflow or list_workflow_runs. Adequate but leaning on the title rather than stating a clear verb+resource intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Read operation' gives no when-to-use information, no alternatives (e.g., get_workflow for a single item, list_workflow_runs for executions), and no pagination guidance. The agent is left to infer everything from the name.

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

overlay_imageOverlay imageB

Destructive

POST /v5/tools/overlay_image. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.1/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, non-idempotent), the description discloses that provider scopes, locks and credits apply, that confirmation is mandatory before execution, and that only one submission is allowed. This adds real operational context an agent needs, though it doesn't explain what gets destroyed or the return behavior.

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?

Three short clauses, front-loaded with the endpoint, with no filler. It is tight, though the leading endpoint path is more reference than value, keeping it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations carry the safety profile and the schema is rich with a nested payload, so much is covered. However, for a destructive, open-world operation the description never explains the actual image-overlay behavior or its output, leaving a meaningful gap.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload and payload_file in detail. The description adds no parameter-level meaning beyond what the structured fields provide, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the operation and endpoint, but 'POST /v5/tools/overlay_image' largely restates the tool name rather than stating what overlaying does (image onto a video?) or its effect. The surrounding text is metadata about provider scopes and confirmation rather than purpose. An agent gets the resource but no real verb semantics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a precondition ('Mandatory confirmation before provider execution; one submission only'), which is useful, but gives no when-to-use context and never contrasts with siblings like overlay_video or apply_color_filter. No alternatives or exclusions are offered.

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

overlay_videoOverlay videoC

Destructive

POST /v5/tools/overlay_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, so the safety profile is covered. The description adds genuinely new operational context: provider scopes, locks, credits apply, plus the mandatory confirmation gate and one-submission-only constraint. These are real behavioral facts not present in 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded sentences with no filler; the endpoint and V5 context lead, followed by the confirmation constraint. It is efficient, though it spends its limited budget on procedural metadata rather than describing the operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, destructive, non-idempotent video operation with a deeply nested payload and no output schema, the description covers the confirmation/credit mechanics but omits what the tool actually renders and any output or job-polling expectations. It is minimally adequate given the rich schema but leaves real gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so both the top-level params (account, confirm, payload, payload_file) and nested payload fields are documented in the schema itself. The description adds no parameter-level meaning (e.g., no explanation of the x/y/position interplay or audio mixing modes), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description only restates the endpoint path ("POST /v5/tools/overlay_video") and labels it a "Current Bannerbear V5 operation". It never explains what overlaying a video onto another video actually does, and it draws no distinction from siblings like overlay_image, add_cover_art, or concat_videos. Purpose is inferable only from the name/title, not the description text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a procedural precondition ("Mandatory confirmation before provider execution; one submission only") but gives no guidance on when to choose this tool over the many other video tools in the sibling list. There are no when-to-use or when-not-to-use conditions relative to alternatives.

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

poll_jobBounded existing job pollingA

Read-onlyIdempotent

Read only an existing image, animation, batch, tool job or workflow run. At most 20 GETs, no create/resubmit. Completed/failed terminal states stop; missing/unrecognised state stops as unknown.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes
`account`	No
`resource`	Yes
`max_polls`	No
`interval_ms`	No

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description nonetheless adds real behavioral detail beyond them: a bounded budget of 20 GETs, an explicit refusal to create/resubmit, and terminal-state semantics (completed/failed stop the poll; missing or unrecognised state stops as 'unknown'). That last rule in particular is nontrivial behavior an agent cannot get from the schema or 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?

Three compact sentences with the core operation front-loaded before the constraints. No filler or restated boilerplate. It is dense rather than verbose, though the terminal-state rule and the polling budget are packed tightly enough that a reader must parse carefully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no nested objects, the description carries the return-shape burden, yet it only gestures at states (completed/failed/unknown) without describing what the poll actually yields or how partial/in-progress results are returned. Combined with the unexplained interval_ms and account parameters, it is adequate for a simple polling call but leaves meaningful gaps.

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

Parameters3/5

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It does partially: the enumerated resource types explain the `resource` enum, and 'At most 20 GETs' echoes the max_polls ceiling of 20. But `uid`, `account`, `max_polls`, and `interval_ms` receive no direct explanation of format, default behavior, or backoff semantics, leaving roughly half the surface unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Read only') and enumerates the exact resource types it covers (image, animation, batch, tool job, workflow run), which maps cleanly onto the `resource` enum. An agent can tell it is a read/poll operation on existing jobs. It does not, however, explicitly differentiate itself from siblings like get_image, get_batch, or get_tool_job, so the agent must infer that this is the polling variant.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (poll an existing job until it reaches a terminal state) and constrains it with 'At most 20 GETs, no create/resubmit', which tells the agent this is not a creation path. But it never names an alternative or states the condition for choosing this over the plain get_* siblings, leaving the when-to-use decision implicit.

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

preview_operationPreview a requestB

Read-onlyIdempotent

Validate and preview an exact local named request. No authentication, provider validation or quota estimate. Raw asset previews reveal only byte count/hash.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes
`operation`	Yes

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description earns credit for adding behavioral context annotations cannot express: that authentication, provider-side validation, and quota checks are deliberately skipped, and that raw asset previews are redacted to byte count/hash. It stops short of saying what validation actually succeeds or whether output is a dry-run plan.

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?

Three short sentences, no filler, with the core action stated first and the exclusions/redaction caveats immediately after. Slightly dense phrasing ('exact local named request') costs a little clarity but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only tool whose annotations cover safety, the description is adequate but incomplete. With a 68-value operation enum and an opaque nested arguments object, and no output schema, the agent still lacks guidance on how arguments map to operations and what a successful preview returns outside the raw-asset case.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry param meaning and largely does not. It gestures at 'named request' suggesting operation + arguments, but explains nothing about how the nested 'arguments' object is shaped or keyed per operation, which is the critical semantics for this tool. The self-describing enum helps only with the operation half of the pair.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific compound verb (validate and preview) applied to a specific resource (an exact local named request), and frames the scope as local-only. However, it never contrasts itself with the many execution siblings (apply_render_batch, run_workflow, install_publication) that an agent must choose between, so sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The negative scope (no authentication, provider validation, or quota estimate) implicitly tells the agent this is a pre-flight check rather than a real execution, which is useful. But there is no explicit instruction on when to reach for this versus get_operation_schema or the actual apply/run tools, and nothing about ordering or prerequisites.

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

preview_render_batchReview a render batchC

Read-onlyIdempotent

Local schema-validated 1–100 native image payload review. Digest binds exact order, method/path, profile label and body. No provider state or price validation.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No
`payload`	No
`payload_file`	No

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive safety, so the bar is lower, and the description adds genuinely new context beyond them: validation is 'local' (no provider round-trip) and it explicitly performs 'No provider state or price validation.' That scoping tells the agent what the tool will and will not catch, which is real behavioral value.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler and the key scope constraint front-loaded. However, the compression is so aggressive that the text reads as internal jargon rather than an explanation, undermining the conciseness benefit.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with a very large nested schema, 0% parameter description coverage, and no output schema, the description is too thin. It never explains what the preview returns (a 'digest' is named but not defined) or how the agent should act on a successful validation, leaving the agent unable to use the result confidently.

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

Parameters3/5

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

Schema description coverage is 0% across 3 parameters, so the description must compensate. It loosely frames the payload as '1–100 native image payload' (matching the items min/max) and notes the digest binds 'exact order, method/path, profile label and body,' but it does not explain the account, payload, or payload_file parameters or their required/optional status.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a validation/review action over image payloads ('schema-validated 1–100 native image payload review'), which is a specific verb+resource. However, it never clarifies the relationship to its obvious sibling apply_render_batch, and the telegraphic phrasing ('Digest binds exact order, method/path...') forces the agent to already know the domain to parse the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance and no named alternative. The name implies a preview/dry-run and the sibling apply_render_batch is the natural counterpart, but the description never states that this should be called before applying a batch, nor when to skip it.

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

query_pagesBounded native pagesC

Read-onlyIdempotent

Read 1–5 pages of a selected native paginated read. Stop at an empty page; report a resume page at the cap. No completeness assumption from a short page.

ParametersJSON Schema

Name	Required	Description	Default
`arguments`	Yes
`max_pages`	No
`operation`	Yes

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower, and the description still adds real behavior: a stop-on-empty-page rule, a resume-page report when the 5-page cap is hit, and an explicit warning not to infer completeness from a short page. These are exactly the runtime traits that aren't visible in the schema and that prevent an agent from mistaking a truncated result for a full one.

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?

Three short sentences, front-loaded with the core action and the range, then the termination/resume rules. Nothing is padding, though the terseness leaves the parameters unexplained rather than being genuinely complete.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a dispatcher over 12 operations with a fully opaque nested `arguments` object, 0% schema documentation, and no output schema. The description covers paging semantics well but omits the essential contract: what `arguments` should contain per operation, and what a page/resume report looks like. For a tool of this complexity, that is a substantial gap.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate, and it barely does. "1–5 pages" loosely restates max_pages, but the nested `arguments` object — the field that actually carries per-operation inputs — is never described, nor is how `operation` selects an underlying list call. An agent has no basis for populating `arguments` from the description alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb and object are present ("Read 1–5 pages"), but the resource is described circularly as "a selected native paginated read," which is jargon an agent must decode. It never states plainly that this is a generic paging wrapper over the list_* operations, so distinguishing it from siblings like list_images or list_webhooks requires reading the operation enum in the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains stop conditions ("Stop at an empty page") and resumption ("report a resume page at the cap") but gives no guidance on when to use this batched pager versus calling the individual list_* tools directly. There is no condition, prerequisite, or alternative named, so routing between it and its dozen list_* siblings is left to inference.

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

remove_bgRemove bgC

Destructive

POST /v5/tools/remove_bg. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds real context beyond them: provider scopes/locks/credits consumption and a mandatory confirmation plus "one submission only" rule. That materially helps an agent understand cost and non-repeatability.

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?

Two compact sentences, front-loaded with the endpoint and immediately followed by the highest-value operational constraints. No filler, though the leading endpoint token is low-information relative to the rest.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a nested payload object, the description covers operational preconditions but says nothing about the actual result (e.g., a processed image reference) or which provider performs the work. Annotations carry the safety profile, making this adequate but not complete.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (account, confirm, payload, payload_file) are already documented in the schema. The description adds no syntax or format detail about them, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with "POST /v5/tools/remove_bg," which is effectively a restatement of the tool name and title rather than a description of what the tool does. It never states in prose that it removes the background from an image, nor distinguishes it from the many other media-processing siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, and no alternatives are named despite many adjacent tools (generate_ai_image, apply_color_filter, etc.). The only usage-ish instruction is the confirmation requirement, which is a precondition rather than selection guidance.

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

resize_videoResize videoC

Destructive

POST /v5/tools/resize_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.7/5.0

Behavior4/5

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

Annotations already declare destructive=true, openWorld=true, idempotent=false and readOnly=false, so the safety profile is covered. The description adds real value beyond that: mandatory confirmation before provider execution and "one submission only," which warns the agent not to retry since the call is non-idempotent and consumes credits. It does not disclose the asynchronous/job result behavior, which would be nice for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is short and free of padding, but it front-loads the redundant endpoint path and the vague "Current Bannerbear V5 operation" clause instead of the actual purpose. Only the final clause about mandatory confirmation and single submission carries distinctive information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent video operation with a nested payload and no output schema, the definition omits what the tool returns (job id? poll via get_tool_job?), how long processing takes, and what the resize parameters accept. The confirmation/single-submission note is the sole substantive detail in an otherwise thin definition.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema carries the parameter burden and the baseline of 3 applies. The nested payload properties (video_url, width, height, fit) have no inline descriptions, and the description adds no meaning for fit's cover/contain/blur semantics or dimension expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The only statement of purpose is the HTTP route "POST /v5/tools/resize_video" plus "Current Bannerbear V5 operation," which restates the name and title without describing what resizing does (dimensions, aspect handling, output). It gives no differentiation from closely related siblings such as crop_video, trim_video, concat_videos or soften_video.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no condition selecting this tool over crop_video or other video operations, and no prerequisites beyond a generic note that provider scopes and credits apply. The agent must infer the use case entirely from the name.

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

run_workflowRun workflowB

Destructive

POST /v5/workflow_runs. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false and openWorld=true, so the safety profile is covered. The description adds real context beyond that: provider scopes, locks and credits apply, and confirmation is mandatory with a single submission allowed, tying directly to the confirm parameter and the credit-consuming nature of the run.

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?

Three compact clauses, front-loaded with the endpoint, with zero filler. It is terse but dense, packing scope, credits, confirmation and single-submission rules into a small footprint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with no output schema and a nested payload, the description covers the key risks (credits, locks, mandatory confirmation, one submission). The payload/inputs structure is left to the schema, which is acceptable given full coverage there.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters including the exclusivity of payload vs payload_file. The description adds no parameter-level detail beyond noting mandatory confirmation, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys the operation only through its HTTP endpoint ('POST /v5/workflow_runs') rather than stating a plain verb and resource. It does implicitly distinguish the run-creating action from siblings like get_workflow_run and list_workflow_runs, but an agent must infer that this triggers execution rather than read it stated directly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as create_workflow, preview_operation, or apply_render_batch. The 'one submission only' note is a behavioral constraint, not usage routing, so the agent gets no when/when-not context.

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

soften_videoSoften videoC

Destructive

POST /v5/tools/soften_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety profile is covered. The description adds genuinely useful context beyond that: provider scopes, locks and credit consumption, plus the mandatory-confirmation and one-submission-only rules. It stops short of describing the actual result of softening or what gets consumed on failure, so it adds value but not richly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but its first sentence is the endpoint path, which is redundant with the tool name and does not earn its place. The remaining behavioral sentences are efficient. Overall it is terse to the point of under-specifying a destructive operation rather than being genuinely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world, credit-consuming tool the description does cover the key operational constraints (scopes, locks, credits, confirmation, single submission). However, it omits any explanation of the actual softening behavior or its parameters, and there is no output schema to lean on. Adequate but with a clear gap in describing the core operation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters, including the strength enum and the payload/payload_file exclusivity. The description adds no parameter-level detail (no strength meaning, no video format guidance) beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the HTTP endpoint path ('POST /v5/tools/soften_video'), which restates the tool name rather than explaining what the operation does to a video. It never states the actual effect (a softening/blur-like video transformation) or how it differs from siblings like apply_color_filter or trim_video. The purpose is effectively a tautology of the name plus endpoint metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states a constraint ('Mandatory confirmation before provider execution; one submission only') but gives no when-to-use guidance and no comparison against sibling video tools. It does not say when an agent should reach for soften_video versus apply_color_filter or other transformations. No alternatives or exclusions are named.

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

subtitle_videoSubtitle videoB

Destructive

POST /v5/tools/subtitle_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already declare a non-read-only, destructive, non-idempotent, open-world operation, and the description reinforces this with 'provider scopes, locks and credits apply' and 'one submission only' — useful additions on cost consumption and non-retryability. It still omits what gets modified/returned and the practical effect of the operation, keeping it short of a 5.

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?

Three short clauses, front-loaded with the endpoint and immediately followed by the operational constraints. Nothing is padded, though the raw URL string is low-value text for an agent compared to a plain-language purpose statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, destructive, credit-consuming video operation with a nested payload and no output schema, the description never explains the resulting artifact (output video/subtitle job), how it is delivered, or job life-cycle. Annotations plus schema cover the surface, but the high-complexity context demands more than endpoint + confirmation boilerplate.

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

Parameters3/5

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

Schema description coverage is 100%, so account/confirm/payload/payload_file and all nested payload fields are already documented in the schema. The description adds nothing about payload shape or parameter meaning, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description leads with the HTTP endpoint ('POST /v5/tools/subtitle_video') and calls it a 'Current Bannerbear V5 operation', but never states what the operation actually does to a video (e.g. burns in subtitles/captions). The self-descriptive name carries the meaning, so it is distinguishable from video siblings, but the description itself adds no verb+resource clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one firm usage constraint — 'Mandatory confirmation before provider execution; one submission only' — which tells the agent to set confirm=true and not retry. However, it offers no guidance on when to choose this tool versus other video tools (trim_video, overlay_video, add_audio, etc.), so routing is left to the name alone.

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

trim_videoTrim videoC

Destructive

POST /v5/tools/trim_video. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, but the description adds real operational context: that provider scopes/locks/credits apply and that execution requires mandatory confirmation with a single submission only. The 'one submission only' note meaningfully reinforces the non-idempotent behavior with a practical consequence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences and front-loaded, but 'Current Bannerbear V5 operation' is filler that doesn't inform tool selection. The valuable operational cautions are present but the framing sentence could be tightened or replaced with actual purpose text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, open-world mutation with a nested payload, the description covers the safety/confirmation side adequately and the schema covers the body shape, but it never explains output behavior or that start/end are numeric time offsets, and there is no output schema to compensate. Adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload, and payload_file, including the mutual-exclusivity of payload vs payload_file. The description adds nothing about parameters (e.g., units for start/end), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description mostly restates the tool name and restates the HTTP route ('POST /v5/tools/trim_video'), adding no natural-language explanation of what trimming does or how it differs from siblings like crop_video, resize_video, or concat_videos. An agent learns nothing beyond the identifier it already has.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose trim_video over the many adjacent video-editing siblings (crop_video, concat_videos, soften_video). The only imperative is a confirmation requirement, which is a procedural constraint rather than a use-vs-alternative guideline.

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

update_animation_templateUpdate animation templateB

Destructive

PATCH /v5/animation_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructive=true, idempotent=false, openWorld=true, readOnly=false. The description adds genuine value beyond them: 'provider scopes, locks and credits apply', a mandatory confirmation gate before execution, and 'one submission only' warning against retries. It stops short of stating exactly what is destroyed on the template or whether the payload replaces vs merges.

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?

Three short sentences, front-loaded with the endpoint and layered with operational constraints. Every clause carries weight (scopes, credits, confirmation, single submission). The path prefix is mildly redundant with the name but useful for API alignment.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema and a deeply nested payload, the description covers safety gates and cost but omits the key replacement-vs-merge behavior of the PATCH body and what happens to unspecified existing layers. Given the annotations already carry the safety profile, it is adequate but with a clear gap on mutation semantics.

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

Parameters3/5

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

Schema coverage is 80%: account, confirm, payload and payload_file all carry descriptions, and the endpoint path references {uid}. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies. Notably it does not surface the payload/payload_file exclusivity or the 'complete body' replacement semantic, both of which live only in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the concrete operation via 'PATCH /v5/animation_templates/{uid}', which together with the name makes the update-on-animation-template purpose unambiguous. It does not explicitly contrast with siblings like create_animation_template or update_image_template, but the HTTP verb plus resource is specific enough for an agent to distinguish it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance or naming of alternatives. Nothing tells the agent when to prefer this over create_animation_template, update_image_template, or delete_animation_template, nor what prerequisites exist beyond the confirmation flag.

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

update_image_templateUpdate image templateB

Destructive

PATCH /v5/image_templates/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.4/5.0

Behavior4/5

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

Beyond annotations it discloses that provider scopes, locks and credits apply (auth + billing cost), that confirmation is mandatory before execution, and that only one submission is permitted — the latter corroborating idempotentHint=false and warning against retries. It stops short of saying what the destructive update overwrites or how partial updates behave.

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?

Three short, front-loaded sentences with the endpoint leading. The telegraphic style ('Current Bannerbear V5 operation') is efficient though slightly clipped, and no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex PATCH tool with nested layer objects, no output schema and only 80% param coverage, the description does not explain what a payload update replaces or how the confirm gate works. The safety-critical notes are present, but coverage of the update semantics is thin.

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

Parameters3/5

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

Schema description coverage is 80%, so account, confirm, payload and payload_file are documented in the schema itself; the baseline of 3 applies. The description adds no parameter-level meaning, not even clarifying the {uid} path variable or the payload/payload_file exclusivity it alludes to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource via 'PATCH /v5/image_templates/{uid}', which clearly signals an update operation distinct from create/get/delete siblings. However it never names the sibling tools or spells out what fields of the template can be modified, leaving the agent to infer scope from the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It notes 'Mandatory confirmation before provider execution; one submission only,' which is a procedural constraint, but gives no guidance on when to choose update over create_image_template, delete_image_template, or get_image_template. No conditions, prerequisites, or alternatives are stated.

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

update_instant_urlUpdate instant urlA

Destructive

PATCH /v5/instant_urls/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds value beyond that: it warns that provider scopes, locks and credits apply (external cost/side effects) and that only one submission is allowed, which is a real retry constraint. The jargon ('locks') is vague but the added context is genuine.

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 the HTTP path, then three short clauses with no padding. 'Current Bannerbear V5 operation' is mild filler, but the whole definition stays tight and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with a nested payload object and no output schema, the description covers confirmation and cost/locks but never says which fields the payload updates or what happens to unspecified settings. Annotations carry the safety burden, so this is adequate but leaves gaps.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents account, confirm, payload and payload_file. The description only implicitly touches the 'confirm' parameter via 'Mandatory confirmation' and adds no syntax or format detail beyond the schema, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource through the HTTP operation 'PATCH /v5/instant_urls/{uid}', making clear this modifies an existing instant URL. It doesn't differentiate from siblings like create_instant_url or delete_instant_url, but the verb and path are unambiguous about what is being acted upon.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a use prerequisite ('Mandatory confirmation before provider execution; one submission only') but never states when to choose this tool over create_instant_url or get_instant_url, nor what prerequisites the account/uid must satisfy. Usage is implied rather than explained.

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

update_webhookUpdate webhookB

Destructive

PATCH /v5/webhooks/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-redundant operational context: mandatory confirmation before provider execution, a single-submission rule (no retry), and that provider scopes, locks, and credits apply. It still omits what specifically is destroyed or changed, keeping it short of a 5.

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 definition is short and front-loads the endpoint, with no wasted clauses at the sentence level. However, 'Current Bannerbear V5 operation' is generic filler that does not add actionable information. Overall compact and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with no output schema and a nested payload object, the description covers the confirmation/one-shot constraint but says nothing about what a successful update returns or what happens on failure. Combined with annotations and 80% schema coverage it is minimally adequate, not complete.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents uid, account, confirm, payload, payload_file, and the nested enum fields. The description adds nothing about parameters and does not explain exclusivity or the effect of the nested payload fields beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description conveys the operation only through the raw REST path 'PATCH /v5/webhooks/{uid}', which does imply updating a webhook but never states in prose what it changes (url, event, status, resource). It does not differentiate itself from siblings such as create_webhook, delete_webhook, or get_webhook beyond the HTTP verb. Purpose is inferable but not articulated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no mention of alternatives or preconditions relative to the sibling webhook tools. The 'Mandatory confirmation before provider execution; one submission only' line is an execution constraint rather than a selection guide. An agent gets no help deciding between this and other webhook operations.

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

update_workflowUpdate workflowB

Destructive

PATCH /v5/workflows/{uid}. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`uid`	Yes
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

B3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely new context beyond that: provider scopes/locks/credits apply, confirmation is mandatory before execution, and it is a one-submission operation (reinforcing non-idempotence and warning against retries). That is real behavioral value, though it never states what the destructive update actually replaces.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is tight and front-loaded, but the terseness comes at the cost of under-specification rather than efficiency. Two of the three clauses (scopes/locks/credits, confirmation) are dense jargon that would benefit from one clarifying phrase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with a nested payload and no output schema, the description covers execution mechanics (confirmation, single submission) but omits the key semantic that the payload is a complete replacement body whose omitted fields are dropped. Given schema-side coverage and the destructive annotation, this is minimally adequate rather than complete.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents account, confirm, payload and payload_file (including the 'payload or payload_file exclusively' note). The description adds nothing about parameter meaning or interaction beyond echoing {uid} in the path. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the HTTP method and path (PATCH /v5/workflows/{uid}), which conveys a mutating operation on the workflows resource, but it never says in semantic terms what is being updated (name, tags, steps). It does no sibling differentiation against update_image_template, update_webhook, or update_instant_url, which share the same verb.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is a prerequisite hint ('Mandatory confirmation before provider execution'), but no guidance on when to reach for update_workflow versus create_workflow or get_workflow, and no statement of when-not-to-use. 'Current Bannerbear V5 operation' implies a version constraint but is not actionable as routing guidance.

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

upload_assetUpload assetA

Destructive

POST /v5/assets. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`asset_file`	Yes	Regular non-symlink local file, at most 5,000,000 bytes. Uploaded only after confirmation.
`content_type`	Yes	Exact documented Content-Type for these raw file bytes.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true. The description adds real context beyond that: provider scopes/locks/credits are consumed, confirmation is mandatory before execution, and the call may only be submitted once. It still omits failure handling and whether the response is synchronous, which keeps it short of a 5.

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?

Three short, front-loaded fragments with no filler; the endpoint leads and the operational constraints follow. The 'POST /v5/assets' clause is somewhat redundant with the tool name, costing it the top score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent write with no output schema, the description covers confirmation and credit/lock implications reasonably, but says nothing about what is returned (asset id, job handle) or how partial/async completion is signalled. Account selection behavior is left entirely to the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (account, confirm, asset_file, content_type) are already fully documented in the schema. The description only reinforces the 'confirm' requirement, adding marginal meaning beyond the structured fields — the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource via the endpoint 'POST /v5/assets', and the tool name makes the action clear. It does not, however, distinguish itself from adjacent write endpoints (create_image, create_instant_url) or explain what an 'asset' is in this system, so sibling differentiation is only implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Mandatory confirmation before provider execution; one submission only' implies procedural usage but never states when to pick this tool over the other upload/create siblings. No prerequisites, no when-not conditions, no named alternatives.

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

video_thumbnailsVideo thumbnailsC

Destructive

POST /v5/tools/video_thumbnails. Current Bannerbear V5 operation; provider scopes, locks and credits apply. Mandatory confirmation before provider execution; one submission only.

ParametersJSON Schema

Name	Required	Description
`account`	No	Exact private workspace profile label; no fallback to another profile key.
`confirm`	No	Must be true for this exact requested render, upload, edit, install or delete.
`payload`	No	Complete current native JSON body. Use payload or payload_file exclusively.
`payload_file`	No	Regular non-symlink local JSON file, at most 1 MiB.

TDQS

C2.9/5.0

Behavior4/5

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

Beyond the annotations, the description discloses that provider scopes, locks and credits apply, that confirmation is mandatory before provider execution, and that only one submission is allowed. These are meaningful operational traits (cost consumption, irreversibility of submission) that align with and extend the destructiveHint/openWorldHint 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?

The definition is brief and front-loads the endpoint and confirmation rule with no filler. It is arguably too terse for a nested-payload video operation, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, credit-consuming video tool with a nested payload object and no output schema, the description covers confirmation and cost but says nothing about the result (e.g. number of thumbnails returned, URLs, or job/polling behavior). It is minimally adequate but leaves real gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, payload and payload_file in detail. The description only echoes the confirmation requirement already implied by the confirm parameter, adding no new syntax or format detail, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with the raw endpoint string "POST /v5/tools/video_thumbnails," which essentially restates the tool name rather than stating what the operation produces. It never says in plain language that it extracts or generates thumbnail images from a video, so an agent depends entirely on inferring intent from the name and siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the many sibling video tools (trim_video, create_gif_preview, create_video_slideshow, etc.), nor any stated precondition beyond the generic confirmation note. The agent must infer use cases on its own.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

75 tool updatesv2.0.0Oct 3, 2026
- First observedadd_audio
- First observedadd_cover_art
- First observedanimate_template
- First observedapply_color_filter
- First observedapply_render_batch
- First observedcheck_assets
- First observedconcat_videos
- First observedcreate_animation
- First observedcreate_animation_template
- First observedcreate_batch
- First observedcreate_gif_preview
- First observedcreate_image
- First observedcreate_image_template
- First observedcreate_instant_url
- First observedcreate_pdf
- First observedcreate_video_slideshow
- First observedcreate_webhook
- First observedcreate_workflow
- First observedcrop_video
- First observeddelete_animation_template
- First observeddelete_image_template
- First observeddelete_instant_url
- First observeddelete_webhook
- First observeddelete_workflow
- First observedgenerate_ai_image
- First observedgenerate_ai_video
- First observedgenerate_voiceover
- First observedget_account
- First observedget_animation
- First observedget_animation_template
- First observedget_asset
- First observedget_batch
- First observedget_image
- First observedget_image_template
- First observedget_instant_url
- First observedget_layer_schema
- First observedget_operation_schema
- First observedget_publication
- First observedget_tool_job
- First observedget_webhook
- First observedget_workflow
- First observedget_workflow_run
- First observedinstall_publication
- First observedlist_accounts
- First observedlist_animation_templates
- First observedlist_animations
- First observedlist_assets
- First observedlist_batches
- First observedlist_image_templates
- First observedlist_images
- First observedlist_instant_urls
- First observedlist_publications
- First observedlist_tool_jobs
- First observedlist_webhooks
- First observedlist_workflow_runs
- First observedlist_workflows
- First observedoverlay_image
- First observedoverlay_video
- First observedpoll_job
- First observedpreview_operation
- First observedpreview_render_batch
- First observedquery_pages
- First observedremove_bg
- First observedresize_video
- First observedrun_workflow
- First observedsoften_video
- First observedsubtitle_video
- First observedtrim_video
- First observedupdate_animation_template
- First observedupdate_image_template
- First observedupdate_instant_url
- First observedupdate_webhook
- First observedupdate_workflow
- First observedupload_asset
- First observedvideo_thumbnails

Deploy Server

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

TDQS

C2.9/5.0

Scored 2026-10-03 02:55 across 75 tools

Disambiguation3/5

Most tools target a distinct resource+action, but the surface is large enough to create genuine confusion between near-neighbors: create_animation vs create_animation_template vs animate_template, list_animations vs list_animation_templates, create_batch vs apply_render_batch vs run_workflow, and preview_operation vs preview_render_batch vs preview_render_batch/apply_render_batch. Descriptions are formulaic and largely identical boilerplate, so they do little to disambiguate beyond the name itself.

Naming Consistency4/5

The overwhelming majority follow a clean verb_noun snake_case pattern (list_/get_/create_/update_/delete_ + resource). A few outliers break the pattern, such as video_thumbnails (noun-only), remove_bg, animate_template, and poll_job, but they remain readable and predictable.

Tool Count2/5

75 tools is a very heavy surface for a single MCP server, well past the point where an agent can reliably select among them. While Bannerbear's V5 API is genuinely broad, the count far exceeds a well-scoped set and risks tool-selection overload.

Completeness4/5

Coverage spans templates, images, animations, videos, webhooks, batches, workflows, assets, tool utilities, plus local schema/preview/poll helpers, and includes dedicated create/update/delete for most resources. Minor gaps exist (no delete for images, animations, batches, or assets), but these are plausible API limitations rather than dead ends.

Maintenance

ActivityNo data

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp-serverOAuth
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
studioOAuth
io.kaitoi
Build and run visual creative-production workflows from your AI agent.
AI & Machine Learning Design Tools App Automation
2
GigSoul x402 A
com.gigsoul.api
26 pay-per-call AI agent tools for marketing, sales, content, research, verification, and integration testing. Agents pay per call via x402 micropayments (USDC on Base), raw JSON in and out. Includes delivery-acceptance receipts (ACCEPT/REJECT/REVIEW), a webhook capture/replay/conformance lab, and n8n workflow validation with bounded JSON-Patch repair.
Marketing
301
Pixelixe
com.pixelixe
Brand-safe MCP for AI agents to create editable, on-brand graphics and automate variants.
Design Tools Marketing App Automation
2

Related MCP Servers

AI-Canvas MCP Server
Design Tools Developer Tools
laoluojuhai
A
license
Not graded
quality
C
maintenance
Enables AI assistants to inspect, modify, export, and validate design documents with 47 tools covering design, code generation, branding, and print/mockup workflows.
Updated 6 months ago (2026-03-18 14:42 UTC)
1 npm
1
MIT
indesign-mcp-server
Design Tools App Automation
lucdesign
A
license
C
quality
B
maintenance
Enables AI assistants to automate Adobe InDesign publishing workflows, including document creation, text formatting, image placement, PDF export, and more via 35+ professional tools.
Updated a month ago (2026-09-01 12:06 UTC)
36
45
MIT
InDesign MCP Server
Design Tools Content Management Systems
zachshallbetter
A
license
C
quality
B
maintenance
Transforms Adobe InDesign into an AI-powered design automation platform with 135+ professional tools for seamless programmatic control over layout and design capabilities.
Updated 10 days ago (2026-09-23 23:25 UTC)
100
20
MIT
Axonity Flow MCP Serverofficial
Agent Orchestration Developer Tools
AxonityAI
A
license
A
quality
A
maintenance
Enables AI agents to author and manage workflows, agents, tools, skills, policies, and reference docs in an Axonity tenant via the public REST API, with guardrails preventing direct publishing and secret exposure.
Updated 24 days ago (2026-09-09 19:30 UTC)
100
39 npm
MIT

Bannerbear MCP Server & CLI

Two ways to use it

Command line

MCP server, for your AI app

Which one

Features

Contents

1. What you can ask it

2. Quick install

3. Set up Bannerbear access

Private V5 workspace keys

Plans, credits and limits

Rotation and revocation

4. Connect your client

5. Check it works

6. Output, flags and exit codes

7. MCP or CLI and token cost

8. Every tool and argument

get_account

list_image_templates

create_image_template

get_image_template

update_image_template

delete_image_template

list_images

create_image

get_image

list_batches

create_batch

get_batch

list_webhooks

create_webhook

get_webhook

update_webhook

delete_webhook

list_assets

upload_asset

get_asset

check_assets

list_publications

get_publication

install_publication

list_instant_urls

create_instant_url

get_instant_url

update_instant_url

delete_instant_url

list_animations

create_animation

get_animation

list_animation_templates

create_animation_template

get_animation_template

update_animation_template

delete_animation_template

animate_template

remove_bg

generate_ai_image

generate_ai_video

video_thumbnails

subtitle_video

generate_voiceover

create_pdf

trim_video

concat_videos

resize_video

crop_video

overlay_video

overlay_image

add_audio

add_cover_art

create_video_slideshow

apply_color_filter

soften_video

create_gif_preview

list_tool_jobs

get_tool_job

list_workflows

create_workflow

update_workflow