kurdish-tts-stt

Server Details

Sorani & Kurmanji TTS+STT: Kurdish speech most APIs lack. 885 voices, free tier, no key to browse.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 40 days
Last Tested: 2026-09-26 14:39
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.3/5.0

Scored 2026-09-15 17:30 across 6 tools

Disambiguation4/5

The six tools split cleanly into metadata/planning (get_plan, list_dialects, list_voices) and execution (synthesize_speech, transcribe_audio, start_streaming_transcription). The only mild overlap is between synthesize_speech and start_streaming_transcription, but the descriptions explicitly contrast TTS vs STT and streaming vs one-shot, so an agent should be able to disambiguate.

Naming Consistency4/5

Most tools follow a clear verb_noun pattern: get_plan, list_dialects, list_voices, synthesize_speech, transcribe_audio. start_streaming_transcription is the outlier — it uses a gerund phrase rather than a simple verb_noun form, and it is the only tool that does not start with a bare imperative verb. Still, the pattern is mostly consistent and readable.

Tool Count5/5

Six tools is a well-scoped size for a Kurdish TTS/STT server: two metadata calls, one plan/account call, one TTS call, one batch STT call, and one streaming STT call. Each tool covers a distinct capability without redundancy or bloat.

Completeness4/5

The surface covers the core lifecycle: discover dialects, list voices, check plan, synthesize speech, transcribe audio, and stream transcription. Minor gaps exist — there is no direct streaming TTS tool (the description points to an external HTTP endpoint) and no way to manage API keys or usage history — but the core TTS/STT workflows are complete.

Available Tools

6 tools

get_planGet plan, entitlements and pricingA

Read-onlyIdempotent

Inspect

Show what this connection may use. With an API key: your current plan, remaining allowance, which model_versions and speaker ids you may render. Without a key: the purchasable plan ladder and how to get a key. Free, no credits consumed. Call this FIRST when any tool returns a 401 or 403 — it is the fastest way to learn what went wrong.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`stt`	No
`plan`	No
`status`	No
`catalog`	No
`keys_url`	Yes
`next_step`	Yes
`plan_name`	No
`plans_url`	Yes
`authenticated`	Yes
`usable_speaker_ids`	No
`tts_characters_used`	No
`tts_characters_quota`	No
`allowed_model_versions`	No
`cast_and_studio_voices`	No
`tts_characters_remaining`	No

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already cover read-only/idempotent, but the description adds substantial context beyond them: cost transparency ('Free, no credits consumed'), auth-dependent output shape, and an error-recovery role for 401/403. That is exactly the behavioral information the agent cannot get from structured fields.

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?

Four short sentences, front-loaded with the core purpose, then the two auth branches, then the cost guarantee, then the highest-value routing tip. No filler and no restatement of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a parameterless, read-only introspection tool, the description supplies purpose, both auth modes, cost, and an error-recovery trigger — nothing an agent needs is missing.

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?

There are zero parameters, so the baseline is 4. The description correctly doesn't waste space documenting nonexistent inputs, but it also doesn't clarify why auth state changes output (a behavioral note rather than a parameter note).

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?

Names a specific resource (plan/entitlements/pricing) and states the scope precisely: available model_versions and speaker ids. It also splits behavior by auth state ('With an API key' vs 'Without a key'), which no sibling tool covers, so an agent can distinguish it immediately.

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

Usage Guidelines5/5

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

Explicitly prescribes the trigger condition: 'Call this FIRST when any tool returns a 401 or 403'. It also tells you when the no-key variant applies, giving both a routing rule and an alternative-path explanation.

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

list_dialectsList Kurdish dialectsA

Read-onlyIdempotent

Inspect

List the supported Kurdish dialects and their scripts. Static capability descriptor — costs nothing and needs no API key.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`dialects`	Yes

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds genuinely new context beyond the annotations: zero cost and no API-key/auth requirement, which the agent cannot derive from the structured fields.

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?

Two tight sentences, front-loaded with the resource, followed by the one operational fact an agent needs. No filler or restated fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need no explanation, and a zero-parameter read-only lookup has no other prerequisites or edge cases. What an agent needs to call it correctly is present.

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?

Parameter count is 0 and schema coverage is 100%, so there are no parameters to document and no gap for the description to fill. Baseline 4 applies.

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?

