Podcast Index MCP — wraps the Podcast Index API (podcastindex.org). The open podcast database: podcast search, podcast metadata, episodes, and trending podcasts across the public podcast ecosystem.
Four tools with complete input schemas and descriptions. Naming follows verb_noun pattern (search_, get_, list via 'episodes', trending). Descriptions are adequate (100-200 chars) but lack dependency hints and recovery guidance. All parameters have types and descriptions. Critical gap: no output schemas documented, LLMs cannot plan downstream calls or extract required fields. No error handling guidance (e.g., 'If credentials fail, try omitting _apiKey to use shared key'). The _apiKey parameter pattern is non-standard (KEY:SECRET string) and exposes auth complexity to the agent; should be server-side injected. No pagination guidance despite API supporting max limits.
List recent episodes for a podcast by its Podcast Index feed ID. Returns episode title, description, publish date, duration, audio URL, and episode/season numbers. Example: episodes({ feed_id: 920666, max: 10 })
Get full metadata for a single podcast by its Podcast Index feed ID. Returns title, author, description, owner, episode count, categories, language, and artwork. Example: get_podcast({ feed_id: 920666 })
Podcast search by term. Find podcasts in the open podcast database by name or keyword. Returns matching podcasts with title, author, description, categories, episode count, and artwork. Example: search_podcasts({ query: "true crime", max: 10 })
Get trending podcasts across the open podcast database, ranked by recent activity. Optionally filter by language or category. Returns podcast title, author, categories, artwork, and trend score. Example: trending({ max: 10, lang: "en", cat: "Technology" })
No output schemas documented. LLMs cannot infer what fields to expect (e.g., does search_podcasts return feed_id or id? Is it 'categories' or 'category'?). This forces agents to guess and breaks downstream tool chaining.
_apiKey parameter exposes authentication complexity to the agent. Credentials should be server-side injected via environment variables or vault, not passed as tool parameters. Agent traces log all parameters, secrets leak into logs.
No error handling guidance. If API returns 401 (bad credentials), the response is just {error: 401, message: <text>}. LLM has no recovery path. Should return: 'Invalid credentials. Omit _apiKey to use the shared Pipeworx key, or provide valid KEY:SECRET.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Parameter descriptions include example values ('e.g. "true crime", "javascript"'). LLMs tend to reuse examples literally. Use enum constraints or format declarations instead.
'episodes' tool name is ambiguous, does it list episodes or create one? Rename to 'list_episodes' or 'get_episodes' to match verb_noun convention and clarify intent.