Skip to main content
Glama
enesjakozh
hammeiam

Speech MCP Server

by hammeiam
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

음성 MCP 서버

Kokoro TTS 모델을 사용하여 텍스트-음성 변환 기능을 제공하는 모델 컨텍스트 프로토콜 서버입니다.

구성

다음 환경 변수를 사용하여 서버를 구성할 수 있습니다.

변하기 쉬운

설명

기본

유효 범위

MCP_DEFAULT_SPEECH_SPEED

텍스트 음성 변환을 위한 기본 속도 배수

1.1

0.5에서 2.0까지

커서에서:

지엑스피1

Related MCP server: TTS-MCP

특징

  • 🎯 Kokoro TTS 모델을 사용한 고품질 텍스트 음성 변환

  • 🗣️ 다양한 음성 옵션 제공

  • 🎛️ 사용자 정의 가능한 음성 매개변수(음성, 속도)

  • 🔌 MCP 호환 인터페이스

  • 📦 간편한 설치 및 설정

  • 🚀 API 키가 필요하지 않습니다

설치

# Using npm
npm install speech-mcp-server

# Using pnpm (recommended)
pnpm add speech-mcp-server

# Using yarn
yarn add speech-mcp-server

용법

서버를 실행합니다:

# Using default configuration
npm start

# With custom speech speed
MCP_DEFAULT_SPEECH_SPEED=1.5 npm start

서버는 다음과 같은 MCP 도구를 제공합니다.

  • text_to_speech : 기본 텍스트-음성 변환

  • text_to_speech_with_options : 사용자 정의 가능한 속도의 텍스트 음성 변환

  • list_voices : 사용 가능한 모든 음성을 나열합니다.

  • get_model_status : TTS 모델의 초기화 상태를 확인합니다.

개발

# Clone the repository
git clone <your-repo-url>
cd speech-mcp-server

# Install dependencies
pnpm install

# Start development server with auto-reload
pnpm dev

# Build the project
pnpm build

# Run linting
pnpm lint

# Format code
pnpm format

# Test with MCP Inspector
pnpm inspector

사용 가능한 도구

1. 텍스트 음성 변환

기본 설정을 사용하여 텍스트를 음성으로 변환합니다.

{
  "type": "request",
  "id": "1",
  "method": "call_tool",
  "params": {
    "name": "text_to_speech",
    "arguments": {
      "text": "Hello world",
      "voice": "af_bella"  // optional
    }
  }
}

2. 텍스트_음성_변환_옵션

사용자 정의 가능한 매개변수를 사용하여 텍스트를 음성으로 변환합니다.

{
  "type": "request",
  "id": "1",
  "method": "call_tool",
  "params": {
    "name": "text_to_speech_with_options",
    "arguments": {
      "text": "Hello world",
      "voice": "af_bella",  // optional
      "speed": 1.0,         // optional (0.5 to 2.0)
    }
  }
}

3. 목록_음성

텍스트 음성 변환에 사용 가능한 모든 음성을 나열합니다.

{
  "type": "request",
  "id": "1",
  "method": "list_voices",
  "params": {}
}

4. 모델 상태 가져오기

TTS 모델 초기화의 현재 상태를 확인하세요. 특히 서버를 처음 시작할 때 모델을 다운로드하고 초기화해야 하므로 유용합니다.

{
  "type": "request",
  "id": "1",
  "method": "call_tool",
  "params": {
    "name": "get_model_status",
    "arguments": {}
  }
}

응답 예:

{
  "content": [{
    "type": "text",
    "text": "Model status: initializing (5s elapsed)"
  }]
}

가능한 상태 값:

  • uninitialized : 모델 초기화가 시작되지 않았습니다.

  • initializing : 모델이 다운로드되고 초기화됩니다.

  • ready : 모델을 사용할 준비가 되었습니다.

  • error : 초기화 중 오류가 발생했습니다.

테스트

MCP Inspector를 사용하거나 원시 JSON 메시지를 보내어 서버를 테스트할 수 있습니다.

# List available tools
echo '{"type":"request","id":"1","method":"list_tools","params":{}}' | node dist/index.js

# List available voices
echo '{"type":"request","id":"2","method":"list_voices","params":{}}' | node dist/index.js

