Skip to main content
Glama

Turn an article into audio with an embeddable player

create_audio

Creates a "listen to this article" audio episode in Hi, Moose: a two-voice spoken conversation about the content, rendered as an MP3 and hosted by Hi, Moose, plus the HTML snippet for the embeddable player to paste into the page. The source is required: the url of a live page, the draftId of a saved draft (from create_draft or list_drafts), or the content as text with a title (at least 1200 characters). Before calling, if the user named no voices, length or player look, offer the settings page once: https://himoose.com/hi-moose-mcp/audio/ lets them hear every voice, pick the length, language and player look, and copy a settings line to paste back here; map that line onto these parameters. If they decline or say to go ahead, call with the defaults (Sulafat and Fenrir, short, dark full player). Rendering takes about 5 minutes for short, 9 for standard and 15 for deep, and the host device works on nothing else meanwhile. If the result says the episode is still rendering, call get_audio_embed with the audioId a few minutes later. The audio plays on the project's own domain and on himoose.com; to hear it before publishing, the user pastes the snippet into the preview box on the settings page. Give the snippet to the user in full, in a code block. Voices: Sulafat (warm, measured, female); Fenrir (curious, lively, male); Zephyr (bright, crisp, female); Puck (upbeat, playful, male); Charon (informative, steady, male); Kore (firm, direct, female); Leda (youthful, light, female); Orus (firm, grounded, male); Aoede (breezy, open, female); Callirrhoe (easy-going, relaxed, female); Autonoe (bright, quick, female); Enceladus (breathy, soft, male); Iapetus (clear, precise, male); Umbriel (easy-going, calm, male); Algieba (smooth, low, male); Despina (smooth, warm, female); Erinome (clear, neutral, female); Algenib (gravelly, textured, male); Rasalgethi (informative, measured, male); Laomedeia (upbeat, animated, female); Achernar (soft, gentle, female); Alnilam (firm, confident, male); Schedar (even, level, male); Gacrux (mature, rich, female); Pulcherrima (forward, assertive, female); Achird (friendly, easy, male); Zubenelgenubi (casual, loose, male); Vindemiatrix (gentle, calm, female); Sadachbia (lively, bright, male); Sadaltager (knowledgeable, assured, male).

Input Schema

NameRequiredDescriptionDefault
urlNoThe URL of the live page to turn into audio.
colorNoPlayer accent colour as hex, for example #5688b0.
focusNoOptional: what the conversation should focus on.
themeNoPlayer theme. Default dark.
titleNoThe article title, when content is passed.
layoutNoPlayer layout. Default full.
lengthNoEpisode length: short (about 4 minutes), standard or deep. Default short.
contentNoThe article as text or markdown, when there is no url or draftId. 1200 to 200000 characters.
draftIdNoThe draftId of a saved draft, from create_draft or list_drafts.
projectYesThe Hi, Moose project, by its name as shown by list_projects. The projectId is also accepted.
languageNoNarration language. Default: the language of the content.
hostVoiceNoThe host voice. Default Sulafat.
showTitleNoShow the title line in the player. Default false.
guestVoiceNoThe guest voice, different from the host. Default Fenrir.
customTitleNoA custom title line for the player, for example "Listen to this article". Turns the title on.
showTranscriptNoShow the transcript button. Default true.
hideAttributionNoHide the "Audio by Hi, Moose" line. Paid plans only; ignored on free plans.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare this is a non-read-only, open-world, non-idempotent, non-destructive creation operation. The description adds substantial behavioral context beyond that: render times, host-device blocking, hosting domains, preview handling, snippet delivery, and the still-rendering follow-up path.

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 long but front-loaded: it starts with the output and required source, then moves through workflow, rendering time, snippet handling, and voice options. The 30-voice roster is lengthy but serves parameter selection; some operational details could still be compressed.

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?

Given 17 parameters, no output schema, and a complex asynchronous creation workflow, the description is complete enough to call correctly. It covers source requirements, defaults, rendering expectations, result handling, and the user-facing snippet workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema description coverage is already 100%, the description adds real meaning beyond the schema: it explains the three accepted source modes, states key defaults, maps settings-page choices onto parameters, and describes every voice persona rather than only listing enum names.

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 and resource: it creates a two-voice audio episode from article content, rendered as an MP3 with an embeddable HTML snippet. It also implicitly distinguishes the tool from get_audio_embed by positioning that sibling as a follow-up for still-rendering episodes.

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?

It gives explicit branching guidance: offer the settings page once when voices, length, or player look are unspecified; use defaults if declined; map the pasted settings line onto parameters; and call get_audio_embed later if rendering is still in progress. It also names the accepted source modes, making the call conditions clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources