Skip to main content
Glama
Sign In

switch

by ai.switchapp
OverviewDiscussionsAdmin

Generate Dialogue

generate_dialogue

Make ONE audio file, saved to your library, of two or more people talking to each other, spoken by ElevenLabs v3 (or v4, with model). Give it lines in order, each with the voice who says it (a voice name or a voice id from list_voices) and the words. The speakers react to each other the way people in one room do, which is why this beats making each line on its own and stitching them. Inside any line's text you can write performance tags in square brackets and the model acts them instead of reading them out: [laughs], [laughs harder], [starts laughing], [wheezing], [whispers], [sighs], [exhales], [sarcastic], [curious], [excited], [crying], [snorts], [mischievously]. There are also sound tags such as [gunshot], [applause], [clapping] and [explosion], and experimental ones such as [sings] and [strong French accent]. Use ellipses and ordinary punctuation for pauses; there is no pause tag. As many lines as you like, up to 10 different voices, and up to 2000 characters of speech in total. Billed per 250 characters of everything said. For one person speaking use generate_speech.

Input Schema

NameRequiredDescriptionDefault
linesYesThe conversation in order, as many lines as it takes. Example: [{ "voice": "Rachel", "text": "[whispers] Did you hear that?" }, { "voice": "Adam", "text": "[sighs] It is just the wind." }]
modelNoOptional. Always "v4" (Eleven v4); leave it out.
languageNoOptional two-letter language code, for example "es", when the conversation is not in English.
stabilityNoOptional, 0 to 1. Lower is more expressive and the tags land harder, higher is steadier and calmer.
similarityNoOptional, 0 to 1. How closely each read sticks to its own voice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / model / description
      Previous value: -"Optional. \"v3\" (the default) or \"v4\". Both speak dialogue."New value: +"Optional. Always \"v4\" (Eleven v4); leave it out."
  2. Changed2 schema fields changed
    • changedInput schema / properties / lines / description
      Previous value: -"The conversation in order, 2 to 20 lines. Example: [{ \"voice\": \"Rachel\", \"text\": \"[whispers] Did you hear that?\" }, { \"voice\": \"Adam\", \"text\": \"[sighs] It is just the wind.\" }]"New value: +"The conversation in order, as many lines as it takes. Example: [{ \"voice\": \"Rachel\", \"text\": \"[whispers] Did you hear that?\" }, { \"voice\": \"Adam\", \"text\": \"[sighs] It is just the wind.\" }]"
    • addedInput schema / properties / model
      Added value: +{
+  "description": "Optional. \"v3\" (the default) or \"v4\". Both speak dialogue.",
+  "type": "string"
+}
  3. Added

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the mutation profile is largely covered. The description does add valuable context beyond them: output lands in the library, billing is per 250 characters, caps of 10 voices and 2000 characters, and the model version trade-off. That is meaningful disclosure, but the v3/v4 wording is muddled against the schema's "always v4" 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?

Front-loaded with the core action and the key alternative in the first two sentences. The long performance-tag enumeration earns its place as actionable syntax, though the v3/v4 parenthetical adds confusion rather than value.

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?

No output schema exists, yet the description covers where the result goes (your library), what it costs, the hard limits on voices and characters, and how tags behave. For a 5-parameter generation tool this is sufficient to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all five parameters are already documented, and the description adds little parameter-level detail beyond the tag catalogue, which is also partly in the schema. stability and similarity are not explained in the description at all, and the model guidance ("or v4, with model") conflicts with the schema's instruction to leave model out.

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?

States a specific verb and resource with scope: "Make ONE audio file ... of two or more people talking to each other." It also names the sibling it is not (generate_speech) for the single-speaker case, so an agent can route without opening either 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?

Explicitly says when to use it (multi-speaker conversation) and gives the alternative with the condition that selects it: "For one person speaking use generate_speech." It also explains why it beats per-line generation plus stitching, which preempts a plausible wrong approach.

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

All switch toolsInspect
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