States a specific verb+resource ('List the supported Kurdish dialects and their scripts') that no sibling duplicates — the other tools handle plans, voices, synthesis, and transcription. It never names a sibling to distinguish itself from, but the resource is unambiguous.

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?

'Static capability descriptor — costs nothing and needs no API key' implies the tool is a free, safe lookup, which suggests when to reach for it. It does not state when-not to use it or point to any alternative for related needs (e.g. voices), leaving usage to inference.

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

list_voicesList Kurdish TTS voicesA

Read-onlyIdempotent

Inspect

List available Kurdish text-to-speech voices. Returns speaker ids to use with synthesize_speech. Free metadata call — no credits consumed, no API key needed. Defaults to model_version "v3", the SAME default synthesize_speech uses — pass the same model_version to both, because a speaker id from one catalog does not exist in another. Results are paginated; the response reports total_count and which ids a free plan may render.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum voices to return. Default 25.
`gender`	No	Filter by voice gender.
`offset`	No	Number of voices to skip, for paging. Default 0.
`dialect`	No	Filter by dialect.
`model_version`	No	Voice catalog. Default "v3", matching synthesize_speech. v3 is the compatibility catalog; v4 is the large catalog (hundreds of voices); v5 is the curated catalog plus Cast and Studio voices, and requires a paid API plan.

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`limit`	Yes
`offset`	Yes
`has_more`	Yes
`speakers`	Yes
`your_plan`	Yes
`total_count`	Yes
`model_version`	Yes
`returned_count`	Yes
`unique_speaker_ids`	Yes
`model_version_source`	Yes
`free_plan_speaker_ids`	Yes
`your_allowed_model_versions`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explicitly states 'no credits consumed, no API key needed', which is a free-call guarantee not in the annotations. It also discloses pagination behavior and the model_version default matching synthesize_speech. This is meaningful added context, though it doesn't describe the exact response structure (but an output schema exists).

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 compact and front-loaded: the core purpose is in the first sentence, followed by the most important usage constraint (model_version matching), then pagination and free-plan notes. Every sentence earns its place, and the critical warning about speaker id catalogs is placed early. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only metadata list tool with 100% schema coverage, an output schema, and annotations covering safety, the description is complete. It covers the key cross-tool dependency (model_version must match synthesize_speech), pagination behavior, free-plan rendering info, and the no-credits/no-key fact. An agent has everything needed to call this tool correctly and interpret its results.

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 5 parameters thoroughly, including enums and defaults. The description adds some cross-parameter context (model_version default matches synthesize_speech, and the v3/v4/v5 distinction is already in the schema). It doesn't add much beyond the schema, but the baseline of 3 is appropriate because the schema carries 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 states a specific verb ('List'), a clear resource ('available Kurdish text-to-speech voices'), and explicitly distinguishes its output from a sibling ('Returns speaker ids to use with synthesize_speech'). It also clarifies it is a metadata call, which differentiates it from synthesis and transcription siblings. This is a clear, specific purpose statement.

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

Usage Guidelines5/5

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

The description explicitly tells the agent when to use this tool: to get speaker ids for synthesize_speech. It also gives a critical usage rule: pass the same model_version to both list_voices and synthesize_speech because speaker ids are catalog-specific. It also notes that results are paginated and that the response reports which ids a free plan may render, giving the agent actionable context for using the tool correctly.

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

start_streaming_transcriptionStart live Kurdish transcription session (listening, not speaking)A

Destructive

Inspect

Open a live speech-to-text session for LISTENING — a microphone or audio stream you transcribe in real time. This does NOT make anything speak; to speak Kurdish use synthesize_speech, or POST https://www.kurdishtts.com/api/tts-stream for progressive audio. WARNING: calling this immediately consumes one streaming session from your STT plan quota — only call it when you are ready to connect. Returns a websocket_url: open it, stream PCM16 mono 16kHz audio chunks, send {"type": "finalize"} to flush and {"type": "done"} to close. Session duration is limited by plan.

ParametersJSON Schema

Name	Required	Description	Default
`dialect`	Yes	Dialect that will be spoken.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations mark this non-idempotent and destructive, and the description adds real behavioral detail beyond them: it consumes a streaming session from the plan quota immediately, returns a websocket_url, requires PCM16 mono 16kHz chunks, and defines the finalize/done control messages plus a plan-limited session duration. That is substantial disclosure for a mutation-style tool.

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?

Front-loads the LISTENING scope, then the exclusion, then the quota warning, then the protocol. Dense but every clause carries operational information; the only mild cost is the density of the websocket protocol detail in a single paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description explains the return value (websocket_url) and exactly how to consume it, including audio format and close semantics. An agent has everything needed to call and drive the session correctly.

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% with a single enum dialect parameter fully documented in the schema, so the baseline is 3. The description adds nothing about the dialect parameter (e.g., which dialects the STT model supports), so it neither compensates nor detracts.

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?

States a specific verb+resource (open a live speech-to-text session) and immediately scopes it as LISTENING only, explicitly naming the contrasting sibling synthesize_speech for the speaking direction. An agent can distinguish it from synthesize_speech and transcribe_audio from the first sentence alone.

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

Usage Guidelines5/5

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

Explicit when-to-use (only when ready to connect), when-not (does not make anything speak), and the alternative route for the opposite capability (synthesize_speech or the tts-stream endpoint). The quota warning gives a concrete precondition for calling.

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

synthesize_speechKurdish text to speechAInspect

Convert Kurdish text (Sorani or Kurmanji) to speech audio. Requires a TTS API key; characters are billed against your plan. Get speaker_id from list_voices called with the SAME model_version you pass here (default "v3") — ids are not shared between catalogs. Returns one complete clip: MCP cannot stream, so for a live voice agent call POST https://www.kurdishtts.com/api/tts-stream directly instead (SSE, first audio in ~1s). Max 4000 characters per call in the default mp3 container, 600 with format "wav"; free plans are capped at 500 server-side. Note: speed is caller-facing (higher = faster).

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Kurdish text to synthesize. Max 4000 characters (only 600 if you set format "wav"); free plans are capped at 500.
`speed`	No	Playback speed, higher = faster. Default 1.
`format`	No	Audio container. Default "mp3". Audio is returned base64-encoded inside the tool result, so the container decides how much of your context it costs: for identical speech, mp3 is ~7.5x smaller than wav and opus ~11.5x. Choose "wav" only when you need uncompressed audio, and keep the text under 600 characters if you do.
`dialect`	No	Language the text is in. Normally inferred from the speaker_id prefix and safe to omit. REQUIRED to get a correct Kurmanji read from a Cast or Studio voice (cast_, studio_): those are tagged sorani after their reference clip but read Sorani and Kurmanji, so without this they pronounce Kurmanji with Sorani phonetics. "badini" is valid only with one of the six badini_ voices — pairing it with any other voice is refused with a 400.
`speaker_id`	Yes	Voice id from list_voices, e.g. "sorani_85" or "kurmanji_6" on the default "v3" catalog. Dialect is derived from the prefix. Must come from the same model_version you pass below.
`model_version`	No	Voice catalog and plan entitlement. Default "v3". Explicit "v5" and the Cast/Studio voices require a paid API plan.
`include_timestamps`	No	Return JSON with word-level timestamps instead of an audio block. NOTE: the audio in that JSON is headerless raw PCM16 (24kHz mono), not a WAV file — add a WAV header before saving it, or it will not play.

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavioral context beyond the neutral annotations: API key requirement, per-character billing, 4000/600/500 character caps, free-plan server-side limit, one-complete-clip non-streaming behavior, model-version catalog scoping for voice IDs, and the caller-facing speed direction. This goes well beyond what annotations convey and directly shapes expectation.

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 dense and front-loaded: purpose, then prerequisites, then limitations and the streaming alternative, then speed semantics. It repeats a couple of schema details like default 'v3' and character limits, but each sentence carries operational importance and the structure is logical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only neutral annotations, the description carries the full burden of operational context and does so thoroughly: auth, billing, size limits, streaming limitation, fallback endpoint, and cross-tool prerequisites. Nothing an agent needs to decide whether to invoke it and do so correctly is missing.

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%, so the schema already documents each parameter. The description adds real cross-parameter meaning: speaker_id must come from the same model_version, format determines character limits and audio size tradeoffs, and speed is caller-facing. This exceeds the baseline for fully-covered schemas.

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?

