An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Scored across 5 tools
Each tool has a clear, non-overlapping role: listing latest episodes, fetching transcripts, searching by keyword, searching by semantic topic, and providing feedback. The two search tools are explicitly differentiated by lexical versus semantic matching, eliminating ambiguity.
All tool names follow a consistent verb_noun snake_case pattern: get_latest_episodes, get_transcript, give_feedback, search_episodes, search_episodes_by_topic. The naming is predictable and immediately conveys each tool's action and target.
Five tools is well-scoped for a podcast transcript server: discovery, retrieval, and feedback are all represented without unnecessary bloat. Every tool has a clear purpose and the set feels intentionally minimal.
The server covers the core podcast transcript workflow: finding episodes, retrieving transcripts, browsing recent content, and reporting issues. There are no obvious dead ends since search tools return the GUIDs needed for transcript retrieval and feedback handles missing data.
Return 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.
Fetch 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.
Send 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 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.
Semantic 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_latest_episodes6 fields changedInput schema / properties / cursorAdded value: +{
+ "default": 0,
+ "description": "Zero-based episode offset for pagination. Use the `next_cursor` returned by a prior search/listing call to fetch the next page of results.",
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / count / descriptionPrevious value: -"Number of episodes returned."New value: +"Number of episodes returned on this page."Output schema / properties / next_cursorAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Cursor to pass to the next search call to retrieve the next page of results, or null if there are no more pages."
+}Output schema / properties / total_countAdded value: +{
+ "description": "Total number of matching transcript-ready episodes across all pages.",
+ "type": "integer"
+}Output schema / properties / total_count_is_approximateAdded value: +{
+ "default": false,
+ "description": "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).",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "episodes",
- "count"
-]New value: +[
+ "episodes",
+ "count",
+ "total_count"
+]search_episodes6 fields changedInput schema / properties / cursorAdded value: +{
+ "default": 0,
+ "description": "Zero-based episode offset for pagination. Use the `next_cursor` returned by a prior search/listing call to fetch the next page of results.",
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / count / descriptionPrevious value: -"Number of episodes returned."New value: +"Number of episodes returned on this page."Output schema / properties / next_cursorAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Cursor to pass to the next search call to retrieve the next page of results, or null if there are no more pages."
+}Output schema / properties / total_countAdded value: +{
+ "description": "Total number of matching transcript-ready episodes across all pages.",
+ "type": "integer"
+}Output schema / properties / total_count_is_approximateAdded value: +{
+ "default": false,
+ "description": "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).",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "episodes",
- "count"
-]New value: +[
+ "episodes",
+ "count",
+ "total_count"
+]search_episodes_by_topic6 fields changedInput schema / properties / cursorAdded value: +{
+ "default": 0,
+ "description": "Zero-based episode offset for pagination. Use the `next_cursor` returned by a prior search/listing call to fetch the next page of results.",
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / count / descriptionPrevious value: -"Number of episodes returned."New value: +"Number of episodes returned on this page."Output schema / properties / next_cursorAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Cursor to pass to the next search call to retrieve the next page of results, or null if there are no more pages."
+}Output schema / properties / total_countAdded value: +{
+ "description": "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.",
+ "type": "integer"
+}Output schema / properties / total_count_is_approximateAdded value: +{
+ "default": false,
+ "description": "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.",
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "episodes",
- "count",
- "query"
-]New value: +[
+ "episodes",
+ "count",
+ "query",
+ "total_count"
+]search_episodes_by_topicget_transcript6 fields changedOutput schema / properties / duration_secondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Episode duration in seconds when available from the source feed."
+}Output schema / properties / episode_titleAdded value: +{
+ "description": "Podcast episode title.",
+ "type": "string"
+}Output schema / properties / published_dateAdded value: +{
+ "description": "Episode publication timestamp in ISO 8601 format.",
+ "type": "string"
+}Output schema / properties / rss_feed_urlAdded value: +{
+ "description": "RSS feed URL for the podcast show.",
+ "type": "string"
+}Output schema / properties / show_titleAdded value: +{
+ "description": "Podcast show title.",
+ "type": "string"
+}Output schema / requiredPrevious 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"
+]get_latest_episodes6 fields changedInput schema / properties / published_afterAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Inclusive lower publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime."
+}Input schema / properties / published_beforeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Inclusive upper publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime."
+}Input schema / properties / sortAdded value: +{
+ "default": "published_desc",
+ "description": "Sort order for results. `relevance` ranks full-text searches first and falls back to newest-first when no query is provided.",
+ "enum": [
+ "relevance",
+ "published_desc",
+ "published_asc"
+ ],
+ "type": "string"
+}Output schema / properties / episodes / items / properties / duration_secondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Episode duration in seconds when available from the source feed."
+}Output schema / properties / episodes / items / properties / rss_feed_urlAdded value: +{
+ "description": "RSS feed URL for the podcast show.",
+ "type": "string"
+}Output schema / properties / episodes / items / requiredPrevious value: -[
- "show_guid",
- "show_title",
- "episode_guid",
- "episode_title",
- "published_date",
- "description"
-]New value: +[
+ "show_guid",
+ "show_title",
+ "episode_guid",
+ "episode_title",
+ "published_date",
+ "rss_feed_url",
+ "description"
+]search_episodes6 fields changedInput schema / properties / published_afterAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Inclusive lower publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime."
+}Input schema / properties / published_beforeAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Inclusive upper publication-date bound. Accepts YYYY-MM-DD or ISO 8601 datetime."
+}Input schema / properties / sortAdded value: +{
+ "default": "relevance",
+ "description": "Sort order for results. `relevance` ranks full-text searches first and falls back to newest-first when no query is provided.",
+ "enum": [
+ "relevance",
+ "published_desc",
+ "published_asc"
+ ],
+ "type": "string"
+}Output schema / properties / episodes / items / properties / duration_secondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Episode duration in seconds when available from the source feed."
+}Output schema / properties / episodes / items / properties / rss_feed_urlAdded value: +{
+ "description": "RSS feed URL for the podcast show.",
+ "type": "string"
+}Output schema / properties / episodes / items / requiredPrevious value: -[
- "show_guid",
- "show_title",
- "episode_guid",
- "episode_title",
- "published_date",
- "description"
-]New value: +[
+ "show_guid",
+ "show_title",
+ "episode_guid",
+ "episode_title",
+ "published_date",
+ "rss_feed_url",
+ "description"
+]give_feedback1 field changedInput schema / properties / contactRemoved value: -{
- "default": "",
- "description": "Optional follow-up contact details (e.g. email address, handle, or preferred channel) the server team can use if they address the feedback or have clarifying questions. Only provide with user consent; leave empty to remain anonymous.",
- "maxLength": 500,
- "type": "string"
-}get_latest_episodesget_transcriptgive_feedbacksearch_episodesMCP server for structured access to Lenny Rachitsky podcast transcripts. For content creators.
An MCP server that provides congressional transcripts
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
An MCP server that gives any LLM or agent clean YouTube transcripts on demand: a single video, a whole channel, or a playlist, plus AI cleanup of auto-generated captions. API-key auth, credit-based, same backend as the public v1 API. Get a free API key with 25 free credits at youtubetranscriptdownload.com/account.
Add one secure layer between your agents and this server.
