This server enables voice-based English pronunciation, grammar, and fluency coaching with Claude — all processed locally on your machine.
Voice conversation (converse): Record yourself speaking freely, get an automatic transcript, and receive inline English feedback (pronunciation, grammar, fluency) woven into Claude's reply.
Pronunciation drill (practice): Read a reference sentence aloud and get a detailed assessment including word alignment, per-word phoneme-level feedback (expected vs. produced IPA), learner-profile hints, minimal-pair drills, and prosody notes.
Retry practice (retry): Re-record and re-assess the last practiced sentence to track improvement.
Quick drill (quick_practice): Automatically pick a random sentence by phoneme focus (e.g., "th", "r_l", "vowels") and difficulty, then record and assess it in one step.
Sentence suggestion (suggest_sentence): Get a recommended practice sentence by phoneme focus or difficulty without recording.
Raw recording (record): Capture audio to a WAV file without analysis.
Assess a recording (assess): Analyze a previous or specified WAV file — with a reference text for full phoneme-level alignment and prosody; without one, runs transcript and prosody only.
Microphone check (check_mic): List available audio input devices and troubleshoot recording issues.
Notable features: All audio capture and transcription (via faster-whisper) happen locally for privacy. Optional wav2vec2 forced alignment reduces false mispronunciation flags. Rule-based learner-profile hints (e.g., Korean-L1) provide language-specific guidance. Cross-platform support includes macOS, Linux, Windows, and WSL2.
Accuracy and safety notice
This project is a local language-learning practice tool. It may contain bugs, runtime errors, inaccurate transcripts, inaccurate pronunciation feedback, or platform-specific recording issues. Pronunciation feedback is a coaching signal, not a standardized-test, clinical, employment, or high-stakes assessment. Review outputs carefully before relying on them. See DISCLAIMER.md.
An MCP (Model Context Protocol) server that lets you talk to your MCP assistant by voice while getting English pronunciation, grammar, and fluency feedback in the same turn. Use it for casual voice chat with light coaching, or switch to drill mode when you want to practice a specific sentence.
Built for Codex CLI, Claude Desktop, Claude Code, Cursor, VS Code, and other MCP clients. Everything runs locally — audio is captured with your mic, transcribed by faster-whisper on-device, and never leaves your machine.
mcp-name: io.github.JuhongPark/pronunciation
Voice MCP servers today treat speech as a typing replacement. English tutor MCP servers are text-only. This one combines the two: you speak freely, your assistant replies, and feedback on what you just said (pronunciation, grammar, fluency) surfaces inside the same tool call so the assistant can weave it into a natural reply — or stay out of the way when you're just chatting.
Related MCP server: brainiall-mcp-server
Voice conversation with your MCP assistant. Speak, auto-stop on silence, then let the assistant read your transcript and respond.
Phoneme-level drill feedback (when a reference sentence is given): Needleman-Wunsch word alignment, per-word expected vs produced IPA, learner-profile hints, minimal-pair drills, and prosody checks (word stress, final-rise intonation, intra-clause pauses).
Extensible learner-profile support: the current rule pack includes Korean-L1 pronunciation-pattern hints and Korean-language tips. Contributions for additional L1 profiles are welcome.
Whisper-bias mitigation via optional [phoneme] extra: wav2vec2 CTC forced alignment verifies whether the user actually produced each reference word, so rare proper nouns and domain-specific terms that Whisper rewrites toward more common alternatives no longer surface as mispronunciations.
Inline English feedback in conversation: pronunciation, grammar (common irregular-verb errors), and fluency (pace + long pauses).
Drill mode (practice, quick_practice, retry) for focused sentence practice.
Local-only: Whisper model runs on your machine, audio never leaves it.
Cross-platform: macOS, Linux, Windows, and WSL2 (recording auto-routes through Windows).
Fast startup: lazy imports + background model pre-load keep the MCP handshake under a second.
Python 3.11+
A working microphone
~150 MB disk space for the default Whisper model (base.en)
Additional ~360 MB if you install the optional [phoneme] extra (wav2vec2 weights for forced alignment)
MCP spec: targets 2025-06-18 via the official Python SDK (mcp>=1.2)
Install the latest stable release:
uvx mcp-server-pronunciationFor pip users:
pip install mcp-server-pronunciationTo pin this release explicitly:
uvx mcp-server-pronunciation@0.3.0Run doctor before relying on the server in a live session:
mcp-server-pronunciation doctor# Recommended: uvx (no global install, cached between runs)
uvx mcp-server-pronunciation
# Or install as a uv tool
uv tool install mcp-server-pronunciation
# Or pip
pip install mcp-server-pronunciation
# Optional: forced-alignment upgrade for Whisper-bias mitigation + tighter
# phoneme-level feedback. Adds ~200 MB of torch CPU wheels.
pip install 'mcp-server-pronunciation[phoneme]'sounddevice ships PortAudio inside the wheel on macOS and Windows, but on Linux you need the system library:
# Debian / Ubuntu
sudo apt-get install libportaudio2
# Fedora / RHEL
sudo dnf install portaudio
# Arch
sudo pacman -S portaudio
# PipeWire-only systems may also need
sudo apt-get install pipewire-alsaBefore wiring the server into an MCP client, run the preflight:
uvx mcp-server-pronunciation doctorOptional — pre-download the Whisper model (~150 MB) so the first call is instant:
uvx mcp-server-pronunciation pull-model base.encodex mcp add pronunciation -- uvx mcp-server-pronunciationclaude mcp add pronunciation -- uvx mcp-server-pronunciationEdit claude_desktop_config.json:
{
"mcpServers": {
"pronunciation": {
"command": "uvx",
"args": ["mcp-server-pronunciation"]
}
}
}On macOS, if Claude Desktop can't find uvx (spawn uvx ENOENT), use an absolute path. Find it with which uvx in your terminal.
Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"pronunciation": {
"command": "uvx",
"args": ["mcp-server-pronunciation"]
}
}
}Add to .vscode/mcp.json or your user settings:
{
"servers": {
"pronunciation": {
"type": "stdio",
"command": "uvx",
"args": ["mcp-server-pronunciation"]
}
}
}You: "Let's have a voice chat. I'll ask you about the weekend. Use the converse tool."
Assistant (calls
converse): records your speech, transcribes it, notes that you said "buyed" instead of "bought"Assistant: "Oh nice — what kind of apples did you buy? And by the way, the past tense of 'buy' is 'bought' — small thing, but I noticed it."
You: "Give me a sentence to practice with 'th' sounds."
Assistant (calls
suggest_sentencewithfocus=th): "Try this: The three brothers thought thoroughly about their future."You: "Record me reading it."
Assistant (calls
practicewith that reference): returns an alignment table (match / sub / ins / del) with per-word acoustic confidence when the[phoneme]extra is installed, phoneme-level issues with expected vs produced IPA, learner-profile hints when applicable, minimal-pair drills, and prosody notes (word stress, final-rise intonation, intra-clause pauses).
You: "Let me try again."
Assistant (calls
retry): re-records the same target sentence and compares
Tool | Purpose |
| Primary. Record + transcribe + quick feedback + assistant guidance for natural voice-chat-with-coaching. |
| Drill mode: record user reading a specific reference sentence, return detailed assessment. |
| Pick a random sentence (by phoneme focus + difficulty) and drill it. |
| Re-record the last sentence and compare the new attempt against the previous one. |
| Open the MCP Apps voice panel when the client supports embedded UI. |
| Analyze WAV audio uploaded by the voice panel and store it as the latest voice capture. |
| Start recording in the background and return a session id immediately. |
| Check whether a background capture is recording, analyzing, done, cancelled, or failed. |
| Wait for a background capture to finish and return transcript + feedback. |
| Return the most recent background voice capture result. |
| Mark a background capture as cancelled before analysis starts. |
| Return a practice sentence without recording. |
| Record audio and save a WAV file (raw, no analysis). |
| Assess the last recording (or a specified WAV) without re-recording. When given a reference, runs the full drill pipeline (alignment, phoneme diff, learner-profile hints, prosody). |
| List available audio input devices. |
Tools that assess speech also return structured MCP output with transcript,
clarity_pct, speaking_rate_wpm, top_issue, next_action,
retry_comparison, the full machine-readable assessment, and the rendered
report_markdown. MCP clients can use the structured result to offer a retry,
surface the top issue, or build a richer practice UI without parsing Markdown.
For MCP clients without an embedded voice UI, use the background capture tools to keep the user informed:
start_voice_capture(duration=8, mode="conversation")
voice_capture_status(session_id)
wait_for_voice_capture(session_id, timeout=30)
latest_voice_capture()The status response includes recording, analyzing, done, error, or
cancelled, plus elapsed time, transcript, clarity, speaking rate, feedback
markdown, and the full structured assessment when available. On WSL2, keep
duration short because PowerShell recording may wait for the full requested
duration before analysis begins.
Clients that support MCP Apps can call open_voice_panel to render the
ui://pronunciation/voice-panel resource. The panel requests browser
microphone access, records locally in the browser, uploads a WAV clip through
analyze_uploaded_audio, and displays the returned transcript and feedback.
The uploaded clip is stored in the same voice session registry as MCP-only
recordings, so assistants can call latest_voice_capture after the panel
finishes and respond to both the development note and the pronunciation
feedback. Clients without MCP Apps support should use the visible
voice-capture workflow above.
MCP clients that expose server prompts can start common workflows directly:
Prompt | Purpose |
| Start a local voice conversation with light feedback. |
| Run a short suggested-sentence practice loop. |
| Start a drill for a chosen focus and difficulty. |
| Inspect microphone devices and recording settings. |
Set MCP_PRONUNCIATION_MODEL to pick a different model size:
# Default — fast, English-only (~150 MB)
export MCP_PRONUNCIATION_MODEL=base.en
# Smaller / faster (~75 MB)
export MCP_PRONUNCIATION_MODEL=tiny.en
# More accurate (~470 MB)
export MCP_PRONUNCIATION_MODEL=small.en
# Multilingual options (larger)
export MCP_PRONUNCIATION_MODEL=small
export MCP_PRONUNCIATION_MODEL=mediumAvailable: tiny, tiny.en, base, base.en, small, small.en, medium, medium.en, large-v3, large-v3-turbo. For English-only use, the .en variants are faster and more accurate at a given size.
GPU (CUDA 12 + cuDNN 9) is auto-detected when available; otherwise runs on CPU with int8 quantization.
By default Whisper weights are cached in ~/.cache/huggingface/hub/. Override with HF_HUB_CACHE:
export HF_HUB_CACHE=/path/to/cacheBy default the server preloads the Whisper model in the background after the
MCP handshake starts. Set MCP_PRONUNCIATION_PRELOAD=0 for registry
inspection, Docker smoke tests, or other environments that only need tool
discovery and should avoid model downloads:
export MCP_PRONUNCIATION_PRELOAD=0Recordings are written as temporary WAV files so assess can inspect the last
recording. By default they are removed when the server process exits:
export MCP_PRONUNCIATION_AUDIO_RETENTION=sessionSet MCP_PRONUNCIATION_AUDIO_RETENTION=keep if you want temporary recordings
to remain on disk for manual inspection.
By default the server uses your system default microphone. Native
sounddevice recording stops after 1.5 seconds of detected silence. WSL2
records through Windows PowerShell and may wait for the full requested
duration, so use a short duration value for quick voice checks. You can
override native recording behavior:
# Use a specific input device index or name from the `check_mic` tool
export MCP_PRONUNCIATION_INPUT_DEVICE=1
# Options: low, normal, high
# high helps soft speakers; low is better in noisy rooms
export MCP_PRONUNCIATION_VAD_SENSITIVITY=high
# Seconds of silence before auto-stop, clamped to 0.3-5.0
export MCP_PRONUNCIATION_SILENCE_DURATION=2.0Run check_mic to see the default input device, available device indexes, and
the active VAD settings.
# Codex CLI
codex mcp add --env MCP_PRONUNCIATION_MODEL=small.en pronunciation -- uvx mcp-server-pronunciation
# Claude Code
claude mcp add pronunciation -e MCP_PRONUNCIATION_MODEL=small.en -- uvx mcp-server-pronunciationInstalling mcp-server-pronunciation[phoneme] enables wav2vec2-based CTC forced alignment. It verifies which reference words the user acoustically produced, regardless of how Whisper's language-model-weighted decoder rewrote them — so rare proper nouns and domain terms no longer surface as false mispronunciations. On first run the extra downloads ~360 MB of weights into ~/.cache/torch/hub/ (override via TORCH_HOME). Inference is CPU-only by default and runtime-quantized to int8 (~95 MB RAM).
Without the extra, assess / practice still run the full pipeline except for the forced-alignment step: you get Needleman-Wunsch word alignment against the Whisper hypothesis, CMUdict phoneme-sequence diff, learner-profile hints, and prosody.
Platform | Recording method | Status |
macOS | sounddevice (bundled PortAudio) | Supported |
Linux | sounddevice (needs | Supported |
Windows | sounddevice (bundled PortAudio) | Supported |
WSL2 | PowerShell MCI (winmm.dll) | Supported |
WSL2 note: WSLg's PulseAudio does not forward microphone audio from the Windows host. This server detects WSL2 automatically and records through PowerShell on the Windows side instead. WSL2 recording may wait for the full requested duration instead of auto-stopping on silence.
uvx mcp-server-pronunciation doctor is your first stopIt reports on PortAudio, input devices, Whisper model cache, pronunciation resources, optional forced-alignment dependencies, free disk space, and Python version. Run it whenever something feels off.
sounddevice import fails on LinuxYou're missing libportaudio2. See the install section above. After installing:
uvx mcp-server-pronunciation doctormacOS: System Settings → Privacy & Security → Microphone. Grant access to the app that launched your MCP client, such as Codex CLI, Claude Desktop, or Claude Code.
Linux: Check pavucontrol (PulseAudio) or pw-cli list-objects (PipeWire) for input levels. On PipeWire-only systems, install pipewire-alsa.
WSL2: Test your mic in Windows Settings → Sound → Input. The server records through Windows, not through WSLg.
The Whisper model downloads on first use (~150 MB for base.en). Pre-download it once:
uvx mcp-server-pronunciation pull-model base.enSubsequent runs reuse the cached weights. If startup still feels slow, try MCP_PRONUNCIATION_MODEL=tiny.en.
spawn uvx ENOENTClaude Desktop launches MCP servers from a GUI-only environment without ~/.local/bin on PATH. Use the absolute path to uvx in your config (/Users/YOU/.local/bin/uvx or wherever which uvx reports).
This is a stable package release, but the pronunciation and prosody feedback remain experimental coaching signals. Bugs, runtime errors, inaccurate feedback, and platform-specific recording issues can still occur.
Pronunciation scores are coaching signals, not standardized-test, clinical, or native-speaker-equivalence judgments.
Whisper can still mishear rare names, domain terms, short clips, quiet audio, or heavily accented speech. The optional [phoneme] extra reduces some reference-sentence false positives but does not eliminate them.
Prosody feedback is heuristic. Pitch tracking can be unreliable with noisy audio, very short utterances, vocal fry, overlapping speech, or clipped recordings.
Learner-profile hints are intentionally rule-based. The current package includes Korean-L1 hints, but they can miss errors, over-trigger on ASR mistakes, and should be treated as targeted practice aids. Contributions for additional L1 profiles are welcome.
First-time setup may download model or pronunciation resources. Run doctor and pull-model before relying on the server in a live session.
Temporary WAV recordings are written under the system temp directory so that the last recording can be assessed. By default they are removed when the server exits. Set MCP_PRONUNCIATION_AUDIO_RETENTION=keep if you want to inspect them later.
This project is moving toward benchmark-backed scoring. Planned public benchmark work is tracked in ROADMAP.md, the testing methodology lives in docs/TESTING.md, and the current benchmark helper docs live in docs/BENCHMARKS.md. The primary candidate is Speechocean762 because it has a permissive CC BY 4.0 license and multi-level expert pronunciation scores. L2-ARCTIC is useful for phone-error and learner-profile research checks, including Korean-L1 subset review, but its non-commercial license means it should remain optional and separate from default release claims.
The source repository is public. PyPI, GitHub Release, and MCP Registry publication steps are tracked in docs/PUBLICATION.md.
All audio processing happens locally on your machine.
Recordings are temporary .wav files under your system temp directory ($TMPDIR) and are removed when the server exits unless MCP_PRONUNCIATION_AUDIO_RETENTION=keep is set.
The Whisper model runs locally — no audio data is sent to any external service.
When the optional [phoneme] extra is installed, the wav2vec2 forced aligner also runs locally. Weights are downloaded once from the PyTorch Hub.
No telemetry. No analytics. No network calls except the one-time model weight downloads (Whisper from Hugging Face, wav2vec2 from PyTorch Hub).
git clone https://github.com/JuhongPark/mcp-server-pronunciation.git
cd mcp-server-pronunciation
uv sync --extra dev
uv run pytest -v
uv run ruff check .
uv run ruff format --check .To work on the optional wav2vec2 forced-alignment path, install the phoneme extra as well:
uv sync --extra dev --extra phonemeIssues: https://github.com/JuhongPark/mcp-server-pronunciation/issues
MIT. See LICENSE.
Third-party components (all MIT / permissive):
faster-whisper — MIT
OpenAI Whisper models — MIT
CTranslate2 — MIT
sounddevice — MIT
PortAudio — MIT
cmudict — BSD
g2p-en — Apache 2.0
librosa — ISC
Optional ([phoneme] extra): PyTorch — BSD, torchaudio — BSD, wav2vec2 weights — MIT
Assess the last recording (or a specific audio file) without re-recording.
When reference_text is provided, the assessor:
Aligns the user's speech to the reference word-by-word (Needleman-Wunsch; single deletions/insertions no longer cascade into phantom substitutions).
Runs wav2vec2 CTC forced alignment to verify which reference words the user actually produced — mitigates Whisper-bias mistranscriptions on rare proper nouns and domain terms by checking acoustic evidence against the reference directly.
Surfaces per-word phoneme-level feedback (expected vs produced IPA, weak phonemes) from CMUdict.
Surfaces learner-profile pronunciation hints and drills. The bundled rule pack currently includes Korean-L1 patterns such as r/l, th→s, final cluster deletion, and intrusive onset vowel.
Adds prosody notes: word-stress placement, sentence-final rising intonation on declaratives, intra-clause hesitation pauses.
Without a reference, only the transcript and prosody run.
Args: reference_text: Expected text the user was trying to say (optional). audio_path: Path to a WAV file. Uses the last recording if not specified.
Returns: Detailed pronunciation assessment report (markdown).
| Name | Required | Description | Default |
|---|---|---|---|
| reference_text | No | ||
| audio_path | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description is highly transparent, detailing algorithms (Needleman-Wunsch, wav2vec2 CTC), bias mitigation, phoneme feedback, learner profiles, and prosody notes. It fully discloses behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points, each providing unique information. It front-loads the main purpose and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description adequately covers inputs and output format (markdown report). It is complete for agent invocation, covering optional parameters and behavior differences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema (which has 0% coverage). It explains reference_text as expected text and audio_path as optional WAV path defaulting to last recording, providing context and usage examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assesses the last recording or a specific audio file without re-recording, using the verb 'assess' and resource 'audio'. It distinguishes from sibling tools like 'record' and 'practice' by focusing on evaluation rather than creation or interactive practice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use reference_text (for alignment and phoneme feedback) and what happens without it (only transcript and prosody). However, it does not explicitly exclude usage scenarios or mention alternative tools like 'converse' or 'check_mic'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available audio input devices and verify microphone access.
Use this if the user reports recording problems — it shows which devices are available and which one is the default.
Returns: List of available microphone devices.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it lists devices and verifies access, returns a list. With no annotations, more detail (e.g., permissions required, read-only nature) would improve transparency, but the simplicity reduces gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose and usage guidance. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and usage adequately for a zero-parameter tool with output schema. Could mention prerequisites like permissions, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4. No additional parameter info needed; description focuses on tool purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists audio input devices and verifies microphone access, and mentions showing the default device. This distinguishes it from siblings like 'record' which records audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this if the user reports recording problems', providing clear context for when to use. No explicit when-not-to or alternatives, but implied by sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the user speaking, transcribe it, and return the transcript plus quick English feedback. This is the primary tool for voice conversations: call it, read the transcript + feedback, then respond conversationally in your own words — weaving the feedback in naturally or mentioning it only if it matters.
Recording auto-stops when the user finishes speaking (silence detection).
Use this tool when:
The user wants to chat with you by voice instead of typing
The user wants casual English feedback while talking with you
You want to hear what the user said rather than read a typed message
For a focused drill where the user reads a specific sentence, use practice
instead.
Args: target_hint: Optional. Only set this if the user is explicitly trying to say a specific sentence (e.g. they asked "how do I say X?" and you told them X). Leave blank for free-form conversation. duration: Maximum recording duration in seconds (default 30, max 120). Auto-stops earlier on silence.
Returns: Markdown report containing the user's transcript, brief English feedback (pronunciation + grammar + fluency), and a 'For Claude' section with guidance on how to respond.
| Name | Required | Description | Default |
|---|---|---|---|
| target_hint | No | ||
| duration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations exist, the description explains key behaviors: auto-stop on silence, duration limits (default 30, max 120), and the components of the return value. It does not mention privacy or authentication, but for a recording tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, auto-stop note, usage list, and parameter details. It is slightly verbose but every sentence serves a purpose; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adds value by explaining the return content (transcript, feedback, guidance) and usage context. It covers the tool's role among siblings adequately, though it could detail edge cases like long silences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining both parameters: target_hint (optional, for specific sentences) and duration (default 30, max 120, auto-stop). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records user speech, transcribes it, and returns transcript plus English feedback. It distinguishes itself from the sibling 'practice' tool for focused drills, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use this tool (voice chats, casual feedback) and when to use an alternative (use 'practice' for focused drills). This provides clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drill mode: the user reads a specific sentence aloud and gets a detailed pronunciation assessment. Use this when the user explicitly wants to practice reading a particular sentence, not for free-form chat.
For voice conversation with casual feedback, use converse instead.
Recording auto-stops when the user finishes speaking.
Args: reference_text: The sentence the user will read aloud. duration: Maximum recording duration in seconds (default 15, max 120).
Returns: Detailed pronunciation assessment report.
| Name | Required | Description | Default |
|---|---|---|---|
| reference_text | Yes | ||
| duration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-stop recording behavior and returns a detailed assessment. However, it could elaborate on processing time or privacy aspects. Overall, sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with clear sections: purpose statement, usage contrast, auto-stop detail, then structured args/returns. Every sentence is useful with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers use case, parameters, return, and differentiation from siblings. Could hint at required microphone access, but output schema exists, making it complete enough for an agent to act.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning to both parameters: reference_text is 'the sentence to read aloud', duration includes default and max values. Schema has 0% coverage, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for drill mode pronunciation assessment of a specific sentence, distinguishing it from free-form chat and sibling tools like 'converse'. The verb 'practice' directly conveys the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (explicit practice of a particular sentence) and when not to (free-form chat). Names the alternative 'converse' for casual feedback, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick a random practice sentence and drill it immediately.
Combines suggest_sentence + practice into one step: picks a sentence
matching the criteria, then records and assesses.
Args: focus: Phoneme focus area. Options: "th", "f_v", "r_l", "vowels", "general". If not specified, picks randomly. difficulty: Difficulty level. Options: "beginner", "intermediate", "advanced". If not specified, picks randomly. duration: Maximum recording duration in seconds (default 15, max 120).
Returns: The sentence to read, followed by the pronunciation assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | ||
| difficulty | No | ||
| duration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explains the tool picks a sentence based on criteria, records, and assesses. It notes that focus/difficulty are optional and duration defaults to 15 max 120. It could disclose more about side effects (e.g., saving recordings), but overall it's transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The first sentence states the purpose, the second explains the combination, and the Args section lists parameters with options. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters and an output schema. The description covers the main behavior and return value. It could mention what happens with invalid inputs, but given the simple nature, it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides full explanations for all three parameters: focus options, difficulty options, and duration default and max. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'picks a random practice sentence' and 'drills it immediately', using specific verbs and resource. It distinguishes from siblings like 'suggest_sentence' and 'practice' by combining both steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool combines two steps, implying it's for when you want both suggestion and practice. However, it does not explicitly state when not to use it (e.g., if you want to select a sentence manually) or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record audio from the microphone without assessing it.
Recording auto-stops when the user finishes speaking (silence detection). The duration is the maximum time — you don't have to wait the full duration.
Most of the time prefer converse or practice, which record AND analyze
in one step. Only use record alone if you want the raw WAV file.
Args: duration: Maximum recording duration in seconds (default 10, max 120).
Returns: Path to the recorded WAV file.
| Name | Required | Description | Default |
|---|---|---|---|
| duration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auto-stop on silence detection, duration as maximum, and raw WAV return. No annotations provided, so description carries full burden; it covers key behaviors but could mention if recording requires mic permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, then auto-stop, duration clarification, usage guidance, and explicit args/returns. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completes all needed context: purpose, behavior, parameter meaning, return type, and comparative guidance. Sufficient for a simple tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema lacks parameter description (0% coverage). Description provides meaning: duration is max recording time in seconds, with default 10 and max 120, adding essential context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it records audio from the microphone, auto-stops on silence, and returns a WAV file. It distinguishes from siblings 'converse' and 'practice' by noting they also analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring 'converse' or 'practice' for combined recording and analysis, using 'record' only for raw WAV. Also explains duration as max time not requiring full wait.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry the last sentence the user was practicing.
Re-records and re-assesses using the same reference text from the previous
practice or converse call. Use this to let the user try again after
getting feedback.
Args: duration: Maximum recording duration in seconds (default 15, max 120).
Returns: Pronunciation assessment report for the new attempt.
| Name | Required | Description | Default |
|---|---|---|---|
| duration | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses re-recording and re-assessing behavior and returns a report, but omits side effects, authentication needs, or rate limits. Adequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with purpose, and uses clear Args/Returns structure. Every sentence adds value with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers core behavior, parameter, and return value. Given output schema exists, return explanation suffices. Could expand on prerequisite of prior call, but overall adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description compensates by explaining 'duration' as 'Maximum recording duration in seconds (default 15, max 120),' adding meaning beyond type and default. No other parameters to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retries the last practiced sentence by re-recording and re-assessing using the same reference text from a previous 'practice' or 'converse' call. This specific action distinguishes it from siblings like 'practice' and 'converse'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes 'Use this to let the user try again after getting feedback,' providing clear context for when to invoke. It implies a prior call exists but does not explicitly state prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest a practice sentence the user can read aloud.
Args: focus: Phoneme focus area. Options: "th", "f_v", "r_l", "vowels", "general". If not specified, picks randomly. difficulty: Difficulty level. Options: "beginner", "intermediate", "advanced". If not specified, picks randomly.
Returns: A practice sentence with its focus area and difficulty.
| Name | Required | Description | Default |
|---|---|---|---|
| focus | No | ||
| difficulty | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that parameters have random defaults but does not discuss other behavioral aspects such as sentence generation source, repetition avoidance, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise purpose statement followed by Args and Returns sections, each providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and presence of output schema, the description covers purpose, parameters, and return value. However, it lacks details on how the sentence is generated (e.g., fixed set vs. dynamic) and any restrictions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description compensates by listing allowed values for 'focus' and 'difficulty', and explaining default behavior (random selection). This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'suggest' and the resource 'a practice sentence', with explicit purpose of reading aloud. It is distinct from sibling tools like 'practice' or 'record' which handle execution or recording.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for generating sentences but does not explicitly guide when to use this tool versus siblings like 'practice' or 'quick_practice'. No exclusion or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: check_mic for microphone setup, record for raw audio, practice for sentence drills, assess for detailed evaluation, converse for free-form conversation, quick_practice for random drills, retry for repeating, and suggest_sentence for generating sentences. No two tools overlap significantly in functionality.
Naming conventions are mixed: some tools use single verbs (assess, converse, practice, record, retry), while others use verb_noun with underscores (check_mic, suggest_sentence) and one uses adjective_verb (quick_practice). This inconsistency reduces predictability, though the names are still clear.
8 tools is a well-scoped number for a pronunciation practice server. It covers all essential workflows—microphone check, recording, assessment, practice, conversation, retry, and sentence suggestion—without being excessive or insufficient.
The tool set covers the full domain of pronunciation practice: checking audio input, recording, assessing with or without reference, free-form conversation, focused drills, random practice, retrying, and generating practice sentences. There are no obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Pronunciation scoring, speech-to-text, and text-to-speech for language learning
MCP server for Speech-to-Text
Pronunciation assessment, phoneme scoring, speaker voice ID, audio transcription, speech synthesis.
Coach your communication from your own recorded conversations: talk-time, questions, rapport, more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JuhongPark/mcp-server-pronunciation'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
