FFmpeg Micro MCP Server. Transcode videos from n8n or Make using FFmpeg in the cloud. Code+Docs: https://github.com/javidjamae/ffmpeg-micro-mcp/
Scored across 15 tools
Most tools have clearly distinct purposes, but there is potential overlap between generic transcode/transcribe operations and blueprint workflows (e.g., resize-format vs transcode_video), and between polling variants. Descriptions clarify the differences well, so misselection is unlikely with careful reading.
Tool names consistently follow a snake_case verb_noun pattern (e.g., get_transcode, run_blueprint, cancel_transcode). Minor variations like get_transcribe_download and run_blueprint_and_wait are still predictable and readable.
15 tools is reasonable for a video processing API covering upload, transcode, transcribe, and blueprints. However, convenience duplicates like run_blueprint_and_wait and transcode_and_wait add slight redundancy to an otherwise well-scoped set.
The surface covers core workflows: upload, transcode, transcribe, blueprints, cancellation, listing, and download URL generation. Minor gaps exist, such as no list or cancel operation for transcribe jobs, but these are workable around via get_transcribe polling.
Cancel a pending or processing transcode job. Jobs that are already completed, failed, or canceled cannot be canceled and return an error.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transcode job UUID to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the error condition for non-cancelable states, which is useful, but it does not mention side effects (e.g., resource cleanup) or confirm that canceling is irreversible. It is not contradictory, but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action, and every sentence adds value. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema and no annotations, the description covers the essential: what it does, when to use it, and the error condition. It could mention the outcome on success, but that is minor for a cancel operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter as 'Transcode job UUID to cancel' with 100% coverage, so the description adds no additional semantic detail. Baseline 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and the resource ('pending or processing transcode job'), which is specific and distinct from sibling tools. It also specifies the states that are eligible, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly defines when the tool applies (pending or processing) and when it does not (completed, failed, canceled), which gives an agent clear decision criteria. It does not name alternatives, but no cancel alternatives exist among siblings, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 2 of the direct-upload flow. Call after PUTting the file bytes to the URL returned by request_upload_url. Returns the final gs://... fileUrl plus probe metadata (duration, format, codecs). Use the fileUrl directly as a media_url for transcribe_audio or as an inputs[].url for transcode_video.
| Name | Required | Description | Default |
|---|---|---|---|
| fileSize | Yes | File size in bytes — must match the size declared in `request_upload_url`. | |
| filename | Yes | Storage object name returned by `request_upload_url` (the `result.filename` field), NOT the original local filename. | |
| uploadId | No | Optional upload tracking ID, if the gateway returned one with the presigned URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return values (fileUrl and probe metadata) but does not disclose validation behavior, error conditions, or side effects. With no annotations, a slightly higher bar would require mention of what happens if fileSize mismatch or other 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Key information is front-loaded: 'Step 2 of the direct-upload flow.' Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return values (fileUrl and probe metadata) and how to use them. Provides sufficient context for a two-step flow, linking to sibling tools. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all parameters with descriptions. The main description adds value by clarifying that 'filename' is the storage object name (not original local filename) and that 'fileSize must match the size declared in request_upload_url'. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as 'Step 2 of the direct-upload flow' and states its specific verb+resource ('confirm upload'). It distinguishes from sibling tools like request_upload_url by positioning it as the follow-up step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly specifies when to use ('after PUTting the file bytes to the URL returned by request_upload_url') and what to do with the result ('use the fileUrl as media_url for transcribe_audio or inputs[].url for transcode_video'). Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a caption-video blueprint run that paused in status awaiting_review for transcript review. Pass the approved (optionally edited) SRT text; the run continues to render the captioned video. Poll with get_blueprint_run afterwards.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Blueprint run ID (must be in status awaiting_review) | |
| srt_text | Yes | The reviewed/edited SRT transcript to burn into the video |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the preconditions and the post-call behavior (continues rendering and poll afterward), which is useful. However, it doesn't cover potential failure modes, side effects, or what happens if the run is not in awaiting_review, so it is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all useful: the purpose and condition, the input and effect, and the next action. No filler or repetition of schema details, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter resume action with no output schema, the description covers the essential flow: precondition status, input value, continuation of rendering, and how to check the result. It doesn't specify immediate return behavior or error cases, but the 'poll afterwards' guidance compensates for most of that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters fully (id and srt_text) with meaningful descriptions, so the description adds little beyond what the schema provides. The phrase 'approved (optionally edited) SRT' adds some contextual nuance about the expected input, but the schema already says 'reviewed/edited SRT transcript.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Resume') and resource ('caption-video blueprint run'), and immediately distinguishes its purpose from starting a new run by noting it continues after pausing in awaiting_review. This clearly differentiates it from siblings like run_blueprint and run_blueprint_and_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: resume only a run paused in awaiting_review, pass the approved SRT, and then poll with get_blueprint_run. It doesn't explicitly state when not to use this tool versus alternatives, but the status condition and follow-up instruction make the intended workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current state of a blueprint run: status (pending/processing/awaiting_review/completed/failed), current step, and outputs when completed. Multi-output blueprints (listing-kit, hook-variants) return an outputs array of {label, url}; single-output blueprints return output_url. Download URLs are signed with a 10-minute TTL — re-fetch this run for fresh links. A caption-video run in status awaiting_review includes srt_text; review/edit it and resume with continue_blueprint_run.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Blueprint run ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and handles it well: it explains result-shape differences between multi-output and single-output blueprints, the 10-minute signed URL TTL and need to re-fetch, and the special srt_text field for caption-video awaiting_review runs. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then adds only high-value behavioral specifics. Although longer than a one-liner, every clause covers a distinct aspect an agent needs to invoke or interpret the result correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, this description covers output variants, TTL behavior, special status-specific fields, and how to continue a run. An agent has enough to call the tool correctly and interpret responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single id parameter, so the baseline applies. The description does not need to add parameter details; it already explains the broader run context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Fetch the current state of a blueprint run', and enumerates exactly what is returned (status, current step, outputs). This clearly differentiates it from sibling write/control tools like run_blueprint and continue_blueprint_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: use this to poll status, re-fetch when signed URLs expire, and resume caption-video runs with continue_blueprint_run. It names the continuation sibling explicitly, though it does not mention other potentially relevant siblings such as get_download_url or run_blueprint_and_wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a short-lived (10 minute) signed HTTPS URL for a completed transcode's output file. The job must be in completed status. Use this instead of the output_url field on the job object, which is a gs:// URL that HTTP clients cannot fetch directly.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Completed transcode job UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the URL is short-lived (10 minutes), is an HTTPS URL, and requires job to be completed. This provides useful behavioral context beyond schema. Could mention if the URL is single-use or reusable, but still strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three precise sentences, front-loaded with purpose, condition, and rationale. No redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (one param, no output schema, low complexity), the description covers purpose, condition, and alternative. Could be more explicit about return type, but overall adequate for an agent to decide to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline is 3. Description adds meaningful context: explains why the id parameter is needed (completed transcode job) and justifies the tool's existence. This adds value beyond schema's basic type description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a signed HTTPS URL for a completed transcode output file. The description uses specific verbs and resource ('generate a signed HTTPS URL for output file') and distinguishes it from sibling tools like get_transcode by focusing on download URL generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool should be used instead of the output_url field on the job object because it is a gs:// URL that HTTP clients cannot fetch directly. It also specifies the job must be in completed status, providing clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current state of a single transcode job by ID, including status (pending/processing/completed/failed/canceled) and output_url when completed.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transcode job UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It clearly indicates a read-only fetch operation and discloses the meaningful behaviors: status values returned and that output_url is only present when completed. It does not discuss not-found/error behavior, but for a simple read operation this is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, well-structured sentence that front-loads the action and resource, then adds the conditional return detail. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and full schema coverage, the description provides enough context for a typical read operation. It explains the statuses and the conditional output_url, though it does not mention error cases or 404 behavior, which are minor for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single 'id' parameter at 100% coverage. The description adds that the id refers to a transcode job, but does not need to add much beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch'), a clear resource ('current state of a single transcode job'), and identifies it by ID. It also enumerates the key return content (status values and output_url), which fully distinguishes it from siblings like list_transcodes and transcode_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you need the current state of one transcode job given its ID. However, it does not explicitly state when to prefer this over list_transcodes or the polling/wait variants, nor does it name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the current state of a single transcribe job by ID, including status (pending/processing/completed/failed/canceled) and output_url when completed. Mirrors get_transcode but for SRT generation jobs created via transcribe_audio.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Transcribe job UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the status values and that output_url appears only when completed, which is useful behavioral context. However, it does not mention polling behavior, error cases, or whether the job result is retained/deleted, which would be valuable for a job-status tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and return fields, then a useful sibling comparison. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter fetch tool, the description covers the purpose, the return fields, and the relationship to sibling tools. It lacks explicit polling/error behavior, but the simplicity of the tool and the 100% schema coverage make the definition largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter 'id' is already described as 'Transcribe job UUID'. The description adds that the ID refers to a transcribe job created via transcribe_audio, which is a small clarification, but it does not add format or source details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Fetch'), a specific resource ('current state of a single transcribe job by ID'), and the exact fields returned (status values and output_url). It also explicitly distinguishes itself from the sibling get_transcode, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it mirrors get_transcode but for SRT generation jobs created via transcribe_audio, which gives clear context for when to use it. It does not explicitly state when not to use it or name alternatives beyond get_transcode, but the context is sufficient for a single-ID fetch tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a short-lived (10 minute) signed HTTPS URL for a completed transcribe job's SRT file. The job must be in completed status. The returned URL can be dropped directly into a transcode's subtitles='<url>' filter to burn captions into a video.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Completed transcribe job UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the URL's short-lived duration (10 minutes) and file type (SRT). However, it does not mention rate limits, idempotency, or error behavior if the job is not completed, which are relevant for a generation endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no fluff. The first states the primary action and duration, the second sets precondition and a usage example. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is complete enough. It covers purpose, precondition, and a practical integration tip. It lacks only minor behavioral details like error cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds context that the 'id' parameter corresponds to a completed transcribe job. The schema already describes the parameter as 'Completed transcribe job UUID', so the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool 'Generate a short-lived signed HTTPS URL' for a completed transcribe job's SRT file, clearly distinguishing it from sibling tools like get_transcribe (which likely returns job metadata) and get_download_url (might be for other file types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the precondition that the job must be in 'completed' status, and provides a practical use case in a transcode filter. It does not explicitly state when not to use the tool or list alternatives, but the context is sufficiently clear for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transcode jobs for the authenticated account, with optional filters for status and time range. Paginated (default page 1, limit 20).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-indexed page number | |
| limit | No | Page size (max 100) | |
| since | No | ISO timestamp — only return jobs created at/after this time | |
| until | No | ISO timestamp — only return jobs created at/before this time | |
| status | No | Filter by job status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses pagination behavior ('Paginated (default page 1, limit 20)'), which is useful, and implies read-only operation via 'List'. However, it does not disclose whether the operation is safe, idempotent, or has any side effects. Since annotations are absent, a 3 is appropriate for including some behavioral context but missing deeper transparency like rate limits or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first covers purpose and filters; the second covers pagination defaults. No fluff, every word earns its place, and the critical action is front-loaded. This is a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list endpoint with no output schema and no annotations, the description covers essential aspects: purpose, filters, and pagination defaults. It does not describe the return structure (e.g., array of jobs with fields), but given the tool's simplicity and the schema's completeness, it is nearly complete. Could mention that the response includes total count or that filters are optional, but these are minor gaps. Thus a 4 is justified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of all parameters with clear descriptions (e.g., 'ISO timestamp' for since/until, enum for status). The description only mentions 'filters for status and time range', which adds minimal value beyond the schema. Baseline 3 is correct as the description does not contradict or significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List transcode jobs'), the target resource (transcode jobs for the authenticated account), and the optional filters. It distinguishes itself from sibling 'get_transcode' (which likely retrieves a single job) by implying a list operation. The verb 'List' and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (listing jobs with optional filters) but does not explicitly state when not to use it or suggest alternatives like 'get_transcode' for retrieving a specific job. The filters (status, time range) imply typical usage scenarios, but there is no direct comparison with sibling tools. This is a clear but not proactive usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Step 1 of the direct-upload flow. Returns a short-lived presigned HTTPS URL that the caller PUTs the file bytes to (with the same Content-Type that was passed in). After the PUT succeeds, call confirm_upload with the same filename and fileSize to receive the final gs:// URL for use as a transcode/transcribe input. The presigned URL expires in ~15 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| fileSize | Yes | File size in bytes (positive integer). Max 1.9GB. | |
| filename | Yes | Original filename, e.g. 'webinar.m4a'. Used as the suffix of the storage object name. | |
| contentType | Yes | MIME type of the file (e.g. 'audio/mp4', 'video/mp4', 'image/png'). Must be a supported media type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description discloses key behaviors: short-lived presigned URL, PUT requirement with same Content-Type, expiry time. Could note error states but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, logically structured steps. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return type (presigned URL) and next step. Could specify exact return format but sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage; description adds context: filename as suffix, fileSize max 1.9GB, contentType must match PUT. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool as 'Step 1 of the direct-upload flow' returning a presigned URL, distinguishing it from sibling tools like 'confirm_upload'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains the workflow (this step, then PUT, then confirm_upload) and mentions the URL expiry (~15 min), giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a blueprint run — a pre-built video workflow (captioning, resizing, watermarking, ads, and more). Returns the new run ({id, status, blueprint, tokens_charged}); poll it with get_blueprint_run, or use run_blueprint_and_wait to do both in one step.
Per-blueprint input fields (* = required):
product-ad: logo_url*, photo_url*, music_url? — GENERATIVE, costs 200 tokens
caption-video: video_url*, language?, style? (bold-bottom|clean-lower|center-pop|top-title) — pauses at awaiting_review with srt_text for transcript review; resume with continue_blueprint_run
viral-short: video_url*, hook_text*, style? (top-hook|center-statement|bottom-caption|lower-left), music_url?
quote-card: quote*, name?, handle?, photo_url?, output? (video|image)
watermark: video_url*, logo_url*, position? (top-left|top-right|bottom-left|bottom-right|center), size? (small|medium|large)
resize-format: video_url*, format? (9x16|1x1|16x9|4x5), fit? (pad|crop)
zoom-in: video_url*
zoom-out: video_url*
camera-glide: video_url*, direction? (right|left)
boomerang: video_url*
speed-changer: video_url*, speed? (0.5|1.5|2|4)
video-to-gif: video_url*, length? (5|10|15), size? (480|640), caption?, caption_position? (bottom|top|center) — output is a .gif
product-slideshow: photo1_url*, photo2_url*, photo3_url?..photo5_url?, music_url?, aspect? (9x16|1x1|16x9)
listing-kit: video_url* — multi-output (4 platform variants in outputs)
hook-variants: video_url*, hook1*, hook2?, hook3?, ratio? (9x16|4x5|1x1|original), style? (top-hook|center-statement|bottom-caption) — multi-output (one per hook in outputs)
Input URLs: public https or upload-bucket gs:// (use request_upload_url + confirm_upload to get one). FFmpeg-lane blueprints charge no tokens (they meter plan compute minutes); only generative blueprints (product-ad) charge tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Blueprint to run | |
| inputs | Yes | Blueprint input fields keyed by name — see the tool description for each blueprint's fields |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does a strong job: it discloses async behavior (poll it with get_blueprint_run), the return shape ({id, status, tokens_charged}), token costs (200 for product-ad), the GENERATIVE vs FFmpeg distinction, and the awaiting_review pause/resume flow for caption-video. It doesn't state rate limits, idempotency, or error behavior, but for a tool with no annotations this is well above average transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but earned: it front-loads the operation ('Start a blueprint run'), return shape, and polling/alternative hints before the per-blueprint field catalog. The catalog itself is dense and repetitive, but each line enumerates distinct parameters that the schema cannot express for a dynamic inputs object. It could be tightened (e.g., grouping multi-output notes), but every line carries information the agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-blueprint polymorphic tool with an opaque generic input schema and no annotations, the description is near-complete: it covers per-blueprint required/optional fields, enums, token costs, the awaiting_review pause, polling/resume alternatives, and output expectations. It doesn't include an explicit example payload, and input URL format is only hinted by the types in the field descriptions, but no output schema exists and none is promised, so the coverage is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes inputs as an object and slug as a Blueprint to run, so the description must do the heavy lifting. It does: enums for slug, required fields per blueprint, enum options for style/position/fit/direction and output types, and the multi-output note for listing-kit and hook-variants. Subtraction: the input schema also has a 'viral-short' slug while the description says 'viral-short' — same, okay. There is a minor mismatch: the schema enum includes 'product-slideshow' while description says 'product-slideshow' with photo1_url.. photo3_url?..photo5_url? – okay. The description maps fields to each slug, which the schema's generic inputs object does not. This is genuinely additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Start a blueprint run — a pre-built video workflow.' It clearly distinguishes from siblings by listing the exact blueprint slugs and pointing to get_blueprint_run and run_blueprint_and_wait as alternatives. The distinction from take-this-instead tools like run_blueprint_and_wait is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: it tells the agent to poll with get_blueprint_run, use run_blueprint_and_wait as a synchronous alternative, and mentions continue_blueprint_run for resuming. It also clearly states the required versus optional fields per blueprint and even flags which blueprints are generative vs FFmpeg-based, affecting token usage. This is comprehensive usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot convenience tool: starts a blueprint run and polls until it completes, fails, or pauses for review. Returns the final run with output_url (or outputs [{label, url}] for multi-output blueprints — prefer outputs when present). Download URLs are signed with a 10-minute TTL; re-fetch with get_blueprint_run for fresh links. NOTE: caption-video pauses in status awaiting_review — this tool then returns early with awaitingReview: true and the run's srt_text; review/edit the transcript and resume with continue_blueprint_run. If your MCP client enforces a short per-request timeout (many default to 60s), use run_blueprint + get_blueprint_run polling instead.
Per-blueprint input fields (* = required):
product-ad: logo_url*, photo_url*, music_url? — GENERATIVE, costs 200 tokens
caption-video: video_url*, language?, style? (bold-bottom|clean-lower|center-pop|top-title) — pauses at awaiting_review with srt_text for transcript review; resume with continue_blueprint_run
viral-short: video_url*, hook_text*, style? (top-hook|center-statement|bottom-caption|lower-left), music_url?
quote-card: quote*, name?, handle?, photo_url?, output? (video|image)
watermark: video_url*, logo_url*, position? (top-left|top-right|bottom-left|bottom-right|center), size? (small|medium|large)
resize-format: video_url*, format? (9x16|1x1|16x9|4x5), fit? (pad|crop)
zoom-in: video_url*
zoom-out: video_url*
camera-glide: video_url*, direction? (right|left)
boomerang: video_url*
speed-changer: video_url*, speed? (0.5|1.5|2|4)
video-to-gif: video_url*, length? (5|10|15), size? (480|640), caption?, caption_position? (bottom|top|center) — output is a .gif
product-slideshow: photo1_url*, photo2_url*, photo3_url?..photo5_url?, music_url?, aspect? (9x16|1x1|16x9)
listing-kit: video_url* — multi-output (4 platform variants in outputs)
hook-variants: video_url*, hook1*, hook2?, hook3?, ratio? (9x16|4x5|1x1|original), style? (top-hook|center-statement|bottom-caption) — multi-output (one per hook in outputs)
Input URLs: public https or upload-bucket gs:// (use request_upload_url + confirm_upload to get one). FFmpeg-lane blueprints charge no tokens (they meter plan compute minutes); only generative blueprints (product-ad) charge tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Blueprint to run | |
| inputs | Yes | Blueprint input fields keyed by name — see the tool description for each blueprint's fields | |
| timeoutSeconds | No | Max time to wait for the run to finish, in seconds. Default 600 (10 min). Max 1800. | |
| pollIntervalSeconds | No | Polling interval in seconds. Default 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: polling until completion/failure/pause, early return with awaitingReview for caption-video, signed URL TTL (10 min) and re-fetch instruction, token costs for generative vs FFmpeg-lane, and the multi-output format. This exceeds what annotations would typically provide and gives the agent a complete mental model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries necessary information. It is front-loaded with the core behavior and return format, then covers caveats (timeout, URL expiry) and per-blueprint details. For a tool with 15 blueprint variants, this density is justified and well-organized with clear bullet separators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a complex tool: covers output types (single, multi-output), pause behavior, URL signing, token costs, upload URL acquisition, and alternative polling strategies. The presence of a nested `inputs` object and no output schema is compensated by exhaustive description of all input combinations and result fields. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning: it enumerates every blueprint's required/optional input fields, allowed enum values (e.g., style options), and output behavior (e.g., multi-output vs single). This is far beyond the schema's terse 'Blueprint to run' and 'input fields keyed by name', making the description indispensable for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('starts a blueprint run and polls until it completes') and clearly differentiates from siblings like run_blueprint (just starts) and get_blueprint_run (just polls). The description explicitly frames it as a one-shot convenience tool, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance: 'If your MCP client enforces a short per-request timeout... use run_blueprint + get_blueprint_run polling instead.' Also instructs when to use continue_blueprint_run after an awaiting_review pause. Per-blueprint input fields guide the agent on which parameters to supply for each slug, leaving no ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot convenience tool: creates a transcode job, polls until it reaches a terminal state (completed/failed/canceled) or the timeout expires, and returns the final job plus a signed download URL if completed. Use this when you want the full transcode in one step without managing polling yourself.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | One to ten input videos. Multiple inputs are concatenated in order. | |
| preset | No | Simple mode — quality/resolution presets. Ignored if `options` is provided. | |
| options | No | Advanced mode — raw FFmpeg options or virtual options. Overrides `preset`. | |
| outputFormat | Yes | Container format for the output file | |
| timeoutSeconds | No | Max time to wait for the job to complete, in seconds. Default 600 (10 min). Max 1800. | |
| pollIntervalSeconds | No | Polling interval in seconds. Default 3. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behaviors on its own. It accurately states the tool creates a job, polls until terminal state or timeout, and returns a signed URL only on completion. It also mentions the timeout behavior and the return payload. It does not explicitly state what happens on failure (e.g., does it throw an error or return the failed job?), but the phrasing 'returns the final job' covers that. The description adequately discloses the main operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence packs the full behavior (create, poll, terminal state, return value) and the second delivers the usage guidance. All information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters including nested objects, no output schema, and no annotations, the description provides a clear mental model of the operation: create, poll, return. It explains the return value (final job + signed URL if completed) and the timeout behavior. Missing details like error handling or cost/performance implications are minor for a convenience tool. The description is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed per-parameter descriptions (e.g., inputs max/min, preset vs. options precedence, timeout defaults). The tool description adds minimal parameter-specific detail beyond the schema; it only contextualizes timeout and polling implicitly through the overall workflow. Baseline 3 applies since the schema already carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a one-shot convenience wrapper that creates a transcode job, polls to a terminal state, and returns the job plus a signed download URL. It uses a specific verb sequence and names the exact resource, making it distinct from siblings like transcode_video (which likely just submits) and get_transcode (which just reads status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence explicitly states when to use this tool: 'when you want the full transcode in one step without managing polling yourself.' This implies the alternative (manual polling via separate calls) and provides a clear selection criterion. However, it does not name the specific sibling tools (e.g., transcode_video, get_transcode) or state when not to use it beyond the implied case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a video transcode job on FFmpeg Micro. Accepts one or more input videos (gs:// or https://) and an output format. Returns immediately with a pending job — use get_transcode, list_transcodes, or transcode_and_wait to follow progress.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes | One to ten input videos. Multiple inputs are concatenated in order. | |
| preset | No | Simple mode — quality/resolution presets. Ignored if `options` is provided. | |
| options | No | Advanced mode — raw FFmpeg options or virtual options. Overrides `preset`. | |
| outputFormat | Yes | Container format for the output file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the asynchronous behavior ('Returns immediately with a pending job') and the input URL schemes, but does not mention failure modes, permissions, or whether input files are retained. It adds some behavioral context beyond the schema but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no fluff. The primary action and resource are front-loaded, followed by the key inputs and then the critical async behavior with pointers to follow-up tools. Every sentence earns its place and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential workflow: create the job, note it's pending, and know how to track it. It doesn't repeat schema details like max inputs or the preset/options precedence, which are already in the schema. For a job-creation tool with a rich schema, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters, including the preset/options interplay. The description only restates that inputs and output format are accepted, adding no new meaning. It correctly relies on the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a video transcode job') and the resource (FFmpeg Micro), and specifies the key inputs (input videos and output format). It also distinguishes itself from sibling progress-tracking tools by naming them explicitly, so an agent can tell this is the creation tool, not a polling or waiting tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool returns immediately with a pending job and directs the agent to `get_transcode`, `list_transcodes`, or `transcode_and_wait` to follow progress. This gives clear context for when to use this tool vs. those alternatives, though it doesn't explicitly say 'use transcode_and_wait if you want to block until completion' — a minor omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an SRT subtitle file from an audio or video URL using Whisper. Returns a pending job envelope immediately — poll with get_transcribe until status is completed, then fetch the signed SRT URL with get_transcribe_download. The SRT URL can be dropped directly into a transcode's subtitles='<url>' filter to burn captions into a video.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | 'transcribe' keeps the source language; 'translate' outputs English regardless of source. Defaults to 'transcribe'. | |
| language | No | Optional BCP-47 language hint (e.g. 'en', 'es'). Auto-detected when omitted. | |
| media_url | Yes | Audio or video URL to transcribe. gs://bucket/object (preferred, from the upload flow) or a public https:// URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the operation is asynchronous (returns envelope immediately, requires polling) and describes the output (SRT). While there are no annotations, the async behavior is core and explicitly disclosed. It also mentions handing the SRT URL to a transcode filter, revealing integration behavior. No annotation contradiction. Missing job envelope details like job ID field not named, but for transcription it's strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: outcome, async pattern with explicit polling instruction, downstream integration. Dense and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes the async flow and result type, and names the follow-up tools. It doesn't mention the job envelope shape, completion conditions beyond status='completed', authentication, or SRT URL expiry. But given schema and sibling names, it's adequate for use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters at 100%, so baseline 3 is appropriate. The description adds context that the input is audio or video and output is SRT, but doesn't add detail about the task/language parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: generate an SRT subtitle file from an audio or video URL using Whisper. This clearly distinguishes it from siblings like transcode_video and run_blueprint_run, and the downstream references to get_transcribe/get_transcribe_download clarify its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly maps the async workflow: call to get a pending envelope, poll get_transcribe until completed, then use get_transcribe_download. It also explains why you'd use this and how the output integrates with transcode's subtitles parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
continue_blueprint_runget_blueprint_runlist_transcodes1 field changedInput schema / properties / status / enumPrevious value: -[
- "queued",
- "processing",
- "completed",
- "failed",
- "cancelled"
-]New value: +[
+ "pending",
+ "processing",
+ "completed",
+ "failed",
+ "canceled"
+]run_blueprintrun_blueprint_and_waitconfirm_uploadrequest_upload_urlget_transcribeget_transcribe_downloadtranscribe_audiocancel_transcodeget_download_urlget_transcodelist_transcodestranscode_and_waittranscode_video
Add one secure layer between your agents and this server.