# Convert text to speech
echo '{"type":"request","id":"3","method":"call_tool","params":{"name":"text_to_speech","arguments":{"text":"Hello world","voice":"af_bella"}}}' | node dist/index.js

Claude Desktop과 통합

Claude Desktop과 함께 이 서버를 사용하려면 Claude Desktop 구성 파일( ~/Library/Application Support/Claude/claude_desktop_config.json )에 다음을 추가하세요.

{
  "servers": {
    "speech": {
      "command": "npx",
      "args": ["@decodershq/speech-mcp-server"]
    }
  }
}

기여하다

기여를 환영합니다! 풀 리퀘스트를 제출해 주세요.

특허

MIT 라이센스 - 자세한 내용은 LICENSE 파일을 참조하세요.

문제 해결

모델 초기화 문제

서버는 시작 시 자동으로 TTS 모델을 다운로드하고 초기화하려고 시도합니다. 초기화 오류가 발생하는 경우:

  1. 서버는 시도 사이에 정리 작업을 거쳐 최대 3회까지 자동으로 재시도합니다.

  2. get_model_status 도구를 사용하여 초기화 진행 상황과 오류를 모니터링합니다.

  3. 모든 재시도 후에도 초기화가 실패하면 모델 파일을 수동으로 제거해보세요.

# Remove model files (MacOS/Linux)
rm -rf ~/.npm/_npx/**/node_modules/@huggingface/transformers/.cache/onnx-community/Kokoro-82M-v1.0-ONNX/onnx/model_quantized.onnx
rm -rf ~/.cache/huggingface/transformers/onnx-community/Kokoro-82M-v1.0-ONNX/onnx/model_quantized.onnx

# Then restart the server
npm start

이제 get_model_status 도구는 응답에 재시도 정보를 포함합니다.

{
  "content": [{
    "type": "text",
    "text": "Model status: initializing (5s elapsed, retry 1/3)"
  }]
}

Available Tools

4 tools
get_model_statusB

Get the current status of the TTS model initialization

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 the full burden of behavioral disclosure. It states the tool retrieves status, implying a read-only operation, but doesn't specify what the status includes (e.g., 'initialized', 'loading', 'error'), whether it has side effects, or how it handles errors. For a status-checking 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, clear sentence that front-loads the core purpose without unnecessary details. It efficiently communicates the tool's function without redundancy or fluff, 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 adequate but incomplete. It covers the basic purpose but lacks details on what the status output entails, error handling, or dependencies on other tools. For a status-checking tool, this leaves gaps in understanding its full context.

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 avoids discussing nonexistent inputs. A baseline of 4 is justified as the description doesn't introduce confusion about parameters.

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 ('Get') and resource ('current status of the TTS model initialization'), making the purpose immediately understandable. It distinguishes from siblings like list_voices and text_to_speech by focusing on model status rather than voice listing or speech generation. However, it doesn't explicitly differentiate from potential overlapping tools, keeping it at 4 rather than 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 alternatives. It doesn't mention prerequisites (e.g., whether the model must be initialized first), typical use cases (e.g., checking readiness before text_to_speech), or exclusions. This leaves the agent with minimal context for decision-making.

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

list_voicesB