States the exact function — converting Kurdish text (Sorani or Kurmanji) to speech audio — with a specific verb, resource, and dialect scope. The description also distinguishes this from streaming/TTS streaming and transcribe-style siblings by noting MCP cannot stream, so the agent can correctly separate it from start_streaming_transcription and transcribe_audio.

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

Usage Guidelines4/5

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

Explicitly directs live voice agent use cases away from this tool to the direct HTTPS SSE endpoint, and instructs the agent to obtain speaker_id from list_voices with the same model_version. It does not explicitly contrast this tool with transcribe_audio or start_streaming_transcription beyond the streaming note, but the purpose clarity makes those distinctions obvious.

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

transcribe_audioKurdish speech to textAInspect

Transcribe Kurdish audio (Sorani or Kurmanji) to text. Requires an STT API key; usage is metered per audio minute against your plan. IMPORTANT: dialect selects the decoder and nothing detects it for you — transcribing Sorani audio as Kurmanji returns fluent, confident, WRONG text with no error. Pass dialect "auto" when you are not certain, and pick the coherent transcript from the two it returns. Max 3MB of decoded audio over MCP (~90s of 16kHz WAV, but ~25 minutes of 64kbps MP3 — send compressed audio to fit more); for larger files call POST https://www.kurdishtts.com/api/stt-proxy directly (multipart).

ParametersJSON Schema

Name	Required	Description
`dialect`	Yes	Which decoder to run. "sorani" or "kurmanji" when you know the dialect. "auto" transcribes with BOTH and returns both transcripts so you can choose — it bills the audio twice, so prefer a known dialect when you have one.
`filename`	No	Original filename, used to infer the format. Default audio.wav.
`mime_type`	No	Audio MIME type. Default audio/wav.
`audio_base64`	Yes	Base64-encoded audio file (WAV, MP3, FLAC, OGG or M4A). Max 3MB decoded — compressed formats fit far more speech in that budget than WAV does.

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations (which only declare non-read-only, non-destructive, non-idempotent) by disclosing the API-key requirement, per-minute metering, the double billing of "auto", and the silent wrong-output failure mode when the dialect is misidentified. This is exactly the context an agent cannot get from structured fields.

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?

Front-loads the operation, then the hard constraint (dialect selection), then the size limit and escape hatch. Dense but every clause earns its place; the parenthetical bitrate arithmetic is the only slightly bulky part.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by stating what "auto" returns (two transcripts) and warning about the silent-failure mode. It stops short of describing the single-dialect response shape or error behavior, a minor gap for a well-annotated tool.

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%, so the baseline is 3, but the description adds real meaning: it explains the consequence of the dialect choice (wrong decoder produces confident nonsense) and the practical size math for WAV versus MP3. It does not add anything about filename or mime_type, which the schema already handles.

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?

States a specific verb and resource ('Transcribe Kurdish audio ... to text') and narrows scope to two dialects, which cleanly separates it from synthesize_speech and the streaming sibling. An agent can identify the operation immediately.

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

Usage Guidelines4/5

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

Gives explicit conditions for choosing a known dialect versus "auto" and tells the agent to bypass MCP for files over the size limit, including the endpoint and encoding. It never names the sibling start_streaming_transcription as the alternative for long audio, so routing within the toolset is left to inference.

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.

2 tool updatesSep 15, 2026

Changedlist_voices1 field changed

changedInput schema / properties / dialect / enum

Previous value: -[
-  "sorani",
-  "kurmanji"
-]New value: +[
+  "sorani",
+  "kurmanji",
+  "badini"
+]

Changedsynthesize_speech2 fields changed

changedInput schema / properties / dialect / description

Previous value: -"Language the text is in. Normally inferred from the speaker_id prefix and safe to omit. REQUIRED to get a correct Kurmanji read from a Cast or Studio voice (cast_*, studio_*): those are tagged sorani after their reference clip but read both dialects, so without this they pronounce Kurmanji with Sorani phonetics."New value: +"Language the text is in. Normally inferred from the speaker_id prefix and safe to omit. REQUIRED to get a correct Kurmanji read from a Cast or Studio voice (cast_*, studio_*): those are tagged sorani after their reference clip but read Sorani and Kurmanji, so without this they pronounce Kurmanji with Sorani phonetics. \"badini\" is valid only with one of the six badini_ voices — pairing it with any other voice is refused with a 400."

