Skip to main content
Glama

光标声音 MCP

模型上下文协议 (MCP) 实现,可在 Cursor AI 完成代码生成后播放音效。此 MCP 与 Cursor 集成,可提供音频反馈,从而带来更具互动性的编码体验。

受到 X.com 上的 @EricListin 的启发 - 我对代码做了一些更改,以免出错并保持在线。

特征

  • 当 Cursor 完成代码生成时播放音效

  • 使用模型上下文协议 (MCP) 进行标准化集成

  • 可配置的音效

  • 改进的错误处理和日志记录

  • 稳定的 JSON 响应格式

Related MCP server: MCP Sound Tool

游标规则

将其添加到您的 Cursor 自定义指令中:

“每次你完成任何任务或者需要我做某事时,请运行 sound-mcp MCP 服务器来引起我的注意。”

安装

  1. 安装依赖项:

npm install
  1. 添加音效:将声音文件放在sounds目录中。默认的预期声音是:

  • sounds/completion.mp3 - 代码生成后播放

您可以在 freesound.org 上找到免费的音效。

  1. 构建项目:

npm run build

用法

运行 MCP 服务器:

npm start

服务器将启动并通过 stdio 传输监听来自 Cursor 的事件。

配置

音效和音量可以通过以下方式定制:

  1. 替换sounds目录中的声音文件

  2. 修改src/index.ts中的声音文件路径

发展

对于使用自动重新编译的开发:

npm run dev

Available Tools

1 tool
playCompletionSoundC

Plays a completion sound when called

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/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 states the tool plays a sound, implying an auditory output, but doesn't disclose behavioral traits like whether it requires audio permissions, if it blocks execution, error handling, or what happens on failure. This is a significant gap for a tool with zero annotation coverage.

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 appropriately sized for a simple tool and front-loaded with the core action. Every word earns its place, 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.

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 incomplete. It lacks context about the sound's source, volume, duration, or system requirements. With no annotations to fill gaps, the description should provide more detail to ensure the agent understands how to invoke it effectively.

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% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline score of 4 is appropriate, reflecting that no additional information is required beyond the empty schema.

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's purpose ('Plays a completion sound when called'), which is clear but vague. It specifies the action ('Plays') and resource ('a completion sound'), but lacks detail about what constitutes a 'completion sound' or how it's played. With no sibling tools, differentiation isn't needed, but the purpose remains somewhat ambiguous.

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. It doesn't specify appropriate contexts (e.g., after a task finishes), prerequisites, or alternatives. With no sibling tools, this isn't a comparative issue, but the lack of any usage context leaves the agent without direction.

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
    • First observedplayCompletionSound

TDQS

B3/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap between tools. The single tool has a clear, distinct purpose that cannot be mistaken for another.

Naming Consistency5/5

A single tool inherently has perfect naming consistency, as there are no other names to compare it against. The tool name 'playCompletionSound' follows a clear verb_noun pattern.

Tool Count2/5

One tool is too few for a server's purpose, as it severely limits functionality and suggests the server is trivial or incomplete. A single sound-playing tool does not justify a full MCP server.

Completeness1/5

The server is severely incomplete, as it only offers a single sound-playing tool with no other related operations (e.g., stop sound, list sounds, adjust volume). This minimal surface fails to cover any meaningful domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • 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
  • A
    license
    B
    quality
    D
    maintenance
    Plays sound effects (completion, newtype, and error sounds) in response to various situations like task completion, insights, or errors. Integrates with Claude Desktop to provide audio feedback for improved workflow efficiency and entertainment.
    2
    16 npm
    6
    MIT