List all available voices for text-to-speech

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 tool lists voices but does not describe any behavioral traits such as rate limits, authentication needs, response format, or whether it's a read-only operation. This leaves significant 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, clear sentence that directly states the tool's purpose without any unnecessary words or fluff. It is front-loaded and efficiently communicates the essential information, 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 (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavioral aspects like response format or usage context. For a simple list tool, this is acceptable but leaves room for improvement in guiding the agent fully.

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 information is needed. The description appropriately does not discuss parameters, and since there are none, it meets the baseline expectation without requiring additional details, earning a score above the minimum.

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 ('List all available voices') and the resource ('for text-to-speech'), providing a specific verb+resource combination. However, it does not differentiate from sibling tools like 'get_model_status' or 'text_to_speech', which might also relate to voice or model operations, so it lacks explicit sibling 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?

The description implies usage for retrieving voice options but offers no explicit guidance on when to use this tool versus alternatives like 'text_to_speech' or 'get_model_status'. There is no mention of prerequisites, exclusions, or specific contexts, leaving the agent to infer usage from the tool name alone.

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

text_to_speechB

Convert text to speech and play it through system audio

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe text to convert to speech
voiceNoThe voice to use for speech synthesis (e.g. 'af_bella'). Use list_voices to see available options.

TDQS

B3.4/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 the action and output ('play it through system audio'), but fails to address key traits like permissions needed, rate limits, whether it's a read-only or destructive operation, or error handling. This leaves significant gaps for an AI agent.

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 front-loads the core purpose without unnecessary details. Every word earns its place, making it highly concise and well-structured for quick understanding.

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 a text-to-speech tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral aspects (e.g., audio format, playback behavior, errors) and does not explain return values or side effects, leaving the agent with insufficient context for reliable use.

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 already documents both parameters (text and voice) thoroughly. The description does not add any additional meaning or context beyond what the schema provides, such as examples or usage notes for parameters. Baseline 3 is appropriate when the schema does the heavy lifting.

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

Purpose5/5

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

The description clearly states the specific action ('convert text to speech') and the resource ('system audio'), distinguishing it from siblings like list_voices (which lists options) and text_to_speech_with_options (which offers more customization). It uses precise verbs and specifies the output mechanism.

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

Usage Guidelines3/5

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

The description implies usage for converting text to audio playback, but does not explicitly state when to use this tool versus text_to_speech_with_options or other alternatives. It provides basic context but lacks explicit guidance on exclusions or comparisons with siblings.

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

text_to_speech_with_optionsC

Convert text to speech with customizable speed

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesThe text to convert to speech
voiceNoThe voice to use for speech synthesis (e.g. 'af_bella'). Use list_voices to see available options.
speedNoSpeech rate multiplier (0.5 to 2.0)

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 mentions 'customizable speed' but doesn't disclose other behavioral traits: it doesn't specify output format (e.g., audio file, stream), permissions required, rate limits, or whether it's a read-only or mutating operation. For a tool with no annotations, this leaves significant gaps in understanding its 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 fluff. It's appropriately sized and front-loaded, with every word earning its place. No structural issues or unnecessary elaboration.

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 complexity (3 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the output (e.g., what's returned, format), lacks behavioral context like error handling or performance, and doesn't guide usage relative to siblings. For a tool with no structured support, more descriptive detail is needed.

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 already documents all parameters (text, voice, speed) thoroughly. The description adds minimal value beyond the schema—it implies speed customization but doesn't provide additional context like default values or examples. Baseline 3 is appropriate when the schema does 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 tool's purpose: converting text to speech with customizable speed. It specifies the verb ('convert') and resource ('text to speech'), distinguishing it from siblings like list_voices (which lists options) or get_model_status (which checks status). However, it doesn't explicitly differentiate from text_to_speech (likely a simpler version), so it's not a perfect 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 alternatives. It doesn't mention when to choose text_to_speech_with_options over text_to_speech (the likely sibling), nor does it specify prerequisites like needing to list_voices first for voice selection. Usage is implied but not explicitly stated.

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. 4 tool updates
    • First observedget_model_status
    • First observedlist_voices
    • First observedtext_to_speech
    • First observedtext_to_speech_with_options
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 4 tools

Disambiguation4/5

The tools are mostly distinct, but 'text_to_speech' and 'text_to_speech_with_options' could cause confusion as they overlap in core functionality. The other tools ('get_model_status' and 'list_voices') have clear, unique purposes related to system status and voice selection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., 'get_model_status', 'list_voices', 'text_to_speech'). There are no deviations in naming conventions across the set.

Tool Count4/5

Four tools is a reasonable count for a speech-focused server, though it feels slightly minimal. The tools cover key aspects like status, voice listing, and speech generation, but could potentially benefit from one or two more operations (e.g., stop speech or adjust volume) for better scope.

Completeness3/5

The server provides core text-to-speech functionality with status and voice listing, but lacks operations for managing speech playback (e.g., pause, stop, or volume control) and advanced customization beyond speed. This creates minor gaps that agents might need to work around for full speech interaction.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • TTS-MCP

    nakamurau1
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server that integrates high-quality text-to-speech capabilities with Claude Desktop and other MCP-compatible clients, supporting multiple voice options and audio formats.
    7 npm
    1
    MIT

  • Edge-TTS MCP Server

    yuiseki
    A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides text-to-speech functionality for AI agents using Microsoft Edge's text-to-speech technology, supporting multiple voices, languages, and voice customization.
    2
    8
    MIT

Appeared in Searches