Skip to main content
Glama
nocoo

MCP Make Sound

by nocoo
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

🔊 MCP Make Sound

A Model Context Protocol (MCP) server that provides comprehensive sound playback capabilities for macOS. This server allows AI assistants and other MCP clients to play system sounds, text-to-speech, and custom audio files for rich audio feedback.

✨ Features

  • 🔔 Simple Sound Methods: Pre-configured info, warning, and error sounds

  • 🎵 Custom System Sounds: Play any of the 14 built-in macOS sounds

  • 🗣️ Text-to-Speech: Convert text to speech with customizable voices

  • 📁 File Playback: Play custom audio files from disk

  • 🚀 Built with TypeScript and the MCP SDK

  • 🪶 Lightweight and easy to integrate

Related MCP server: MCP Sound Tool

📋 Requirements

  • 🍎 macOS (uses afplay and system sounds)

  • 🟢 Node.js 18+

  • 📝 TypeScript

🚀 Installation

  1. Clone this repository:

git clone <repository-url>
cd mcp-make-sound

  1. Install dependencies:

npm install

  1. Build the project:

npm run build

💡 Usage

🎵 Running the Server

Start the MCP server:

npm start

For development with auto-reload:

npm run dev

🎯 Example: Claude Integration with Warp Terminal

Here's how you can set up the MCP sound server to provide audio feedback when AI tasks complete in Warp terminal:

Configuration Rule: "When AI is done, use mcp-make-sound to play a sound. The MCP supports error, info and success. Play the right sound based on AI task outcome."

This setup allows you to:

  • 🔔 Hear a pleasant chime when tasks complete successfully

  • ⚠️ Get an alert sound for warnings or partial completions

  • ❌ Receive clear audio feedback for errors or failures

The audio feedback helps you stay focused on other work while knowing immediately when your AI assistant has finished processing your requests.

🛠️ Available Tools

The server provides four tools:

Simple Sound Methods (Legacy)

play_info_sound

  • Description: Play an informational system sound

  • Parameters: None

  • Sound: Glass.aiff

play_warning_sound

  • Description: Play a warning system sound

  • Parameters: None

  • Sound: Purr.aiff

play_error_sound

  • Description: Play an error system sound

  • Parameters: None

  • Sound: Sosumi.aiff

Advanced Sound Method

play_sound

  • Description: Play various types of sounds with customizable parameters

  • Parameters:

    • type (required): "system", "tts", or "file"

    • Additional based on type (see examples below)

📖 Usage Examples

System Sounds

Play any of the 14 built-in macOS sounds:

{
  "name": "play_sound",
  "arguments": {
    "type": "system",
    "name": "Basso"
  }
}

Available system sounds: Basso, Blow, Bottle, Frog, Funk, Glass, Hero, Morse, Ping, Pop, Purr, Sosumi, Submarine, Tink

Text-to-Speech

Convert text to speech with optional voice selection:

{
  "name": "play_sound",
  "arguments": {
    "type": "tts",
    "text": "Hello, this is a test message",
    "voice": "Albert"
  }
}

Without voice (uses system default):

{
  "name": "play_sound",
  "arguments": {
    "type": "tts",
    "text": "Task completed successfully"
  }
}

Supported voices:

  • English: Albert, Alice, Bad News, Bahh, Bells, Boing, Bruce, Bubbles, Cellos, Daniel, Deranged, Fred, Good News, Hysterical, Junior, Kathy, Pipe Organ, Princess, Ralph, Trinoids, Whisper, Zarvox

  • International: Anna, Amélie, Daria, Eddy, Fiona, Jorge, Juan, Luca, Marie, Moira, Nora, Rishi, Samantha, Serena, Tessa, Thomas, Veena, Victoria, Xander, Yelda, Zosia

Note: If an unsupported voice is specified, the system will gracefully fall back to the default voice and continue playback.

Custom Audio Files

Play audio files from disk:

{
  "name": "play_sound",
  "arguments": {
    "type": "file",
    "path": "/Users/username/Music/notification.mp3"
  }
}

Supports common audio formats: .aiff, .wav, .mp3, .m4a, etc.

🔒 Security & Limitations

  • System Sounds: Only the 14 official macOS sounds are allowed

  • Text-to-Speech:

    • Text limited to 1000 characters maximum

    • Voice validation with graceful fallback to system default

    • Curated list of 43+ supported voices for security

  • File Playback: Requires absolute paths and validates file existence

🔗 Integration with MCP Clients

This server can be integrated with any MCP-compatible client, such as:

  • 🤖 Claude Desktop

  • 🛠️ Custom MCP clients

  • 🧠 AI assistants that support MCP

MCP Configuration Example

Add this to your MCP client configuration:

