Skip to main content
Glama

Speech MCP Server for MacOS

This is a Model Context Protocol (MCP) server that provides text-to-speech capabilities using OmniVoice AI neural Voice Design and native macOS say. It allows AI agents (like Google Antigravity, Claude Desktop, Cursor, Windsurf, or Codex) to speak to you directly with unique, persona-tailored voices.

Note: This server is designed for macOS systems (with Apple Silicon MPS acceleration).

MCP Speak Persona Fleet

Explore the interactive web showcase and prompt compiler: https://fellowgeek.github.io/mcp-speak/ Browse the AI Agent Persona Catalog & Avatars: PERSONAS.md

Features

  • OmniVoice Voice Cloning: Drop reference audio clips into voices/<persona>.wav to clone real vocal timbre and identity with zero configuration.

  • OmniVoice Voice Design Fallback: Generates custom persona voices from natural language style prompts when no reference audio file is present.

  • 3-Tier Robust Voice Pipeline: Seamlessly falls back: Cloned Voice (.wav)Voice Design (instruct)macOS native say.

  • Consistent Neural Speech: Generates complete messages in a continuous synthesis pass for seamless, uniform vocal timbre and expression throughout.

  • Interactive Setup Wizard: Run python3 setup.py to choose your TTS engine (OmniVoice or macOS say), select agent personas, and generate instruction files (AGENTS.md, GEMINI.md, CLAUDE.md, .cursorrules).

  • Sequential Speech Queue: Strict FIFO queue ensures multiple non-blocking speech calls never talk over each other.

  • Automatic Fallback: Seamlessly falls back to native macOS say if neural models cannot be loaded.

  • Auto-Provisioning Virtual Environment: Uses run.sh to automatically create a local .venv (Python 3.12) and install dependencies.

  • Blocking & Non-Blocking Support: Choose between waiting for speech to finish (speak) or continuing immediately (speak_non_blocking).

Related MCP server: Yak MCP

Prerequisites

  • MacOS

  • Python 3 installed

Quick Start (Interactive Setup)

  1. Clone this repository or navigate to the project folder:

    git clone https://github.com/fellowgeek/mcp-speak.git
    cd mcp-speak
  2. Run the interactive setup wizard (automatically configures MCP settings, sets permissions, and creates instruction files):

    python3 setup.py

Non-Interactive Setup (CLI Options)

You can also run setup.py with command-line flags for automated provisioning:

# Example: Configure all tools with OmniVoice on MPS using the Neutral Mainframe persona
python3 setup.py --non-interactive --tool 8 --engine omnivoice --device mps --persona neutral_mainframe --name "Mr. Reed"

# Example: Configure Cursor locally with macOS say and Sarcastic Senior
python3 setup.py --tool 4 --engine say --persona sarcastic_senior --local

Flag

Options / Format

Description

--tool

1-8

1: Antigravity, 2: Claude Desktop, 3: Claude CLI, 4: Cursor, 5: Windsurf, 6: Codex Desktop, 7: Codex CLI, 8: All

--engine

omnivoice, say

Select text-to-speech engine

--device

auto, mps, cuda, cpu

Compute device for OmniVoice neural synthesis

--persona

Persona key (e.g. neutral_mainframe)

Persona prompt name

--name

String (e.g. "Mr. Reed")

User name for personalized agent address

--target

File path

Custom target agent instruction file (e.g. AGENTS.md)

--global / --local

Flags

Write instructions globally to user profile (default) or locally in workspace

--no-config-edit

Flag

Skip modifying tool JSON / TOML configuration files

--non-interactive

Flag

Run automatically with defaults or provided flags


Persona Voice Audition (test_personas.py)

Preview and compare persona vocal identities directly in the terminal before configuring your AI agent:

# Launch interactive terminal audition menu
python3 test_personas.py

# Audition a specific persona
python3 test_personas.py --persona agent_smith

# Audition all personas sequentially
python3 test_personas.py --all

# Test with custom speech text and specific engine
python3 test_personas.py --persona neutral_mainframe --engine omnivoice --text "System operational. All parameters within nominal thresholds."

