MCP Podcast Scraper

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.4/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-podcast-scraper MCP server](https://glama.ai/mcp/servers/walid-koleilat/mcp-podcast-scraper/badges/card.svg)](https://glama.ai/mcp/servers/walid-koleilat/mcp-podcast-scraper)

Score Badge

Copy to your README.md:

[![mcp-podcast-scraper MCP server](https://glama.ai/mcp/servers/walid-koleilat/mcp-podcast-scraper/badges/score.svg)](https://glama.ai/mcp/servers/walid-koleilat/mcp-podcast-scraper)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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