Vidova

Replace a person in a video

replace_person

Replace a person in a video with someone from a picture, keeping the scene, the camera and the moves: put the user into a trend clip, or swap two people for two others. The new video is as long as the video, in whole seconds. To use part of a longer video, make an asset of that part first: download_asset gives its link, and import_asset_url with startSeconds and endSeconds imports only that part. 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. Uses credits for each second of the video: about 61 credits a second at standard and about 81 credits a second at pro, so a 10-second clip uses 610 credits at standard.

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": {
      "videoAssetId": "<videoAssetId>",
      "references": "<references>",
      "prompt": "<prompt>",
      "quality": "<quality>",
      "keepSound": "<keepSound>",
      "projectId": "<projectId>"
    },
    "name": "replace_person"
  }
}

Input Schema

Name	Required	Description
`prompt`	Yes	Who replaces whom. Call the video @Video1 and the pictures @Image1 to @Image4 in their order: "Replace the man on the left in @Video1 with the person in @Image1, and the woman on the right with the person in @Image2. Keep everything else the same." Up to 2000 characters.
`quality`	Yes	standard for most videos. pro keeps faces, hands and fine detail sharper, and uses more credits.
`keepSound`	Yes	null or true (the default) keeps the video's sound, such as the song of a dance trend. false makes the new video silent.
`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	1 to 4 pictures of the people to put in, in this order, each in one of these forms: asset:ID, an image asset as it is; asset:ID#t=14.6, the frame of a video asset at 14.6 seconds; film:#t=3.2, the frame of the edit at 3.2 seconds. Use the IDs search_assets gives. A face and clothes come from the picture.
`videoAssetId`	Yes	The video to recast: a ready video asset of 3 to 10 seconds, at least 720 pixels on each side.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only mark it as a non-idempotent, open-world write; the description adds the behavior an agent cannot see: it returns immediately with a Job ID and renders in the background, the output length equals the whole-second length of the source, and each second of video consumes credits (about 61/s standard, about 81/s pro, with a worked 10-second example). That resolves cost and latency planning before invocation.

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 purpose, then prerequisites, then the async contract, then cost; each sentence carries real information and none is filler. The prose is dense and somewhat run-on with colon-heavy clauses, which slightly hurts scanability but not correctness.

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?

Complete for a six-required-parameter generative mutation: duration/quality constraints, cost, return path, and downstream follow-up (wait_for_jobs, patch_film) are all covered despite there being no output schema. Failure handling and cancellation (a cancel_render sibling exists) are not mentioned, so the agent gets no guidance on what to do if a job fails.

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 schema already explains every parameter, including the @Image1..@Image4 ordering convention, quality enum trade-offs, keepSound defaulting behavior, and reference frame syntax. The description adds only the general ordering idea for multi-person swaps, so it sits at the baseline for schema-complete tools.

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 ('Replace a person in a video with someone from a picture') plus the invariants (scene, camera, moves) and two concrete use cases (trend clip, swap two people). It never names a sibling such as replace_film or replace_component to draw the boundary, so an agent must infer when this is the wrong replacement tool.

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?

Gives clear when-to-use context (put the user into a trend clip, swap two people) and an explicit prerequisite workaround for long sources: download_asset then import_asset_url with startSeconds/endSeconds. It also prescribes the multi-step async workflow (start all generations, then wait_for_jobs, then patch_film). No explicit 'use X instead when...' exclusion is given for cases outside these two scenarios.

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.