Kuro

Generate voice-over

generate_voiceover

Start a voice-over generation from text. This spends credits and returns immediately. Pass subject to read in the voice bound to one of the account's Subjects — her model, voice, delivery and language — or pick model and voice yourself; omit both to use the default model's default voice. Lines of one script must sound like one take: generate the whole script once and cut it, or keep the model, voice and delivery fixed across lines. Models:

elevenlabs-tts (Eleven v3): ~8.5 per 1,000 chars; up to 3000 chars; default voice Rachel; controls language/speed; custom voice ids
eleven-v4 (Eleven v4): ~7 per 1,000 chars; up to 4000 chars; default voice JBFqnCBsd6RMkjVDRZzb; controls language; custom voice ids; stitches lines (continues_from)
gemini-3.1-flash-tts (Gemini 3.1 Flash TTS): ~11 per 1,000 chars; up to 4000 chars; default voice Kore; controls style prompt/language
kokoro-82m (Kokoro 82M): ~0.5 per 1,000 chars; up to 4000 chars; default voice af_bella; controls speed
minimax-speech-2.8-hd (MiniMax Speech 2.8 HD): ~4.5 per 1,000 chars; up to 4000 chars; default voice Wise_Woman; controls language/speed/emotion; custom voice ids
inworld-tts-2 (Inworld TTS 2.0): ~2.5 per 1,000 chars; up to 2000 chars; default voice Ashley; controls language/speed; custom voice ids

Input Schema

TableJSON Schema

Name	Required	Description
`text`	Yes	The words to speak. Each model has its own ceiling, shown in its roster line ("up to N chars"); a longer script is split into lines.
`model`	No
`speed`	No
`voice`	No
`emotion`	No
`subject`	No	A Subject's name or id. Reads in her bound voice; model, voice, style_prompt and language_code then come from the binding and may not be passed.
`style_prompt`	No
`language_code`	No
`continues_from`	No	The generation ids of up to three earlier lines of the same script, oldest first, on a model whose roster line says it stitches; keeps the voice continuous across separately generated lines. Same model and voice as those lines.
`idempotency_key`	No	Optional. Pass the same value to retry one operation without spending twice; omit it for a new operation. Different arguments under a reused key are refused.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`message`	Yes
`generation`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 21, 2026

addedOutput schema / properties / generation / properties / ready_in_seconds
```
Added value: +{
+  "type": [
+    "number",
+    "null"
+  ]
+}
```

changedOutput schema / properties / generation / required

Previous value: -[
-  "generation_id",
-  "kind",
-  "status",
-  "model",
-  "prompt",
-  "aspect_ratio",
-  "refined_from",
-  "caption_style",
-  "output_url",
-  "credits_cost",
-  "error",
-  "vendor_phase",
-  "stalled",
-  "created_at",
-  "app_url"
-]New value: +[
+  "generation_id",
+  "kind",
+  "status",
+  "model",
+  "prompt",
+  "aspect_ratio",
+  "refined_from",
+  "caption_style",
+  "output_url",
+  "credits_cost",
+  "error",
+  "vendor_phase",
+  "stalled",
+  "ready_in_seconds",
+  "created_at",
+  "app_url"
+]

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds behavior the annotations do not carry: that the call spends credits, that it returns immediately rather than blocking, per-model cost and character ceilings, and the stitching (continues_from) semantics for keeping a voice continuous across separately generated lines. The idempotency_key note (reuse to retry without spending twice, different args refused) clarifies spend behavior, which is the material risk here; annotations only say destructiveHint=false and idempotentHint=false, which is consistent with a non-destructive but credit-consuming call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Front-loads the action, its cost, and its non-blocking nature in the first sentence, then routing rules, then the script-consistency caveat, then the model roster. The roster is dense but every line carries decision-relevant data (cost, ceiling, default voice, supported controls) rather than filler.

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 10-parameter generative tool with an output schema, the description covers cost, latency, voice selection strategy, script continuity, and model trade-offs — enough to call it correctly without reading other tools. It omits error/retry behavior beyond the idempotency hint and any note on retrieving the resulting generation, which the output schema and get_generation presumably cover.

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 description coverage is only 40%, so the description must compensate, and it largely does: the per-model roster documents default voices, character limits, and which controls (language, speed, emotion, style prompt, custom voice ids) each model supports. It does not explain the speed range (0.1-5) or emotion enum values, and leaves language_code format unspecified, but the enums in the schema cover the discrete choices.

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 ("Start a voice-over generation from text") and immediately scopes it as an async, credit-spending operation. It is clearly distinguishable from siblings such as change_video_voice or cast_voice, which operate on existing media rather than producing a new generation.

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 routing rules for the core parameter choice: pass `subject` to inherit a bound voice (with the caveat that model/voice/style/language may then not be passed), or pick `model`/`voice` yourself, or omit both for the default. It also gives a strong consistency rule for multi-line scripts (generate once and cut, or keep model/voice/delivery fixed). It does not name sibling tools or state when-not to use this tool, so it stops short of a 5.

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

All Kuro 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?