webcam-mcp

一个 MCP 服务器，让编码代理拥有宿主机器上的眼睛和耳朵：网络摄像头静态图像、麦克风语音转文字，以及可选的文字转语音回复。

一切都在本地运行。ffmpeg 捕获帧，faster-whisper 在 CPU 上转写，openWakeWord 处理唤醒词。音频、视频、转录文本或图像不会发送到任何地方。服务器唯一一次网络调用是首次转写时从 Hugging Face 一次性下载模型。

它存在的原因：一个能读取屏幕却看不到你、听不到你的编码代理，会错过对话的整整一个侧面。这为任何在带有摄像头和麦克风的机器上的 MCP 客户端弥补了这一缺口。

工具

Related MCP server: Voice MCP

设置

需要 Python 3.11+、PATH 上的 ffmpeg，以及 uv。

uv sync

独立运行以确认它能启动：

uv run server.py

它处于等待 MCP stdio 输入的状态，因此在客户端连接之前看起来什么都不做。这是正常的。按 Ctrl+C 退出。

在 MCP 客户端中将其注册为 stdio 命令，模式与任何其他服务器相同。

用血泪换来的经验

• mcp 被固定在 2 以下。mcp 2.0.0 将 mcp.server.fastmcp 重命名为 mcp.server.mcpserver，这会在服务器启动时静默破坏导入。 请停留在实际能加载的 1.x 版本。

• 预热时间不是多余的。网络摄像头打开时是暗的，自动曝光需要 一点时间。低于大约一秒时，帧会以黑色或曝光不良的状态返回。 默认 1.5 秒是有原因的。

• 捕获失败几乎总是因为设备已被占用。Zoom、Teams 或 浏览器标签页持有摄像头会产生 ffmpeg I/O 错误。工具会检测到 这一点并明确说明。第二常见的原因是操作系统隐私设置 阻止桌面应用访问摄像头或麦克风。

• Whisper 模型大小：base（默认）是速度和准确度的最佳平衡点。 small 在浓重口音上明显更好，但计算量约为三倍。 首次下载后，模型会缓存在用户配置文件下。

• 模型是惰性加载的，并在服务器进程的生命周期内按大小保持缓存。 每次调用重新加载会花费数秒和大量内存。

• 默认唤醒模型是 openWakeWord 的预训练 hey_jarvis。无需训练， 无需数据集，开箱即用。在默认 0.5 阈值下它很可靠， 误报不是实际需要担心的问题。

语音和语音限制

speak 默认使用旧版 SAPI 声音。它们听起来很机械。现代操作系统 的自然声音要好得多，安装后即可在本地运行，speak 会在它们存在后自动选用。

诚实的架构限制是，这是一个四跳管道：语音转 文本、文本转模型、模型转文本、文本转语音。它比原生 音频模型慢，而且将语音转换为文本会在模型看到文字之前丢弃语调、音量和 情感。一跳的原生音频设置可以解决这两个问题， 但这需要一个原生接受音频的提供商。在文本 MCP 框架内，四跳是正确的设计，而不是捷径。

capture_stitched 只有在第二个摄像头实际连接时才值得使用。 否则图像的后半部分是连接旋转指示器。

输出文件

捕获默认输出到带有时间戳名称的临时文件夹。传入 output_path 可以将 它们发送到持久位置。record_and_transcribe 之后会删除其 WAV， 除非你传入 keep_audio=True。

这里不会自动清理旧捕获。请偶尔清理该文件夹。

自测

uv run server.py --selftest

打印设备列表，无需 MCP 客户端，这是确认安装正常的最快方式。

许可证

MIT。参见 LICENSE。