Parses Podcast 2.0 RSS feeds from Jupiter Broadcasting shows, providing tools to list shows, search episodes by various criteria, retrieve detailed episode information, and fetch episode transcripts
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jupiter Broadcasting Podcast Data MCP Server search for recent Linux Unplugged episodes about Docker"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A FastMCP server that parses Podcasting 2.0 RSS feeds and provides access to episode data through MCP tools.
This MCP server provides four main tools:
List Shows - Returns a list of available podcast shows
Search Episodes - Search episodes by show, date range, hosts, or text content
Get Episode - Retrieve detailed information about a specific episode
Get Transcript - Fetch episode transcripts when available
Related MCP server: Lenny's Podcast MCP
This project uses the uv package manager for Python dependency management.
Python 3.10 or higher
uv package manager
curl -LsSf https://astral.sh/uv/install.sh | shgit clone <repository-url>
cd podcast_mcp
uv syncTo start the MCP server:
uv run podcast_mcpOr alternatively:
uv run python -m podcast_mcp.serverReturns an array of available podcast show names.
{
"tool": "list_shows",
"arguments": {}
}Returns: Array of show names (e.g., ["Linux Unplugged", "This Week in Bitcoin", ...])
Search for episodes using various criteria. At least one parameter must be provided.
{
"tool": "search_episodes",
"arguments": {
"show_name": "Linux Unplugged",
"since_date": "2024-01-01",
"before_date": "2024-12-31",
"hosts": ["Chris Fisher", "Wes Payne"],
"text_search": "kubernetes"
}
}Parameters:
show_name (optional): Filter by specific show
since_date (optional): Episodes published on or after this date (YYYY-MM-DD or ISO format)
before_date (optional): Episodes published before this date (YYYY-MM-DD or ISO format)
hosts (optional): Array of host names to filter by
text_search (optional): Search text in episode titles and descriptions
Returns: Array of episode objects with metadata
Retrieve detailed information about a specific episode.
{
"tool": "get_episode",
"arguments": {
"show_name": "Linux Unplugged",
"episode_number": "635"
}
}Parameters:
show_name (required): Name of the show
episode_number (required): Episode number
Returns: Episode object with full metadata including:
Title and description
Publication date
Host information
Audio file URLs
Transcript URL (if available)
Duration
Hosts
Fetch the transcript content for an episode.
{
"tool": "get_transcript",
"arguments": {
"show_name": "Linux Unplugged",
"episode_number": "635"
}
}Parameters:
show_name (required): Name of the show
episode_number (required): Episode number
Returns: Object containing transcript text or error message
To add or modify RSS feeds, edit the FEEDS dictionary in podcast_mcp/server.py:
FEEDS = {
"Show Name": "https://example.com/feed.rss",
"Another Show": "https://example.com/another-feed.rss",
}This server supports Podcast 2.0 namespace elements including:
<podcast:person> for host information
<podcast:transcript> for transcript URLs
Standard RSS elements for titles, descriptions, and enclosures
# Install with development dependencies
uv sync --group dev
# Run tests
uv run pytest
# Format code
uv run black .
uv run isort .
# Type checking
uv run mypy .podcast_mcp/
├── podcast_mcp/
│ ├── __init__.py
│ ├── server.py # Main MCP server
│ └── rss_parser.py # RSS feed parsing logic
├── tests/ # Test files
├── pyproject.toml # Project configuration
└── README.mdThe server includes comprehensive error handling:
Invalid search parameters return error messages
Network failures when fetching feeds are logged
Missing episodes or transcripts return appropriate error responses
Malformed RSS feeds are handled gracefully
fastmcp: FastMCP framework for building MCP servers
lxml: High-performance XML parsing with full Podcast 2.0 namespace support
requests: HTTP client for fetching feeds and transcripts
MIT License - see LICENSE file for details.
Fork the repository
Create a feature branch
Make your changes
Add tests for new functionality
Run the test suite and linting
Submit a pull request
For issues and questions, please open an issue on the GitHub repository.
Get detailed information about a specific episode.
Args: show_name: Name of the show episode_number: Episode number
Returns: Episode data including title, description, hosts, enclosures, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| show_name | Yes | ||
| episode_number | Yes |
| Name | Required | Description |
|---|---|---|
No output 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 states the tool retrieves information (implying read-only behavior) but lacks details on permissions, rate limits, error handling, or data freshness. The mention of returns like 'title, description, hosts, enclosures, etc.' hints at output structure but is vague, failing to fully compensate for the absence of 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?
The description is well-structured and appropriately sized, with a clear purpose statement followed by sections for Args and Returns. Each sentence adds value, though the 'Returns' section could be more specific (e.g., listing exact fields instead of 'etc.'). It avoids redundancy and is front-loaded with the core functionality.
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 low complexity (2 required parameters, no nested objects) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers purpose, parameters, and return types, though it lacks behavioral details like error cases or usage guidelines, which are minor gaps in this 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?
Schema description coverage is 0%, so the description must add meaning beyond the schema. It lists parameters ('show_name', 'episode_number') and briefly explains their roles, but doesn't provide format details (e.g., episode number as string vs. integer) or examples. This partially compensates for the schema gap but leaves ambiguity, aligning with the baseline for moderate compensation.
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 a specific verb ('Get detailed information') and resource ('about a specific episode'). It distinguishes this from siblings like 'list_shows' (which lists shows) and 'search_episodes' (which searches across episodes), though it doesn't explicitly contrast with 'get_transcript' (which might retrieve transcript data for an episode).
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_episodes' or 'get_transcript'. It mentions retrieving 'detailed information' but doesn't specify scenarios where this is preferred over other tools, leaving 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.
Get the transcript for a specific episode.
Args: show_name: Name of the show episode_number: Episode number
Returns: Dictionary containing the transcript text or error message.
| Name | Required | Description | Default |
|---|---|---|---|
| show_name | Yes | ||
| episode_number | Yes |
| Name | Required | Description |
|---|---|---|
No output 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 of behavioral disclosure. It mentions that the tool returns a 'Dictionary containing the transcript text or error message,' which gives some insight into output behavior, but it does not cover critical aspects like authentication needs, rate limits, error conditions beyond generic messages, or whether it's a read-only operation. For a tool with zero annotation coverage, this is insufficient.
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 appropriately sized and front-loaded, with the purpose stated first, followed by structured sections for Args and Returns. Each sentence earns its place, but the Args section could be more integrated into the flow. Overall, it is efficient with minimal waste.
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 (2 required parameters) and the presence of an output schema (which handles return values), the description is somewhat complete. It covers the basic purpose and parameters, but gaps remain in usage guidelines and behavioral transparency. With no annotations and incomplete parameter details, it is adequate but has clear room for improvement.
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 0%, so the description must compensate. It lists the parameters (show_name, episode_number) and their roles, adding meaning beyond the bare schema. However, it does not provide details on format (e.g., episode_number as string vs. integer), constraints, or examples. With 2 parameters and some semantic clarification, it meets the baseline but lacks depth.
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 transcript for a specific episode.' It specifies the verb ('Get') and resource ('transcript'), but does not explicitly differentiate from sibling tools like get_episode or search_episodes, which might also retrieve episode-related data. This makes it clear but not fully sibling-distinctive.
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 does not mention sibling tools like get_episode or list_shows, nor does it specify contexts or exclusions for usage. This lack of comparative guidance leaves the agent without clear direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available podcast shows.
Returns: List of show names available for searching and episode retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the return is a 'List of show names' and hints at usage for 'searching and episode retrieval,' but doesn't disclose behavioral traits like whether it's paginated, rate-limited, or requires authentication. For a 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 appropriately sized with two sentences: one states the purpose, and the other explains the return value and usage. It's front-loaded with the main action, and every sentence adds value without waste. However, it could be slightly more structured by separating usage guidance 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 has 0 parameters, 100% schema coverage, and an output schema exists, the description is adequate but incomplete. It explains the purpose and return usage, but with no annotations, it should do more to cover behavioral aspects like performance or constraints. The output schema reduces the need to explain return values, but overall completeness is minimal viable.
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 the baseline is high. The description adds value by clarifying the output's purpose ('available for searching and episode retrieval'), which goes beyond the empty schema. This compensates well for the lack of parameters, but doesn't reach a 5 as it could detail output format more.
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: 'List all available podcast shows' specifies the verb (list) and resource (podcast shows). It distinguishes from siblings like get_episode or get_transcript by focusing on shows rather than episodes or transcripts. However, it doesn't explicitly differentiate from search_episodes, which might also involve shows, keeping 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?
The description implies usage by stating 'available for searching and episode retrieval,' suggesting this tool is for initial discovery before using other tools. However, it lacks explicit guidance on when to use this vs. alternatives like search_episodes, and no exclusions or prerequisites are mentioned, making it only adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for episodes based on various criteria. At least one search parameter must be provided.
Args: show_name: Name of the specific show to search in (required) since_date: Only return episodes published on or after this date (YYYY-MM-DD or ISO format) before_date: Only return episodes published before this date (YYYY-MM-DD or ISO format) hosts: List of host names to filter by text_search: Search text to match against episode titles and descriptions page: Page number (1-indexed, default: 1) per_page: Number of results per page (default: 5)
Returns: Dictionary containing episodes, pagination info (total, page, per_page, total_pages).
| Name | Required | Description | Default |
|---|---|---|---|
| show_name | Yes | ||
| since_date | No | ||
| before_date | No | ||
| hosts | No | ||
| text_search | No | ||
| page | No | ||
| per_page | No |
| Name | Required | Description |
|---|---|---|
No output 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 mentions that at least one search parameter is required and describes the return format, but lacks details on permissions, rate limits, error handling, or whether this is a read-only operation. For a search tool with 7 parameters, this leaves significant behavioral gaps.
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 well-structured with a clear opening sentence, followed by organized 'Args' and 'Returns' sections. It's appropriately sized for a tool with 7 parameters, though the 'At least one search parameter must be provided' note could be integrated more smoothly into the parameter descriptions.
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 complexity (7 parameters, no annotations, but with an output schema), the description is largely complete. It covers all parameters in detail and describes the return format, though it could benefit from more behavioral context (e.g., read-only nature, error cases). The output schema reduces the need to fully explain returns, but some operational guidance is missing.
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 0%, so the description must fully compensate. It provides detailed semantics for all 7 parameters, including required status, formats (e.g., YYYY-MM-DD or ISO for dates), defaults (page: 1, per_page: 5), and usage context (e.g., 'search text to match against episode titles and descriptions'). This adds substantial value beyond the bare schema.
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: 'Search for episodes based on various criteria.' It specifies the resource (episodes) and action (search), though it doesn't explicitly differentiate from sibling tools like 'get_episode' or 'list_shows' beyond the search functionality.
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 some usage context: 'At least one search parameter must be provided' and implies usage for filtered searches. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_episode' (for single episodes) or 'list_shows' (for shows rather than episodes), leaving the agent to infer distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: get_episode retrieves metadata for a specific episode, get_transcript fetches the transcript text, list_shows enumerates available shows, and search_episodes performs filtered searches. There is no overlap in functionality, making tool selection straightforward for an agent.
All tools follow a consistent verb_noun naming pattern (get_episode, get_transcript, list_shows, search_episodes). The verbs are appropriate and descriptive, and the snake_case style is uniformly applied throughout the tool set.
With 4 tools, the server is well-scoped for podcast data retrieval, covering key operations like listing shows, searching episodes, and fetching episode details and transcripts. However, it might benefit from additional tools for broader podcast management (e.g., update or delete operations), but the count is reasonable for the stated purpose.
The tool set provides comprehensive read-only access to podcast data, including listing shows, searching episodes, and retrieving episode metadata and transcripts. Minor gaps exist, such as the lack of create, update, or delete operations, but for a data retrieval server, the coverage is solid and allows agents to perform essential queries without dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, draft and manage your podcast workspace from your agent.
Podcast search, metadata, chapters, and transcripts for AI agents — from $15/mo
Create, import, and publish Jellypod podcast episodes from your AI assistant.
Search 4M+ podcasts & YouTube, transcribe any episode, search transcripts, generate AI lessons.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Red5d/podcast_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
