Edict vs Mac Voice MCP
A side-by-side look at the Edict and Mac Voice MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
E
EdictSpeech-to-TextSearch your dictation transcripts and transcribe audio or video on-device, with speaker labels.37FairAuth: not declaredVerdict: choose Edict for speech-to-text work; choose Mac Voice MCP for speech-to-text as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Mac Voice MCP when
- You need dedicated capabilities in the Speech-to-Text domain.
- You prefer a local stdio subprocess transport.
- You want tools like
speak_and_listen, voice_setup.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | E Edict | |
|---|---|---|
| Category | Speech-to-Text | Speech-to-Text |
| Quality signal | 37/100 · Fair | 60/100 · Good |
| Install command | Not confirmed yet | Confirmed |
| Transport | — | Local subprocess (stdio) |
| Auth | Not declared | Not declared |
| Pricing | Not declared | Not declared |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | — | 0 |
| Directory activity | 0 views 0 installs 0 upvotes | 2 views 0 installs 0 upvotes |
| Tools | Not listed | 2 |
| Full listing | View Edict | View Mac Voice MCP |
Tools & capabilities
Edict tools
No tool names declared yet. Check the project README from the listing page.
Mac Voice MCP tools 2
speak_and_listenSay something out loud to the user and hear their spoken reply. Speaks text_to_speak through the computer's speakers, then listens like a conversation turn — it waits for the user to start talking and stops when they finish — and returns an on-device transcript of what they said. Write text_to_speak for the ear, not the screen: - 1–3 short sentences, under ~40 words; lead with the outcome, then one question. - Plain words only: no markdown, bullets, emoji, code, file paths, URLs, stack traces or tables. - Describe code instead of reading it ("I added a retry to the upload function"), say file names not paths ("in index.ts"), round numbers ("about two hundred ms"), spell out symbols. - Ask one question at a time, answerable in a few words ("Should I deploy it — yes or no?"). - Put the details (diffs, logs, links) in your normal on-screen reply, and say so out loud. - Tool output (Bash stdout, file writes) is NOT the on-screen reply. Only your own assistant message text renders. - A spoken turn with no assistant message text shows the user nothing — never skip the on-screen reply. Good: "The build passed and all tests are green. Want me to open the pull request?" Bad: "## Results\n- `npm test` ✅ 42/42\n- see /Users/x/repo/src/index.ts:120" Once the user is talking with you by voice, keep the conversation in voice: answer each transcript with another speak_and_listen call (not a text reply) until they say stop or start typing. To end voice mode, or for a one-way announcement, pass listen: false: it returns at once and speaks while you work. A reply of "(No speech detected …)" means the user did not answer — never treat it as consent. Ask once more; if still nothing, stop and say on screen that voice mode is paused and they can type to carry on (not speak: the mic is off). The "voice-mcp timing" line at the end is diagnostics: ignore it unless the user asks why things feel slow. If it reports that voice-mcp is not set up, call voice_setup.voice_setupCheck whether this computer has everything speak_and_listen needs — text-to-speech, a microphone recorder (SoX), whisper.cpp speech-to-text and the speech model — and optionally install what's missing. Anything already installed is reused (an existing model elsewhere on disk is symlinked, not re-downloaded). Call it with install=false (the default) first and tell the user what is missing. Only call it with install=true after the user agrees: it runs `brew install` for the missing packages and downloads the speech model once. It never uninstalls or changes anything else. kokoro=true (also only after the user agrees) installs the optional Kokoro voice: more natural than the built-in one, runs on this Mac, about 1 GB on disk. Once installed it's used automatically; the built-in voice stays as the fallback. If it reports INSTALLING, the install continues in the background — wait a minute and call it again to check.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Edict
No confirmed install command for Edict yet — follow the setup steps linked from its listing page rather than a guessed package name.
Mac Voice MCP
{
"mcpServers": {
"mac-voice-mcp": {
"command": "npx",
"args": [
"-y",
"mac-voice-mcp@latest"
]
}
}
}
Frequently asked questions
Edict is categorized under Speech-to-Text and uses an install path we have not confirmed yet. Mac Voice MCP belongs to Speech-to-Text and uses a local stdio subprocess. Pick Edict for speech-to-text work and Mac Voice MCP for speech-to-text.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client. Edict has no confirmed install command yet — follow its own setup instructions.
Edict has no declared pricing — check the project's own site. Mac Voice MCP has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add edict and mac-voice-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Edict has a quality signal of 37/100 (Fair) with 0 views, 0 installs and 0 GitHub stars. Mac Voice MCP has 60/100 (Good) with 2 views, 0 installs and 0 GitHub stars.