{
  "mcp-make-sound": {
    "command": "node",
    "args": [
      "/Users/nocoo/Workspace/mcp-make-sound/dist/index.js"
    ],
    "env": {},
    "working_directory": "/Users/nocoo/Workspace/mcp-make-sound",
    "start_on_launch": true
  }
}

Example tool calls:

{
  "name": "play_info_sound",
  "arguments": {}
}
{
  "name": "play_sound",
  "arguments": {
    "type": "system",
    "name": "Hero"
  }
}

🛠️ Development

📁 Project Structure

mcp-make-sound/
├── src/
│   ├── index.ts          # Main server implementation
│   └── __tests__/        # Unit tests
│       └── sound.test.ts # Sound system tests
├── dist/                 # Compiled JavaScript output
├── eslint.config.js      # ESLint configuration
├── vitest.config.ts      # Vitest test configuration
├── package.json          # Project configuration
├── tsconfig.json         # TypeScript configuration
└── README.md            # This file

📜 Scripts

Build & Run

  • npm run build - 🔨 Compile TypeScript to JavaScript

  • npm start - ▶️ Run the compiled server

  • npm run dev - 🔄 Development mode with auto-rebuild and restart

  • npm run kill - 🛑 Stop all running MCP server instances

Code Quality & Testing

  • npm run lint - 🔍 Check code style and errors

  • npm run lint:fix - 🔧 Fix auto-fixable linting issues

  • npm run test - 🧪 Run tests in watch mode

  • npm run test:run - ✅ Run tests once

  • npm run test:ui - 🎛️ Run tests with interactive UI

⚙️ How It Works

  1. The server implements the MCP protocol using the official SDK

  2. It exposes four tools for different sound capabilities

  3. When a tool is called, it uses macOS commands:

    • afplay for audio file playback (system sounds and custom files)

    • say for text-to-speech synthesis

  4. System sounds are located in /System/Library/Sounds/

  5. The server communicates over stdio transport

🔧 Technical Details

  • 🔌 Transport: Standard I/O (stdio)

  • 📡 Protocol: Model Context Protocol (MCP)

  • 🎧 Audio Backend: macOS afplay and say commands

  • 🎵 Sound Files: System .aiff files, custom audio files, and synthesized speech

🚨 Error Handling

The server includes comprehensive error handling:

  • Validates tool names and parameters

  • Handles afplay and say command failures

  • Validates required parameters for each sound type

  • Returns appropriate error messages to clients

  • Graceful server shutdown on errors

📄 License

MIT License

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

🎼 Sound Capabilities

Simple Methods (Legacy)

  • 🔔 Info: Glass.aiff - A pleasant chime sound

  • ⚠️ Warning: Purr.aiff - A gentle alert sound

  • ❌ Error: Sosumi.aiff - A distinctive error sound

Advanced Method (play_sound)

  • 🎵 14 System Sounds: All built-in macOS sounds available

  • 🗣️ 50+ TTS Voices: Multiple languages and character voices

  • 📁 Custom Files: Support for .aiff, .wav, .mp3, .m4a, and more

These capabilities provide rich audio feedback options for any application need.

Available Tools

4 tools
play_error_soundB

