Skip to main content
Glama
haibinwang9

MiMo TTS MCP Server

by haibinwang9
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

MiMo TTS - designed voice

design_voice_to_speech

Generate speech using a voice invented from your text description, with no preset voice or audio sample, then save the audio and return its file path.

Instructions

Synthesize speech with Xiaomi MiMo mimo-v2.5-tts-voicedesign, inventing a brand-new voice from a text description. No preset voice and no audio sample involved. Writes the audio to a file and returns its path.

Input Schema

NameRequiredDescriptionDefault
textNoText to speak. Optional only when optimize_text_preview is true, in which case MiMo generates or polishes the script itself.
formatNoOutput container. wav is lossless and takes the low-latency streaming path; mp3 is smaller.wav
file_nameNoBase name used when output_path is omitted, e.g. "greeting".
output_pathNoWhere to write the audio file. Must stay inside MIMO_TTS_OUTPUT_DIR (~/mimo-tts) unless the server sets MIMO_TTS_ALLOW_ANY_PATH. A relative path resolves against the server process cwd. Existing files are never overwritten; a -2, -3 suffix is added instead.
voice_descriptionYesVoice design brief, 1-4 sentences. Cover dimensions such as gender and age, timbre, emotion, pace, plus optional persona/scene/era. Avoid post-processing terms (reverb, EQ) and contradictions.
optimize_text_previewNoLet MiMo polish the script (or invent one when text is omitted) before synthesis.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden but only discloses the output contract: audio is written to a file and the path is returned. It says nothing about permissions, latency, cost, failure modes, or what the server does if synthesis fails, so it is a modest disclosure for an unannotated mutation tool.

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, zero filler: what the tool does, what it is not, and what it returns. The most important distinction is front-loaded before the output behavior.

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 6-parameter tool with 100% schema coverage and no output schema, the description covers purpose, the model behind it, and the return shape (file path). It is essentially complete; only richer behavioral context (latency, auth, error handling) is missing.

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 every parameter including voice_description, output_path restrictions and the text/optimize_text_preview interaction is already documented in the schema. The description adds no parameter-level semantics beyond what the schema supplies, which is the baseline 3 case.

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 ('Synthesize speech'), names the exact model ('mimo-v2.5-tts-voicedesign'), and pins the differentiator: a brand-new voice invented from a text description. The exclusions ('No preset voice and no audio sample') let an agent separate it from text_to_speech and clone_voice_to_speech without opening schemas.

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

Usage Guidelines4/5

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

The exclusions 'no preset voice and no audio sample involved' effectively define the selection condition against the two sibling TTS tools, and the phrase 'inventing a brand-new voice from a text description' signals the use case. It never names the alternatives explicitly, so it stops short of a full when/when-not routing statement.

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