OpenRouter Voice MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENROUTER_VOICE | No | Preset voice id (Fish Audio has none; leave empty). | |
| VOICE_OUTPUT_DIR | No | Default output directory for generated audio files. | %USERPROFILE%\OpenRouterVoice\output |
| OPENROUTER_API_KEY | Yes | Your OpenRouter API key. Required. Never logged or returned. | |
| OPENROUTER_APP_TITLE | No | Application title sent as X-OpenRouter-Title. | OpenRouter Voice MCP |
| OPENROUTER_VOICE_MODEL | No | The default OpenRouter speech model. | fish-audio/s2.1-pro-free:free |
| OPENROUTER_AUDIO_FORMAT | No | Audio format: mp3 or pcm. | mp3 |
| OPENROUTER_HTTP_REFERER | No | HTTP Referer header sent to OpenRouter (optional). | |
| OPENROUTER_TIMEOUT_SECONDS | No | Timeout in seconds for API requests. | 120 |
| OPENROUTER_VOICE_FALLBACK_MODEL | No | Optional fallback model to use when the primary is unavailable (do not set unless you accept paid usage). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| healthA | Report MCP configuration status without spending a TTS request. Checks that the API key is configured, echoes the active model, endpoint and output directory, and does one free auth probe against OpenRouter. The API key itself is never returned. |
| render_voiceoverB | Render narration text to a local audio file via OpenRouter. |
| render_long_voiceoverA | Render a long script by splitting it into segments and rendering each. Splits on paragraph, then sentence, then word boundaries -- never mid-word. Short scripts fall through to a single request. When FFmpeg is available and the format is mp3, the segments are stream-copy concatenated into output_path; otherwise the segment paths are returned for the caller to join. |
| preview_voiceA | Render a short sample so you can hear a voice before a full render. Writes into /previews and, on Windows, opens it with the default player. Playback is best-effort: if it fails, audio_path is still returned. |
| list_speech_modelsA | List the OpenRouter models whose output modality is speech. Returns id, name and pricing only. Use this to point OPENROUTER_VOICE_MODEL at a different provider without touching the code. |
| model_infoA | Live details for the configured speech model (or the one you name). Pricing, tier and voice-cloning support come from the OpenRouter endpoints API; anything OpenRouter does not report is returned as "unknown". |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: health for configuration status, preview_voice for a sample, render_voiceover for standard text-to-speech, render_long_voiceover for long scripts with splitting, list_speech_models for enumerating models, and model_info for details on a specific model. No overlaps in functionality.
Most tools follow a verb_noun pattern (preview_voice, render_voiceover, list_speech_models), but 'health' and 'model_info' are arguably nouns instead of commands. Minor inconsistency in verb usage, but overall naming is clear and predictable.
With 6 tools, the server is well-scoped for a text-to-speech utility. Each tool addresses a distinct need—status, preview, rendering, long rendering, model discovery, and model details—without unnecessary extras.
The tool surface covers the full lifecycle of using OpenRouter's TTS: checking configuration, previewing voices, rendering short and long audio, listing available models, and querying model attributes. No obvious dead ends or critical missing operations.