Click on "Install 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., "@voiceconsole find my budget spreadsheet on the desktop"
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.
对着电脑说一句「打开桌面」或「执行 dir」，它就执行并播报结果——给 MCP / CLI 加一层本地语音入口。
本地语音控制台：STT 识别 → 意图解析 → 安全门 → 工具执行 → TTS 播报。以 MCP Server 形态提供 5 个工具，可被任意 MCP 客户端调用。
能力 | 说明 |
MCP Server | 标准 stdio 传输，5 个工具（ |
本地语音链路 | faster-whisper 本地 STT（无 key 可用）+ edge-tts 播报（自动降级系统 TTS） |
安全门 | 黑/白名单 + 注入字符拦截 + 二阶段语音确认（30s 超时自动拒绝） |
三种入口 | 热键语音循环 / |
零依赖 Web UI | 标准库 |
Related MCP server: computer-use-windows
# 安装依赖（mcp / faster-whisper / edge-tts / keyboard / sounddevice ...）
pip install -r requirements.txt
# 方式 1：作为 MCP Server（任意 MCP 客户端 stdio 调用）
python -m voiceconsole
# 方式 2：本地热键语音循环（Windows 需管理员运行）
python main.py
# 方式 3：免麦克风/免管理员：交互文本模式
python main.py --text
# 方式 4：本地 Web 控制台（浏览器打开 http://127.0.0.1:8765）
python -m voiceconsole.webui --port 8765热键：Ctrl+Shift+Space 开始/停止录音 · Ctrl+Shift+Q 退出。
工具 | 输入 | 说明 |
|
| 白名单执行；危险命令抛错，其余需语音确认 |
|
| 按文件名模糊搜索 |
|
| 系统文件管理器打开 |
|
| TTS 播报 |
|
| 发起并等待语音确认，超时默认拒绝 |
main.py 热键监听 + 全局循环
voiceconsole/
__init__.py MCP server 入口（register + run）
__main__.py python -m voiceconsole（stdio）
mcp_server.py MCP SDK 工具注册与执行编排
safety.py 安全门：黑白名单 + 确认状态机（线程安全）
actions.py 真实执行体（全项目唯一 subprocess 处）
intent.py 规则意图解析 + 工具映射
stt.py / tts.py STT / TTS 引擎封装（含降级）
webui.py 本地 Web 控制台（零依赖）
tests/ pytest 测试（71 例，含真实 stdio 子进程握手）检查顺序：空命令/注入字符（; && | > < $( 等）→ 黑名单 → 白名单 → 其余需确认
黑名单默认拒绝：rm sudo curl wget dd mkfs mv del shutdown bash passwd net user 等
白名单默认放行：ls cd cat pwd dir git status git log ping ps top 等
执行默认超时 10s 防挂起；密钥一律走环境变量，绝不硬编码
python -m pytest tests/ -v语音与控制指令仅在本机处理；STT 使用本地模型或你配置的在线 API，TTS 使用本地/在线引擎。
工具可执行本机命令，请自行评估风险；确认门默认开启，危险操作需语音二次确认。
演示请运行 python demo.py（免麦克风，覆盖打开桌面/找文件/危险命令拒绝/退出全链路）。
本项目仅供学习交流与演示用途，不构成任何形式的商业服务或技术承诺。软件按「现状」提供，不作任何明示或暗示的保证，包括但不限于适销性、特定用途适用性与非侵权性。 您理解并同意：使用本项目即表示您自行承担全部风险。如您在使用过程中发现缺陷或问题，欢迎通过 GitHub Issues 反馈，但作者不因使用本软件所直接或间接产生的任何损失（包括但不限于数据丢失、业务中断、第三方索赔）承担责任。 本项目以功能演示与学习交流为主要目的，其架构设计、安全基线、容错机制与性能表现均未按生产级标准进行验证与加固，不适用于实际生产环境或关键业务场景。任何将本项目部署于生产系统、对外提供服务、或将其接入真实业务工作流的做法，均属使用者的自主决策行为；由此产生的任何直接或间接不良后果，包括但不限于服务中断、数据损坏或泄露、业务损失、合规风险、以及因依赖本软件而引发的第三方纠纷，开发者均不承担任何责任。若您确有生产级使用需求，请在充分评估与自行加固（包括但不限于安全审计、压力测试、代码审查）后，自行承担相应风险。
GPL-3.0 — Copyright (C) 2026 anyuer678
发起并等待一次语音安全确认，超时默认拒绝。例句：confirm(prompt='确认执行该操作？')
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: waiting (blocking) and timeout defaulting to reject, which is crucial for a confirmation tool. However, it does not state what the tool returns on success or whether it returns a boolean or other result.
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 a single sentence plus an example. It is front-loaded with the primary action, includes a relevant example, and contains no extraneous information. Every word contributes.
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?
For a simple one-parameter tool with no output schema, the description covers the essential timeout behavior but omits the return value/result semantics. It also doesn't mention any side effects or environment requirements. While not severely lacking, the missing return info leaves a gap.
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?
The schema has a single prompt parameter with no description (0% coverage). The description provides an example (confirm(prompt='确认执行该操作？')) that illustrates the parameter's usage as a question string, but it does not elaborate on expected format or content beyond the example.
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 initiates and waits for a voice security confirmation, which is a specific verb+resource combination. It is distinctly different from sibling tools like run_cli, find_file, open_folder, and speak. The timeout behavior adds further specificity.
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 security-related confirmations via the term '语音安全确认' (voice security confirmation) and provides an example, but it does not explicitly state when to use this tool versus alternatives or any prerequisites. It gives context but lacks clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
按文件名模糊搜索文件。例句：find_file(pattern='报告', directory='C:/Users/xxx/Desktop')
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | ||
| directory | No | . |
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 core behavior (fuzzy match by filename) and provides an example with pattern and directory, but it does not explain return values, scope of search (e.g., recursive), or any limitations. This is adequate but not rich.
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 one sentence with a practical example. It immediately states the purpose and includes a concrete usage illustration, making it both concise and easy to parse.
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?
For a simple two-parameter search tool, the description and example cover the essential usage. However, the lack of any output schema means the agent does not know what to expect as a return, and the description does not mention that (e.g., list of paths, matches). Given low schema coverage and no annotations, slightly more detail would improve completeness.
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 schema only provides names and a default for directory. The example partially compensates by showing pattern='报告' and directory='C:/Users/xxx/Desktop', implying that pattern is a filename keyword and directory is the folder to search. However, it does not fully explain the parameters' semantics beyond the example.
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's function: fuzzy search files by filename. It uses a specific verb (search) and resource (files), and distinguishes it from siblings like run_cli or open_folder which serve different purposes.
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 when to use it (searching for files by name) through the example, and the sibling tools are not similar, so there is no confusion. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在系统文件管理器中打开文件夹。例句：open_folder(path='C:/Users/xxx/Desktop')
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
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 only states that the tool opens a folder in the file manager, but does not mention what happens if the path does not exist, whether it creates missing folders, or if any output is returned. This is insufficient for a tool with zero annotation support.
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 a single sentence with an example, front-loaded with the core purpose. There is no wasted text, and the example is directly relevant. This is exemplary conciseness for a simple tool.
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?
For a simple one-parameter tool with no output schema, the description is minimally sufficient. However, it lacks context about edge cases (e.g., invalid paths, cross-platform behavior) and whether it returns a success indicator. Given the absence of annotations, a bit more detail would improve completeness, but it's not drastically inadequate.
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?
The schema has no description for the 'path' parameter (0% coverage), so the description must compensate. The example 'path='C:/Users/xxx/Desktop'' provides a concrete format, but it does not explicitly explain the parameter's meaning or any constraints (e.g., absolute vs. relative paths). The parameter name is self-explanatory but the description adds only marginal 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's function: 'Open folder in system file manager.' It uses a specific verb (open) and resource (folder), and the distinction from siblings like find_file (searching) and run_cli (command execution) is evident from the phrasing.
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 tool's usage is implied by the description and the provided example, but there is no explicit guidance on when to use it over alternatives or any exclusions. For instance, it doesn't mention that find_file might be more appropriate for locating files or that run_cli is for command-line operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
执行 shell 命令（白名单内直接执行，危险命令拒绝，其余需语音确认）。例句：run_cli(command='dir')
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | ||
| command | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly explains the safety triage: whitelisted commands execute, dangerous ones are rejected, and others need voice confirmation. This is valuable, though it does not mention return format or potential side effects, leaving room for improvement.
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 a single, well-structured sentence that front-loads the primary verb and resource, then adds safety behavior and an example. Every part is relevant and there is no redundant or filler content.
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 tool's complexity (shell execution with security controls) and absence of output schema/annotations, the description covers the core function, safety policy, and an example. Missing details like return value or cwd behavior are notable but do not undermine the overall utility; the description is sufficiently complete for typical agent invocation.
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?
The input schema has 0% description coverage, and the description compensates by providing a usage example ('例句：run_cli(command='dir')') that clarifies the 'command' parameter. However, the 'cwd' parameter receives no explanation, so the description only partially compensates for the schema's lack of semantic detail.
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 executes shell commands ('执行 shell 命令'), using a specific verb and resource. It also distinguishes itself from siblings by describing its safety policy (whitelist, rejection, confirmation), which is unique among the listed tools.
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 provides implicit usage guidance by explaining when commands run directly, when they are rejected, and when confirmation is needed. While it doesn't explicitly name alternatives, the inclusion of a whitelist and confirmation workflow gives practical context for when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TTS 播报一段文本（供工具回读结果）。例句：speak(text='已打开文件夹')
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states that it broadcasts text via TTS, but does not mention any side effects, return values, or whether it blocks. For a simple TTS tool, this is minimal but adequate, though more detail (e.g., no return value) would improve transparency.
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: one sentence stating purpose and one example. It is front-loaded with the core action and usage, with no wasted 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 the tool's simplicity (one string parameter, no output schema, no annotations), the description adequately covers purpose and usage. It could mention whether the tool returns anything or if it is synchronous, but for a TTS utility this is not critical.
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?
The input schema has no descriptions, and schema coverage is 0%. The description compensates with a concrete example: speak(text='已打开文件夹'), which demonstrates both the parameter name and expected format. This adds meaning beyond the schema's bare type definition.
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 does TTS (text-to-speech) for reading back results. The verb '播报' (broadcast) is specific and the resource is text. It distinguishes from siblings by its unique purpose of speaking text aloud.
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 phrase '供工具回读结果' indicates when to use: when the tool needs to read back results to the user. It does not explicitly mention alternatives, but the purpose is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clear primary purpose, but run_cli already includes voice confirmation for non-whitelisted commands, which overlaps with the standalone confirm tool. This creates minor ambiguity about when to use confirm explicitly.
All tool names are lowercase with underscores, and most follow a verb_noun pattern (run_cli, find_file, open_folder). The exceptions are the single-word verbs 'speak' and 'confirm', which deviate from the pattern but remain clear and consistent in style.
Five tools is a well-scoped set for a voice-controlled system assistant, covering command execution, file search, folder navigation, speech output, and safety confirmation without bloat.
The tool surface covers the core voice-console workflows, but lacks direct file operations (e.g., open_file, delete_file) and relies on run_cli for such tasks. Also, the standalone confirm tool isn't clearly integrated with run_cli's built-in confirmation, leaving a minor gap in the safety model.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
AI voice generation: text-to-speech and voice cloning from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/anyuer678/voiceconsole'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
