framesail

Edit voices and voice blocks

voiceover_edit

Destructive

Voices and voice blocks; free. set_voice: the narrator's or a character's voice; every speaker needs one before the voiceover. rescan_blocks: split the active script into voice blocks again after an edit, assets untouched; blocks whose words are unchanged keep their audio. settings: the voice engine, narrator speed and language.

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": {
      "action": "<action>",
      "project_id": "<project_id>"
    },
    "name": "voiceover_edit"
  }
}

Input Schema

Name	Required	Description
`action`	Yes	set_voice: speaker, voice_id; rescan_blocks; settings: voice_tts_provider, narrator_speed and/or language
`speaker`	No	set_voice: "narrator", or a character's name
`language`	No	settings: the script's language as an ISO 639-1 code; Analyze Script detects it and overwrites it on every run
`voice_id`	No	set_voice: a voice id from voiceover_read action=voices
`project_id`	Yes	Project id
`narrator_speed`	No	settings: speaking rate, 0.5-2.0 (default 1.0); pauses come only from `<break>` tags
`voice_tts_provider`	No	settings: the voice engine

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

changedInput schema / properties / action / description

Previous value: -"set_voice: speaker, voice_id; rescan_blocks; settings: voice_tts_provider and/or narrator_speed"New value: +"set_voice: speaker, voice_id; rescan_blocks; settings: voice_tts_provider, narrator_speed and/or language"

addedInput schema / properties / language

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "settings: the script's language as an ISO 639-1 code; Analyze Script detects it and overwrites it on every run"
+}

AddedOct 1, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds value beyond them by noting 'assets untouched' for rescan and that 'blocks whose words are unchanged keep their audio', which tells the agent the blast radius is limited to changed blocks. It also notes the tool is 'free'. It stops short of saying what happens to the audio of changed blocks or that set_voice may invalidate existing generated audio.

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?

Compact and front-loaded, with action names leading each clause so an agent can scan for the mode it needs. The telegraphic style ('Voices and voice blocks; free.') is slightly clipped and costs a little readability.

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 destructive, 7-parameter multiplexed tool with no output schema, the description covers all three modes and their key side effects, which is enough to invoke it correctly. Missing only return/confirmation behavior and any permission or prerequisite notes.

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 enum values are self-documenting, so the schema does the heavy lifting and a 3 is the baseline. The description's per-action notes ('every speaker needs one', provider/speed/language grouping) largely duplicate the action property's own description rather than adding new constraint or format detail.

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?

The description names the resource (voices and voice blocks) and enumerates three concrete actions with a one-clause summary of each (set_voice, rescan_blocks, settings). An agent can tell what the tool does without opening the schema, though the opening fragment 'Voices and voice blocks; free.' restates the title rather than stating a verb, and it never distinguishes itself from voiceover_generate or voiceover_read.

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?

Each action carries a usage trigger: set_voice is required 'before the voiceover', rescan_blocks is for 'after an edit'. That gives clear situational context, but there are no explicit when-not rules and no routing to the sibling voiceover_read/voiceover_generate tools for the read and produce paths.

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

All framesail 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.

Resources

Need Help?