Skip to main content
Glama

Brainiall Pronunciation

by com.brainiall

Synthesize Speech

synthesize_speech
Read-onlyIdempotent

Generate natural speech audio from English text.

Produces high-quality speech with 12 English voices. Returns base64-encoded WAV audio (16-bit PCM, 24kHz mono) along with metadata.

Available voices:

  • af_heart (default), af_bella, af_nicole, af_sarah, af_sky (American female)

  • am_adam, am_michael (American male)

  • bf_emma, bf_isabella (British female)

  • bm_george, bm_lewis, bm_daniel (British male)

Args: text: English text to synthesize (1-5000 characters). voice: Voice ID. See list above. Defaults to 'af_heart'. speed: Speed multiplier from 0.5 to 2.0 (default: 1.0).

Returns: dict with keys: - audio_base64 (str): Base64-encoded WAV audio (16-bit PCM, 24kHz) - duration_ms (str): Audio duration in milliseconds - voice (str): Voice ID used - text_length (str): Input text character count - processing_ms (str): Synthesis time in milliseconds

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesEnglish text to convert to speech. Max 5000 characters.
speedNoSpeech speed multiplier (0.5 = half speed, 2.0 = double).
voiceNoVoice ID (e.g. 'af_heart', 'am_adam'). Uses default if omitted.

TDQS

A4.8/5.0
Behavior5/5

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

The description fully discloses behavior beyond the annotations: it returns base64-encoded WAV audio with specific format details (16-bit PCM, 24kHz mono), includes metadata keys such as duration_ms and processing_ms, and enumerates all 12 voices. This goes well beyond the readOnlyHint and idempotentHint annotations.

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?

The description is front-loaded with the core verb and resource, then uses a clear voice list and compact Args/Returns structure. Every sentence carries useful information; the length is justified by the voice catalog and return format documentation.

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 tool with no output schema, the description fully documents the return dictionary and its keys. It covers required input, optional parameters, defaults, ranges, and voice options, leaving no gap an agent would need to infer before calling the tool correctly.

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 coverage is already 100%, and the description adds substantial value by enumerating every valid voice ID with accent/gender groupings, specifying the 1-5000 character text constraint, and explaining the speed multiplier range with default. This gives an agent everything needed to construct correct parameters.

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 opens with a specific verb and resource: 'Generate natural speech audio from English text.' It goes on to list the exact output format and available voice options, making the tool's function unmistakable and clearly distinct from sibling tools like transcribe_audio or voice_id_enroll.

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 description provides clear context for use: English text input, voice selection, and speed control. It does not explicitly state when not to use this tool or name alternative tools for related tasks, but the purpose is unambiguous enough that an agent can correctly select it for text-to-speech synthesis.

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

All Brainiall Pronunciation toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools map to clearly distinct actions, but transcribe_audio and transcribe_audio_pro are near-duplicates and the four check_*_service tools require careful reading. The detailed descriptions make the distinctions recoverable, so confusion should be rare.

Naming Consistency4/5

The set overwhelmingly follows a snake_case verb_* pattern, and the voice_id_* family is internally consistent. Minor deviations like get_phoneme_inventory vs list_tts_voices and the _pro suffix on transcribe_audio_pro keep it from being perfect.

Tool Count4/5

Fourteen tools is within a reasonable range, but the server bundles pronunciation, STT, TTS, voice ID, and four health checks, making it feel broader than the 'Pronunciation' name suggests. A few health checks could be consolidated, but nothing is excessive.

Completeness3/5

Core pronunciation, transcription, and synthesis workflows are present, but the voice ID portion has create/list/verify/identify with no way to delete or unenroll a speaker. That is a notable lifecycle gap in an otherwise fairly complete speech toolkit.

Resources