Skip to main content
Glama
pedra-ai

Pedra MCP Server

Official
by pedra-ai

Generate voiceover audio

pedra_generate_voice

Convert a script into a text-to-speech voiceover and return an audioId to attach as narration with synced subtitles when creating or updating a video.

Instructions

Render a voiceover from a script via text-to-speech. Returns an audioId — pass it to pedra_create_video / pedra_update_video as voice.audioId to attach the narration (with synced subtitles).

Input Schema

NameRequiredDescriptionDefault
textYesThe script to narrate (max 1000 characters).
voiceIdNoWhich voice narrates. Call pedra_music_library for the voices offered per language — a voice is only valid for the language it is listed under. Defaults to that language's first voice.
languageNoVoice language, e.g. "English", "Español". Defaults to English.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • addedInput schema / properties / voiceId
      Added value: +{
      +  "description": "Which voice narrates. Call pedra_music_library for the voices offered per language — a voice is only valid for the language it is listed under. Defaults to that language's first voice.",
      +  "type": "string"
      +}
  2. Addedv0.3.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the main remaining burden is workflow behavior. The description usefully discloses that it returns an audioId for downstream attachment with synced subtitles, but omits cost/credit consumption and any rate or length constraints beyond the schema's 1000-char note.

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 sentences, no filler, and the primary action is front-loaded ahead of the downstream-chaining note. Every clause carries information.

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?

With no output schema, the description correctly compensates by stating the return value (audioId) and how to consume it. For a simple three-param TTS tool this is nearly sufficient; only cost/limits are unaddressed.

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% and the schema params are richly documented (voiceId points at pedra_music_library, language defaulting rules, text length cap). The description adds no parameter meaning beyond the schema, so baseline 3 applies.

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 ('Render a voiceover from a script via text-to-speech') and names the enabling mechanism. It is clearly distinguishable from pedra_generate_voice_script, which is the script-writing sibling, because this tool's output is 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 tells the agent what to do with the result: pass the audioId to pedra_create_video / pedra_update_video as voice.audioId. That is real workflow routing, but there is no when-not-to-use guidance or prerequisite (e.g. credits) noted.

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