changedInput schema / properties / dialect / enum

Previous value: -[
-  "sorani",
-  "kurmanji"
-]New value: +[
+  "sorani",
+  "kurmanji",
+  "badini"
+]

3 tool updatesSep 13, 2026

Changedlist_voices5 fields changed

addedOutput schema / properties / speakers / items / properties / dialect_note
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / speakers / items / properties / reads_either_dialect
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / properties / speakers / items / required

Previous value: -[
-  "free_plan",
-  "usable_by_you",
-  "requires_developer_plan"
-]New value: +[
+  "free_plan",
+  "usable_by_you",
+  "requires_developer_plan",
+  "reads_either_dialect"
+]

addedOutput schema / properties / unique_speaker_ids
```
Added value: +{
+  "type": "number"
+}
```

changedOutput schema / required

Previous value: -[
-  "model_version",
-  "model_version_source",
-  "your_plan",
-  "your_allowed_model_versions",
-  "total_count",
-  "returned_count",
-  "offset",
-  "limit",
-  "has_more",
-  "free_plan_speaker_ids",
-  "note",
-  "speakers"
-]New value: +[
+  "model_version",
+  "model_version_source",
+  "your_plan",
+  "your_allowed_model_versions",
+  "total_count",
+  "unique_speaker_ids",
+  "returned_count",
+  "offset",
+  "limit",
+  "has_more",
+  "free_plan_speaker_ids",
+  "note",
+  "speakers"
+]

Changedsynthesize_speech4 fields changed

addedInput schema / properties / dialect

Added value: +{
+  "description": "Language the text is in. Normally inferred from the speaker_id prefix and safe to omit. REQUIRED to get a correct Kurmanji read from a Cast or Studio voice (cast_*, studio_*): those are tagged sorani after their reference clip but read both dialects, so without this they pronounce Kurmanji with Sorani phonetics.",
+  "enum": [
+    "sorani",
+    "kurmanji"
+  ],
+  "type": "string"
+}

addedInput schema / properties / format

Added value: +{
+  "description": "Audio container. Default \"mp3\". Audio is returned base64-encoded inside the tool result, so the container decides how much of your context it costs: for identical speech, mp3 is ~7.5x smaller than wav and opus ~11.5x. Choose \"wav\" only when you need uncompressed audio, and keep the text under 600 characters if you do.",
+  "enum": [
+    "mp3",
+    "opus",
+    "wav"
+  ],
+  "type": "string"
+}

changedInput schema / properties / text / description

Previous value: -"Kurdish text to synthesize. Max 600 characters; free plans are capped at 500."New value: +"Kurdish text to synthesize. Max 4000 characters (only 600 if you set format \"wav\"); free plans are capped at 500."

changedInput schema / properties / text / maxLength
```
Previous value: -600New value: +4000
```

Changedtranscribe_audio3 fields changed

changedInput schema / properties / audio_base64 / description

Previous value: -"Base64-encoded audio file (WAV, MP3, FLAC, OGG or M4A). Max 3MB decoded."New value: +"Base64-encoded audio file (WAV, MP3, FLAC, OGG or M4A). Max 3MB decoded — compressed formats fit far more speech in that budget than WAV does."

changedInput schema / properties / dialect / description

Previous value: -"Dialect spoken in the audio."New value: +"Which decoder to run. \"sorani\" or \"kurmanji\" when you know the dialect. \"auto\" transcribes with BOTH and returns both transcripts so you can choose — it bills the audio twice, so prefer a known dialect when you have one."

changedInput schema / properties / dialect / enum

Previous value: -[
-  "sorani",
-  "kurmanji"
-]New value: +[
+  "sorani",
+  "kurmanji",
+  "auto"
+]

6 tool updatesSep 13, 2026

Addedget_plan

Changedlist_dialects4 fields changed

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

