What can you do with this server?

This MCP server provides speech recognition (STT) and synthesis (TTS) via Yandex SpeechKit, plus utilities for managing voices. * Recognize speech: Convert Base64 audio (oggopus/lpcm) to text using recognize (supports ru-RU, en-US, tr-TR, kk-KK). * Synthesize speech: Convert text (up to 5000 chars) to Base64 audio (oggopus/lpcm/mp3) with configurable voice, speed, and emotion using synthesize. * List available voices: Fetch TTS voices, optionally filtered by language prefix (e.g., ru, en) using list_voices. * High-level transcription: Get clean text from audio with the skill_transcribe tool (can return raw API response if needed). * High-level synthesis: Generate speech with smart defaults and automatic language detection from voice using skill_synthesize (defaults to mp3 format).

Which integrations are available for this server?

Provides speech recognition (STT), speech synthesis (TTS), and voice listing using Yandex SpeechKit API, enabling audio transcription, text-to-speech conversion, and voice management.

How do I use @theyahia/yandex-speechkit-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@theyahia/yandex-speechkit-mcp Transcribe this audio file" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

@theyahia/yandex-speechkit-mcp

by theYahia

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

🗄 Repository archived
Development has moved to theYahia/YaAll — a build where the entire Yandex layer lives in one place: its own MCP servers, Claude Code skills, and materials from Yandex's official sets.
The current version of what was here: mcp/yandex-speechkit-mcp/
The npm package is the same — @theyahia/yandex-speechkit-mcp, installs and works as before. Nothing is updated here anymore. Issues and pull requests go to YaAll.
Archived — development moved to theYahia/YaAll, a single repository bundling the whole Yandex stack. The current version of this package now lives at mcp/yandex-speechkit-mcp/. The npm package @theyahia/yandex-speechkit-mcp is unchanged. Please open issues and pull requests there.

This server is part of the theYahia/YaAll build — the entire Yandex layer in one repository: ten MCP servers, Claude Code skills for SEO and demand validation, plus materials from Yandex's official servers. Here it lives separately, there — alongside the rest: mcp/yandex-speechkit-mcp/
Part of theYahia/YaAll — the whole Yandex stack in one repo.

@theyahia/yandex-speechkit-mcp

MCP server for Yandex SpeechKit API — speech recognition, synthesis, and voice listing. 5 tools.

npm License: MIT

Part of the Russian API MCP series by @theYahia.

Related MCP server: salutespeech-mcp

Installation

Claude Desktop

{
  "mcpServers": {
    "yandex-speechkit": {
      "command": "npx",
      "args": ["-y", "@theyahia/yandex-speechkit-mcp"],
      "env": {
        "YANDEX_SPEECHKIT_API_KEY": "your-api-key",
        "FOLDER_ID": "your-folder-id"
      }
    }
  }
}

Claude Code

claude mcp add yandex-speechkit \
  -e YANDEX_SPEECHKIT_API_KEY=your-api-key \
  -e FOLDER_ID=your-folder-id \
  -- npx -y @theyahia/yandex-speechkit-mcp

Streamable HTTP (remote / Docker)

YANDEX_SPEECHKIT_API_KEY=... FOLDER_ID=... npx @theyahia/yandex-speechkit-mcp --http
# Listens on :8080/mcp (override with PORT env var)

Smithery

Deploy via smithery.ai — config in smithery.yaml.

Authentication

Variable	Description
`YANDEX_SPEECHKIT_API_KEY`	Yandex Cloud API key (preferred)
`YANDEX_API_KEY`	Legacy alias (still works)
`IAM_TOKEN`	Short-lived IAM token (alternative to API key)
`FOLDER_ID`	Yandex Cloud folder ID (required)
`YANDEX_FOLDER_ID`	Legacy alias for FOLDER_ID

Get credentials at Yandex Cloud Console.

Tools (5)

Tool	Type	Description
`recognize`	Core	Speech recognition (STT) — Base64 audio to text
`synthesize`	Core	Speech synthesis (TTS) — text to Base64 audio
`list_voices`	Core	List available TTS voices, filter by language
`skill_transcribe`	Skill	High-level transcription — returns clean text
`skill_synthesize`	Skill	High-level synthesis — smart defaults, auto-detects language from voice

Examples

Transcribe this audio file
Synthesize "Hello, how are you?" with voice filipp
What voices are available in Russian?
Speak this text using the alena voice

Development

npm install
npm run build
npm test
npm run dev    # stdio mode

License

MIT

Available Tools

5 tools

list_voicesB

