Skip to main content
Glama
elibarnett

kie-mcp

by elibarnett
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

generate_sfx

Generate a sound effect from text via Suno V5 (kie.ai removed the ElevenLabs sound-effect model). Great for game sounds: UI clicks, magic spells, item pickups, explosions. For loop/BPM/key control use generate_sounds instead.

Instructions

Generate a sound effect from text via Suno V5 (kie.ai removed the ElevenLabs sound-effect model). Great for game sounds: UI clicks, magic spells, item pickups, explosions. For loop/BPM/key control use generate_sounds instead. Downloads to kie/assets/raw/.

Input Schema

NameRequiredDescriptionDefault
textYesSound description (e.g. "magical sparkle chime, fairy-like, short 0.5s")
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.
filenameNoOutput filename. Auto-generated if omitted.
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).
duration_secondsNoTarget duration hint, folded into the prompt (Suno has no hard duration control).
max_wait_secondsNoOverride the blocking-mode polling budget in seconds (defaults: image 600, video 900, audio 300, speech 300). Ignored when wait=false.
prompt_influenceNoDeprecated — ignored (no Suno equivalent). Kept for backward compatibility.

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

A4.4/5.0
Behavior4/5

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

There are no annotations, so the description carries the full burden; it discloses the provider/model, that the previous ElevenLabs model was removed, and the default download destination (kie/assets/raw/). It does not mention cost/credit expenditure in the description itself, though the max_credits and estimate_only params cover that ground in the schema.

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 tight sentences, front-loaded with the verb+resource, then differentiation, then the output location. The game-sound examples earn their space by anchoring the intended prompt style; nothing 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 9-parameter generation tool with no annotations and no output schema, the description covers purpose, the sibling alternative, and where files land, while the schema handles the async/cost mechanics. The main gap is that the description never states the tool spends credits or what a returned task looks like, leaving that entirely to the parameters.

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 schema already documents every parameter including async behavior and the deprecated prompt_influence flag. The description adds no syntactic or format detail beyond what the schema provides, so the baseline of 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?

States a specific verb+resource ('Generate a sound effect from text') plus the engine ('via Suno V5'), and explicitly separates itself from generate_sounds for loop/BPM/key control. An agent can pick between the two sibling generators without opening a 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?

Names the alternative (generate_sounds) with the condition that selects it, gives concrete use-case examples (UI clicks, magic spells, pickups, explosions), and flags the async path ('wait=false... poll with check_task') for long generations. When-to-use, when-not-to-use, and alternatives are all present.

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