removedInput schema / required
```
Removed value: -[
-  "context"
-]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "dialects": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "direction": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "script": {
+            "type": "string"
+          },
+          "speaker_id_prefix": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "name",
+          "script",
+          "direction",
+          "speaker_id_prefix"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "dialects"
+  ],
+  "type": "object"
+}

Changedlist_voices8 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

addedInput schema / properties / gender

Added value: +{
+  "description": "Filter by voice gender.",
+  "enum": [
+    "male",
+    "female"
+  ],
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Maximum voices to return. Default 25.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}

changedInput schema / properties / model_version / description

Previous value: -"Voice catalog. v3 is the compatibility default; v4 has up to 664 voices; v5 is the curated catalog: 20 voices, plus 13 Cast and Studio voices on plans bought for the API."New value: +"Voice catalog. Default \"v3\", matching synthesize_speech. v3 is the compatibility catalog; v4 is the large catalog (hundreds of voices); v5 is the curated catalog plus Cast and Studio voices, and requires a paid API plan."

addedInput schema / properties / offset

Added value: +{
+  "description": "Number of voices to skip, for paging. Default 0.",
+  "minimum": 0,
+  "type": "integer"
+}

removedInput schema / required
```
Removed value: -[
-  "context"
-]
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "free_plan_speaker_ids": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "has_more": {
+      "type": "boolean"
+    },
+    "limit": {
+      "type": "number"
+    },
+    "model_version": {
+      "type": "string"
+    },
+    "model_version_source": {
+      "type": "string"
+    },
+    "note": {
+      "type": "string"
+    },
+    "offset": {
+      "type": "number"
+    },
+    "returned_count": {
+      "type": "number"
+    },
+    "speakers": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "dialect": {
+            "type": "string"
+          },
+          "free_plan": {
+            "type": "boolean"
+          },
+          "gender": {
+            "type": "string"
+          },
+          "id": {
+            "type": "string"
+          },
+          "name": {
+            "type": "string"
+          },
+          "requires_developer_plan": {
+            "type": "boolean"
+          },
+          "speaker_id": {
+            "type": "string"
+          },
+          "usable_by_you": {
+            "type": [
+              "boolean",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "free_plan",
+          "usable_by_you",
+          "requires_developer_plan"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "total_count": {
+      "type": "number"
+    },
+    "your_allowed_model_versions": {
+      "anyOf": [
+        {
+          "items": {
+            "type": "string"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "your_plan": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "required": [
+    "model_version",
+    "model_version_source",
+    "your_plan",
+    "your_allowed_model_versions",
+    "total_count",
+    "returned_count",
+    "offset",
+    "limit",
+    "has_more",
+    "free_plan_speaker_ids",
+    "note",
+    "speakers"
+  ],
+  "type": "object"
+}

Changedstart_streaming_transcription3 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "dialect",
-  "context"
-]New value: +[
+  "dialect"
+]

Changedsynthesize_speech7 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

changedInput schema / properties / include_timestamps / description

Previous value: -"Return JSON with word-level timestamps and base64 audio instead of audio content."New value: +"Return JSON with word-level timestamps instead of an audio block. NOTE: the audio in that JSON is headerless raw PCM16 (24kHz mono), not a WAV file — add a WAV header before saving it, or it will not play."

changedInput schema / properties / model_version / description

Previous value: -"Voice catalog and plan entitlement. Default v3; every option renders on V5, and explicit v5 requires a paid API plan."New value: +"Voice catalog and plan entitlement. Default \"v3\". Explicit \"v5\" and the Cast/Studio voices require a paid API plan."

changedInput schema / properties / speaker_id / description

Previous value: -"Voice id from list_voices, e.g. sorani_1 or kurmanji_236. Dialect is derived from the prefix."New value: +"Voice id from list_voices, e.g. \"sorani_85\" or \"kurmanji_6\" on the default \"v3\" catalog. Dialect is derived from the prefix. Must come from the same model_version you pass below."

changedInput schema / properties / text / description

Previous value: -"Kurdish text to synthesize."New value: +"Kurdish text to synthesize. Max 600 characters; free plans are capped at 500."

changedInput schema / required

Previous value: -[
-  "text",
-  "speaker_id",
-  "context"
-]New value: +[
+  "text",
+  "speaker_id"
+]

Changedtranscribe_audio5 fields changed

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / audio_base64 / description

Previous value: -"Base64-encoded audio file (WAV, MP3, FLAC, OGG or M4A)."New value: +"Base64-encoded audio file (WAV, MP3, FLAC, OGG or M4A). Max 3MB decoded."

addedInput schema / properties / audio_base64 / maxLength
```
Added value: +4194308
```

removedInput schema / properties / context

Removed value: -{
-  "description": "Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): \"Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization.\"",
-  "type": "string"
-}

changedInput schema / required

Previous value: -[
-  "audio_base64",
-  "dialect",
-  "context"
-]New value: +[
+  "audio_base64",
+  "dialect"
+]

1 tool updateSep 10, 2026

Changedlist_voices1 field changed

changedInput schema / properties / model_version / description

Previous value: -"Voice catalog. v3 is the compatibility default; v4 has up to 664 voices; v5 is the 21-voice curated catalog."New value: +"Voice catalog. v3 is the compatibility default; v4 has up to 664 voices; v5 is the curated catalog: 20 voices, plus 13 Cast and Studio voices on plans bought for the API."

2 tool updatesSep 4, 2026

Changedlist_voices2 fields changed

changedInput schema / properties / model_version / description

Previous value: -"Voice catalog version. v4 (default) has 664 voices."New value: +"Voice catalog. v3 is the compatibility default; v4 has up to 664 voices; v5 is the 21-voice curated catalog."

changedInput schema / properties / model_version / enum

Previous value: -[
-  "v3",
-  "v4"
-]New value: +[
+  "v3",
+  "v4",
+  "v5"
+]

Changedsynthesize_speech2 fields changed

changedInput schema / properties / model_version / description

Previous value: -"TTS model. Default v3; v4 requires a plan with v4 access."New value: +"Voice catalog and plan entitlement. Default v3; every option renders on V5, and explicit v5 requires a paid API plan."

changedInput schema / properties / model_version / enum

Previous value: -[
-  "v3",
-  "v4"
-]New value: +[
+  "v3",
+  "v4",
+  "v5"
+]

5 tool updatesAug 10, 2026
- First observedlist_dialects
- First observedlist_voices
- First observedstart_streaming_transcription
- First observedsynthesize_speech
- First observedtranscribe_audio

Related MCP Connectors

tts A
com.brainiall
Hosted pay-per-use TTS: 54 neural voices, 9 languages incl. Brazilian Portuguese. $10 free credits.
Text-to-Speech Audio Processing
2
mazdek AI — Kurdish Language Tools
ai.mazdek
Kurdish-first AI tools: translation (250+ languages), spell check, grammar, speech-to-text and TTS.
Language Translation Text-to-Speech AI & Machine Learning
1
echo A
com.thetempleofdoom.echo-mcp
Text-to-speech API: neural voices, pay-per-credit in Bitcoin sats via BTCPay.
Text-to-Speech Payments & Billing
51
Speech AI - Pronunciation, STT & TTS A
io.github.fasuizu-br
Pronunciation scoring, speech-to-text, and text-to-speech for language learning
Text-to-Speech Speech Processing Audio Processing
2

Related MCP Servers

firered-tts
Text-to-Speech Speech Processing Audio Processing
taral14
F
license
Not graded
quality
B
maintenance
Local multilingual TTS (24 languages incl. Ukrainian) with zero-shot voice cloning, voice design, and speech editing via HTTP API and MCP server.
Updated a month ago (2026-08-21 19:05 UTC)
4
-
brainiall-tts-mcp
Text-to-Speech Audio Processing
fasuizu-br
A
license
Not graded
quality
A
maintenance
Hosted text-to-speech MCP server for AI agents with 54 neural voices in 9 languages, including Brazilian Portuguese. Pay-per-use API, no GPU or subscriptions needed.
Updated a month ago (2026-08-11 04:48 UTC)
MIT
NeuroDynamic Audio and LLM
Audio Processing AI & Machine Learning Payments & Billing
Hy1ander
A
license
A
quality
A
maintenance
Discover audio and LLM services, compare seven voices, and check prices for free. Generate speech, transcribe audio and request LLM text with optional capped USDC payments on Base; voice-cloning requirements are also available.
Updated 3 days ago (2026-09-23 11:23 UTC)
6
1
MIT
Advanced TTS MCP Server
Text-to-Speech Multimedia Processing Audio Processing
samihalawa
A
license
A
quality
D
maintenance
Provides high-quality text-to-speech synthesis with 10 natural voices, emotion control, and dynamic pacing for professional applications requiring expressive speech output.
Updated a year ago (2025-06-25 06:17 UTC)
5
2
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?