Vidova

Generate an image

generate_image

Generate an image from a prompt. Before you generate, ask whether a frame of the person's own footage does the job: for a still a template slot asks for, a thumbnail, a before and after, or a small edit such as text over a shot, a frame of the source (the moment you found with read_asset, placed as a short video clip at that second, or passed as a reference) keeps the real light and the real subject and costs nothing; generate when the picture must show something the footage does not hold. With references, the image model also sees up to 3 pictures: image assets, frames or contact sheets of video assets, and frames or contact sheets of the edit. Use them to keep a person's face from a frame, to copy the style of an image, or to sum up a range of a video or of the edit in one picture. Choose aspectRatio and imageSize (1K is standard). It answers at once with a Job ID and the media is made in the background: start every generation you need, keep working, then call wait_for_jobs with all their Job IDs to get each Asset ID for patch_film. One image uses 34 credits at 1K, 50 at 2K and 75 at 4K, with or without references.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "prompt": "<prompt>",
      "aspectRatio": "<aspectRatio>",
      "imageSize": "<imageSize>",
      "references": "<references>",
      "projectId": "<projectId>"
    },
    "name": "generate_image"
  }
}

Input Schema

Name	Required	Description
`prompt`	Yes	Up to 4000 characters.
`imageSize`	Yes
`projectId`	Yes	The project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.
`references`	Yes	Up to 3 pictures the image model sees with the prompt, in this order, or [] to generate from the prompt alone. Each one is: asset:ID, an image asset as it is (a video asset with no time gives its first frame); asset:ID#t=14.6, the frame of a video asset at 14.6 seconds; asset:ID#t=200,215, a contact sheet of that video from 200 to 215 seconds; film:#t=3.2, the frame of the edit at 3.2 seconds; film:#t=0,12, a contact sheet of the edit from 0 to 12 seconds. Contact sheets have no times written on them. Use the IDs search_assets gives. In the prompt, say what to take from each picture by its place: "keep the face of the man in the first picture", "paint it in the style of the second picture", "one poster that sums up the scene in the third picture".
`aspectRatio`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare non-read-only, open-world, non-idempotent, non-destructive; the description adds the crucial async contract (returns a Job ID at once, media rendered in the background, must be retrieved via wait_for_jobs), the reference cap of 3, and a full credit schedule (34/50/75 at 1K/2K/4K, references included). That is real behavioral context an agent cannot get from 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.

Conciseness3/5

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

Purpose is front-loaded, but the body is a single dense run-on paragraph stitched together with semicolons and commas, mixing selection advice, reference behavior, and billing. The information earns its place, but the packaging makes it harder to scan than it needs to be.

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 paid, asynchronous, non-idempotent generation tool with no output schema, the definition covers the workflow, cost, reference limit, and handoff to wait_for_jobs/patch_film. Remaining gaps are minor: nothing about failure behavior for a job or whether aspectRatio/imageSize interact with references.

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 moderate at 60%, and the description compensates for the thin parts: it explains that imageSize 1K is "standard," that up to 3 reference pictures are seen by the model, and how to address each picture by position in the prompt. projectId semantics are left entirely to the schema, which already documents the null/open-project behavior.

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?

Opens with a specific verb and resource ("Generate an image from a prompt") and immediately delimits the case against its main alternative: generating only when "the picture must show something the footage does not hold," versus taking a frame from read_asset. An agent can distinguish this from read_asset or patch_film without opening another schema.

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?

Gives explicit when-to-use criteria (template slot still, thumbnail, before/after, text-over-shot) and the cheaper alternative (a source frame, "costs nothing"), plus the exact downstream procedure: collect Job IDs, keep working, then call wait_for_jobs for Asset IDs to feed patch_film. It also maps three distinct reference use cases (keep a face, copy a style, summarize a range).

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.