Skip to main content
Glama
sena-labs

Replicate-MCP-Server

by sena-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Clone a voice with Replicate

replicate_clone_voice

Clone a voice from a short reference audio sample and synthesize speech from text, reproducing the voice's characteristics for personalized audio.

Instructions

Synthesize speech in a cloned voice. Provide a short reference audio sample (~5-30 s) and the text to speak; the model reproduces the voice characteristics.

DISPLAY REQUIREMENT — after this tool returns successfully, include the URL printed in the tool's text content as a markdown link [Audio](URL) so the user can play it. URLs expire in ~24h.

Args:

  • text (string, 1-5000): Text to synthesize in the cloned voice.

  • reference_audio_url (URL): URL of the voice sample to clone from. Use replicate_upload_file to upload a local file first.

  • language (string, optional): ISO-639 code (e.g. "en", "es", "it"). Default "en".

  • model (string, default "xtts-v2"): Curated key (xtts-v2, openvoice-v2) or "owner/name[:version]".

  • extra_input (object, optional): Model-specific extras.

  • download (boolean, default true).

  • timeout_ms: Default 300000.

Returns: PredictionResult. local_paths contain WAV/MP3 files.

Examples:

  • text="Hello world, this is my cloned voice.", reference_audio_url="<url-to-your-voice-sample.wav>"

  • text="Buongiorno a tutti!", reference_audio_url="", language="it"

Input Schema

NameRequiredDescriptionDefault
textYesText to synthesize in the cloned voice.
modelNoVoice cloning model. Curated: xtts-v2, openvoice-v2. Or "owner/name".xtts-v2
downloadNo
languageNoISO-639 language code (e.g. 'en', 'es', 'it'). Default: 'en'.
timeout_msNoMax ms to wait for the prediction. If exceeded, returns the prediction ID so you can poll via replicate_get_prediction. Default: 300000 (5min).
extra_inputNoAdditional model-specific inputs.
reference_audio_urlYesURL of a short voice sample (~5-30s) to clone. Use replicate_upload_file if you only have a local file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.3.1
    • addedInput schema / properties / extra_input / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. First observedv3.2.3

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare the generic profile (non-read-only, open-world, non-idempotent, non-destructive); the description adds genuinely new behavior: output URLs expire in ~24h, a mandatory display action after success, local WAV/MP3 artifacts when download is true, and the timeout fallback returning a prediction ID. It omits cost/credit implications and any per-model caveats, so it is strong but not exhaustive.

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?

The display requirement is correctly front-loaded and visually separated, and the args/returns/examples layout is scannable. There is some duplication between the Args block and the schema, but the total length is reasonable for a 7-parameter tool with post-call obligations.

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?

With no output schema, the description does the necessary work by naming the return type and telling the agent that local_paths holds WAV/MP3 files plus the URL to surface. Missing only cost/rate context and any guidance on which curated model key to prefer.

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 already 86%, and the Args block largely restates those same definitions. The only additions beyond the schema are the upload hint for reference_audio_url and the worked examples, which is incremental value rather than compensating 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 first sentence states a specific verb and outcome — synthesizing speech in a cloned voice from a reference sample plus text — which is concrete and matches the tool name. It never explicitly distinguishes itself from the very similar sibling replicate_generate_speech, so an agent must infer that the reference audio is the differentiator (which the second clause does hint at).

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?

The description gives a real prerequisite (upload a local file with replicate_upload_file first) and a follow-up path on timeout (poll via replicate_get_prediction), plus usage examples. However it never states when to pick this over replicate_generate_speech or replicate_generate_audio, which is the primary selection decision an agent faces with these siblings.

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