Skip to main content
Glama
sawa-zen

Sound Effects MCP

by sawa-zen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

サウンドエフェクトMCP 🎵

様々なシチュエーションに応じた効果音を再生するMCPサーバーです。

特徴

  • 🎵 3種類の効果音（完了、ニュータイプ音、エラー音）

  • 🚀 Claude Desktopとの連携

  • 🛠️ シンプルなMCPツール

  • 🎯 作業効率とエンターテイメント性の両立

Related MCP server: Cursor Sound MCP

使用方法

Claude Code経由での使用

Claude CodeでプロジェクトレベルでこのMCPを追加：

claude mcp add sound-effects-mcp -s project -- npx -y sound-effects-mcp
WARNING

環境によってはnpxが見つからない場合があります。その場合はwhich npxでフルパスを確認して使用してください：

# npxのフルパスを確認
which npx

# フルパスを使用（例）
claude mcp add sound-effects-mcp -s project -- /usr/local/bin/npx -y sound-effects-mcp

Claude Desktopとの連携

Claude Desktopの設定ファイル（~/Library/Application Support/Claude/claude_desktop_config.json）に以下を追加：

{
  "mcpServers": {
    "sound-effects-mcp": {
      "command": "npx",
      "args": ["-y", "sound-effects-mcp"]
    }
  }
}

利用可能なツール

play-sound-effect

様々な効果音を再生します。

パラメータ:

  • sound (必須): 効果音の種類

    • complete: 完了音（メロディ）

    • newtype: ニュータイプ音（キュピーン）

    • error: エラー音（警告音）

  • message (オプション): メッセージ

使用例:

play-sound-effect を使って、complete音でタスク完了を知らせてください

list-sound-effects

利用可能な効果音の一覧を表示します。

使用例:

list-sound-effects で効果音一覧を見せてください

便利なプロンプト設定

Claude CodeのCLAUDE.mdファイルに以下を追加すると、自動的に適切なタイミングで効果音が再生されます：

# サウンドエフェクト
- タスクやプロジェクトが完了した時は `play-sound-effect` の `complete` 音を再生してください
- 問題の原因が特定できた時は `play-sound-effect` の `newtype` 音を再生してください
- 重要な気づきやひらめきがあった時は `play-sound-effect` の `newtype` 音を再生してください

対応プラットフォーム

  • macOS: 音声ファイル（MP3）をafplayコマンドで再生

音声ファイルは初回実行時に自動的にダウンロードされ、一時ディレクトリに保存されます。

使用用途

このMCPサーバーは以下のような場面で活用できます：

  • 完了音: プロジェクト完了、長時間処理の終了、タスク完了時

  • ニュータイプ音: 特別な達成、ひらめき時、問題の原因が特定できた時（ネタ要素）

  • エラー音: エラー発生時、警告時、注意が必要な場面

作業効率向上と楽しさを両立できるツールです。

開発者向け情報

開発・コントリビューションについては CONTRIBUTING.md をご覧ください。

ライセンス

MIT License

Available Tools

2 tools
list-sound-effectsB

利用可能な効果音の一覧を表示します

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. It states this is a display/list operation, which implies it's read-only and non-destructive. However, it doesn't disclose any behavioral traits like pagination, sorting, filtering, rate limits, authentication needs, or what format the list returns. For a tool with zero annotation coverage, this is insufficient.

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, clear sentence in Japanese that directly states the tool's function. It's front-loaded with the core purpose and has no unnecessary words. Every part of the sentence earns its place.

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 complete. It states what the tool does but lacks details on behavior, output format, or sibling differentiation. For a basic list tool, it's adequate but has clear gaps in guidance and transparency.

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 with 100% schema description coverage (empty schema). The description doesn't need to explain any parameters, and it correctly implies no inputs are required. With no parameters, the baseline is 4, as the description adequately matches the schema.

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 tool's purpose: '利用可能な効果音の一覧を表示します' (Displays a list of available sound effects). It uses a specific verb ('表示します' - displays) and resource ('効果音の一覧' - list of sound effects). However, it doesn't explicitly differentiate from its sibling tool 'play-sound-effect', which would be needed for a score of 5.

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 sibling 'play-sound-effect'. It doesn't mention any context, prerequisites, or alternatives. The only implied usage is to get a list, but no explicit guidance is given.

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

play-sound-effectB

効果音を再生します（完了音、ニュータイプ音、エラー音）

ParametersJSON Schema
NameRequiredDescriptionDefault
soundYes再生する効果音の種類（complete: 完了音, newtype: ニュータイプ音, error: エラー音）
messageNoメッセージ（オプション）

TDQS

B3.1/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 states what the tool does but lacks details on execution (e.g., synchronous/asynchronous playback, volume control, error handling if audio fails). This leaves gaps in understanding how the tool behaves beyond its basic function.

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 and lists the available sound types. It's front-loaded with the core function and avoids unnecessary elaboration, making it highly concise and well-structured.

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 low complexity (simple playback with two parameters) and high schema coverage, the description is minimally adequate. However, with no annotations or output schema, it lacks details on behavioral aspects like playback behavior or error responses, leaving room for improvement in completeness.

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 100%, so the schema fully documents both parameters. The description doesn't add any additional meaning beyond what the schema provides (e.g., it doesn't explain the optional 'message' parameter's purpose or usage context). Baseline 3 is appropriate as the schema handles the heavy lifting.

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 sound effects') and lists the specific types available (completion sound, newtype sound, error sound). It distinguishes itself from the sibling tool 'list-sound-effects' by focusing on playback rather than listing, though it doesn't explicitly mention this distinction.

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. It doesn't mention prerequisites like audio output availability or compatibility, nor does it specify scenarios where one sound type is preferred over another.

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.

  1. 2 tool updatesv1.0.0
    • First observedlist-sound-effects
    • First observedplay-sound-effect
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one lists available sound effects, and the other plays a selected sound effect. There is no overlap or ambiguity between these functions, making it easy for an agent to choose the correct tool based on the task.

Naming Consistency5/5

Both tool names follow a consistent verb-noun pattern using kebab-case (list-sound-effects, play-sound-effect). This predictable naming scheme enhances readability and makes the tool set coherent and easy to understand.

Tool Count2/5

With only 2 tools, the set feels thin for a sound effects server. While the tools cover basic listing and playback, there are likely missing operations such as searching, filtering, or managing sound effects (e.g., upload, delete). The count is too low for a comprehensive sound effects domain.

Completeness2/5

The tool set is severely incomplete for a sound effects domain. It lacks essential operations like searching for specific sounds, uploading new effects, deleting or organizing effects, and controlling playback (e.g., stop, pause, volume). Agents will face dead ends when trying to perform common sound management tasks.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers