Loading ToolBench
MCP server for scraping podcast transcripts. Use with Claude for summarization.
The server provides 10 tools with complete input schemas and descriptions visible in src/index.ts. Tool naming follows verb_noun patterns (scrape_podcast, get_transcript, save_summary, etc.), which is good. However, descriptions are inconsistent in quality and detail, some are vague (e.g., check_new_episodes lacks context on what 'new' means or how to use results), and most lack guidance on when to call them relative to similar tools. Parameter descriptions are present but minimal; many lack format constraints, ranges, or recovery hints. Output schemas are not documented, callers must infer what fields are returned. Error handling is acknowledged (errorReporting: true) but not visible in the code snippet provided, so cannot be verified. The server uses STDIO transport, which imposes a hard cap on protocol readiness. Overall, this is a competent tool suite with clear intent but incomplete patterns for production LLM agents.
Add a podcast RSS feed to the tracking list. Use check_new_episodes to find new episodes.
Check all tracked podcasts for new episodes that haven't been scraped yet
Get the custom prompt/instructions for how to summarize podcasts. Read this before summarizing to follow the user's preferences.
Read the transcript of a previously scraped episode. After reading, use get_summary_prompt for summarization instructions.
List all episodes that have transcripts but are missing summaries. Use this to find episodes that need summarization.
List all podcasts currently being tracked
Output schemas are not documented in tool definitions. LLMs cannot determine what fields are returned by scrape_podcast, get_transcript, check_new_episodes, search_podcast, list_tracking, or other tools. This forces agents to guess output structure and plan downstream calls blindly.
check_new_episodes has a vague description ('Check all tracked podcasts for new episodes that haven't been scraped yet'). It does not explain what 'new' means, what structure is returned, how to use the results, or when to call it vs list_tracking. This violates the principle that discovery tools must explain what structure they reveal.
list_tracking and list_incomplete lack clear descriptions of what structure they return and when to call them relative to each other. An LLM cannot distinguish: should I call list_tracking to see what's being monitored, or list_incomplete to find work? Descriptions should clarify the use case and downstream context.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Remove a podcast from the tracking list
Save your generated summary to a markdown file.
Scrape a podcast episode and transcribe it. Returns transcript file path. Use get_transcript to read it, then save_summary after summarizing.
Search for podcasts or episodes on YouTube, or parse an RSS feed URL to see available episodes
Parameter descriptions are minimal and lack format constraints. For example, episodeDate is described only as 'Date of the episode (YYYY-MM-DD format)', good, but query in search_podcast is vague ('Search query for YouTube, or RSS feed URL to parse'). The description should specify: YouTube URL format, example RSS URL pattern, supported search operators, and what happens if both YouTube and RSS queries are provided.
No documented error handling or recovery guidance visible. What happens if scrape_podcast fails mid-transcription? If a feed URL is invalid? If an episode has already been scraped and force=false? Errors should guide the LLM on next steps (retry, use alternative tool, ask user).
Composition issue: scrape_podcast, get_transcript, and save_summary form a workflow (scrape → read → save), but dependencies are not explicit. The description of scrape_podcast says 'Use get_transcript to read it, then save_summary after summarizing', good hint, but get_transcript requires podcastName, episodeTitle, and episodeDate. Does scrape_podcast return these fields? Undocumented output breaks the chain.
check_new_episodes and list_incomplete are discovery tools but lack pagination or result limits in their schemas. If a user tracks 100 podcasts with 10 episodes each, both tools could return 1000+ records. No documented limit, no documented pagination, and no documented output schema means the LLM cannot reason about result size or pagination.
Idempotency unclear. If an LLM retries scrape_podcast with the same query but force=false, will it re-download and re-transcribe, or return the cached transcript? If an LLM retries add_tracking twice with the same podcast and feedUrl, will it create a duplicate entry? Descriptions should state idempotency guarantees.