VoxFabric

by YottaMeta

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 targets a distinct function: speak for TTS, listen for one-shot STT, listen_start/get_speech/listen_stop for streaming sessions, set_engine/catalog for configuration, and health for status. No two tools have overlapping responsibilities.
Naming Consistency4/5
Most names follow an imperative verb style with snake_case for compound actions (listen_start, get_speech). A few single-word names like catalog and health deviate from a strict verb_noun pattern, but the overall style is consistent and readable.
Tool Count5/5
8 tools is well within the ideal range. Each tool serves a clear purpose in the voice lifecycle (speech, recognition, session control, engine management, health) without redundancy.
Completeness4/5
The core voice workflows are covered: one-shot and continuous recognition, TTS, engine switching, and status. Minor gaps exist such as no explicit pause/resume or volume control for speech, but these can be worked around using engine settings.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden for behavior disclosure. It mentions cloud configuration and the JSON return format, but does not disclose recording duration/timeout behavior, microphone permissions, privacy implications of cloud ASR, engine selection, or 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?
The description is three short sentences with the core purpose front-loaded. It contains no filler or redundant information, every sentence adds useful context, and it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and output format, but for a tool with two meaningful parameters and no annotations, it leaves important invocation details undocumented (engine choices, timeout semantics, and the distinction from listen_start). The output schema may cover return values, but the input-side guidance is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property descriptions are entirely absent (0% coverage), and the description never mentions the engine or timeout parameters. The agent cannot infer valid engine values or how timeout affects recognition, leaving the parameters effectively undocumented.
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 tool captures local microphone speech and recognizes it as Chinese text, giving a specific verb and resource. It distinguishes from speak (TTS) and health/catalog, but does not differentiate it from the sibling listen_start, so it is clear but not fully positioned among siblings.
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?
It provides setup context: local or cloud ASR is possible, and cloud requires configuring asr.aliyun in config.yaml. However, it does not explicitly state when to use this tool versus listen_start, get_speech, or speak, nor does it give exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavior. It does reveal that the tool is a polling mechanism and lists event types, but it omits critical behavioral traits such as whether timeout blocks, how since_id acts as a cursor, whether events are consumed or cumulative, or any side effects. The agent gets only a vague sense of how the tool actually behaves.
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 concise and front-loaded with the action (轮询拉取), followed by event examples and a use-case note. It avoids verbosity and structures information in two short sentences. While it is underspecified in other dimensions, as a standalone piece of text it is efficiently written without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the tool is a polling endpoint with two undeclared parameters and no guidance on alternative tools. The description provides only a minimal understanding of the polling loop and does not explain how timeout and since_id fit into that loop, making it insufficient for an agent to use the tool correctly in context. The overall picture is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the tool description does not mention the parameters timeout or since_id at all. As a result, the agent has no semantic information about what these parameters do, how they influence polling behavior, or what values are appropriate. There is no compensation for the schema's lack of descriptions.
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 tool's verb and resource: '轮询拉取实时语音事件' (poll to fetch real-time speech events), and lists specific event types (speech_start/final/state). This distinguishes it from sibling tools like speak and listen, which focus on producing or managing audio rather than consuming event streams.
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 phrase '宿主可据此感知用户说话' (host can use this to perceive user speech) implies the tool is for polling speech events during a session. However, there is no explicit guidance on when to prefer this tool over alternatives such as listen or listen_start, and no mention of exclusions or conditions. The usage context is implied rather than clearly defined.
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 carries the full burden for behavioral disclosure. It explains the core behavior (background dictation, real-time transcription) and the return value, but it does not disclose lifecycle details such as whether the session must be explicitly stopped, resource cleanup, or potential side effects on microphone state.
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, front-loaded sentence that names the action, describes the ongoing behavior, and states the return values. It is concise without wasted words and is appropriately structured.
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?
The tool starts a stateful, long-lived session, and while an output schema exists, the description could have benefited from referencing listen_stop for termination or explaining session lifecycle and concurrency constraints. The provided description is adequate but leaves gaps for a stateful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'asr' parameter at all. With schema description coverage at 0%, the schema itself provides no explanation either, so the description fails to compensate for the complete lack of parameter semantics.
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 tool starts a persistent voice session, performs background microphone dictation with real-time transcription, and returns a session_id and status. This specific verb+resource combination distinguishes it from siblings like listen_stop and likely one-shot listen.
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 clearly conveys that this tool is for long-running, continuous voice sessions ('常驻语音会话'), which implies when to use it over a one-off listen command. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It mentions 'session-level' which indicates a state change, but it doesn't explain side effects, reversibility, or whether changing the engine affects ongoing operations. It also doesn't describe error conditions or permission requirements. This is a notable gap for a state-mutating 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?
The description is extremely concise, fitting in two short sentences with no wasted words. The action is front-loaded, and the parameter guidance is immediately adjacent. Every clause 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 the tool's simplicity (2 required params, no schema descriptions) and the presence of an output schema, the description covers the core purpose and parameter semantics. However, it omits behavioral context like side effects or session lifetime. With no annotations, this leaves the agent without full risk awareness, making it incomplete for a state-changing operation.
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?
Schema coverage is 0%, so the description must compensate. It does by listing the allowed values for kind and explaining that name is obtained via catalog(). This adds meaningful meaning beyond the bare schema. It could go further by describing what each kind represents, but the current explanation is sufficient for basic usage.
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: switching a type of engine at session level. It enumerates the valid kinds (vad/asr/agent/tts), which immediately distinguishes it from sibling tools like speak or listen. The verb 'switch' plus the resource 'engine' is specific and 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?
It gives explicit guidance on valid kind values and tells the user to consult catalog() for the name parameter, implying a workflow. However, it doesn't explicitly state when to use this tool versus alternatives, or mention potential prerequisites like an active session. Still, the catalog reference provides a clear path for correct invocation.
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 carry the transparency burden. It does specify the content of the status summary, which is useful, but it does not explicitly mention that the operation is read-only or discuss any potential side effects or failure conditions. For a health check, the described behavior is adequately clear, though not deeply detailed.
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, concise sentence that immediately states the tool's purpose and key output details. It is front-loaded and contains no unnecessary words, earning a perfect score for structure.
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 simplicity (no parameters) and the presence of an output schema, the description sufficiently covers the main return fields: version, ffplay availability, and current engine. It does not explain every possible nuance but is complete enough for a health status 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 baseline is 4. The description does not need to explain parameters, and the input schema already confirms an empty parameter set. No additional parameter information is necessary.
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 tool returns a status summary including version, ffplay availability, and current engine. The verb '返回' (returns) is specific, and the resource is well-defined. This distinguishes it from the sibling tools, which focus on speech operations like speak and listen.
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 use for checking system or voice network status but does not explicitly state when to use this tool versus the siblings. No alternatives or exclusions are mentioned, so the 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the main effect (stopping session, releasing microphone) but doesn't mention edge cases like idempotency or behavior when no session is active.
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, clear sentence that directly states the action and resource. No filler or repetition.
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 simple no-parameter stop tool, the description covers the essential behavior. It could mention what happens if no session is active, but the tool's simplicity makes it mostly 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?
There are zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and no additional parameter information is necessary.
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 tool stops the resident voice session and releases the microphone. This is a specific verb-resource pair that distinguishes it from siblings like 'listen_start' and 'listen'.
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 usage is implied from the context of stopping a voice session, but no explicit guidance is given on when to use or not use this tool. It doesn't mention alternatives or prerequisites.
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, the description carries the full burden of behavioral disclosure. It clearly states the tool's behavior (listing registered engines and the current selection) and implies a read-only operation. It does not mention edge cases like empty catalogs, but the core behavior is transparent.
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 sentence that is front-loaded with the action ('list') and the resource, with no unnecessary wording. Every part 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 the zero-parameter input and the presence of an output schema, the description is sufficient for understanding the tool's purpose. It doesn't explain what 'engines' are, but the sibling tool names (set_engine, speak) provide domain context to fill this gap.
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 has zero properties, so there are no parameters to document. The description correctly focuses on the tool's purpose rather than parameter details, aligning with the baseline for 0-parameter tools.
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 the specific verb 'list' with a clear resource ('all registered engines and current selection'), which distinguishes it from sibling tools like set_engine (which modifies selection) and speak/listen (which use engines). It precisely states what the tool does.
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 is provided, and no alternative tools are named. However, the listing purpose is implied by the context of engine management siblings, making the usage context reasonable but not explicitly articulated.
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, the description carries the burden. It discloses key behavior: local operation and the interrupt effect (interrupts current playback), adding useful context beyond the schema. It doesn't cover all edge cases but provides essential traits.
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 compact statements, front-loaded with purpose and a concise behavioral note. No wasted words, and structure is clean.
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 covers the core operation and key side effect, but misses prerequisites like engine configuration (implied by sibling set_engine). Given the tool's simplicity and output schema presence, it is reasonably complete but not exhaustive.
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 has 0% description coverage, so the description must compensate. It explains the interrupt parameter and mentions emotion, but does not explain the voice parameter or provide allowed values, leaving some parameter semantics under-specified.
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 tool reads/recites text locally with optional emotion, using a specific verb and resource. It distinguishes from sibling tools like listen by focusing on speech output.
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 clear context: it's for local text-to-speech, and explicitly mentions interrupt behavior for real-time interjection. However, it does not explicitly state when not to use it or name alternative tools.
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:

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

Score Badge

Copy to your README.md:

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

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/YottaMeta/VoxFabric'

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