Un servidor MCP (Model Context Protocol) que extrae y transcribe episodios de podcasts. Diseñado para funcionar con Claude Code o Claude Desktop: tú proporcionas el podcast, el MCP lo transcribe y Claude lo resume.
Creado por Walid Koleilat para aprender MCP de principio a fin y resolver un flujo de trabajo real: convertir horas de audio de podcasts en resúmenes útiles enfocados en PM sin salir de Claude.
🎙️ Extrae podcasts de vídeos de YouTube o feeds RSS
🎯 Transcribe audio usando el rápido modelo Nova-2 de Deepgram
📁 Organiza archivos por nombre de podcast y fecha del episodio
🔄 Realiza seguimiento de podcasts para nuevos episodios
⏭️ Omite duplicados - no volverá a extraer episodios ya procesados
📋 Encuentra trabajo incompleto - lista episodios que necesitan resumen
✏️ Prompts de resumen personalizados - personaliza cómo Claude resume según tus necesidades
Related MCP server: ytt-mcp
You: "Check for new episodes and summarize them"
↓
Claude: Calls check_new_episodes() → Finds new episodes
↓
Claude: Calls scrape_podcast() → Downloads & transcribes
↓
Claude: Calls get_summary_prompt() → Reads your custom instructions
↓
Claude: Calls get_transcript() → Reads the transcript
↓
Claude: Summarizes following your prompt
↓
Claude: Calls save_summary() → Saves the .md file
↓
Done! transcript.md + summary.md savedInstala las herramientas de sistema necesarias (macOS):
# Install Homebrew if you don't have it
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
# Install yt-dlp (for YouTube) and ffmpeg (for audio)
brew install yt-dlp ffmpeg# Clone the repository
git clone https://github.com/walid-koleilat/mcp-podcast-scraper.git
cd mcp-podcast-scraper
# Install dependencies
npm install
# Build
npm run buildRegístrate (el nivel gratuito incluye $200 de crédito, suficiente para unas 300 horas de audio)
Crea una clave API
Copia la clave
Copia el archivo de configuración de ejemplo y añade tu clave API:
# Copy the example config
cp config.example.json config.json
# Edit config.json and add your Deepgram API keyTu config.json debería verse así:
{
"outputDirectory": "./podcasts",
"deepgramApiKey": "YOUR_ACTUAL_DEEPGRAM_API_KEY",
"tempDirectory": "./temp"
}⚠️ Importante: Nunca subas
config.jsona git: ¡contiene tu clave API! El archivo.gitignoreya lo excluye.
Añade esto a tu configuración de MCP de Claude Code (~/.cursor/mcp.json o vía Settings → MCP):
{
"mcpServers": {
"podcast-scraper": {
"command": "node",
"args": ["/FULL/PATH/TO/mcp-podcast-scraper/dist/index.js"]
}
}
}Importante: Reemplaza /FULL/PATH/TO/ con la ruta real a tu instalación.
Edita ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"podcast-scraper": {
"command": "node",
"args": ["/FULL/PATH/TO/mcp-podcast-scraper/dist/index.js"]
}
}
}Luego reinicia Claude Desktop.
mcp-podcast-scraper/
├── config.example.json # Template - copy to config.json
├── config.json # Your config (git-ignored, contains API key)
├── tracking.example.json # Example tracking file
├── tracking.json # Your tracked podcasts (git-ignored)
├── prompts/
│ └── summary-prompt.md # Customize how Claude summarizes (editable)
├── podcasts/ # Your transcripts & summaries (git-ignored)
├── src/ # Source code
├── dist/ # Compiled code (git-ignored)
└── node_modules/ # Dependencies (git-ignored)"Scrape this YouTube podcast: https://youtube.com/watch?v=..."
"Find and scrape the latest Lex Fridman episode""Track the Huberman Lab podcast: https://feeds.megaphone.fm/hubermanlab"
"Check my tracked podcasts for new episodes"
"List all podcasts I'm tracking""Show me episodes that need summaries"
"List incomplete episodes"Herramienta | Descripción |
| Extrae y transcribe un episodio. Devuelve la ruta del archivo y una vista previa. |
| Lee la transcripción completa de un episodio extraído. |
| Obtiene tus instrucciones de resumen personalizadas. |
| Guarda tu resumen generado en un archivo markdown. |
| Comprueba los podcasts seguidos en busca de episodios nuevos (no extraídos). |
| Encuentra episodios con transcripciones pero sin resúmenes. |
| Busca en YouTube o analiza feeds RSS para encontrar episodios. |
| Añade un feed RSS de podcast a tu lista de seguimiento. |
| Lista todos los podcasts que estás siguiendo. |
| Elimina un podcast de tu lista de seguimiento. |
Comprobar nuevos episodios:
"Check my tracked podcasts for new episodes"Extraer cada nuevo episodio:
"Scrape the first one"Obtener transcripción y resumir:
"Get the transcript and summarize it"Repetir para los episodios restantes
Si te detuviste a mitad de la sesión:
"Show me episodes that need summaries"Luego, para cada episodio incompleto:
"Get the transcript for [episode] and summarize it"Los archivos están organizados por podcast y episodio:
podcasts/
├── Huberman Lab/
│ ├── 2024-12-10 - Episode Title/
│ │ ├── transcript.md
│ │ └── summary.md
│ └── 2024-12-05 - Another Episode/
│ ├── transcript.md
│ └── summary.md
└── Lex Fridman Podcast/
└── 2024-12-08 - Guest Name/
├── transcript.md
└── summary.mdOpción | Descripción | Predeterminado |
| Dónde guardar transcripciones y resúmenes. Puede ser ruta relativa o absoluta. |
|
| Tu clave API de Deepgram para la transcripción | Requerido |
| Directorio temporal para archivos de audio (limpiado automáticamente al iniciar) |
|
Variables de entorno (alternativa opcional a config.json):
DEEPGRAM_API_KEY
OUTPUT_DIRECTORY
TEMP_DIRECTORY
Controla cómo Claude resume tus podcasts editando prompts/summary-prompt.md.
El prompt predeterminado está adaptado para Product Managers e incluye:
🎯 Resumen del episodio
💡 Perspectivas clave para Product Managers
🧠 Modelos mentales y marcos de trabajo
📈 Conclusiones de desarrollo personal
✅ Elementos de acción
💬 Citas notables
🔗 Temas relacionados
Edita prompts/summary-prompt.md para:
Cambiar el público objetivo (ingeniero, diseñador, fundador, etc.)
Añadir/eliminar secciones
Ajustar la longitud del resumen
Enfocarse en temas específicos
Cambiar el estilo de formato
Ejemplos de personalización:
Para ingenieros:
Focus on:
- Technical concepts and architecture decisions
- Implementation details worth noting
- Tools and technologies mentioned
- Code patterns and best practicesPara fundadores:
Focus on:
- Business strategy insights
- Fundraising advice
- Growth tactics
- Leadership lessons
- Mistakes to avoidClaude leerá este prompt antes de generar cada resumen, asegurando una salida consistente y personalizada.
# Watch mode (auto-rebuild on changes)
npm run dev
# Build once
npm run build
# Run MCP server directly
npm start
# Clean build artifacts and temp files
npm run clean
# Test with MCP Inspector (interactive UI)
npx @modelcontextprotocol/inspector node dist/index.jsbrew install ffmpegAsegúrate de haber copiado config.example.json a config.json y añadido tu clave API.
Ejecuta npm run build
Verifica que la ruta en la configuración de MCP sea correcta
Reinicia Claude Code/Desktop
Usa feeds RSS en su lugar. Encuentra feeds RSS de podcasts en https://getrssfeed.com/
MIT
Add a podcast RSS feed to the tracking list. Use check_new_episodes to find new episodes.
| Name | Required | Description | Default |
|---|---|---|---|
| podcastName | Yes | Name of the podcast | |
| feedUrl | Yes | RSS feed URL of the podcast |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Add') but doesn't disclose whether this requires authentication, what happens on success/failure, if there are rate limits, or how the tracking list is managed. The mention of 'check_new_episodes' adds some context but doesn't cover key behavioral traits.
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 extremely concise with two sentences that are front-loaded and waste no words. Every sentence adds value: the first states the purpose, and the second provides usage guidance, making it efficient and well-structured.
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 tool's moderate complexity (a write operation with 2 parameters) and no annotations or output schema, the description is minimally adequate. It covers the basic purpose and a related tool but lacks details on behavior, error handling, or output expectations, leaving gaps for an agent to operate effectively.
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 description coverage is 100%, with clear descriptions for both parameters ('podcastName' and 'feedUrl'). The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating further.
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 action ('Add a podcast RSS feed') and resource ('to the tracking list'), making the purpose immediately understandable. It distinguishes from some siblings like 'remove_tracking' but doesn't explicitly differentiate from 'list_tracking' or 'search_podcast' in terms of when to add versus list/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 provides clear context by mentioning 'Use check_new_episodes to find new episodes,' which guides the agent on a related workflow. However, it doesn't specify when to use this tool versus alternatives like 'scrape_podcast' or 'search_podcast,' or any prerequisites for adding a feed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check all tracked podcasts for new episodes that haven't been scraped yet
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing behavioral traits such as whether it's read-only or mutative, rate limits, authentication needs, or what 'check' entails (e.g., polling, notifications). It leaves key operational details unspecified.
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, efficient sentence that front-loads the core purpose without wasted words. It directly conveys the tool's function in a compact form, making it easy to parse.
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 no annotations, no output schema, and a tool that likely involves data retrieval or updates, the description is incomplete. It lacks details on return values, error handling, or side effects, leaving gaps in understanding how the tool behaves in practice.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds no parameter info, which is appropriate, earning a baseline score of 4 for not introducing confusion or redundancy.
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 action ('check') and target resource ('tracked podcasts for new episodes'), specifying the scope ('that haven't been scraped yet'). It distinguishes from siblings like 'scrape_podcast' (which scrapes) and 'list_tracking' (which lists tracking), though it doesn't explicitly differentiate them.
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 when checking for unscraped episodes, but provides no explicit guidance on when to use this tool versus alternatives like 'list_incomplete' or 'scrape_podcast', nor any prerequisites or exclusions. It lacks context on timing or frequency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the custom prompt/instructions for how to summarize podcasts. Read this before summarizing to follow the user's preferences.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('Get'), which is useful, but doesn't disclose behavioral traits like authentication needs, rate limits, or error handling. The description adds some context about its role in summarization workflows, but lacks details on how it behaves beyond its basic function.
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 front-loaded and concise, consisting of two sentences that directly state the tool's purpose and usage. Every sentence earns its place by providing essential information without waste, making it efficient and easy to parse.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and when to use it, but lacks details on return values or behavioral aspects. For a read-only tool with no structured output, it meets minimum viability but could be more complete.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters. A baseline score of 4 is appropriate as it doesn't need to compensate for any gaps.
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 purpose: 'Get the custom prompt/instructions for how to summarize podcasts.' It specifies the verb 'Get' and the resource 'custom prompt/instructions,' making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'save_summary' or 'get_transcript,' which slightly limits its clarity.
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 provides clear context for when to use this tool: 'Read this before summarizing to follow the user's preferences.' This implies it should be used as a prerequisite for summarization tasks. It doesn't explicitly state when not to use it or name alternatives, but the guidance is sufficient for effective usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the transcript of a previously scraped episode. After reading, use get_summary_prompt for summarization instructions.
| Name | Required | Description | Default |
|---|---|---|---|
| podcastName | Yes | Name of the podcast | |
| episodeTitle | Yes | Title of the episode | |
| episodeDate | Yes | Date of the episode (YYYY-MM-DD format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Read the transcript'), which is clear, but lacks details on permissions, rate limits, error handling, or what 'previously scraped' entails (e.g., storage location, availability). The mention of 'get_summary_prompt' adds some context for workflow, but overall behavioral traits are under-specified for a tool with no annotation coverage.
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 concise with two sentences that are front-loaded: the first states the core purpose, and the second provides a usage tip. There's no wasted text, and it efficiently communicates key information. However, it could be slightly more structured by separating prerequisites from actions more clearly.
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 tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and hints at prerequisites and next steps, but lacks details on behavioral aspects like error cases, output format, or integration with sibling tools beyond 'get_summary_prompt'. Without annotations or output schema, more context on what the tool returns or how it behaves would improve completeness.
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 three parameters (podcastName, episodeTitle, episodeDate) documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 purpose: 'Read the transcript of a previously scraped episode.' This specifies the verb ('Read') and resource ('transcript'), and distinguishes it from scraping or summarization tools. However, it doesn't explicitly differentiate from other read operations like 'search_podcast' or 'list_incomplete', which could also involve reading data.
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 context by stating 'previously scraped episode' and suggesting 'use get_summary_prompt for summarization instructions.' This provides some guidance on prerequisites (episode must be scraped first) and a related tool for next steps. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_podcast' or 'list_incomplete', nor does it provide exclusions or detailed scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all episodes that have transcripts but are missing summaries. Use this to find episodes that need summarization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool's behavior as listing episodes based on transcript and summary status, but it lacks details on permissions, rate limits, or response format. The description adds some value by specifying the filtering criteria but does not fully cover behavioral traits.
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 front-loaded and concise with two sentences that directly state the tool's purpose and usage without any wasted words. Every sentence earns its place by providing essential information.
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 tool's simplicity (0 parameters, no annotations, no output schema), the description is complete enough for a read-only listing operation. It explains what the tool does and when to use it, though it could benefit from mentioning response format or limitations to be fully comprehensive.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter semantics, but this is acceptable as there are no parameters to describe, aligning with the baseline for zero parameters.
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 purpose with specific verbs ('List all episodes') and resources ('episodes that have transcripts but are missing summaries'), and it distinguishes from siblings by focusing on incomplete summarization status rather than tracking, scraping, or other podcast-related 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?
It explicitly states when to use this tool: 'to find episodes that need summarization.' This provides clear context for usage versus alternatives like 'check_new_episodes' or 'search_podcast,' which might handle different aspects of episode management.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all podcasts currently being tracked
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('List all') but doesn't mention any behavioral traits such as permissions needed, rate limits, pagination, or what 'currently being tracked' entails. This leaves significant gaps for an agent to understand how to use it effectively.
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, clear sentence that directly states the tool's function without any unnecessary words. It is front-loaded and efficiently communicates the core purpose, making it highly concise and well-structured.
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 tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a minimum viable explanation. However, it lacks details on behavioral aspects like how 'tracked' is defined or what the output format might be, which could be helpful for an agent. It meets basic needs but has clear gaps in context.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied as per the rules for tools with 0 parameters.
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 action ('List all') and resource ('podcasts currently being tracked'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'search_podcast' or 'list_incomplete', which might also involve listing operations, so it doesn't reach the highest score.
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 provides no guidance on when to use this tool versus alternatives like 'search_podcast' or 'list_incomplete'. It states what it does but offers no context about prerequisites, timing, or comparative use cases with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a podcast from the tracking list
| Name | Required | Description | Default |
|---|---|---|---|
| podcastName | Yes | Name of the podcast to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Remove') which implies a destructive mutation, but it doesn't disclose critical traits such as whether removal is permanent, requires specific permissions, has side effects (e.g., deleting associated data), or provides confirmation feedback. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, clear sentence that directly states the tool's purpose without any fluff or redundancy. It's front-loaded with the key action and resource, making it efficient and easy to parse. Every word earns its place, achieving optimal conciseness.
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 tool's complexity as a destructive mutation with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., reversibility, error handling), usage context, and what happens post-removal. For a tool that modifies state, this leaves too many unknowns for the agent to operate confidently.
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 the single parameter 'podcastName' fully documented in the schema as 'Name of the podcast to remove'. The description doesn't add any additional meaning beyond this, such as format examples or constraints. Since the schema does the heavy lifting, the baseline score of 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 clearly states the action ('Remove') and resource ('a podcast from the tracking list'), making the purpose immediately understandable. It distinguishes from siblings like 'add_tracking' and 'list_tracking' by specifying removal rather than addition or listing. However, it doesn't specify what 'tracking list' refers to in context, which keeps it from a perfect score.
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?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for removing tracked podcasts, but it doesn't mention prerequisites (e.g., the podcast must already be tracked), exclusions, or comparisons to siblings like 'list_tracking' for checking current tracking. This leaves the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save your generated summary to a markdown file.
| Name | Required | Description | Default |
|---|---|---|---|
| podcastName | Yes | Name of the podcast | |
| episodeTitle | Yes | Title of the episode | |
| episodeDate | Yes | Date of the episode (YYYY-MM-DD format) | |
| summaryText | Yes | The summary content in markdown format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool saves to a file, implying a write operation, but doesn't specify file location, naming conventions, overwrite behavior, or error handling. This is inadequate for a tool that performs file I/O without annotation support.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it efficient and easy to parse for an AI agent.
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 tool's complexity (file-saving operation with 4 required parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., file system interactions), error cases, or what happens on success, leaving significant gaps for the agent to operate safely.
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 fully documents all 4 parameters. The description adds no additional parameter information beyond implying 'summaryText' should be in markdown format, which is already covered in the schema. Baseline 3 is appropriate as the 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 clearly states the action ('save') and the resource ('generated summary to a markdown file'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_incomplete' or 'scrape_podcast', which have different functions, so it doesn't fully address potential confusion with similar-sounding tools.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a summary generated first), exclusions, or how it relates to siblings like 'get_summary_prompt' or 'list_incomplete', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape a podcast episode and transcribe it. Returns transcript file path. Use get_transcript to read it, then save_summary after summarizing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | YouTube URL, RSS feed URL, or search query for the podcast episode | |
| podcastName | No | Name of the podcast (for organization) | |
| episodeTitle | No | Title of the episode (optional, will be auto-detected) | |
| force | No | Force re-scraping even if episode was already scraped (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool returns a transcript file path and implies a multi-step process (scraping, transcribing, then using other tools). However, it lacks details on error handling, rate limits, authentication needs, or whether scraping is destructive to existing data. The description doesn't contradict annotations (none provided), but it's incomplete for a tool with potential behavioral complexities.
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 concise and front-loaded, with two sentences: the first states the core purpose and output, and the second provides usage guidance. There's no wasted text, and it efficiently communicates key information. However, it could be slightly more structured by separating purpose and guidelines more clearly.
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 tool's complexity (scraping and transcribing with 4 parameters) and lack of annotations and output schema, the description is moderately complete. It covers the purpose and basic workflow but misses details like error cases, performance expectations, or output format beyond 'transcript file path'. Without annotations or output schema, more behavioral context would be beneficial.
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 description coverage is 100%, so all parameters are documented in the input schema. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't clarify the format of 'query' or the implications of 'force'). With high schema coverage, the baseline is 3, and the description doesn't compensate with extra insights.
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 purpose: 'Scrape a podcast episode and transcribe it. Returns transcript file path.' This specifies the verb (scrape and transcribe) and resource (podcast episode), and mentions the output (transcript file path). However, it doesn't explicitly differentiate from sibling tools like 'search_podcast' or 'check_new_episodes', which might have overlapping scopes.
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 provides clear context for usage by mentioning related tools: 'Use get_transcript to read it, then save_summary after summarizing.' This guides the agent on workflow steps. However, it doesn't explicitly state when to use this tool versus alternatives like 'search_podcast' or 'check_new_episodes', nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for podcasts or episodes on YouTube, or parse an RSS feed URL to see available episodes
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for YouTube, or RSS feed URL to parse | |
| source | No | Source to search (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what the tool does but lacks critical behavioral details: it doesn't specify whether this is a read-only operation, what the output format looks like (e.g., list of results with metadata), potential rate limits, authentication needs, or error conditions. The description is functional but insufficient for safe agent invocation.
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, efficient sentence that packs two distinct use cases without redundancy. It's appropriately sized for the tool's complexity and front-loads the core functionality. However, it could be slightly improved with structural separation (e.g., bullet points) for the two operations, but this is minor.
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 tool's dual-purpose nature (search and parse), no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., search results list, parsed episode details), how results are structured, or any behavioral constraints. For a tool with two distinct operations and zero structured metadata, more descriptive context is needed for reliable agent use.
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 schema already fully documents both parameters (query and source). The description adds marginal value by clarifying that the query parameter serves dual purposes (search term vs RSS URL) and implying the source parameter's role, but doesn't provide additional syntax, format details, or examples beyond what the schema states. This meets the baseline for high schema coverage.
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 purpose with specific verbs ('search for podcasts or episodes on YouTube' and 'parse an RSS feed URL') and identifies the resources involved (podcasts/episodes, RSS feeds). It distinguishes between two distinct operations but doesn't explicitly differentiate from sibling tools like 'scrape_podcast' or 'check_new_episodes', which prevents a perfect score.
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 contexts through the dual-purpose nature (YouTube search vs RSS parsing) but doesn't provide explicit guidance on when to choose this tool over alternatives like 'scrape_podcast' or 'check_new_episodes'. No when-not-to-use scenarios or prerequisites are mentioned, leaving usage decisions to inference.
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. Dates show when Glama detected each change.
v1.0.0add_trackingcheck_new_episodesget_summary_promptget_transcriptlist_incompletelist_trackingremove_trackingsave_summaryscrape_podcastsearch_podcastMost tools have distinct purposes, but there is some overlap between 'scrape_podcast' and 'check_new_episodes' as both involve scraping episodes, which could cause confusion. However, descriptions clarify that 'scrape_podcast' is for manual scraping of specific episodes, while 'check_new_episodes' automatically checks tracked feeds, so the ambiguity is limited.
Tool names follow a consistent verb_noun pattern throughout, such as 'add_tracking', 'check_new_episodes', and 'save_summary'. The only minor deviation is 'list_incomplete', which uses an adjective instead of a noun, but this does not significantly impact readability or consistency.
With 10 tools, the server is well-scoped for podcast scraping and summarization. Each tool serves a clear purpose in the workflow, from tracking and scraping to transcription and summarization, without being overly sparse or bloated.
The tool set provides complete coverage for the podcast domain, including tracking management (add, list, remove), scraping and transcription, transcript retrieval, summarization with custom prompts, and saving summaries. There are no obvious gaps; it supports a full lifecycle from discovery to final output.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides tools to discover and retrieve podcast episodes 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.
MCP server for structured access to Lenny Rachitsky podcast transcripts. For content creators.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/walid-koleilat/mcp-podcast-scraper'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
