Skip to main content
Glama
Sign In
Podcast Guest and Host Finder MCP Server

Podcast Guest and Host Finder MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Find podcasts and their hosts

find_podcasts
Read-only

Search podcasts by topic or Apple Podcasts/RSS URL and return host and owner contacts, episode cadence, recent guests, companies, and contact or guest-pitch pages.

Instructions

Find podcasts on a topic, or read podcasts you name, and return one row per show: host, the owner name and email the show publishes in its own RSS feed, episode count, latest episode, episodes in the last 90 days, an active flag, the share of episodes that name a guest, recent guest names read from episode titles or podcast:person tags, companies named beside guests, and the contact and be a guest pages on the show website. Give topic (for example B2B sales) to search the Apple Podcasts catalog, or podcast_urls with Apple Podcasts links or RSS feed URLs. Filters: active_within_days, min_episodes, guest_shows_only. A show whose feed cannot be read comes back free with Apple catalog fields only. A run that does not succeed is returned as an error with its run ID. Read-only; requires an APIFY_TOKEN; Apify charges per podcast row returned.

Input Schema

NameRequiredDescriptionDefault
topicNoWhat the podcasts are about, for example B2B sales. Searched in the Apple Podcasts catalog.
topicsNoMore topics, up to 20. A show found under two topics is returned once.
countryNoTwo letter Apple Podcasts catalog country, for example us or gb. Default us.
max_podcastsNoShows per topic, 1 to 200. Each show with its feed read is billed. Default 25.
min_episodesNoOnly shows with at least this many episodes.
podcast_urlsNoApple Podcasts links or RSS feed URLs of shows to read directly, up to 200.
max_charge_usdNoOptional. The run stops before any row that would take its charges over this amount.
episodes_to_readNoNewest episodes read per show for guests and cadence, 5 to 300. Default 50.
guest_shows_onlyNotrue: only shows where 30 percent or more of the episodes read name a guest and 3 or more guests were found. Default false.
find_contact_pageNoRead the show website its feed names for a contact page and a be a guest page. Default true.
active_within_daysNoOnly shows with an episode in the last this many days. Removed shows are free.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/non-idempotent, and the description goes well beyond them: it discloses the APIFY_TOKEN requirement, per-row Apify charges, that unreadable feeds are returned free with Apple catalog fields only, and that failed runs surface as errors with a run ID. These are exactly the operational traits an agent cannot infer elsewhere.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The long run-on enumeration of return columns is dense and placed before the mode-selection sentence, so the key decision (topic vs. podcast_urls) is not front-loaded. Content is largely justified given the absence of an output schema, but the structure is a wall of text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 11 optional parameters, no output schema, and no siblings, the description supplies the return shape, the billing model, the token prerequisite, and degraded-case behavior. Nothing material is missing for correct invocation.

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?

Schema coverage is 100%, so the baseline is 3; the description adds genuine value by naming the operational filters (active_within_days, min_episodes, guest_shows_only) and noting 'removed shows are free', a billing nuance absent from the schema. It does not, however, clarify the interaction between max_podcasts and max_charge_usd.

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?

States a specific verb and resource (find podcasts) and immediately clarifies the two acquisition modes: topic search over the Apple Podcasts catalog vs. reading named shows via podcast_urls. It also enumerates the returned row fields, so an agent knows exactly what the tool produces without opening a schema.

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?

Explicitly routes between the two modes ('Give topic ... or podcast_urls with Apple Podcasts links or RSS feed URLs') and names the filter parameters that narrow results. With no sibling tools, this is the complete selection guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools