Which integrations are available for this server?

Offers an API compatible with OpenAI's audio transcription endpoint, allowing any OpenAI SDK client to transcribe audio using the local VibeVoice-ASR model.

How do I use vibevoice-asr?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@vibevoice-asr transcribe meeting_recording.wav with timestamps" 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.

vibevoice-asr

by tjameswilliams

Overview Schema Related Servers Score Discussions

Python

Local

VibeVoice-ASR Server

Local speech-to-text using Microsoft's VibeVoice-ASR model. Run it as an OpenAI-compatible API server or as an MCP server that plugs directly into Claude Code, OpenCode, Cursor, and other AI tools.

Automatic speaker diarization
Timestamps on every segment
Output as plain text, JSON, SRT, or VTT
Runs on CUDA, Apple Silicon (MPS), or CPU
Model downloads automatically on first run

Requirements

Python 3.10+
FFmpeg (used by the model's audio processor)

Install FFmpeg:

# macOS
brew install ffmpeg

# Ubuntu / Debian
sudo apt-get install ffmpeg

# Windows (with Chocolatey)
choco install ffmpeg

Related MCP server: livechat-mcp

Quick Start

# Clone the repo
git clone https://github.com/tjameswilliams/vibevoice-server.git
cd vibevoice-server

# Create a virtual environment (recommended)
python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate

# Install
pip install -e .

# For NVIDIA GPU acceleration (optional)
pip install -e ".[cuda]"

The first time you run either the API server or MCP server, the model (~3 GB) will be downloaded from HuggingFace and cached locally.

Option 1: OpenAI-Compatible API Server

Start the server:

vibevoice-server

The server starts on http://localhost:8000 by default. It exposes the same endpoint shape as the OpenAI Audio API, so any client library or tool that speaks that protocol works out of the box.

CLI Options

vibevoice-server [OPTIONS]

  --host        Bind address (default: 0.0.0.0)
  --port        Bind port (default: 8000)
  --device      Device: auto, cuda, mps, cpu (default: auto)
  --dtype       Data type: auto, bfloat16, float32 (default: auto)
  --log-level   Log level: debug, info, warning, error (default: info)

Transcribe Audio

curl http://localhost:8000/v1/audio/transcriptions \
  -F file=@meeting.wav \
  -F response_format=verbose_json

Parameters:

Parameter	Type	Default	Description
`file`	file	required	Audio file (wav, mp3, flac, m4a, ogg, etc.)
`model`	string	`vibevoice-asr`	Model identifier (accepted but ignored)
`response_format`	string	`json`	`text`, `json`, `verbose_json`, `srt`, `vtt`
`prompt`	string		Optional context to guide transcription
`language`	string		Language code (used in verbose_json output)

Response Formats

json (default):

{"text": "Hello, welcome to the meeting."}

verbose_json — includes timestamps, speaker IDs, and segments:

{
  "task": "transcribe",
  "language": "en",
  "duration": 12.5,
  "text": "Hello, welcome to the meeting.",
  "segments": [
    {"id": 0, "start": 0.0, "end": 3.2, "text": "Hello, welcome to the meeting.", "speaker": 0}
  ]
}

srt and vtt — subtitle formats with speaker labels, ready to use with video players.

text — plain transcript string, no JSON wrapper.

Other Endpoints

# List models
curl http://localhost:8000/v1/models

# Health check
curl http://localhost:8000/health

Using with OpenAI Client Libraries

Point any OpenAI SDK at your local server:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")

with open("recording.wav", "rb") as f:
    transcript = client.audio.transcriptions.create(
        model="vibevoice-asr",
        file=f,
        response_format="verbose_json",
    )

print(transcript.text)

Docker

# Build
docker build -t vibevoice-server .

# Run (CPU)
docker run -p 8000:8000 -v vibevoice-cache:/models vibevoice-server

# Run (NVIDIA GPU)
docker run --gpus all -p 8000:8000 -v vibevoice-cache:/models vibevoice-server

Option 2: MCP Server

The MCP (Model Context Protocol) server lets AI tools call transcription directly — no HTTP server needed. The model runs in the same process as the MCP server.

MCP Tools

Tool	Description
`transcribe_audio`	Transcribe an audio file. Pass an absolute file path and get back the transcript.
`load_vibevoice_model`	Pre-load the model into memory (~60-90s). Optional — the model loads automatically on first transcription.
`get_vibevoice_status`	Check whether the model is loaded, and which device/dtype it's using.

transcribe_audio parameters:

Parameter	Type	Default	Description
`file_path`	string	required	Absolute path to the audio file
`response_format`	string	`text`	`text`, `json`, `verbose_json`, `srt`, `vtt`
`prompt`	string		Optional context to guide transcription
`language`	string		Language code (for verbose_json output)

Claude Code

Add to your project's .mcp.json (or ~/.claude/mcp.json for global access):

{
  "mcpServers": {
    "vibevoice-asr": {
      "command": "vibevoice-mcp",
      "args": []
    }
  }
}

With device override:

{
  "mcpServers": {
    "vibevoice-asr": {
      "command": "vibevoice-mcp",
      "args": ["--device", "mps"]
    }
  }
}

Restart Claude Code after adding the config. The three tools (transcribe_audio, load_vibevoice_model, get_vibevoice_status) will appear automatically.

Cursor

Add to .cursor/mcp.json in your project root:

{
  "mcpServers": {
    "vibevoice-asr": {
      "command": "vibevoice-mcp",
      "args": []
    }
  }
}

OpenCode

Add to your OpenCode MCP configuration (opencode.json or via settings):

{
  "mcpServers": {
    "vibevoice-asr": {
      "command": "vibevoice-mcp",
      "args": []
    }
  }
}

Any MCP-Compatible Tool

The server uses stdio transport — the standard for local MCP servers. Any tool that supports MCP can run it with:

Command: vibevoice-mcp
Args: [] (optional: ["--device", "mps"] or ["--device", "cuda"])
Transport: stdio

The MCP server reads JSON-RPC from stdin and writes responses to stdout. All logs go to stderr.

MCP CLI Options

vibevoice-mcp [OPTIONS]

  --device      Device: auto, cuda, mps, cpu (default: auto)
  --dtype       Data type: auto, bfloat16, float32 (default: auto)
  --log-level   Log level (default: warning)

Configuration

All settings can be controlled via environment variables (prefixed with VIBEVOICE_), CLI flags, or a .env file. See .env.example for the full list.

Variable	Default	Description
`VIBEVOICE_DEVICE`	`auto`	`auto`, `cuda`, `mps`, `cpu`
`VIBEVOICE_DTYPE`	`auto`	`auto`, `bfloat16`, `float32`
`VIBEVOICE_CACHE_DIR`	(HuggingFace default)	Where to store downloaded model weights
`VIBEVOICE_MODEL_ID`	`microsoft/VibeVoice-ASR-HF`	HuggingFace model ID
`VIBEVOICE_HOST`	`0.0.0.0`	API server bind address
`VIBEVOICE_PORT`	`8000`	API server bind port
`VIBEVOICE_LOG_LEVEL`	`info`	Logging level

Device auto-detection picks the best available: CUDA > MPS > CPU.

Hardware Notes

Platform	Device	Dtype	Notes
NVIDIA GPU	`cuda`	`bfloat16`	Fastest. Flash Attention 2 enabled automatically. Install with `.[cuda]`.
Apple Silicon	`mps`	`float32`	Works well on M1/M2/M3/M4.
CPU	`cpu`	`float32`	Slower but works everywhere.

The model is ~3 GB. First load takes 60-90 seconds (downloading + loading weights). Subsequent starts are faster when cached.

License

MIT

Available Tools

3 tools

get_vibevoice_statusA

Check the current status of the VibeVoice-ASR server.

Returns model loaded state, device, dtype, and version info.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It clearly states it is a read operation returning status. However, it does not disclose potential delays, errors, or network usage. Given the simplicity, a score of 3 is appropriate.

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

Conciseness5/5

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

Two sentences, front-loaded with action and outcome. No unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and a straightforward return (model loaded state, device, dtype, version info), the description is complete. It provides enough context for the agent to understand what the tool does and what it returns.

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

Parameters4/5

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

There are no parameters, and the schema coverage is 100% (empty). Per guidelines, 0 parameters earns a baseline of 4. The description adds no parameter info because none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb 'Check' and specifies the resource 'VibeVoice-ASR server'. It lists the returned information (model loaded state, device, dtype, version info), distinguishing it from siblings like load_vibevoice_model and transcribe_audio.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance. The description implies it is a status check, but does not mention alternatives or prerequisites. For a simple status tool, minimal guidance may be acceptable.

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

load_vibevoice_modelA

Pre-load the VibeVoice-ASR model into memory.

Call this before transcribing to avoid a long wait on the first transcription. Model loading takes ~60-90 seconds depending on hardware.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses that loading takes ~60-90 seconds and is a prerequisite for transcription. However, it does not mention if repeated calls are safe or if there are 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.

Conciseness5/5

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

Two concise sentences, front-loaded with purpose, followed by usage guidance and timing detail. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the tool's purpose and usage context well, but does not describe the output schema (though one exists) or mention idempotency. For a simple priming tool, this is nearly complete.

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

Parameters4/5

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

The tool has zero parameters, so no parameter documentation is needed. The description adds no param info, but this is appropriate given the schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Pre-load' and the resource 'VibeVoice-ASR model', distinguishing it from sibling tools like transcribe_audio (actual transcription) and get_vibevoice_status (status checking).

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

Usage Guidelines4/5

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

Explicitly advises calling before transcribing to avoid delay, and mentions the loading time. While it lacks explicit when-not-to-use, the guidance is clear and actionable.

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

transcribe_audioA

Transcribe an audio file using VibeVoice-ASR.

Args: file_path: Absolute path to the audio file (wav, mp3, flac, etc.) response_format: Output format: text, json, verbose_json, srt, vtt (default: text) prompt: Optional prompt/context to guide transcription language: Language code for verbose_json output (default: en)

ParametersJSON Schema

Name	Required	Default
`prompt`	No
`language`	No
`file_path`	Yes
`response_format`	No	text

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided, so the description must fully disclose behavior. It lacks details on side effects (read-only/mutation), file size limits, timeouts, authentication requirements, or other constraints. Only parameter descriptions exist.

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

Conciseness4/5

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

The description is well-structured with a concise opening sentence followed by a clear 'Args' block. Minor redundancy exists (first sentence restated in file_path), but overall efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers parameters adequately, it omits important context: output format (though output schema exists), model loading prerequisites (implied by siblings), and potential errors. It is functional but not fully self-contained.

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

Parameters5/5

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

The description adds significant value beyond the bare input schema, which has 0% description coverage. It explains file path format and supported extensions, response format options, prompt purpose, and language usage. All four parameters are well-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Transcribe an audio file' and names the specific tool 'VibeVoice-ASR'. It effectively distinguishes from sibling tools (get_vibevoice_status, load_vibevoice_model), which handle status and model loading.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., model must be loaded) or when not to use it. The usage context is only implied by the action name.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.1.0Jun 28, 2026
- First observedget_vibevoice_status
- First observedload_vibevoice_model
- First observedtranscribe_audio

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a unique purpose: checking server status, loading the model, and transcribing audio. No functional overlap, making it clear which tool to use for each task.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_vibevoice_status, load_vibevoice_model, transcribe_audio), making them predictable and easy to remember.

