An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.2/5 across 5 of 5 tools scored. Lowest: 3.6/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.
All tool names follow a consistent verb_noun pattern in snake_case, making them predictable and easy to understand.
5 tools is on the lower end but appropriate for focused podcast episode retrieval and searching. Each tool has a clear role.
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.
get_latest_episodesGet Latest EpisodesAReturn the most recent transcript-ready episodes across the full podcast catalog.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order for results. `relevance` ranks full-text searches first and falls back to newest-first when no query is provided. | published_desc |
| limit | No | Maximum number of episodes to return. Must be between 1 and 50. | |
| cursor | No | Zero-based episode offset for pagination. Use the `next_cursor` returned by a prior search/listing call to fetch the next page of results. | |
| published_after | No | Inclusive lower publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime. | |
| published_before | No | Inclusive upper publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of episodes returned on this page. |
| episodes | Yes | Matching transcript-ready episodes. |
| next_cursor | No | Cursor to pass to the next search call to retrieve the next page of results, or null if there are no more pages. |
| total_count | Yes | Total number of matching transcript-ready episodes across all pages. |
| total_count_is_approximate | No | When true, `total_count` is a lower bound — more matches may exist than were counted. False for exact lexical/date counts; can be true only for semantic results (e.g. the topic-search fallback). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which already establish the safety profile. The description adds that episodes are 'transcript-ready' and span the 'full podcast catalog,' clarifying the scope and quality filter. It does not contradict annotations and adds useful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource. No wasted words; it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with rich schema parameter descriptions, annotations, and an output schema, provides adequate context for most use cases. It doesn't explicitly mention the relevance sort option or search alternatives, but the overall information is sufficient for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with descriptions for all 5 parameters, so the baseline is 3. The description does not add any parameter-specific detail beyond the schema, so no additional credit is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the most recent transcript-ready episodes across the full catalog, using a specific verb ('Return') and resource ('episodes'). It distinguishes from siblings like search_episodes by focusing on 'latest' and 'full catalog' rather than query-based search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for retrieving recent episodes, but it does not explicitly say when to use it over siblings like search_episodes or search_episodes_by_topic. There is no explicit exclusion or alternative reference, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptGet TranscriptAFetch a bounded transcript chunk for a specific episode using its show and episode GUIDs. Use next_cursor to continue reading.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | Zero-based character offset into the transcript. Use the `next_cursor` returned by a prior get_transcript call to fetch the next chunk. | |
| max_chars | No | Target maximum number of transcript characters to return. Chunks prefer natural boundaries and may be slightly shorter. Must be between 100 and 20000. | |
| show_guid | Yes | Podcast show GUID returned by `search_episodes` or `get_latest_episodes`. | |
| episode_guid | Yes | Episode GUID returned by `search_episodes` or `get_latest_episodes`. |
| Name | Required | Description |
|---|---|---|
| text | Yes | Transcript chunk text. |
| char_end | Yes | Exclusive zero-based end offset of this chunk in the complete transcript. |
| has_more | Yes | Whether another get_transcript call is needed to continue reading. |
| show_guid | Yes | Podcast show GUID requested by the client. |
| char_start | Yes | Inclusive zero-based start offset of this chunk in the complete transcript. |
| show_title | Yes | Podcast show title. |
| next_cursor | No | Cursor to pass to the next get_transcript call, or null at the end. |
| total_chars | Yes | Total character count of the complete transcript text. |
| episode_guid | Yes | Podcast episode GUID requested by the client. |
| rss_feed_url | Yes | RSS feed URL for the podcast show. |
| episode_title | Yes | Podcast episode title. |
| published_date | Yes | Episode publication timestamp in ISO 8601 format. |
| duration_seconds | No | Episode duration in seconds when available from the source feed. |
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.
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.
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.
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.
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.
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.
give_feedbackGive FeedbackAInspectSend structured feedback about bugs, missing data, unclear behavior, or feature requests.
| Name | Required | Description | Default |
|---|---|---|---|
| feedback | Yes | Feedback for the server team. Include the problem, missing capability, or suggested improvement without sensitive user data. |
| Name | Required | Description |
|---|---|---|
| status | Yes | Feedback persistence status. |
| message | Yes | Human-readable result summary. |
| feedback_id | Yes | Stable feedback identifier. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and may have external effects (openWorldHint=true). The description adds context about the feedback types but does not disclose what happens after sending (e.g., persistence, confirmation). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the verb and resource, with no unnecessary words. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is complete. It clearly sets expectations for what to send and what the tool is for. No additional behavioral details are required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'feedback' parameter (100% coverage). The tool description adds value by enumerating the feedback categories (bugs, missing data, unclear behavior, feature requests), which enriches understanding beyond the schema's basic 'problem, missing capability, or suggested improvement'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Send structured feedback') and its scope ('about bugs, missing data, unclear behavior, or feature requests'). This unambiguously distinguishes it from all siblings, which are retrieval/search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reporting issues or requests to the server team. It provides clear context but does not explicitly name alternatives or state when not to use the tool. However, sibling tools are all read/search operations, so no real ambiguity exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_episodesSearch EpisodesASearch indexed podcast episodes by keyword or show name and return the show/episode GUIDs needed for transcript retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order for results. `relevance` ranks full-text searches first and falls back to newest-first when no query is provided. | relevance |
| limit | No | Maximum number of episodes to return. Must be between 1 and 50. | |
| query | No | Optional search keywords matched against indexed episode content. Use people, topics, companies, or phrases. | |
| cursor | No | Zero-based episode offset for pagination. Use the `next_cursor` returned by a prior search/listing call to fetch the next page of results. | |
| podcast_name | No | Optional podcast title or internal label to narrow results to a specific show. | |
| published_after | No | Inclusive lower publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime. | |
| published_before | No | Inclusive upper publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime. | |
| published_within_hours | No | Filter episodes published in the past X hours. Maximum 168 hours (1 week). |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of episodes returned on this page. |
| episodes | Yes | Matching transcript-ready episodes. |
| next_cursor | No | Cursor to pass to the next search call to retrieve the next page of results, or null if there are no more pages. |
| total_count | Yes | Total number of matching transcript-ready episodes across all pages. |
| total_count_is_approximate | No | When true, `total_count` is a lower bound — more matches may exist than were counted. False for exact lexical/date counts; can be true only for semantic results (e.g. the topic-search fallback). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by stating that the tool returns show/episode GUIDs needed for transcript retrieval, and that it searches 'indexed' content. However, it does not detail pagination, sorting behavior, or other operational nuances beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 21 words. It is front-loaded with the primary action and purpose, and every word contributes meaning. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (8 params, all documented), output schema, and annotations, the description is sufficient for the tool's core function. It mentions the key return value (GUIDs) but does not explicitly mention that a query is optional or that it can list all episodes when no query is provided. Minor gap, but overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all 8 parameters, so the schema carries the heavy lifting. The description adds no parameter-specific meaning beyond the schema, only the overall purpose. This matches the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search'), states the resource ('indexed podcast episodes'), and specifies scope ('by keyword or show name'). It clearly distinguishes from siblings like search_episodes_by_topic by emphasizing keyword/show-based search, and highlights the end purpose (returning GUIDs for transcript retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need to find episodes by keyword or show name and obtain GUIDs for transcripts. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to infer appropriate usage. A sibling exists for topic-based search, though not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_episodes_by_topicSearch Episodes by TopicASemantic topic search across the podcast catalog. Unlike search_episodes (which does lexical/keyword matching), this tool understands meaning: a query for 'AI safety' will match episodes about 'AI alignment', 'AGI risk', or 'frontier model evaluation' even if they don't contain the exact phrase. Returns ranked episodes with the matched topic phrases so you can explain why each result is relevant before fetching the transcript. Best for conceptual or thematic queries — use search_episodes instead when the user is looking for a specific person, product, or verbatim phrase.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of episodes to return. Must be between 1 and 50. | |
| topic | Yes | Semantic topic to find episodes about. Free-form phrasing welcome — the server embeds this string and finds episodes whose extracted topic phrases are closest in meaning. Good examples: 'AI safety', 'EU AI Act regulation', 'GPU supply constraints', 'Theo Epstein on roster construction'. Distinct from `search_episodes`, which performs lexical keyword matching. | |
| cursor | No | Zero-based episode offset for pagination. Use the `next_cursor` returned by a prior search/listing call to fetch the next page of results. | |
| show_guid | No | Optional canonical show GUID (as returned by `search_episodes` or `get_latest_episodes` in the `show_guid` field) to restrict topic search to a single podcast. Leave empty to search across all shows. | |
| published_after | No | Inclusive lower publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime. | |
| published_before | No | Inclusive upper publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime. |
| Name | Required | Description |
|---|---|---|
| count | Yes | Number of episodes returned on this page. |
| query | Yes | The topic query that was embedded and searched. |
| episodes | Yes | Episodes ranked by best topic-phrase similarity to the query. |
| next_cursor | No | Cursor to pass to the next search call to retrieve the next page of results, or null if there are no more pages. |
| total_count | Yes | Number of matching episodes, counted over the nearest-match candidate window rather than the whole catalog. When `total_count_is_approximate` is true, treat this as a lower bound — broad queries may have more matches than reported. |
| total_count_is_approximate | No | True when the candidate window was exhausted, so `total_count` undercounts the true number of matches. When false, `total_count` is exact. Refine the query for tighter results if this is true and you need a complete set. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds meaningful behavioral context: semantic embedding behavior, ranked results, and returning matched topic phrases to explain relevance. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly written sentences, each serving a distinct purpose: definition, contrast/example, return behavior, and usage guidance. No filler or repetition. The example with 'AI safety' effectively illustrates the semantic capability in one compact sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return fields; it already states results are ranked and include matched topic phrases. It covers the key usage context (semantic vs lexical, conceptual queries, and the alternative tool) and is sufficient for an agent to select and call the tool correctly given six parameters and a rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents each parameter thoroughly. The description reinforces the semantic nature of the `topic` parameter and the distinction from `search_episodes`, but it does not add new meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Semantic topic search across the podcast catalog') and immediately distinguishes itself from the sibling `search_episodes` by contrasting semantic vs lexical matching. This makes the tool's unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('Best for conceptual or thematic queries') and when not to ('use `search_episodes` instead when the user is looking for a specific person, product, or verbatim phrase'), directly naming the alternative. This is exactly what an agent needs to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!