Skip to main content
Glama
Sign In

MCP for Claude & ChatGPT

by com.tuqui
OverviewDiscussionsAdmin

Generate speech

speech_generate
Read-only

Turn one or more texts into spoken audio — for example the narration of a video you are recording. Returns one download URL per text, with its audio format; fetch each with curl to put the audio on disk. The audio never passes through the conversation. Each URL works once and expires in 1 hour. Download a few at a time in parallel, not all at once; if a download answers 429, retry it after the Retry-After seconds. A 402 means the member's budget is used up: stop downloading and tell the user. Up to 30 texts of 1000 characters each; split longer narration into several texts. Use style for delivery instructions (tone, pace, accent), with the accent chosen for who will listen, e.g. 'warm and clear, Rioplatense accent' or 'English, natural'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "texts": "<texts>"
    },
    "name": "speech_generate"
  }
}

Input Schema

NameRequiredDescriptionDefault
styleNoOptional delivery instructions: tone, pace, accent, emotion. Pick the accent for who the audio is for, e.g. 'neutral Latin American Spanish', 'Chilean accent'. Without it, the accent is that of the company's country when the text is in a language spoken there, and neutral otherwise.
textsYesThe texts to speak, one clip per text, in order.
voiceNoVoice to use. Default 'Aoede'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Far exceeds the annotations: it discloses that audio never passes through the conversation, that each URL is single-use and expires in 1 hour, that parallel downloads should be limited, and how to interpret 429 (Retry-After) and 402 (budget exhausted, stop and tell the user). These are operational behaviors an agent could not infer from readOnlyHint/openWorldHint alone.

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 core action and output contract, then moves to download mechanics and error handling in a logical order with no filler. It is dense and slightly long, and the closing `style` paragraph partially restates the schema's accent-default text, but every sentence carries actionable information.

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, the description carries the return-value burden and does so: one URL per text, format included, single-use, 1-hour expiry, fetched via curl. Combined with the documented failure modes, an agent has everything needed to invoke and consume the result correctly.

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; the description adds real value on `texts` (splitting long narration across multiple entries) and on `style` (accent chosen for the listener, with worked examples like 'warm and clear, Rioplatense accent'). It does not mention `voice` or its default, but the schema already covers that fully.

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 ('Turn one or more texts into spoken audio') plus the concrete output shape (one download URL per text with its audio format). This clearly separates it from the only relevant sibling, audio_transcribe, without needing to name it.

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 a concrete use case ('narration of a video you are recording'), batch limits (up to 30 texts of 1000 chars, split longer narration), and when to use `style` versus relying on defaults. It stops short of explicitly excluding the inverse tool (audio_transcribe) or naming alternatives, which keeps it at 4 rather than 5.

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

All MCP for Claude & ChatGPT toolsInspect
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