Tool Count5/5

Three tools cover the essential operations of an ASR server—status check, model loading, and transcription. The count is well-scoped for the domain without unnecessary extras.

Completeness4/5

The set covers the core workflow (status, load, transcribe). A minor gap is the lack of an unload model tool, but this does not severely hinder functionality for typical use cases.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

transcribeOAuth
com.transcribevideototext
Transcribe audio & video to text for AI agents: 100+ languages, speaker labels, webhooks.
Speech Processing Audio Processing Multimedia Processing
2
mcpOAuth
so.transcribe
Transcribe audio and video into speaker-labelled transcripts, subtitles, clips, and cited Q&A.
Speech Processing Audio Processing
1
transcription A
com.scriptivox.www
AI transcription from URLs or files. 119 languages, diarization, SRT/VTT/text export.
Speech Processing Audio Processing AI & Machine Learning
39113
pepys-mcpOAuth
co.pepys
Transcribe audio & video: diarization, timed SRT/VTT, podcasts, paste-a-link, whole-feed batch.
Speech Processing Audio Processing Multimedia Processing
2

Related MCP Servers

Voice MCP
Speech Processing Text-to-Speech Command Line
shreyaskarnik
A
license
Not graded
quality
D
maintenance
Enables bidirectional voice interaction for Claude Code using local speech-to-text and text-to-speech models optimized for Apple Silicon. It provides tools to listen to user speech via microphone and speak responses aloud through system speakers.
Updated 7 months ago (2026-02-10 23:41 UTC)
16
Apache 2.0
livechat-mcp
Speech Processing Developer Tools
brunocramos
A
license
Not graded
quality
D
maintenance
Enables continuous voice conversation with AI coding assistants by locally transcribing speech with Whisper and delivering utterances as text prompts.
Updated 4 months ago (2026-05-17 01:16 UTC)
1
MIT
meetey
Speech Processing Audio Processing Note Taking
jej2k5
A
license
Not graded
quality
A
maintenance
Local-first meeting capture and transcription for Claude Code. Records audio from meeting apps, transcribes locally with whisper.cpp, and produces structured notes via Claude.
Updated a month ago (2026-08-06 21:33 UTC)
1
Apache 2.0
jackai-stt-mcpofficial
Speech Processing AI & Machine Learning
jack-ai-net
A
license
A
quality
C
maintenance
Transcribes audio files by referencing them in chat, using OpenAI's speech-to-text models locally without uploading audio, and supports speaker diarization.
Updated a month ago (2026-08-02 11:53 UTC)
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tjameswilliams/vibevoice-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

VibeVoice-ASR Server

Requirements

Quick Start

Option 1: OpenAI-Compatible API Server

CLI Options

Transcribe Audio

Response Formats

Other Endpoints

Using with OpenAI Client Libraries

Docker

Option 2: MCP Server

MCP Tools

Claude Code

Cursor

OpenCode

Any MCP-Compatible Tool

MCP CLI Options

Configuration

Hardware Notes

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Voice MCP

livechat-mcp

meetey

jackai-stt-mcpofficial

Latest Blog Posts

MCP directory API