langlearn-tts

Overview Schema Source Related Servers Discussions Admin

synthesize

Convert written text into MP3 audio files for listening or language practice. Pick from multiple voices, languages, and speech rates to match your needs.

Instructions

Synthesize text to an MP3 audio file.

Args: text: The text to convert to speech. With ElevenLabs eleven_v3, you can embed audio tags in square brackets anywhere in the text to control delivery — e.g. [tired], [excited], [whisper], [sad], [sigh], [laughs], [dramatic tone]. Tags are free-form; the model interprets them as performance cues. Combine with punctuation (ellipsis for pauses, ! for emphasis) for best results. Tags only work with ElevenLabs eleven_v3 model. voice: Voice name. Default: provider's default voice (currently matilda for ElevenLabs, joanna for Polly, nova for OpenAI). If language is provided without voice, a suitable default voice for that language is selected automatically. language: ISO 639-1 language code (e.g. 'de', 'ko', 'fr'). Enables language-aware voice selection and validation. With Polly, validates voice-language compatibility. With ElevenLabs/OpenAI, passed through (voices are multilingual). rate: Speech rate as percentage (90 = 90% speed, good for language learners). Defaults to 90. ElevenLabs ignores rate; use audio tags like [rushed] or [drawn out] instead. auto_play: Open the file in the default audio player after synthesis. Defaults to true. output_path: Full path for the output file. If not provided, a file is auto-generated in output_dir. output_dir: Directory for output. Defaults to TTS_OUTPUT_DIR env var or ~/langlearn-audio/. stability: ElevenLabs voice stability (0.0-1.0). Ignored by other providers. Defaults to provider default. similarity: ElevenLabs voice similarity boost (0.0-1.0). Ignored by other providers. Defaults to provider default. style: ElevenLabs voice style/expressiveness (0.0-1.0). Ignored by other providers. Defaults to provider default. speaker_boost: ElevenLabs speaker boost toggle. Ignored by other providers. Defaults to provider default.

Returns: JSON string with path, text, voice, and language fields.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`rate`	No
`text`	Yes
`style`	No
`voice`	No
`language`	No
`auto_play`	No
`stability`	No
`output_dir`	No
`similarity`	No
`output_path`	No
`speaker_boost`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.2Aug 30, 2026

TDQS

A3.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses provider-specific default voices, language-aware voice selection, audio tag constraints and model restriction, auto_play default, output_path/output_dir fallback behavior, the TTS_OUTPUT_DIR environment variable, and that stability/similarity/style/speaker_boost are ignored by non-ElevenLabs providers. It also states the return JSON fields. This is far beyond minimal.

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

Conciseness2/5

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

The first sentence is a good front-loaded summary and Args/Returns structure helps, but the description contains repeated blocks: audio-tag guidance and voice/language/rate sections appear twice, bloating the text and risking confusion. It needs deduplication before it can earn a higher score.

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 tool with 11 parameters, no annotations, and no schema descriptions, the description covers essentially every parameter and the return value. It is only held back by the duplication and by not explicitly routing the agent to sibling tools for batch/pair workflows.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so every parameter must be documented in prose. The description covers all 11 parameters with defaults, allowed types/ranges, provider-specific behavior, and output implications, adding meaning the schema cannot convey: default voice names, ignored-by-other-providers flags, and env-var fallback.

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 description opens with a specific verb and resource: 'Synthesize text to an MP3 audio file.' It clearly identifies the tool as text-to-speech. However, it never explicitly mentions single-item synthesis or contrasts with siblings synthesize_batch/synthesize_pair, so an agent must infer the distinction from sibling names alone.

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

Usage Guidelines2/5

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

No guidance is given for when to choose this tool over its batch/pair siblings. The description focuses on parameter mechanics (voices, tags, output paths) and never states 'use this for a single utterance' or 'use synthesize_batch for multiple texts.' The usage is only implied by the singular 'text' and sibling names.

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

Deploy Server