List available TTS voices. Optionally filter by language.

ParametersJSON Schema

Name	Required	Description	Default
`lang`	No	Filter by language prefix (e.g. ru, en, kk)

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the listing is read-only, requires authentication, or has rate limits. It only says 'List available TTS voices' without further context.

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 very concise (one sentence, 8 words) and front-loaded with the main purpose. However, given the lack of annotations, a bit more structure or detail could be beneficial.

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?

The description is adequate for a simple list tool with one optional parameter, but it does not describe the return format or any behavioral details. With no output schema, additional context about what the list contains would improve 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?

The parameter 'lang' is fully described in the input schema with an example. The description repeats 'optionally filter by language' but adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 'List available TTS voices' with a specific verb and resource, and it distinguishes from sibling tools like recognize, synthesize, skill_synthesize, and skill_transcribe, which perform different operations.

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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or compare with sibling tools like recognize or synthesize.

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

recognizeC

Speech recognition (STT) via Yandex SpeechKit. Takes Base64 audio, returns text.

ParametersJSON Schema

Name	Required	Description	Default
`audio_base64`	Yes	Audio data encoded as Base64
`lang`	No	Recognition language (ru-RU, en-US, tr-TR, kk-KK)	ru-RU
`format`	No	Audio format (oggopus, lpcm)	oggopus

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description only says 'takes Base64 audio, returns text'. It does not disclose behavioral traits such as required permissions, latency, or error handling, which are critical 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.

Conciseness4/5

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

The description is very short (two sentences) with no wasted words. It is front-loaded with the purpose, though it could benefit from more detail without becoming verbose.

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 no output schema and a simple but non-trivial tool, the description is incomplete. It does not specify the return format (e.g., plain text vs JSON), error conditions, or any constraints like audio size limits.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides, only reiterating 'Base64 audio' and 'returns text'.

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 'Speech recognition (STT)' and specifies input/output format, making the tool's purpose obvious. However, it does not differentiate from the sibling tool 'skill_transcribe', which may have a similar function.

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 given on when to use this tool versus alternatives like 'skill_transcribe' or 'synthesize'. The description simply states what it does without contextual usage advice.

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

skill_synthesizeB

High-level speech synthesis skill. Smart voice defaults, auto-detects language.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to speak (max 5000 chars)
`voice`	No	Voice name	filipp
`lang`	No	Language — auto-detected from voice if omitted
`format`	No	Output format (mp3, oggopus, lpcm)	mp3

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description discloses 'smart voice defaults' and 'auto-detects language' but omits details like the default voice name, error handling, or response format. The schema covers constraints like max text length, which the description misses.

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 very concise (one sentence) and front-loads key features. It is efficient but could be structured with separate aspects for clarity.

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 4 parameters, no output schema, and no annotations, the description lacks details on return values, error handling, and how this 'skill' differs from the sibling 'synthesize'. It is incomplete for an agent to fully understand tool behavior.

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?

Schema coverage is 100% with descriptions for each parameter. The description adds context by explaining smart defaults for 'voice' and auto-detection for 'lang', augmenting the schema information meaningfully.

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 it's a 'high-level speech synthesis skill' with smart defaults and auto-detection, distinguishing it from a lower-level 'synthesize' sibling. However, 'skill' is vague without further explanation.

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 explicit guidance on when to use this tool versus siblings like 'synthesize' or 'list_voices'. The description implies use when defaults are desired, but does not state alternatives or exclusions.

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

skill_transcribeC

High-level transcription skill. Returns clean text from audio.

ParametersJSON Schema

Name	Required	Description	Default
`audio_base64`	Yes	Audio data encoded as Base64
`lang`	No	Language (ru-RU, en-US, kk-KK)	ru-RU
`format`	No	Audio format (oggopus, lpcm)	oggopus
`return_raw`	No	Return raw API response instead of plain text

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states it returns clean text. It does not disclose behavioral traits such as authorization requirements, data handling, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is very concise but under-specified. It uses vague language like 'high-level' and does not provide enough detail for effective tool selection.

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 has 4 parameters, no output schema, and sibling tools available, the description lacks information about output format, error handling, or constraints, making it incomplete.

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 coverage is 100%, so parameters are already documented. The description adds no extra meaning beyond 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 it transcribes audio to text with a specific verb and resource. However, it does not differentiate from the sibling 'recognize' tool, which may perform a similar function.

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 like 'recognize' or 'skill_synthesize'. The description lacks context about appropriate use cases or prerequisites.

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

synthesizeC