Play an error system sound

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/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 states the action ('Play') but doesn't describe what 'Play' entails (e.g., audio output, duration, system requirements) or any side effects (e.g., interruptions, permissions needed). This leaves significant gaps in understanding 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavioral context (e.g., how the sound is played, any system dependencies). For such a straightforward tool, this is acceptable but not comprehensive.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, which is correct for a parameterless tool, earning a high baseline score for not adding unnecessary information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Play') and resource ('error system sound'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'play_warning_sound' or 'play_info_sound' beyond the 'error' qualifier, which is why it doesn't reach a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'play_warning_sound' or 'play_sound'. It lacks explicit context, exclusions, or comparisons to sibling tools, leaving the agent to infer usage based on the 'error' keyword alone.

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

play_info_soundB

Play an informational system sound

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('play') but doesn't describe what happens when invoked (e.g., audible output, system behavior, permissions needed, or side effects). This leaves significant gaps for understanding 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized for a simple, parameterless tool and is front-loaded with essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless tool with no output schema, the description adequately covers the basic purpose. However, it lacks behavioral context (e.g., what 'play' entails, system requirements, or error conditions) that would be helpful given the absence of annotations and output schema.

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?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose without unnecessary detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Play an informational system sound' clearly states the action (play) and resource (informational system sound). It distinguishes from sibling tools like 'play_error_sound' and 'play_warning_sound' by specifying the type of sound, though it doesn't explicitly differentiate from the generic 'play_sound' tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'play_error_sound', 'play_warning_sound', or 'play_sound'. It doesn't specify appropriate contexts, exclusions, or prerequisites for usage.

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

play_soundC

Play various types of sounds with customizable parameters

ParametersJSON Schema
NameRequiredDescriptionDefault
typeYesType of sound to play
nameNoSystem sound name (required when type is "system")
textNoText to speak (required when type is "tts")
voiceNoVoice name (optional, used with type "tts", uses system default if not specified)
pathNoAbsolute path to audio file (required when type is "file")

TDQS

C2.6/5.0
Behavior2/5

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 mentions 'customizable parameters' but fails to explain key traits like whether playback is blocking or non-blocking, error handling (e.g., if a file path is invalid), or system dependencies (e.g., TTS availability). This leaves significant gaps in understanding 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core purpose ('play various types of sounds'). It avoids redundancy but could be more structured by explicitly mentioning the parameter types (e.g., system, TTS, file) to enhance clarity without adding unnecessary length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of handling multiple sound types (system, TTS, file) with no annotations or output schema, the description is incomplete. It lacks details on behavioral aspects like playback effects, error responses, or how outputs are handled, making it insufficient for safe and effective use by an AI agent.

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?

The input schema has 100% description coverage, providing clear details for all parameters, including enums and requirements. The description adds minimal value beyond this, as it only vaguely references 'customizable parameters' without elaborating on their semantics or interactions, aligning with the baseline score for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool 'play[s] various types of sounds with customizable parameters', which clarifies the action (play) and resource (sounds) but is vague about scope and differentiation. It does not specify what 'various types' means or how it differs from sibling tools like play_error_sound, leaving room for ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternatives, such as the sibling tools (play_error_sound, play_info_sound, play_warning_sound). The description implies general sound playback but offers no context for choosing between this and more specific tools, leading to potential misuse.

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

play_warning_soundB

Play a warning system sound

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/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 states the action ('Play') but doesn't describe what happens—e.g., whether it's audible, requires permissions, has side effects, or how it interacts with the system. For a tool with zero annotation coverage, this is a significant gap in transparency.

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?

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving maximum clarity in minimal space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no output schema), the description is minimal but adequate for basic understanding. However, with no annotations and no output schema, it lacks details on behavior, effects, or return values, which could be important for an agent to use it correctly in context. It's incomplete for a tool that might have auditory or system-level implications.

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?

The tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. Baseline is 4 for zero parameters, as there's nothing to compensate for.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Play') and the resource ('a warning system sound'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its siblings (play_error_sound, play_info_sound, play_sound) beyond specifying 'warning' versus other sound types, which is somewhat implicit but not explicit about distinctions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus its siblings or alternatives. It implies usage for warning scenarios but doesn't specify contexts, exclusions, or comparisons with other sound-playing tools, leaving the agent to infer based on the name alone.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0
Disambiguation2/5

The tool set has significant ambiguity, as 'play_sound' appears to be a general-purpose tool that can handle what the three specific tools (error, info, warning) do, making it unclear when to choose one over the other. This overlap could easily lead to misselection by agents, as the specific tools seem redundant given the customizable 'play_sound'.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with 'play_' as the prefix, using snake_case throughout. This predictability makes it easy for agents to parse and understand the naming conventions without confusion.

Tool Count3/5

With 4 tools, the count is borderline for the server's purpose of playing sounds. It feels slightly thin, as the domain might benefit from more specific or varied sound operations, but it's not extreme. The tools cover basic sound types, though the overlap reduces the effective utility of having four separate tools.

Completeness3/5

The tool set covers basic sound playback for error, info, warning, and customizable sounds, which aligns with the server's name 'Make Sound'. However, there are notable gaps, such as missing operations like listing available sounds, stopping sounds, or adjusting volume, which could limit agent workflows in more complex scenarios.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Notify Server

    Cactusinhand
    A
    license
    B
    quality
    F
    maintenance
    A Model Context Protocol service that sends desktop notifications and alert sounds when AI agent tasks are completed, integrating with various LLM clients like Claude Desktop and Cursor.
    1
    54
    MIT

  • MCP Sound Tool

    tijs
    A
    license
    A
    quality
    F
    maintenance
    A Model Context Protocol implementation that plays sound effects (completion, error, notification) for Cursor AI and other MCP-compatible environments, providing audio feedback for a more interactive coding experience.
    3
    1
    MIT

  • ChatGPT MCP Server

    xncbf
    A
    license
    B
    quality
    C
    maintenance
    A Model Context Protocol server that allows AI assistants to communicate with the ChatGPT desktop app on macOS, enabling users to send prompts to ChatGPT from any MCP-compatible assistant.
    3
    78
    MIT

Appeared in Searches

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/nocoo/mcp-make-sound'

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