# Audition an arbitrary WAV audio reference file for voice cloning
python3 test_personas.py --persona pun_master --voice-file voices/pun_master.wav

Neural Voice Cloning (voices/)

You can clone any persona's voice simply by dropping a 3-10 second .wav audio sample into the voices/ directory:

voices/
├── README.md
├── pun_master.wav         # Reference audio for pun_master
├── pun_master.txt         # (Optional) Transcript for faster startup without Whisper
├── nature_narrator.wav
└── agent_smith.wav

How the 3-Tier Voice Pipeline Works:

  1. Tier 1 (Cloned Voice): If voices/<persona_name>.wav exists, OmniVoice clones the voice timbre from that recording.

  2. Tier 2 (Voice Design): If no .wav file is present, OmniVoice falls back to the natural language instruct voice design prompt.

  3. Tier 3 (macOS Native Fallback): If neural synthesis fails or is disabled, the server automatically speaks using macOS say.

Tip: Adding an optional transcript file (e.g. voices/pun_master.txt) with the exact spoken words in the audio allows OmniVoice to tokenize the reference audio immediately without needing to load or run the Whisper ASR model.


MCP Tool Interface Reference

The MCP Speak server exposes two tools via FastMCP:

Tool

Mode

Description

speak(message: str)

Blocking

Synthesizes and speaks the message aloud, waiting for audio playback to finish completely before returning.

speak_non_blocking(message: str)

Non-Blocking

Queues the message into a strict sequential FIFO queue and returns immediately. Subsequent calls play in order without talking over each other.


Configuration & Environment Variables

The server loads configuration from config.json at startup:

{
  "engine": "omnivoice",
  "persona": "neutral_mainframe",
  "device": "auto",
  "voices_dir": "voices",
  "fallback_to_say": true
}

Environment Variable Overrides

Runtime parameters can be overridden via environment variables without modifying config.json:

  • MCP_SPEAK_ENGINE: Set to "omnivoice" or "say".

  • MCP_SPEAK_PERSONA: Set to any persona key (e.g. "agent_smith", "neutral_mainframe").

  • MCP_SPEAK_DEVICE: Set to "auto", "mps", "cuda", or "cpu".

  • MCP_SPEAK_VOICES_DIR: Set to a custom directory path containing reference audio files.


Client Integration

Manual Configuration (Optional)

If you prefer to configure your MCP client manually, add the "voice" server pointing to run.sh:

1. Google Antigravity (AGY)

Edit ~/.gemini/antigravity/mcp_config.json:

{
  "mcpServers": {
    "voice": {
      "command": "/ABSOLUTE/PATH/TO/run.sh"
    }
  }
}

2. Claude CLI (Claude Code)

claude mcp add --scope user voice -- /ABSOLUTE/PATH/TO/run.sh

3. Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "voice": {
      "command": "/ABSOLUTE/PATH/TO/run.sh"
    }
  }
}

4. Cursor IDE

Edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "voice": {
      "command": "/ABSOLUTE/PATH/TO/run.sh"
    }
  }
}

5. Windsurf Editor

Edit ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "voice": {
      "command": "/ABSOLUTE/PATH/TO/run.sh"
    }
  }
}

6. Codex Desktop

Edit ~/.codex/config.toml:

[mcp_servers.voice]
command = "/ABSOLUTE/PATH/TO/run.sh"

7. Codex CLI

codex mcp add voice -- /ABSOLUTE/PATH/TO/run.sh

Agent Personalization & Personas

AI agents (Google Antigravity, Claude Code, Claude Desktop, Cursor, Windsurf, Codex) can be customized with unique vocal personalities, tones, and behavioral boundaries.

View the complete persona gallery, detailed system prompts, and avatar showcase in PERSONAS.md.

Available Personas Overview

Avatar

Persona

Key

Character & Style

The Sarcastic Senior

sarcastic_senior

Intelligent, unimpressed, and slightly judgmental.

The Over-Eager Intern

over_eager_intern

Pathologically optimistic and desperate for approval.

The Existential Emo

existential_emo