Speech synthesis (TTS) via Yandex SpeechKit. Takes text, returns Base64 audio.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to synthesize (max 5000 chars)
`lang`	No	Synthesis language (ru-RU, en-US, tr-TR, kk-KK)	ru-RU
`voice`	No	Voice name (filipp, alena, jane, dasha, john, etc.)	filipp
`format`	No	Audio format (oggopus, lpcm, mp3)	oggopus
`emotion`	No	Emotion (neutral, good, evil) — only for voices that support it
`speed`	No	Speech speed multiplier (0.1–3.0)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It only states the basic operation (synthesize text to audio) but omits important behavioral traits such as character limit, voice/emotion restrictions, and output handling. The schema covers some constraints, but the description adds no additional behavioral context.

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 efficiently concise (one sentence) and front-loaded with the core purpose. However, it could be slightly more informative without adding 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 tool has 6 parameters, no output schema, and no annotations, the description is underspecified. It does not explain the return format details (Base64 audio but not the audio format), limitations, or when to use different parameters.

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 with defaults and constraints. The description does not add further meaning beyond 'text' input, so it meets the baseline but does not exceed it.

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 it's speech synthesis (TTS) and that it takes text and returns Base64 audio. It distinguishes from 'recognize' (speech-to-text) and 'list_voices' but does not differentiate from the sibling 'skill_synthesize', which may have a similar purpose.

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 like 'skill_synthesize', 'recognize', or 'list_voices'. There is no mention of prerequisites or use cases.

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. Dates show when Glama detected each change.

5 tool updatesv1.1.0May 29, 2026
- First observedlist_voices
- First observedrecognize
- First observedskill_synthesize
- First observedskill_transcribe
- First observedsynthesize

Install Server

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

TDQS

B3.2/5.0

Disambiguation4/5

Tools are mostly distinct: list_voices (voice listing), recognize (low-level STT), synthesize (low-level TTS), skill_synthesize (high-level TTS), skill_transcribe (high-level STT). The high-level vs low-level distinction is clear in descriptions, but an agent might hesitate between skill_synthesize and synthesize.

Naming Consistency3/5

Naming is inconsistent: list_voices follows verb_noun pattern, recognize and synthesize are single verbs, skill_synthesize and skill_transcribe have a 'skill_' prefix. Mix of patterns could confuse agents.

Tool Count5/5

5 tools is appropriate for a speech kit server. It covers both STT and TTS with low-level and high-level options, without being overwhelming.

Completeness4/5

Core STT and TTS functionality is covered. Minor gaps like explicit language detection or streaming aren't present but are not critical given the high-level tools handle auto-detection.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

PyAI Voice AIOAuth
io.github.atomsai
Speech, transcription, voice agents, Trace, Recap, dubbing and narration with browser OAuth.
1
ElevenLabs
io.elevenlabs
Manage ElevenLabs voice agents and generate speech, music, sound effects, images, and video.
1
Brainiall Pronunciation A
com.brainiall
Pronunciation assessment, phoneme scoring, speaker voice ID, audio transcription, speech synthesis.
Speech Processing Audio Processing Education & Learning Tools
141
Carbon VoiceOAuth
app.carbonvoice.mcp
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Communication Knowledge & Memory Text Summarization
2

Related MCP Servers

mcp-salutespeech
Speech Processing Text-to-Speech
trashchenkov
A
license
Not graded
quality
D
maintenance
Provides speech recognition and synthesis tools via SaluteSpeech API, enabling AI assistants to handle voice input and output.
Updated a year ago (2025-05-07 06:41 UTC)
4
MIT
salutespeech-mcp
Speech Processing Text-to-Speech
theYahia
A
license
A
quality
B
maintenance
Provides speech recognition (STT) and synthesis (TTS) tools via the Sber SaluteSpeech API, enabling audio transcription and voice generation through natural language.
Updated 6 days ago (2026-09-03 04:46 UTC)
5
28
1
MIT
RunAPI Gemini TTS MCP Server
Text-to-Speech Speech Processing Audio Processing
runapi-ai
A
license
A
quality
B
maintenance
Enables AI agents to generate speech using Gemini TTS models, with tools for text-to-speech, task polling, and pricing checks.
Updated a month ago (2026-07-31 09:32 UTC)
4
66
Apache 2.0
elevenlabs-mcp
carlosvidal
F
license
Not graded
quality
D
maintenance
Provides tools for generating speech from text using the ElevenLabs API, including voice listing, text-to-speech conversion, and quota checking.
Updated 5 months ago (2026-03-31 13:48 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/theYahia/yandex-speechkit-mcp'

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