MightyAutomation

Generate audio (ElevenLabs)

grok_generate_audio

Turn a stored transcript (transcript_id), pasted text, or ready-made script turns into a generated podcast episode via ElevenLabs. Paid, metered generation that runs in the background: returns immediately with the job id — call grok_stitch with it for status and the final audio path.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "grok_generate_audio"
  }
}

Input Schema

Name	Required	Description
`text`	No	Raw article/transcript text to adapt — used when transcript_id is absent.
`title`	No	Episode title override.
`turns`	No	Ready-made script turns [{speaker:"HOST"\|"NATALIE", text}] — skips AI script writing.
`with_natalie`	No	Two-voice co-host format (default single-host).
`transcript_id`	No	podcast_transcripts id (uuid) from grok_upload_transcript.

Output Schema

Name	Required	Description
`ok`	No
`error`	No	Present only when ok is false.
`job_id`	No
`run_id`	No
`status`	No
`episode_id`	No
`credits_estimate`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations only declare the generic profile (not read-only, open-world, non-idempotent, non-destructive). The description adds genuinely new behaviour: the operation is paid and metered, runs asynchronously in the background, and returns immediately with a job id rather than audio. It doesn't mention failure modes, credit cost magnitude, or what happens on partial failure.

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 dense sentences with no filler: the first defines the operation and its inputs, the second front-loads the async/metered contract and the handoff tool. Nothing is repeated from the schema or annotations.

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?

An output schema exists, so return values needn't be spelled out, and the async handoff is covered. The one gap is that all five parameters are optional and the description never states that at least one of transcript_id/text/turns must be supplied, leaving the agent to infer the valid call shape.

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 per-parameter baseline is 3. The description earns an extra point by framing the parameters as mutually exclusive input modes (transcript vs text vs turns) and noting that turns 'skips AI script writing', i.e. a cross-parameter precedence not stated in the schema itself.

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 names a specific verb (generate) plus the resource (podcast episode audio via ElevenLabs) and enumerates the three accepted input shapes: stored transcript, pasted text, or ready-made script turns. This clearly separates it from siblings like grok_generate_video and grok_upload_transcript without opening either schema.

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?

It states the input-selection conditions (transcript_id vs pasted text vs turns) and gives an explicit follow-up path: call grok_stitch with the returned job id for status and the final audio path. It stops short of naming when *not* to use this tool or explaining the division of labour with grok_render_status, which is a plausible alternative for polling.

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

All MightyAutomation tools Inspect

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?