Skip to main content
Glama

podcasts

by com.petabloom

Get Transcript

get_transcript
Read-onlyIdempotent

Fetch a bounded transcript chunk for a specific episode using its show and episode GUIDs. Use next_cursor to continue reading.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNoZero-based character offset into the transcript. Use the `next_cursor` returned by a prior get_transcript call to fetch the next chunk.
max_charsNoTarget maximum number of transcript characters to return. Chunks prefer natural boundaries and may be slightly shorter. Must be between 100 and 20000.
show_guidYesPodcast show GUID returned by `search_episodes` or `get_latest_episodes`.
episode_guidYesEpisode GUID returned by `search_episodes` or `get_latest_episodes`.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesTranscript chunk text.
char_endYesExclusive zero-based end offset of this chunk in the complete transcript.
has_moreYesWhether another get_transcript call is needed to continue reading.
show_guidYesPodcast show GUID requested by the client.
char_startYesInclusive zero-based start offset of this chunk in the complete transcript.
show_titleYesPodcast show title.
next_cursorNoCursor to pass to the next get_transcript call, or null at the end.
total_charsYesTotal character count of the complete transcript text.
episode_guidYesPodcast episode GUID requested by the client.
rss_feed_urlYesRSS feed URL for the podcast show.
episode_titleYesPodcast episode title.
published_dateYesEpisode publication timestamp in ISO 8601 format.
duration_secondsNoEpisode duration in seconds when available from the source feed.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed6 schema fields changed
    • addedOutput schema / properties / duration_seconds
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Episode duration in seconds when available from the source feed."
+}
    • addedOutput schema / properties / episode_title
      Added value: +{
+  "description": "Podcast episode title.",
+  "type": "string"
+}
    • addedOutput schema / properties / published_date
      Added value: +{
+  "description": "Episode publication timestamp in ISO 8601 format.",
+  "type": "string"
+}
    • addedOutput schema / properties / rss_feed_url
      Added value: +{
+  "description": "RSS feed URL for the podcast show.",
+  "type": "string"
+}
    • addedOutput schema / properties / show_title
      Added value: +{
+  "description": "Podcast show title.",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "show_guid",
-  "episode_guid",
-  "text",
-  "total_chars",
-  "char_start",
-  "char_end",
-  "has_more"
-]New value: +[
+  "show_guid",
+  "show_title",
+  "episode_guid",
+  "episode_title",
+  "published_date",
+  "rss_feed_url",
+  "text",
+  "total_chars",
+  "char_start",
+  "char_end",
+  "has_more"
+]
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With annotations already declaring read-only, idempotent, and non-destructive behavior, the description adds value by explaining the chunked/paginated nature ('bounded transcript chunk') and the continuation mechanism. No additional details like error handling are needed given the safety profile.

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?

The description is two concise, front-loaded sentences. The first states the verb, object, and required parameters; the second gives the essential pagination instruction. No filler or redundancy.

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?

Given the rich schema and annotations, the description is nearly complete. It covers the core purpose and pagination. A minor gap is not explicitly directing users to sibling tools for obtaining GUIDs, but the schema does mention this, so the overall context is sufficient for a simple read-only paginated tool.

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%, with all parameters fully documented (e.g., cursor offset, max_chars bounds). The description adds no novel parameter info beyond mentioning show/episode GUIDs and next_cursor, which are already in the schema. Baseline 3 applies as schema does the heavy lifting.

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 uses a specific verb ('Fetch') and resource ('transcript chunk') with clear scope ('for a specific episode') and parameters ('show and episode GUIDs'). It distinguishes itself from sibling tools that list or search episodes, making the purpose unambiguous.

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?

The description clearly indicates how to paginate ('Use next_cursor to continue reading'), which is key usage context. However, it does not explicitly state when to prefer this tool over siblings or provide exclusions; the differentiation is implied by the transcript-specific purpose.

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

All podcasts toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool serves a distinct purpose: two different search methods (keyword vs. semantic), one for listing episodes, one for transcripts, and one for feedback. No ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.

Tool Count4/5

5 tools is on the lower end but appropriate for focused podcast episode retrieval and searching. Each tool has a clear role.

Completeness3/5

Covers core operations: listing, searching (two types), and transcript retrieval. Missing episode metadata details (title, date, description) which agents might need for user-facing tasks.

Resources