The Say MCP Server provides text-to-speech functionality utilizing macOS's built-in say command.
Speak text: Convert text to speech with customizable voice, speaking rate (1-500 wpm), and background execution options
Voice modulation: Adjust speech parameters mid-text using inline commands for rate changes, volume, pitch, emphasis, and silences
Voice selection: Choose from various voices including Alex, Victoria, and Daniel
List voices: Retrieve all available text-to-speech voices installed on the system
Integration: Works seamlessly with other MCP tools for extended workflows
Integrates with Apple Notes to read notes content aloud using text-to-speech functionality, allowing users to have their Apple Notes read to them with customizable voice properties.
Provides text-to-speech capabilities using macOS's built-in 'say' command, allowing customization of voice, speech rate, volume, pitch, and emphasis. Supports background speech processing and can be integrated with other MCP servers to read content aloud.
Can be used to read YouTube video transcripts aloud with customizable voice settings by integrating with a YouTube transcript MCP server to convert video transcripts to speech.
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., "@Say MCP Server read my meeting notes aloud using the Samantha voice"
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.
An MCP server that provides text-to-speech functionality using macOS's built-in say command.
macOS (uses the built-in say command)
Node.js >= 14.0.0
Related MCP server: Edge TTS MCP
Add the following to your MCP settings configuration file:
{
"mcpServers": {
"say": {
"command": "node",
"args": ["/path/to/say-mcp-server/build/index.js"]
}
}
}npm install say-mcp-serverThe speak tool provides access to macOS's text-to-speech capabilities with extensive customization options.
Use macOS text-to-speech to speak text aloud.
Parameters:
text (required): Text to speak. Supports:
Plain text
Basic punctuation for pauses
Newlines for natural breaks
[[slnc 500]] for 500ms silence
[[rate 200]] for changing speed mid-text
[[volm 0.5]] for changing volume mid-text
[[emph +]] and [[emph -]] for emphasis
[[pbas +10]] for pitch adjustment
voice (optional): Voice to use (default: "Alex")
rate (optional): Speaking rate in words per minute (default: 175, range: 1-500)
background (optional): Run speech in background to allow further MCP interaction (default: false)
Voice Modulation:
use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: "[[volm 0.7]] This is quieter [[volm 1.0]] and this is normal [[volm 1.5]] and this is louder",
voice: "Victoria"
}
});Dynamic Rate Changes:
use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: "Normal speed [[rate 300]] now speaking faster [[rate 100]] and now slower",
voice: "Fred"
}
});Emphasis and Pitch:
use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: "[[emph +]] Important point! [[emph -]] [[pbas +10]] Higher pitch [[pbas -10]] Lower pitch",
voice: "Samantha"
}
});With Marginalia Search:
// Search for a topic and have the results read aloud
const searchResult = await use_mcp_tool({
server_name: "marginalia-mcp-server",
tool_name: "search",
arguments: { query: "quantum computing basics", count: 1 }
});
await use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: searchResult.results[0].description,
voice: "Daniel",
rate: 150
}
});With YouTube Transcripts:
// Read a YouTube video transcript
const transcript = await use_mcp_tool({
server_name: "youtube-transcript",
tool_name: "get_transcript",
arguments: {
url: "https://youtube.com/watch?v=example",
lang: "en"
}
});
await use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: transcript.text,
voice: "Samantha",
rate: 175
}
});Background Speech with Multiple Actions:
// Start long speech in background
await use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: "This is a long speech that will run in the background...",
voice: "Rocko (Italian (Italy))",
rate: 69,
background: true
}
});
// Immediately perform another action while speech continues
await use_mcp_tool({
server_name: "marginalia-mcp-server",
tool_name: "search",
arguments: { query: "parallel processing" }
});With Apple Notes:
// Read notes aloud
const notes = await use_mcp_tool({
server_name: "apple-notes-mcp",
tool_name: "search-notes",
arguments: { query: "meeting notes" }
});
if (notes.length > 0) {
await use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: notes[0].content,
voice: "Karen",
rate: 160
}
});
}Example:
use_mcp_tool({
server_name: "say",
tool_name: "speak",
arguments: {
text: "Hello, world!",
voice: "Victoria",
rate: 200
}
});List all available text-to-speech voices on the system.
Example:
use_mcp_tool({
server_name: "say",
tool_name: "list_voices",
arguments: {}
});Add the following to your MCP settings configuration file:
{
"mcpServers": {
"say": {
"command": "node",
"args": ["/path/to/say-mcp-server/build/index.js"]
}
}
}macOS (uses the built-in say command)
Node.js >= 14.0.0
Barton Rhodes (@bmorphism) - barton@vibes.lol
MIT
List available text-to-speech voices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't describe what the output looks like (e.g., list format, voice attributes), whether it's cached, or any rate limits. This leaves significant gaps for an agent to understand the tool's behavior.
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, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loads the core purpose immediately.
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, parameterless tool with no output schema, the description is minimally adequate. However, it lacks details about the output format or behavioral traits, which would help an agent use it correctly. Without annotations, the description should do more to compensate.
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 tool has 0 parameters, and schema description coverage is 100% (though empty). The description doesn't need to add parameter details, so it meets the baseline expectation for a parameterless tool without compensation needed.
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 verb ('List') and resource ('available text-to-speech voices'), making the tool's purpose immediately understandable. It doesn't explicitly differentiate from its sibling 'speak', but the distinction is reasonably implied (listing vs. using voices).
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?
No guidance is provided on when to use this tool versus its sibling 'speak' or any alternatives. The description only states what it does, not when it should be selected over other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use macOS text-to-speech to speak text aloud
| Name | Required | Description | Default |
|---|---|---|---|
| background | No | Run speech in background to unblock further MCP interaction | |
| rate | No | Speaking rate (words per minute) | |
| text | Yes | Text to speak | |
| voice | No | Voice to use (e.g., "Alex", "Victoria", "Daniel") | Alex |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the core behavior (speaking text aloud) but lacks details about permissions needed, whether speech blocks interaction (though the 'background' parameter hints at this), error conditions, or what happens on completion. The description doesn't contradict any annotations since none exist.
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, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or unnecessary elaboration.
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 tool with 4 parameters, 100% schema coverage, and no output schema, the description provides adequate context about what the tool does but lacks details about behavioral aspects like error handling, platform dependencies, or interaction blocking. It's minimally complete but could be more informative given the absence of annotations.
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 100%, so the schema already documents all four parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high schema coverage.
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 specific action ('speak text aloud'), the technology used ('macOS text-to-speech'), and the resource ('text'). It distinguishes from the sibling tool 'list_voices' by focusing on speech output rather than voice enumeration.
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 context (macOS text-to-speech functionality) but doesn't explicitly state when to use this tool versus alternatives or any prerequisites. It mentions the sibling tool 'list_voices' only indirectly through the voice parameter example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0list_voicesspeakThe two tools have clearly distinct purposes: list_voices retrieves available options, while speak performs the core text-to-speech action. There is no overlap or ambiguity between them, making it easy for an agent to select the correct tool.
Both tools follow a consistent verb_noun pattern (list_voices and speak), with clear, descriptive names that align with their functions. There are no deviations or mixed conventions in the naming style.
With only two tools, the server feels thin for a text-to-speech domain. While it covers basic functionality (listing and speaking), it lacks operations like stopping speech, adjusting voice parameters, or managing speech queues, which are common in such systems.
The tool surface is severely incomplete for a text-to-speech server. It provides list and speak functions but misses essential operations such as pausing, resuming, or canceling speech, and offers no control over voice settings like rate or volume, limiting agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI voice generation: text-to-speech and voice cloning from any MCP client.
ElevenLabs in natural language: generate speech in any language, create and manage voices, compose m
Pronunciation scoring, speech-to-text, and text-to-speech for language learning
Create narrated presentations from HTML, poll build status, list them, read one back as text.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bmorphism/say-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server