Vidova

Render a video in the cloud

render_video

Idempotent

Export a synced project to MP4 (H.264 or H.265) in the cloud. Returns an owned durable job immediately. When you need the finished video, call wait_for_jobs with the job's id: it waits until the render succeeds, fails or is cancelled, and answers with its download link. read_render reads its progress without waiting. The job freezes the project during preparation; its reported revision identifies the immutable snapshot rendered. Media must be uploaded and ready: a project that cannot be rendered as it is (a range outside the film, a file not ready, a film or component that does not compile) is refused at once with what to change. Rendering uses credits for each output second, about 0.08 credits a second up to 1080p at 30 fps in H.264: a 60-second film uses 5 credits. A second costs 1.25 times as much at 1440p, 2 times at 2160p, 1.4 times at 50 or 60 fps and 1.5 times in H.265, multiplied together. Failed or cancelled jobs give their credits back. Edits after freezing do not change this export.

Input Schema

TableJSON Schema

Name	Required	Description
`fps`	Yes
`codec`	Yes	The file's video codec. null: H.264, which plays everywhere. H.265 makes a smaller file of the same quality.
`quality`	Yes	How much detail the file keeps against its size. null: the render's own bitrate for its size, about high.
`projectId`	Yes	An owned synced project ID, or null for the open project.
`endSeconds`	Yes	Range end in seconds, or null for the whole film.
`resolution`	Yes	540p is a quick preview to watch. 2160p is 4K. Free allows up to 720p at 30 fps with a watermark. Paid plans allow up to 2160p at 60 fps.
`startSeconds`	Yes	Range start in seconds, or null for the whole film. Both range endpoints must be present or both null.
`idempotencyKey`	Yes	A UUID for this export. Reuse it to safely repeat submission; use a new UUID for another export.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`phase`	Yes
`output`	No
`status`	Yes
`artifact`	Yes
`attempts`	Yes
`branchId`	Yes
`progress`	Yes
`revision`	Yes
`admission`	No
`createdAt`	Yes
`errorCode`	Yes
`projectId`	Yes
`streamUrl`	No
`updatedAt`	Yes
`resolution`	Yes
`totalFrames`	Yes
`errorMessage`	No
`phaseProgress`	Yes
`framesCompleted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare the safety profile (readOnly=false, idempotent=true, destructive=false), and the description adds substantial context beyond them: the job freezes the project into an immutable revision, edits after freezing don't affect the export, invalid renders are refused immediately with actionable feedback, costs are itemized per output second with multipliers, and failed/cancelled jobs refund credits.

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 core action and the follow-up routing before moving into edge cases and pricing. It is a dense single block, but nearly every sentence carries operational weight (validation behavior, refunds, cost model); only minor tightening would help.

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

Completeness5/5

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

For an 8-parameter mutation with an output schema, the description supplies everything else the agent needs: async job model, polling alternatives, immutability of the frozen revision, failure/refusal conditions, and the credit-cost equation. Nothing required 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.

Parameters4/5

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

Schema coverage is already 88%, so the baseline is 3. The description goes further by tying resolution, fps, and codec choices to concrete cost consequences (1.25x at 1440p, 2x at 2160p, 1.4x at 50/60 fps, 1.5x in H.265) and to the snapshot semantics of the render, which the schema alone does not convey.

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?

States a specific verb and resource: 'Export a synced project to MP4 (H.264 or H.265) in the cloud.' It also positions itself against siblings by naming wait_for_jobs and read_render as the follow-up tools, so an agent can tell this is the submission call rather than the polling or inspection call.

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

Usage Guidelines5/5

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

Explicit routing: 'When you need the finished video, call wait_for_jobs with the job's id' and 'read_render reads its progress without waiting.' It also states a precondition for use ('Media must be uploaded and ready') and what happens when that precondition fails, which is exactly the when/when-not guidance an agent needs.

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

All Vidova tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.