Skip to main content
Glama

Clone the owner's voice

voice_clone

Clones a voice from recordings on your own machine (Eleven v4 speaks it), as one of the project's voices of its own (its plan allows a number of them, designed and cloned together; voices_read says how many are left). It returns a one-time https address, good for 30 minutes, and the curl line that sends the recordings to it from your own shell: every file in one command makes one voice, up to 25 recordings and 50 MB in all, and Marsell hears at most 10 minutes of them together. Nothing big passes through your messages, and audio at a web address isn't fetched: download it to the machine first. get_upload_link with kind voice does the same. Set consent: true only when the owner has said, in their own words in this conversation, that the recordings are of their own voice or that they have the speaker's permission to clone it. Never assume it, never set it for them, and never clone a voice of someone who hasn't agreed (a public figure, a voice from a video). Recordings: 1 to 2 minutes of clear speech in total, one speaker only, no music, no background noise and no long pauses; more than 3 minutes doesn't make it better. MP3 is best (any common audio format works: WAV, M4A, OGG, WebM, FLAC; Marsell turns it into MP3). Speak the way the voice should sound in the videos. Cloning spends no tokens; a voice-over in it spends tokens as any voice-over does.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "consent": "<consent>"
    },
    "name": "voice_clone"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe voice's name, what the owner picks it by in Create: "Dad", "Sam".
consentYestrue only when the owner said, in their own words, that it is their own voice or that they have the speaker's permission.
projectNoThe project's id or exact name. Optional when the account has one project.
descriptionNoWhat the voice sounds like, in a few words ("warm, calm, a slight Russian accent").
remove_noiseNotrue to take background noise out of the recordings first (only when they have some: it can thin a clean voice).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say it is a non-read-only, non-destructive, open-world operation; the description adds the one-time 30-minute URL, the curl-based upload path, hard limits (25 recordings, 50 MB, 10 minutes of audio heard), the rule that audio at a web address is never fetched, and the token cost model (cloning is free, voice-overs are not). That is substantially more than the annotations convey.

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

Conciseness3/5

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

Every topic is relevant, but the prose is tangled: the opening sentence stacks three parentheticals, and recording-quality advice, consent policy, and cost notes run together without clear separation. Repeated consent wording also duplicates the schema. It is dense rather than concise, and could be tightened into scannable blocks.

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?

For a five-parameter tool with no output schema that involves uploading external files, the description covers the return value and expiry, upload mechanics, size/duration limits, accepted formats, audio-quality requirements, alternatives, and the consent gate. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description goes beyond the schema on the required consent flag by enumerating the cases it must not be set for (public figures, video-sourced voices, assumed permission). It does not add anything for remove_noise or description, but the consent policy lift is real.

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?

The description states a specific verb and resource (clones a voice from local recordings), the mechanism (one curl command uploading files), and the return (a one-time 30-minute https address). It also distinguishes itself from get_upload_link with kind: voice and points to voices_read for quota, so an agent can tell it apart from siblings 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?

It names an explicit alternative ("get_upload_link with kind voice does the same") and the related read tool for remaining slots (voices_read). It also states hard when-not conditions: never clone a public figure, a voice from a video, or anyone who hasn't agreed, and never set consent on the owner's behalf.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.