Skip to main content
Glama

create_podcast

Start an Animated Podcast episode: two AI hosts with two different voices talking through a topic over a held studio picture, with captions. Returns a job id at once; use check_video for progress and the link.

SPENDS REAL MONEY: one minute from the user's monthly pool per minute of episode. Premium up to 30 minutes, Ultimate up to 60. Agree topic, length, tone, the two hosts (names and voices, which must differ) and the studio with the user first, and call once per request on their own direct request only. The studio is an image_url from preview_podcast_studio the user approved, the name of a saved studio from list_podcast_studios (which also brings that studio's host names, looks and voices unless you give others), or a public link to the user's own finished studio picture. Voices are the built-in ones from list_video_options (not cloned voices). No background music on podcasts. SHOWS: if show_name is one of the user's saved shows, the settings of its last episode fill in anything you do not pass, so a repeat episode only needs a topic; save_show remembers this episode's set-up under show_name. After it is finished: make_podcast_thumbnail for a thumbnail with these hosts, podcast_youtube_details for the YouTube title, description, chapters and tags, and edit_podcast to change lines, voices, captions, sound bar or studio.

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": {
      "topic": "<topic>"
    },
    "name": "create_podcast"
  }
}

Input Schema

NameRequiredDescriptionDefault
toneNofriendly = warm, curious chat (default); educational = one explains, one asks; debate = two sides, kept respectful; funny = quick banter with substance; storytelling = one tells, one reacts.
topicYesWhat the episode is about.
host_aNoLeft host.
host_bNoRight host.
studioNoOr: the name of a saved studio (list_podcast_studios).
minutesNoLength in minutes. Premium 1 to 30, Ultimate 1 to 60. Defaults to 5.
like_ctaNo
soundbarNoThe bars that bounce with the voices. classic = top centre (default); top = full-width along the top edge; hosts = a set above each host, only the talker's light up; edge = full-width along the bottom; corner = small, top-left; off = none.
save_showNoRemember this episode's hosts, voices, studio and settings under show_name, so the next episode only needs a topic.
show_nameNoOptional show name the hosts use.
comment_ctaNo
subscribe_ctaNo
subtitle_styleNoCaptions. Defaults to none (no captions); pick a style to turn them on.
studio_image_urlNoimage_url from preview_podcast_studio after the user approved it, or a public link (https) to the user's own finished studio picture with the two hosts in it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / subtitle_style / description
      Previous value: -"Captions. Defaults to clean; none turns them off."New value: +"Captions. Defaults to none (no captions); pick a style to turn them on."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses real monetary cost (one pool minute per episode minute, tier caps of 30/60) before anything else, states it is asynchronous and returns a job id immediately, and lists hard constraints (voices must differ, built-in voices only, no background music). It also explains non-obvious state behavior — show_name inherits the last episode's settings and save_show persists this one.

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?

Every sentence earns its place — cost, prerequisites, parameter rules, show inheritance, follow-ups — and the money warning is front-loaded right after the purpose. The trade-off is a single dense block with no line breaks or bullets, which makes the studio and show rules harder to scan for a 14-parameter tool.

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 costly, asynchronous, multi-prerequisite creation tool with no output schema, the description covers everything an agent needs before calling: cost model, tier limits, async job-id return, required user agreement, valid studio/voice sources, and post-completion next steps. Only the CTA booleans are left unexplained, which is minor.

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?

At 79% schema coverage the description still adds real meaning the schema does not: the three accepted forms of 'studio' (approved image_url, saved studio name, public link), the side effect that a saved studio supplies host names/looks/voices, and the show_name inheritance/save_show pairing. It says nothing about like_cta, comment_cta or subscribe_cta, and doesn't clarify host_a/host_b 'look' or gender, so a few parameters remain undocumented in prose.

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?

Opens with a concrete verb and resource ('Start an Animated Podcast episode') and immediately describes the output artifact — two AI hosts, two voices, a held studio picture, captions. It is clearly distinguishable from edit_podcast and preview_podcast_studio, which appear later by name.

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 about when and how to invoke: agree topic, length, tone, hosts and studio with the user first; call once per request, only on the user's own direct request. It also routes follow-up work (check_video for progress, make_podcast_thumbnail, podcast_youtube_details, edit_podcast after finishing) and names the prerequisite tools (preview_podcast_studio, list_podcast_studios, list_video_options).

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