Skip to main content
Glama
elibarnett

kie-mcp

by elibarnett
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

generate_dialogue

Generate multi-speaker dialogue using ElevenLabs Text-to-Dialogue V3 via kie.ai. Great for conversations between characters. Downloads to kie/assets/raw/.

Instructions

Generate multi-speaker dialogue using ElevenLabs Text-to-Dialogue V3 via kie.ai. Great for conversations between characters. Downloads to kie/assets/raw/.

Input Schema

NameRequiredDescriptionDefault
waitNoSet false to submit and return immediately with the task_id (async mode) — then poll with check_task and fetch with download_result. Recommended for long generations to avoid client-side watchdog timeouts.
dialogueYesArray of dialogue lines with voice assignments
filenameNoOutput filename. Auto-generated if omitted.
stabilityNoVoice stability — kie accepts exactly 0 (creative), 0.5 (natural), or 1 (robust)
max_creditsNoRefuse to submit if the estimated cost exceeds this many credits (overrides KIE_MAX_CREDITS_PER_CALL). Estimates come from published rates; kie bills the actual amount.
download_dirNoAbsolute directory to save the file(s) into (created if missing). Defaults to the server's kie/assets/raw/. Must be absolute — the MCP server's working directory is not the caller's.
estimate_onlyNoReturn the estimated credit cost WITHOUT submitting anything. Use before expensive runs (video, 4K, 1080p upgrades, layer splits).
language_codeNoLanguage code (e.g. "en")
max_wait_secondsNoOverride the blocking-mode polling budget in seconds (defaults: image 600, video 900, audio 300, speech 300). Ignored when wait=false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv5.8.0
    • addedInput schema / properties / estimate_only
      Added value: +{
+  "description": "Return the estimated credit cost WITHOUT submitting anything. Use before expensive runs (video, 4K, 1080p upgrades, layer splits).",
+  "type": "boolean"
+}
    • addedInput schema / properties / max_credits
      Added value: +{
+  "description": "Refuse to submit if the estimated cost exceeds this many credits (overrides KIE_MAX_CREDITS_PER_CALL). Estimates come from published rates; kie bills the actual amount.",
+  "type": "number"
+}
  2. First observedv4.7.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It usefully discloses the provider/model and the filesystem side effect ('Downloads to kie/assets/raw/'), but says nothing about credit consumption, blocking vs async behavior, or auth — details the agent must recover from the schema parameter descriptions instead.

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?

Three short sentences with zero filler: what it does, what it is good for, and where the output lands. Everything is front-loaded and no sentence is redundant.

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 nine-parameter generation tool with a fully documented schema and no output schema, the description plus schema give the agent enough to invoke it correctly: engine, speaker model, and destination directory. The only shortfall is the missing explicit routing against the other TTS siblings, which is a usage rather than an invocation gap.

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%, so all nine parameters, including the dialogue array shape, wait/async flow, credit guard, and estimate_only, are already documented in the schema. The description adds no parameter-level meaning beyond that, which is the correct baseline when the schema does the heavy lifting.

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 ('Generate multi-speaker dialogue') and names the underlying engine (ElevenLabs Text-to-Dialogue V3 via kie.ai). The 'multi-speaker' qualifier implicitly separates it from the single-speaker siblings generate_tts and generate_gemini_tts, though it never names an alternative, so the differentiation is inferential rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Great for conversations between characters' implies the use case (multi-character dialogue) but is a soft recommendation rather than a rule. There is no statement of when NOT to use it, and no pointer to generate_tts/generate_gemini_tts for single-speaker output, leaving the agent to infer the boundary.

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

Deploy Server

Other Tools