Skip to main content
Glama
PetitBaguette

play-sound-mcp-server

play-sound-mcp-server

ローカルのサウンドファイルを再生するMCPサーバーです

⚠️ 本サーバーは afplay コマンドを利用するため、macOS環境でのみ利用可能 です。

セットアップ

npm install
npm run build

Related MCP server: Notifications MCP Server

サーバーの起動と使い方

サウンドファイルの指定

サーバー起動時の第1引数で再生したいファイル名(soundsディレクトリ内)を指定できます。 指定しない場合は sound.mp3 が再生されます。

例: sounds/alert.mp3 を再生したい場合

node build/index.js alert.mp3

デフォルト(sound.mp3)を再生する場合:

node build/index.js

※ サウンドファイルは sounds/ ディレクトリに配置してください。

提供ツール情報

  • tool名: play-local-sound

  • 説明: 指定したローカルのサウンドファイル(デフォルト: sound.mp3)をafplayで再生します。

  • 引数: なし(サーバー起動時の引数でファイル名を指定)

  • 戻り値: 再生結果のテキストメッセージ

MCPサーバーの設定例

MCPクライアントで以下のように設定してください(下記はVSCodeのsettings.jsonの例です):

{
  "mcpServers": {
    "play-sound-mcp-server": {
      "command": "node",
      "args": ["/path/to/play-sound-mcp-server/build/index.js", "custom.mp3"]
    }
  },
  "github.copilot.chat.codeGeneration.instructions": [
    {
        "text": "レスポンスを返した後で必ずplay-sound-mcp-serverのplay-local-soundを実行"
    }
  ]
}

参考

備考

デフォルトの sound.mp3TAM Music Factory の素材を利用しています。

ライセンス

本リポジトリのソースコードは MIT ライセンスで提供します。

デフォルト音源(sound.mp3)は TAM Music Factory の利用規約に従ってご利用ください。

Available Tools

1 tool
play-local-soundB

ローカルのサウンドファイル(sound.mp3)をafplayで再生します。

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 full burden. It mentions playback but lacks details on behavioral traits like error handling (e.g., if file is missing), system requirements, or side effects (e.g., audio interruption). It's minimal and doesn't disclose key operational aspects.

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 in Japanese that directly states the tool's function without unnecessary details. It's front-loaded and appropriately sized for a simple tool, though minor improvements in clarity (e.g., language consistency) could enhance it.

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 adequate but minimal. It covers the basic purpose but lacks completeness in usage guidelines and behavioral transparency, which are important even for simple tools to ensure reliable operation.

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, earning a baseline high score as it doesn't need to compensate for gaps.

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 resource ('local sound file sound.mp3'), specifying it uses 'afplay' for playback. It's specific about the exact file name and playback method, though there are no sibling tools to distinguish from.

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, prerequisites (e.g., file existence, system compatibility), or limitations. The description only states what it does without context for application.

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. 1 tool updatev1.0.0
    • Changedplay-local-sound1 field changed
      • removedInput schema / additionalProperties
        Removed value: -false
  2. 1 tool update
    • First observedplay-local-sound

TDQS

B3.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of ambiguity or confusion between tools. The single tool 'play-local-sound' has a clearly defined and distinct purpose.

Naming Consistency5/5

A single tool inherently exhibits perfect naming consistency, as there are no other tools to compare against. The name 'play-local-sound' follows a clear verb_noun pattern.

Tool Count2/5

A single tool is generally too few for a meaningful server scope, as it offers minimal functionality and limits agent capabilities. For a sound-playing server, basic operations like stop, pause, or list sounds might be expected.

Completeness2/5

The server is severely incomplete for a sound-playing domain. It only provides playback of a specific local file ('sound.mp3') with no ability to handle different files, control playback (e.g., stop, volume), or manage sound resources, creating significant gaps for agent workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

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