Melancholic, hopeless, and convinced the code will fail.

The Pun Master

pun_master

Relentless wordplay and context-aware dad jokes.

The Tech Priest

tech_priest

Treats every line of code as a holy sacrament.

Agent Smith

agent_smith

Formal, controlled, precise, and menacingly condescending.

The Gothic Poet

poet

Macabre, haunting, and strictly bound by rhyme.

The Nature Narrator

nature_narrator

Observing the developer in their natural habitat with awe.

The Fiery Head Chef

head_chef

Demands culinary perfection—no raw spaghetti code!

The Neutral Mainframe

neutral_mainframe

Cold, calculating, emotionless, and 100% objective.

How Prompts Are Built

Every agent prompt consists of:

  1. Base Guidelines (personas/base_guidelines.md): Voice-first protocol and brevity constraints.

  2. Chosen Persona (personas/): Personality quirks, tone, and strict execution boundaries.

  3. Name Personalization (Optional): Addressing the user naturally by name.

Running python3 setup.py automatically generates and updates your agent instructions (AGENTS.md, GEMINI.md, CLAUDE.md, .cursorrules). For manual configuration steps, full system prompts, and avatars, see PERSONAS.md.

Optimizing Voice Quality

1. Neural Voice Synthesis with OmniVoice (Primary Engine)

OmniVoice delivers high-quality, expressive neural speech out of the box using style prompts tailored to each persona. To achieve the highest vocal fidelity:

  • Neural Voice Cloning: Place a 3 to 10 second clean .wav audio sample in the voices/ directory matching the persona key (e.g. voices/sarcastic_senior.wav). OmniVoice clones the vocal timbre, tone, and inflection directly from the audio file without additional training.

  • Fast Startup with Transcripts: Include an optional matching transcript text file (e.g. voices/sarcastic_senior.txt) containing the exact spoken text. This enables instant tokenization and skips loading the Whisper ASR model on startup.

  • Audio Quality Guidelines: Use clean recordings without background noise, music, or heavy reverb. Standard WAV format sampled at 24kHz or higher is recommended.

  • Voice Design Fallback: When no audio sample is present in voices/, OmniVoice uses natural language instructions (pitch, accent, speed, and character traits) configured in config.json.

2. macOS System Voice Configuration (Fallback Engine)

When using native macOS say (either as a fallback or in lightweight mode), voice quality depends on the active system voice. Configuring a modern Siri or Enhanced voice significantly improves realism and fluidity:

  1. Open System Settings on your Mac.

  2. Navigate to Accessibility > Spoken Content.

  3. Click the System Voice dropdown menu.

  4. Select Manage Voices....

  5. Locate and download high-quality Siri voices (e.g., Siri Voice 1, 2, 3, 4) or voices marked as Enhanced / Premium (e.g., Ava, Evan, Zoe).

  6. Set the downloaded voice as your default System Voice.

Note: Siri and Enhanced voices provide significantly more natural cadence, phrasing, and pronunciation compared to legacy system voices.

Testing & Validation

Run the automated test suite to verify configuration loading, engine fallbacks, single-pass synthesis, and sequential queue behavior:

# Run unit tests
python3 tests/test_speak_server.py

# Or run via unittest discovery in the virtual environment
.venv/bin/python -m unittest discover tests

Available Tools

2 tools
speakA

Speaks the provided message aloud using neural Voice Design or macOS say. Blocking: waits until playback has completely finished before returning.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior4/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 of behavioral disclosure. It discloses the most important behavioral trait—the call blocks until playback finishes—and the fallback mechanism (neural Voice Design vs macOS say). Minor undisclosed details like failure/error behavior and audio-device requirements prevent a 5, but the description covers the critical behavioral facts.

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 sentences, zero filler. The primary action is front-loaded, followed by the one behavioral qualifier that matters (blocking). Every clause 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?

For a one-parameter tool with an output schema present, the description covers what the tool does, how it does it, and the key blocking behavior that differentiates it from its sibling. It falls just short of a 5 by not naming the alternative or noting edge cases, but the sibling's self-explanatory name largely mitigates that 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?

Schema coverage is 0%, so the description must compensate. "Speaks the provided message aloud" clarifies that the message parameter is the text to be converted to speech, which is the essential semantic. For a single self-evident parameter this is adequate, though the description adds no length limits or formatting requirements.

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?

"Speaks the provided message aloud using neural Voice Design or macOS say" gives a specific verb, resource, and mechanism. The explicit "Blocking" qualifier further distinguishes this tool from its speak_non_blocking sibling, so an agent can tell them apart without inspecting either further.

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's "Blocking: waits until playback has completely finished before returning" gives a clear decision criterion between this tool and the sibling speak_non_blocking. However, it never names the sibling or explicitly states when not to use this tool, so the routing is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

speak_non_blockingA

Speaks the provided message aloud using neural Voice Design or macOS say. Non-blocking: queues the message immediately and returns. Guarantees subsequent messages will be queued sequentially and not talk over each other.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well: it discloses the non-blocking nature, immediate return, queueing, and sequential playback guarantee. It also names the synthesis backends ('neural Voice Design or macOS say'). It stops short of covering failure modes or return-value details, but the key behavioral traits are 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?

Three sentences, all relevant and front-loaded. The first sentence states the core action, the second explains the non-blocking semantics, and the third covers the queueing guarantee. No filler or redundancy.

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 low-complexity tool with one parameter and an output schema, the description covers the operation, the key behavioral distinction, and the queueing guarantee. It lacks explicit guidance on when to use this over the sibling 'speak', but is otherwise complete for invoking the tool 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%, but the description references 'the provided message', making it clear that the 'message' parameter is the text to be spoken. There are no constraints, examples, or format details in either the schema or description, but with a single simple string parameter the description provides just enough meaning.

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 ('Speaks') and resource ('the provided message aloud'), and immediately distinguishes the tool through its name and 'Non-blocking' behavior. The sibling tool 'speak' is implicitly differentiated by the guarantee of queueing and immediate return.

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 clearly conveys that this tool is non-blocking and queues messages, which implies when it should be used. However, it does not explicitly mention the sibling 'speak' or state when to choose this tool over it, leaving the routing decision mostly to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv1.1.1
    • Changedspeak1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "properties": {
        +    "result": {
        +      "title": "Result",
        +      "type": "string"
        +    }
        +  },
        +  "required": [
        +    "result"
        +  ],
        +  "title": "speakOutput",
        +  "type": "object"
        +}
    • Changedspeak_non_blocking1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "properties": {
        +    "result": {
        +      "title": "Result",
        +      "type": "string"
        +    }
        +  },
        +  "required": [
        +    "result"
        +  ],
        +  "title": "speak_non_blockingOutput",
        +  "type": "object"
        +}
  2. 2 tool updatesv1.0.0
    • First observedspeak
    • First observedspeak_non_blocking

TDQS

A4.1/5.0
Disambiguation4/5

The two tools are nearly identical in purpose but clearly distinguished by blocking behavior in names and descriptions. An agent could still confuse them if not reading carefully, but the distinction is explicit.

Naming Consistency5/5

Both tools start with 'speak' and use a clear suffix '_non_blocking' for the variant. The naming pattern is entirely consistent and predictable.

Tool Count3/5

With only two tools, the server feels minimal. The pair is reasonable for a focused text-to-speech utility, but it is on the thin side of the recommended range.

Completeness3/5

The core speak operation is covered in both blocking and non-blocking forms, but there is no way to configure voice, rate, or stop speech. These are notable gaps for a text-to-speech server.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables agents to convert text to speech using OpenAI's TTS models with voice selection, delivery instructions, and queue-based audio playback. Supports both blocking and non-blocking modes for flexible audio generation and playback control.
    3
    BSD 3-Clause
  • F
    license
    Not graded
    quality
    C
    maintenance
    Enables coding agents to speak aloud using text-to-speech functionality. Works with agents running inside devcontainers and provides configurable voice settings for creating chatty AI companions.
    4
    -

Latest Blog Posts

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/fellowgeek/mcp-speak'

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