Click on "Deploy 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., "@live-audio-intelligence-mcp Monitor Apple's Q3 earnings call and analyze speaker stress"
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.
MCP server for live financial webcast transcription and heuristic vocal stress analysis.
Turns any live webcast URL (earnings calls, CNBC, investor days) into a real-time pipeline that feeds an LLM two things simultaneously:
A rolling transcript via faster-whisper (CPU, int8).
A heuristic vocal stress score (0–100) derived from F0 pitch jitter, hesitation ratio, and voiced-frame fraction. These prosodic features are well-established correlates of speaker arousal in the vocal-analysis literature; their composition into the score below is heuristic and has not been empirically validated against market outcomes. Treat it as a coarse signal, not an oracle.
Built on the Model Context Protocol. Exposes 4 tools over stdio; drop it into Claude Desktop, Claude Code, or any MCP client.
Sell-side analysts and hedge-fund PMs don't just want to read the earnings transcript after the fact — they want a real-time signal about how confident the CFO sounds when asked about Q4 guidance. This server wires a Whisper pipeline and a pYIN-based prosody analyzer directly into an LLM's tool loop, so the model can ask "what did the CEO just say about China?" and "how stressed did they sound saying it?" in the same conversation.
Related MCP server: EarningsCalls MCP Server
FFmpeg is a system binary, not a Python package. The ffmpeg-python
wrapper is not a dependency here — we drive the binary directly via
subprocess. You must install it yourself.
macOS (Homebrew):
brew install ffmpegLinux (Debian / Ubuntu):
sudo apt-get update && sudo apt-get install -y ffmpegLinux (Fedora / RHEL):
sudo dnf install -y ffmpegWindows — choose one:
# Option A — winget (Windows 10/11)
winget install --id=Gyan.FFmpeg -e
# Option B — Chocolatey
choco install ffmpeg
# Option C — Scoop
scoop install ffmpegConfirm it's on your PATH:
ffmpeg -versionIf the command errors with "not found", reopen the terminal (PATH changes
don't propagate to already-open shells) or add the ffmpeg bin/ directory
to your PATH manually.
Requires Python ≥ 3.10.
pip install live-audio-intelligence-mcpOr run directly without installing with uv:
uvx live-audio-intelligence-mcpThe first run will download the faster-whisper base.en model (~140 MB) from
Hugging Face and cache it under ~/.cache/huggingface/.
Stdio MCP server:
live-audio-intelligence-mcpOr equivalently:
python -m live_audio_intelligence_mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"live-audio-intelligence": {
"command": "live-audio-intelligence-mcp"
}
}
}claude mcp add live-audio-intelligence -- live-audio-intelligence-mcpTool | Purpose |
| Resolve the audio URL, spawn ffmpeg, start chunking + transcription. Returns a |
| Get the last N minutes of concatenated transcript text. |
| Run prosody analysis over the last N seconds of audio. Returns stress score, pitch jitter, hesitation ratio, pause stats, and a human-readable interpretation. |
| Kill ffmpeg, clean up temp files, drop the transcript buffer. |
Score | Interpretation |
0–20 | Confident, fluent delivery |
20–45 | Normal variation |
45–75 | Elevated stress — worth monitoring |
75–100 | High stress — potential market-moving signal |
Composite of:
Pitch jitter (coefficient of variation of F0) — 50% weight, saturating at jitter = 0.12
Hesitation ratio (fraction of audio in pauses > 400 ms) — 35% weight, saturating at 0.30
Unvoiced fraction (speaker trailing off) — 15% weight
The three features are literature-backed correlates of speaker arousal (see pYIN for F0 tracking, and the broad "disfluency is a correlate of cognitive load" line of work). The weights and saturation points are hand-picked defaults, chosen so that a calm speaker scores in the 0–20 band on clean studio audio and visibly stressed speech scores ≥ 45 — they are not fit to any labeled dataset. Consumers who care about absolute numbers should recalibrate thresholds against their own recordings.
A synthetic-audio calibration harness lives at scripts/validate_stress_score.py. It generates controlled audio (smooth sine, jittered pitch, silence-padded speech) and asserts that the score responds in the expected direction. This is calibration evidence, not market-outcome validation.
For speakerphone audio (most earnings Q&A), pass disable_vad=true to
monitor_live_stream. Silero VAD tends to aggressively classify muddy
conference-call speech as silence; disabling it preserves more of the speech
at the cost of transcribing a bit more ambient noise.
By default the server caps concurrent streams at 4 (each stream holds an ffmpeg subprocess, a yt-dlp subprocess, a thread, and a temp directory). Override via env var for high-throughput deployments:
LAI_MAX_CONCURRENT_STREAMS=16 live-audio-intelligence-mcpExceeding the cap raises StreamLimitExceededError rather than silently
queuing.
┌──────────────────┐
URL ─────▶ │ yt-dlp resolve │
└────────┬─────────┘
│ audio URL
▼
┌──────────────────┐ ┌────────────────┐
│ ffmpeg (bg) │ ───▶ │ 15s WAV chunk │
│ 16kHz mono PCM │ │ queue │
└──────────────────┘ └───────┬────────┘
│
┌──────────────────┴────────────────┐
▼ ▼
┌──────────────────┐ ┌──────────────────┐
│ faster-whisper │ │ librosa.pyin │
│ (int8 / CPU) │ │ + pause detect │
└────────┬─────────┘ └────────┬─────────┘
│ rolling transcript │ stress score
▼ ▼
┌────────────── MCP stdio ───────────────┐
│ LLM (Claude) — calls tools freely │
└────────────────────────────────────────┘All blocking work (Whisper inference, ffmpeg I/O, librosa DSP) is dispatched
to threads via asyncio.to_thread so the MCP event loop stays responsive.
git clone https://github.com/ykshah1309/live-audio-intelligence-mcp
cd live-audio-intelligence-mcp
python -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
pytest
live-audio-intelligence-mcpThe pytest suite in tests/ covers the pure-Python logic that doesn't require network or ffmpeg:
URL syntactic validation (scheme allow-list, host presence)
Concurrency-cap enforcement in StreamManager
Custom exception hierarchy (backward-compat with ValueError / RuntimeError)
Prosody analyzer on synthetic audio (sine tone, silence, jittered pitch)
pytest -qpython scripts/validate_stress_score.pyThis generates synthetic audio with known acoustic properties and verifies the stress score responds in the expected direction. It's a sanity check for the weighting heuristics — not a replacement for empirical validation against real earnings-call outcomes.
ffmpeg: command not found — ffmpeg isn't on PATH. See the install
section above. On Windows, reopen your terminal after installing.
yt-dlp could not resolve URL — The site isn't supported by yt-dlp
or the URL is malformed. Test with yt-dlp -F <url> from the command
line; if that fails, the server will too.
Whisper downloads hang on first run — The ~140 MB model download goes
to ~/.cache/huggingface/. Check your network and Hugging Face access.
"Insufficient voiced frames" in stress output — The audio window is
mostly silence or noise. Usually means the stream is still buffering;
wait 30s and retry. For speakerphone Q&A, start the monitor with
disable_vad=true.
See CONTRIBUTING.md.
See CHANGELOG.md.
MIT — see LICENSE.
Analyse the speaker's vocal stress over a recent time window.
Extracts F0 pitch contour, measures pitch jitter (vocal tremor), and detects hesitation patterns (pauses > 400ms). Returns a composite stress score from 0–100 where:
0–20 = confident, fluent delivery 20–45 = normal variation 45–75 = elevated stress — worth monitoring 75–100 = high stress — potential market-moving signal
Higher scores correlate with executive nervousness, evasion, and uncertainty — the kind of prosodic signals that precede guidance revisions and earnings misses.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_id | Yes | ||
| time_window_seconds | No | Analysis window in seconds |
| Name | Required | Description |
|---|---|---|
| stream_id | Yes | |
| time_window_seconds | Yes | |
| stress_score | Yes | Composite vocal stress score 0-100 |
| pitch_mean_hz | Yes | Mean fundamental frequency in Hz |
| pitch_std_hz | Yes | Standard deviation of F0 |
| pitch_jitter | Yes | Normalised pitch jitter (coefficient of variation) |
| hesitation_ratio | Yes | Fraction of audio that is silence >400ms |
| voiced_fraction | Yes | Fraction of voiced frames |
| pause_count | Yes | Number of significant pauses detected |
| longest_pause_ms | Yes | Duration of longest pause in ms |
| analysis | Yes | Human-readable stress interpretation |
| chunks_analyzed | Yes | Number of audio chunks processed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the analysis process (pitch extraction, jitter, hesitation detection) and the meaning of the composite score. However, it does not mention side effects, data persistence, or permissions, but for a read-only analysis this is acceptable.
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 and concise, with a clear summary followed by feature list and score interpretation. The final speculative paragraph is slightly verbose but does not detract significantly.
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 output schema exists, so the description does not need to detail return format. It provides score ranges and feature explanation. Prerequisites (e.g., active stream) and error conditions are not mentioned, but overall sufficient for typical usage.
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 50% (only time_window_seconds has a description). The description adds context about the time window and pause threshold but does not explain stream_id beyond its necessity. Overall, moderate value added beyond 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 analyzes speaker vocal stress over a recent time window, details extracted features (F0 contour, jitter, hesitation patterns), and provides a composite stress score. This differentiates it from sibling tools which handle transcription or monitoring.
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 analyzing stress in a recent window of a live stream but lacks explicit guidance on when to use this tool versus siblings or prerequisites like stream activity. Score ranges provide context but no direct usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the rolling transcript from a monitored stream.
Returns the concatenated text from the last N minutes, ideal for feeding into an LLM for summarisation or sentiment analysis of the earnings call in progress.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_id | Yes | ||
| minutes_back | No | How many minutes of transcript to retrieve |
| Name | Required | Description |
|---|---|---|
| stream_id | Yes | |
| minutes_back | Yes | |
| text | Yes | Concatenated transcript text |
| segment_count | Yes | Number of transcript segments in window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'retrieves' and 'returns' text, implying a read operation, but does not disclose prerequisites (e.g., stream must be monitored), side effects, rate limits, or error conditions. The mention of 'monitored stream' hints at a prerequisite but is insufficient.
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 two sentences long, front-loaded with the action ('Retrieve'), and contains no redundant information. Every word contributes to understanding the tool's purpose and typical use.
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 (not shown), the description does not need to explain return values. However, it omits important context such as error conditions, prerequisites (e.g., stream must be monitored via monitor_live_stream), and behavior when no transcript is available. This leaves gaps for an AI agent.
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 50% (only minutes_back has a description). The tool description does not add any parameter details beyond what the schema provides. For example, stream_id is not described in the tool description, and minutes_back's description in schema is minimal. The description adds no extra semantic value.
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 retrieves rolling transcript from a monitored stream and returns concatenated text from the last N minutes, with a specific use case for LLM summarisation/sentiment. This distinguishes it from siblings like analyze_speaker_stress, monitor_live_stream, and stop_monitor.
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 during an earnings call but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. The context from sibling tools helps, but the description itself lacks explicit usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start monitoring a live financial webcast for transcription and stress analysis.
Provide a URL to a live earnings call, CNBC stream, or any webcast. The server will extract the audio stream, begin chunking it into 15-second segments, and continuously transcribe them in the background.
If the audio is low-quality (speakerphone, poor connection), set disable_vad=true to prevent the voice activity detector from aggressively dropping muddy speech segments.
Returns a stream_id you'll use for all subsequent operations.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| disable_vad | No | Disable Silero VAD filtering. Set to true for low-quality speakerphone audio where VAD aggressively drops speech as silence. |
| Name | Required | Description |
|---|---|---|
| stream_id | Yes | Unique identifier for the monitored stream |
| url | Yes | Original URL being monitored |
| status | Yes | Current stream status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and explains key behaviors: extracts audio, chunks into 15-second segments, continuous background transcription, and VAD behavior control. It could mention potential resource usage or authorization, but the provided details are substantial.
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 approximately 100 words, front-loaded with purpose, then usage guidance, parameter advice, and return value. Every sentence is informative without redundancy, achieving high conciseness.
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 2 parameters, clear purpose, sibling tools suggesting a workflow, and an output schema (not shown), the description covers the initiation process, key parameter behavior, and return value (stream_id). It is complete for an agent to understand and invoke the tool 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?
Schema coverage is 50% (disable_vad has description, url does not). The description adds value by clarifying url as a live webcast link and elaborating on disable_vad beyond the schema, noting its use for low-quality audio where VAD drops muddy speech. This offsets 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 verb 'Start monitoring' and the resource 'live financial webcast' with specific purpose 'for transcription and stress analysis'. It also provides examples of acceptable URLs, distinguishing it from sibling tools that handle different stages like analysis or retrieval.
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 gives explicit guidance on when to use the tool (provide a URL to a live webcast) and a specific scenario (low-quality audio) for setting disable_vad. It implies use for initiation, contrasting with siblings for subsequent operations, but lacks explicit 'when not to use' or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop monitoring a live stream and clean up all resources.
Kills the ffmpeg process, removes temporary audio files, and clears the transcript buffer.
| Name | Required | Description | Default |
|---|---|---|---|
| stream_id | Yes |
| Name | Required | Description |
|---|---|---|
| stream_id | Yes | |
| status | Yes | |
| duration_seconds | Yes | How long the stream was monitored |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details what happens: kills ffmpeg process, removes temp files, clears buffer. This is transparent for a cleanup tool. However, it does not mention idempotency or error handling for invalid stream_id.
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: two sentences. The first states the purpose, the second lists specific actions. 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?
Given an output schema exists, return values are not needed. The description covers the main behavior and cleanup. Minor gap: no mention of edge cases like already stopped stream.
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 tool description does not explain the 'stream_id' parameter's purpose or format. The parameter is left completely undocumented.
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 action: 'Stop monitoring a live stream and clean up all resources.' It distinguishes from siblings like 'monitor_live_stream' which starts monitoring, and others which analyze or retrieve transcripts.
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?
No guidance on when to use this tool versus alternatives. It implies it should be used after 'monitor_live_stream', but there is no explicit context or prerequisites mentioned.
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.
v0.1.3analyze_speaker_stressget_rolling_transcriptmonitor_live_streamstop_monitorScored across 4 tools
Each tool has a unique and well-defined purpose: monitoring, stopping, retrieving transcript, and analyzing stress. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., monitor_live_stream, get_rolling_transcript), making the set predictable for an agent.
With only 4 tools, the server is tightly scoped to live audio monitoring and analysis. Each tool is essential, and the count is appropriate for the domain.
The tools cover the core workflow (start, get transcript, analyze stress, stop). Minor gaps include lack of multi-stream management or status checking, but these are not critical for the primary use case.
Financial podcast intelligence platform — sentiment, narrative, and asset signals from 100+ podcasts
Investment research superagent: podcasts, SEC filings, and no-code research pipelines.
177,000+ earnings call transcripts for AI - speaker segments & full-text search.
Realtime financial context for AI agents: what changed, who is affected, and what to watch next. One suite covering news, events, guidance, filing changes, sentiment, stakeholders, and alerts. Information-efficient responses with evidence for every result. First-class point-in-time safety for backtests. Pairs well with web search and a market-data API. All data is our own.
