Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@voice-analysis-mcp Review ~/calls/support-0412.wav: who dominated the conversation?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives LLMs like Claude the tools to review and do qualitative analysis of call recordings, voice memos, TTS output, and other audio files — transcription, conversation dynamics, vocal delivery, recording quality, and visual inspection via spectrograms/waveforms.
Everything runs locally: ffmpeg for decoding, faster-whisper for transcription (models download on first use), librosa for signal analysis. No API keys required.
Tool | What it answers |
| What is this file? Duration, channels, sample rate, codec, tags. |
| What was said, when? Timestamped segments, optional word timing, per-channel (per-speaker) transcription for stereo calls, words-per-minute. |
| Who talks how much? Talk time and turns per channel, dead air, overlap, interruption counts, response latency (stereo calls: one speaker per channel). |
| How does it sound? Pitch median/range (monotone vs expressive), loudness and dynamic range, pace, pause/hesitation patterns for a window (≤ 300 s). |
| Can I trust this recording? Levels, clipping, noise floor, estimated SNR, narrowband detection, flagged issues. |
| Cut a key moment out to a standalone wav file. |
| A mel spectrogram image the model can look at — spot hold music, DTMF/beeps, hum, dropouts, TTS artifacts. |
| Per-channel waveform image — speaker activity, silences, level imbalance at a glance. |
A typical call review: get_audio_info → analyze_conversation (whole file,
cheap) → transcribe (per channel for stereo) → analyze_prosody /
render_spectrogram on the interesting windows.
Related MCP server: voice-mcp-server
Python 3.11–3.13 and uv
ffmpeg on PATH (brew install ffmpeg)
uv sync
uv run pytest # optional: verifyWorking inside this repo, nothing to configure: the checked-in .mcp.json
registers the server automatically (approve it when prompted). From any other
project, register it globally:
claude mcp add --scope user voice-analysis -- uv run --directory /path/to/voice-analysis.mcp voice-analysis-mcpclaude_desktop_config.json){
"mcpServers": {
"voice-analysis": {
"command": "uv",
"args": ["run", "--directory", "/path/to/voice-analysis.mcp", "voice-analysis-mcp"]
}
}
}The model only needs a file path — every tool takes an absolute path to a local audio file, so "analyze the call in ~/Downloads/call-4711.mp3" is enough to start. The server's instructions steer the model through the intended flow:
get_audio_info — learn duration and channel count (drives everything else)
analyze_conversation — cheap whole-file pass: talk balance, dead air, interruptions
transcribe — content, per channel on stereo calls for who-said-what
analyze_prosody / analyze_quality / render_spectrogram on windows the
first passes flagged — all results use absolute seconds, so findings from
different tools line up
Example prompts that work end-to-end:
Review ~/calls/support-0412.wav: who dominated the conversation, were there awkward silences, and how did the agent's tone change after the customer pushed back?
Compare the TTS output in v1.wav and v2.wav — which sounds less monotone and are there any audible artifacts?
Results are compact JSON (rounded numbers, capped lists) sized for a model's context window; images come back as MCP image content Claude can view directly.
Stereo = per-speaker. Telephony platforms typically export calls with one
speaker per channel. Tools take a channel parameter to isolate a speaker;
analyze_conversation uses both channels for interruption/overlap/latency
metrics. Mono recordings fall back to overall speech/silence dynamics —
model-based diarization (e.g. pyannote) is a possible future addition.
Whisper models: tiny/base/small/medium/large-v3/large-v3-turbo,
cached under the Hugging Face cache dir after first download. base is the
default trade-off; use small+ for noisy telephone audio.
Windows over whole files for the expensive analyses: prosody is capped at
300 s and images at 600 s per call — pass start_time/end_time. All
timestamps in results are absolute seconds into the file, so findings from
different tools line up.
Any input format works if ffmpeg can decode it, including pulling the audio track out of video files.
Measure conversation dynamics: talk time per channel, turns, dead air, overlap.
On stereo call recordings (one speaker per channel) this also reports
interruption counts per side, overlap ratio, and response latency —
who dominates, who interrupts, how quickly each side responds. On mono
audio only overall speech/silence dynamics are available. Cheap to run
on a whole recording; a good early step for call review.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| end_time | No | ||
| start_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It reveals that the tool is cheap to run, and clarifies that stereo recordings yield interruption counts while mono only provides overall dynamics. No destructive or restricted behaviors are hinted at, which is reasonable given the analysis nature.
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 front-loaded with the core purpose in the first sentence, followed by additional details. It avoids redundancy but could be slightly more concise; the second paragraph could be merged with the first. Overall, it efficiently conveys key information.
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 output schema, the description lists expected metrics (talk time, turns, etc.) but does not specify return format or structure. It also omits parameter semantics. For a tool with 3 parameters and moderate complexity, it is reasonably complete but has gaps.
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%, and the description does not mention any of the three parameters (path, start_time, end_time). It adds no meaning about required input or optional time constraints, leaving the agent to infer parameter usage from context alone.
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 'Measure conversation dynamics: talk time per channel, turns, dead air, overlap', specifying the precise verb and resource. It distinguishes between stereo and mono capabilities, and its focus on conversation dynamics differentiates it from siblings like 'analyze_prosody' and 'analyze_quality'.
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 notes 'Cheap to run on a whole recording; a good early step for call review', providing context on when to use it. However, it does not explicitly exclude cases or compare with alternatives for similar tasks, falling short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Measure vocal delivery in a window (max 300s): pitch, energy, pace, pausing.
Returns pitch statistics (median, range in semitones — low range means
monotone delivery), loudness/dynamic range, speech ratio, and pause
patterns (hesitations). Use on specific moments found via transcription or
conversation analysis — e.g. compare an agent's delivery early vs late in a
call, or check whether TTS output sounds flat. Pass channel to isolate one
speaker on stereo recordings.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| channel | No | ||
| end_time | No | ||
| start_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses key behaviors: max 300s window, returns pitch stats, loudness, speech ratio, pause patterns, and channel isolation for stereo. It also clarifies that low pitch range indicates monotone delivery.
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 (3 sentences) and front-loaded with the core purpose. Every sentence adds value, with no 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?
Despite no output schema, the description fully details return values (pitch stats, loudness, etc.) and provides usage examples. It is complete for the tool's moderate complexity.
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 input schema has no parameter descriptions (0% coverage), but the description adds meaning for channel (isolate speaker) and implicitly for start_time/end_time via 'window'. Path is not elaborated but is typical. The description compensates well for the schema gap.
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 measures vocal delivery (pitch, energy, pace, pausing) in a window. It distinguishes from siblings like transcribe or analyze_conversation by focusing on prosodic features.
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 provides explicit use cases (e.g., comparing delivery early vs. late in a call, checking TTS flatness) and context for use on specific moments, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess recording quality: levels, clipping, noise floor, estimated SNR.
Flags common problems (clipping, very low level, high background noise,
narrowband telephone audio). Run this before drawing conclusions from other
analyses — poor quality audio degrades transcription and pitch tracking.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| end_time | No | ||
| start_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists what is flagged (clipping, low level, noise, narrowband) but lacks detail on behavioral aspects like output format, side effects, or thresholds. Adequate but incomplete.
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?
Two efficient sentences with no fluff. The purpose is front-loaded in the first sentence, and the usage guidance is in the second. Every sentence earns its place.
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?
Tool has 3 params, no output schema, and no annotations. Description covers purpose and usage context but omits parameter details and output behavior (e.g., what the flags look like). Not fully complete for a tool with this complexity.
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%, and the description does not mention any of the three parameters (path, start_time, end_time). It adds no meaning beyond the schema, failing to compensate for the coverage gap.
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 recording quality with specific aspects (levels, clipping, noise floor, SNR) and flags common problems. It distinctively focuses on quality assessment among sibling tools like transcribe or get_audio_info.
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 instructs to run this before other analyses because poor quality degrades transcription and pitch tracking, providing clear context for when to use. Does not list explicit alternatives or when not to use, but the priority guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cut a time range out of a recording into a standalone wav file.
Useful for isolating a key moment (an objection, an escalation, a TTS
artifact) to share or analyze further. Returns the path of the new file;
if output_path is omitted the file is written next to the source.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| end_time | Yes | ||
| start_time | Yes | ||
| output_path | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that the tool returns the path of the new file and defaults to writing next to the source if output_path is omitted. It does not mention non-destructive nature, but the behavior is clear enough.
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?
Two sentences, no wasted words. First sentence states action and result; second provides usage context and default behavior. Excellent structure for quick agent comprehension.
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 output schema and no annotations, the description covers purpose, return value, and default output location. Missing details like unit specification and edge cases, but adequate for a simple extraction tool among similar audio siblings.
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 is expected to explain parameters. It clarifies output_path's default but fails to specify units for start_time and end_time (likely seconds), and does not detail validation or range constraints. Partial compensation but incomplete.
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 cuts a time range from a recording into a standalone wav file, with specific use cases like isolating objections or artifacts. This distinguishes it from sibling tools like transcribe or render_spectrogram, which have different purposes.
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 it is useful for isolating key moments for sharing or analysis, giving clear context for when to use it. However, it does not explicitly state when not to use it or compare with alternatives like using get_audio_info for metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata for an audio/video file: duration, channels, sample rate, codec, tags.
Call this first for any new file — duration tells you how to window later
analyses, and channels tells you whether per-speaker (stereo) analysis is possible.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that it returns metadata only (read behavior). Mentions no side effects or destructive actions, which is appropriate for a metadata tool. Slight room to mention if file access requires specific permissions, but 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?
Two sentences with no filler. First sentence states purpose and output. Second sentence provides usage guidance. Front-loaded and efficient.
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 single parameter and no output schema, description covers output (list of metadata types) and usage rationale. Agent can understand when to invoke and what to expect.
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?
Single parameter 'path' with 0% schema description coverage. Description does not explain what path expects (e.g., local file, URI, allowed formats). Agent must infer from context that it's a file path, but lacks explicit guidance.
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 'Get metadata for an audio/video file' listing specific fields (duration, channels, sample rate, codec, tags). It distinguishes from sibling tools by positioning itself as the first call.
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 instructs 'Call this first for any new file' and explains why: duration informs windowing later, channels determines per-speaker analysis. Provides clear context and when-not-to-use alternatives implicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a mel spectrogram image of a window (max 600s) for visual inspection.
Look at this to spot things metrics miss: hold music, DTMF/beep tones,
hum, dropouts, TTS glitches, where energy concentrates. Time axis is in
absolute seconds so findings map back to transcript timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| channel | No | ||
| end_time | No | ||
| start_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the max window size and that the time axis is in absolute seconds, but does not mention whether the tool is read-only, auth requirements, or output format. Adequate but not comprehensive.
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?
Two sentences: first states purpose and constraint, second explains usage and time axis. No unnecessary words, front-loaded with key information.
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 4 parameters and no output schema, the description does not specify the output format (e.g., image file, URL), error handling, or details on all parameters. Incomplete for an agent to invoke correctly without additional inference.
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%, so the description must compensate. It adds meaning to start_time and end_time by mentioning the window limit and absolute seconds, but does not explain path or channel. Partial compensation.
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 renders a mel spectrogram image for visual inspection of audio windows up to 600 seconds, with a specific verb and resource. It distinguishes from sibling tools like render_waveform by emphasizing the mel spectrogram and use case for spotting anomalies.
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 tells when to use the tool: to spot issues that metrics miss (hold music, DTMF, hum, etc.). It does not mention when not to use or compare directly with siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a waveform image (max 600s), one row per channel.
On stereo call recordings the two rows show each speaker's activity at a glance — useful for spotting long silences, who talks when, clipping, and level imbalance between sides.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| end_time | No | ||
| start_time | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses max duration and per-channel rows, but lacks details on error handling (e.g., what happens if duration exceeds 600s), output format (e.g., PNG, dimensions), supported file types, or performance implications. No annotations provided.
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?
Two sentences, front-loaded with core action and constraint. Second sentence adds value with example use cases, but could be more concise by integrating key details about parameters.
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 absence of output schema and annotations, description should cover return format, error behavior, and parameter usage. It only partially addresses duration limits and channel layout, leaving significant gaps for an agent to use correctly.
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?
Does not explain the three parameters (path, start_time, end_time) beyond what is in the schema. Schema coverage is 0%, so description should clarify their purpose and defaults, but it omits any parameter-specific guidance.
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?
Clearly states the tool renders a waveform image with specific constraints (max 600s, one row per channel). Distinguishes from sibling tools like render_spectrogram by focusing on waveform visualization.
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?
Describes use cases (spotting silences, clipping, level imbalance) and implies utility for stereo recordings, but does not explicitly say when not to use it or mention alternatives like render_spectrogram for frequency analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe speech to timestamped text using a local Whisper model (no API key).
Returns segments with start/end times plus detected language and overall
words-per-minute. On stereo call recordings, pass channel=0 or channel=1 to
transcribe one speaker at a time and interleave the results by timestamp for
an accurate who-said-what transcript. model_size: tiny/base/small/medium/
large-v3/large-v3-turbo — larger is more accurate but slower; the model is
downloaded on first use. word_timestamps=True adds per-word timing (useful
for locating exact moments, at some cost in output size).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| channel | No | ||
| end_time | No | ||
| language | No | ||
| model_size | No | base | |
| start_time | No | ||
| word_timestamps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: local model (no API key), return structure (segments with times, language, WPM), first-use model download, and channel behavior. Fully compensates for missing annotations.
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?
Front-loaded with purpose and key info, followed by detailed parameter guidance. Slightly dense but efficient; minimal 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?
Covers main functionality and crucial usage details, but omits descriptions for start_time, end_time, and language parameters. Without an output schema, the return structure is only partially described (segments, language, WPM).
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?
Explains channel, model_size, and word_timestamps well, adding meaning beyond the schema. However, start_time, end_time, and language parameters are not described, and path is only implied. Given 0% schema coverage, more completeness is needed.
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 transcribes speech to timestamped text using a local Whisper model, distinguishing it from sibling tools like analyze_conversation or get_audio_info.
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?
Provides explicit guidance on handling stereo recordings by selecting a channel and interleaving results. Also explains model size trade-offs and word_timestamps usage, but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_conversationanalyze_prosodyanalyze_qualityextract_segmentget_audio_inforender_spectrogramrender_waveformtranscribeEach tool targets a distinct aspect of voice analysis: metadata, transcription, conversation dynamics, prosody, quality, segment extraction, and two visualizations. Descriptions clearly differentiate their purposes, leaving no ambiguity.
Most tools follow a consistent verb_noun pattern (get_audio_info, analyze_conversation, render_spectrogram), but 'transcribe' is a single verb outlier, slightly breaking the pattern. Overall, naming is mostly predictable and clear.
With 8 tools, the server covers a well-scoped range of voice analysis capabilities—from metadata to transcription to advanced metrics and visualizations—without unnecessary redundancy or bloat.
Core workflows for audio analysis are covered (info, transcription, conversation dynamics, prosody, quality, segment extraction, visualizations). A minor gap is lack of explicit speaker diarization beyond stereo transcription, but the set is largely complete for typical analysis tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search speech in podcasts, government meetings, and your own audio: speakers, entities, timestamps.
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Hosted speech-to-text + speech emotion/tone analysis for agents. No install; trial keys built in.
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/Patience-dot-devl/Voice-analysis.mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
