OpenRouter Voice MCP

by Trandu1

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.1/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and behavioral traits. The one-sentence description only states the basic action—rendering text to a file—but does not disclose overwrite behavior, provider-specific quirks, file creation details, or failure modes. The rich behavioral details are buried in parameter descriptions, but the main description fails to summarize them.
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?
The description is a single, focused sentence that states the core purpose without unnecessary words. It is front-loaded and immediately communicates what the tool does. There is no bloat, and the sentence earns its place.
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?
Given 8 parameters, full schema coverage, and an output schema, the description is not required to explain every parameter. However, it lacks contextual guidance on when to use this tool versus alternatives, and does not hint at the short/long distinction that the sibling names imply. The description is adequate for the basic function but incomplete for selection decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific meaning beyond what the schema already provides. However, the schema descriptions are detailed (e.g., overwrite behavior, forward-only for instructions, numbering of siblings), which makes the overall parameter handling strong. Since the description text does not augment the schema, it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('render') and resource ('narration text to a local audio file') and mentions the transport ('via OpenRouter'). However, it does not explicitly differentiate from the sibling 'render_long_voiceover' other than by name, which leaves some ambiguity about when each is appropriate.
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?
The description gives no guidance on when to use this tool versus its siblings (e.g., render_long_voiceover, preview_voice). It does not mention prerequisites, typical scenarios, or alternatives. The agent must infer usage from the name and parameter descriptions, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It does state that data comes from the OpenRouter endpoints API and that missing fields are returned as 'unknown'. It implies a read-only fetch operation, but it does not explicitly state that it makes no modifications, nor does it cover potential errors or rate limits. The disclosure of the external dependency and the 'unknown' fallback adds value, but the description does not fully characterize the tool's side-effect profile. Without annotations, this is a partial disclosure.
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?
The description is two sentences and gets straight to the point. The first sentence states the core purpose, the second explains the data source and handling of missing information. There is no fluff or redundant detail. Every sentence earns its place, and the most important information is front-loaded.
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?
For a one-parameter read-only tool with no annotations, the description covers the essential aspects: what it does, the source of data, and the fallback for missing values. An output schema exists, so return format is implicitly covered. It doesn't address potential error cases or explicitly state that it is a read-only operation, but given its simplicity, the description is nearly complete. The main gap is the lack of explicit guidance on when to choose this over list_speech_models, but that is more of a usage guideline than completeness for calling the tool.
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 input schema declares a single optional string parameter 'model' with a default of an empty string, but provides no further explanation. The description directly explains the parameter semantics: if a model is named, details for that model are returned; otherwise, the configured default is used. This adds essential meaning beyond the schema and clarifies the behavior for both empty and non-empty values. It could go further by specifying the expected format (e.g., model ID or name), but it is largely sufficient.
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 it provides live details for a speech model, either the configured default or a specific one named by the user. It specifies the data points (pricing, tier, voice-cloning support) and the data source, distinguishing it from sibling list_speech_models which would list models rather than give details. The verb is implied ('get') but the resource is specific and the scope is unambiguous.
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?
The description implies usage: you call it to get details about a specific model or the configured default. However, it does not explicitly mention when to use this tool versus list_speech_models or other siblings, nor does it provide any exclusions or conditions (e.g., 'use this when you need details, list_speech_models for a list'). The context is clear enough, but there is no explicit routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 discloses the exact output scope ('Returns id, name and pricing only') and implies a read-only list operation, but it does not explicitly state whether it is read-only, whether authentication is required, or any rate limits. The note about pointing the environment variable is useful context, but key behavioral traits are left implicit.
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?
The description is two sentences, front-loaded with the core purpose and immediately followed by return details and a practical use case. No wasted words; every sentence earns its place.
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?
Given zero parameters and an existing output schema, the description is complete for a simple list tool. It covers the purpose, return scope, and a usage scenario. It does not mention prerequisites like authentication, but that is minor and not critical for this zero-parameter, read-oriented tool.
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 the schema already covers everything. The description need not explain parameters; the baseline for no params is 4. It does not add parameter-specific meaning, but none is needed.
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 states a specific verb ('List') and a precise resource filter ('OpenRouter models whose output modality is speech'). It clearly distinguishes from siblings like render_voiceover or model_info by focusing on listing speech-enabled models with a specific output scope.
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?
Provides a concrete use case: 'Use this to point OPENROUTER_VOICE_MODEL at a different provider without touching the code.' This tells the agent when to invoke it. It does not explicitly contrast with alternatives or mention when not to use it, but the clear purpose and sibling names make the context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: writes to <output_dir>/previews, auto-opens with the default player on Windows, playback is best-effort, and audio_path is still returned on failure. This is rich behavioral disclosure covering side effects, platform dependence, and error handling.
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 tightly written sentences with no filler. The primary purpose is front-loaded in the first sentence, and the second sentence packs essential behavioral details efficiently.
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 tool is simple and the description covers the core purpose, side effects, and failure behavior. The output schema exists, so return values are documented elsewhere. However, the lack of explicit parameter explanations is a gap that prevents this from being a fully self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter descriptions, so the description must compensate. It only loosely implies that 'text' is the content to render and 'voice' refers to a voice, but it never explicitly explains these or the 'play' parameter. This is a significant gap since an agent cannot reliably infer parameter meanings from the description alone.
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 states a specific action ('Render a short sample') and a clear purpose ('so you can hear a voice before a full render'), which distinguishes it from the full rendering sibling tools. The resource and scope are explicit.
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?
It clearly indicates the tool is meant for pre-render previews via 'before a full render', giving context on when to use it. However, it does not explicitly mention alternative tools like render_voiceover or render_long_voiceover, so it misses a direct comparison that would strengthen the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it acquits itself well: it discloses that it checks API key configuration, echoes the model/endpoint/output directory, performs one free auth probe against OpenRouter, and explicitly guarantees the API key is never returned. The one slightly under-specified item is what the 'auth probe' entails, but overall this is thorough disclosure for an annotation-free tool.
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?
Three compact sentences with the key differentiator (no TTS cost) front-loaded. Every sentence earns its place: the first states the core purpose, the second details what is checked, and the third covers the privacy guarantee. No filler or redundant restating of the tool name.
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?
For a parameterless diagnostic tool with an output schema (which exempts the description from explaining return values), this is close to complete: it covers what it checks, the free nature of the call, and the safety guarantee. The only minor gap is that it could explicitly frame the 'verify config before rendering' pattern, though the no-TTS-cost phrasing largely implies it.
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 zero parameters and the schema is empty, so the description correctly focuses on behavior rather than arguments — nothing to explain for parameters. Per the baseline for parameterless tools, a 4 is appropriate; the description adds no param details 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 states a specific verb and resource — "Report MCP configuration status" — and immediately distinguishes it from the speech-generation siblings (preview_voice, render_voiceover, render_long_voiceover) by framing it as a diagnostic operation rather than a generation operation. An agent can tell this is the config/health check at a glance.
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?
The lead phrase "without spending a TTS request" provides clear context for when to pick this tool — it's the free, non-billable diagnostic — which implicitly contrasts with the rendering siblings that consume TTS. However, it stops short of explicit exclusions or direct routing to an alternative (e.g., it never says 'use render_voiceover when you actually need audio'). The context is clear but the when-not guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so admirably. It explains the splitting algorithm (paragraph → sentence → word, never mid-word), the fallback for short scripts, and the output behavior (stream-copy concatenation to output_path when FFmpeg and mp3 are available, otherwise returning segment paths). This openly conveys the tool's decision logic and expected results.
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?
The description is compact and front-loaded: it states the purpose in the first sentence and then provides two specific, high-value behavioral details in the second. Every sentence contributes meaning without repetition or filler, and the structure is easy to parse.
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?
Given the tool's complexity (splitting, conditional concatenation) and the presence of an output schema, the description covers the core behavior thoroughly. It explains the main edge case (FFmpeg absent) and the segmentation rule. It does not address overwrite semantics or what happens when output_path is empty, but these are secondary and the output schema may provide return details. Overall, it is nearly complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does mention output_path and response_format indirectly (through the FFmpeg/mp3 condition) and implies max_chars via segmentation, but it does not explicitly define any parameter. Voice and overwrite are left entirely to the schema, which carries no descriptions. The description adds some meaning but is incomplete for a tool with six parameters.
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 'render' and the resource 'a long script', and immediately explains the core mechanism (splitting into segments and rendering each). It differentiates from the sibling render_voiceover by targeting long scripts and explicitly describing the segmentation boundaries, making its purpose unambiguous.
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?
The description provides strong context: it mentions that short scripts fall through to a single request, which implies this tool is for long scripts and handles both cases. However, it does not explicitly name the sibling render_voiceover as the alternative for short scripts, nor does it state when not to use this tool. The guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp_voice MCP server](https://glama.ai/mcp/servers/Trandu1/mcp_voice/badges/card.svg)](https://glama.ai/mcp/servers/Trandu1/mcp_voice)

Score Badge

Copy to your README.md:

[![mcp_voice MCP server](https://glama.ai/mcp/servers/Trandu1/mcp_voice/badges/score.svg)](https://glama.ai/mcp/servers/Trandu1/mcp_voice)

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/Trandu1/mcp_voice'

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