Vidova

Clean up the voices in a sound

isolate_voice

Clean the speech of a video or a sound: keep the voices and remove the rest, such as a baby crying, wind, traffic, music, a crowd or a room's echo. Every voice that speaks stays. The new sound asset is the whole source, voices only, in step with it from its first second. To use it, put it on an audio track with the same at, offset and duration as the clip whose sound it cleans, and set that clip's volume to 0. 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 about 0.81 credits a second of the whole source: a 1-minute clip uses 49 credits.

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": {
      "assetId": "<assetId>",
      "projectId": "<projectId>"
    },
    "name": "isolate_voice"
  }
}

Input Schema

Name	Required	Description	Default
`assetId`	Yes	The video or sound asset whose speech to clean: a ready asset with sound, up to 30 minutes long. Use the IDs search_assets gives.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare openWorldHint=true and non-idempotent/non-destructive, but the description adds the substantive traits: it returns a Job ID immediately and renders in the background, output is the whole source length aligned from second one, and cost is ~0.81 credits per second of source (49 credits/minute). It does not cover failure modes or what happens on an unsupported/over-long source beyond the schema's 30-minute note.

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 transformation is front-loaded, then usage workflow, then async/cost details, in a logical order. It is longer than most definitions and the credit-cost sentence is slightly elaborate, but every sentence carries operational information rather than filler.

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?

There is no output schema, and the description compensates by explaining the returned Job ID, the resulting asset's content and timing, and the wait_for_jobs/patch_film follow-up needed to consume it. Combined with the credit cost and track-placement instructions, an agent has everything needed to call and use the tool 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?

Schema coverage is 100%, so both assetId and projectId are already fully documented in the schema. The description adds no syntax or format detail beyond them; its only related note is the workflow hint that wait_for_jobs should receive the same projectId, which the schema already states. Baseline 3 applies.

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 ('Clean the speech of a video or a sound: keep the voices and remove the rest') and lists concrete things removed (baby crying, wind, traffic, music, crowd, echo). This clearly distinguishes it from siblings like split_sound or extract_layers without naming them.

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 explicit downstream usage: place the new asset on an audio track with the same at/offset/duration and set the source clip's volume to 0. It also prescribes the async pattern (start all generations, then call wait_for_jobs with all Job IDs, then patch_film). It lacks explicit when-not-to-use guidance relative to alternatives such as split_sound, keeping it below 5.

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.