Skip to main content
Glama
Sign In
Panda Leads Tools

Panda Leads Tools

by pandadad0214
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Podcast Leads Finder: Podcast Host Emails & Guest Booking List

podcast_leads_finder
Read-only

Find active podcasts by topic on Apple Podcasts, including host contact emails from RSS feeds, activity and guest-friendly signals for guest booking, PR and sponsorship outreach.

Instructions

Find active podcasts to pitch by topic from Apple Podcasts and each show's public RSS feed: host, contact email published in the feed, website, socials, episode count, last episode date and a guest-friendly signal. Unlike local_business_leads or company_team_finder (businesses and staff), this targets shows and their hosts for guest booking or sponsorship outreach. Use when you need a podcast guesting, PR or sponsorship list for a niche. Do not use for audience or download numbers (not public) or for general topic popularity (use topic_trends_tracker). Parameters: each keyword is searched separately and results are de-duplicated; deepSearch=true (default) searches descriptions too for up to 3x more shows but is slower. onlyWithEmail and guestFriendlyOnly filter before billing, so they shrink both list and cost. activeWithinDays=0 includes dormant shows. Emails come only from RSS feeds; nothing is guessed. Returns per item: agentSummary, podcastName, author, email, emailSource, website, socials, appleUrl, feedUrl, primaryGenre, episodeCount, lastEpisodeDate, avgDaysBetweenEpisodes, guestFriendly, guestEpisodeShare, recentEpisodeTitles.

Behavior: read-only; runs the Apify Actor pandadad0214/podcast-leads-finder (https://apify.com/pandadad0214/podcast-leads-finder) on your own Apify account. Price: $0.004 per podcast found. Runs that find nothing are not charged per result, and spending is capped per call by run_max_charge_usd (default $0.50). run_max_items (default 50) limits items returned and fills maxResults when you leave it unset, so it also limits what is billed; setting maxResults higher can bill more than is returned. Most calls finish in 5-15 s for a few inputs; large inputs or crawls can take minutes, so raise run_timeout_secs (max 300) or shrink the input after a timeout error. Returns JSON {actor, count, items}; long text output is trimmed to whole items, with all items in structuredContent.

Input Schema

NameRequiredDescriptionDefault
sortByNoSort by. Relevance = Apple's search order. Newest episode = most recently active first. Most episodes = biggest back catalogs first. Choices: relevance = Relevance; newestEpisode = Newest episode; mostEpisodes = Most episodes.relevance
countryNoApple Podcasts country. 2-letter store country to search, e.g. US, GB, CA, AU, IN. Default US.US
keywordsNoTopics / keywords. Podcast topics to search on Apple Podcasts, one per line, e.g. real estate investing, SaaS marketing, women in business. Each keyword returns up to about 600 shows before filters. Leave empty for a 20-podcast demo.
languageNoLanguage. Optional. Keep shows whose feed language starts with this code, e.g. en, es, de.
deepSearchNoDeep search. On by default: also searches show descriptions and keywords, not just titles, for up to 3x more shows per keyword.
maxResultsNoMaximum podcasts. You pay per returned podcast, so this also caps the cost. Whole number, 1 to 3,000; default 100.
minEpisodesNoMinimum episodes. Optional. Skip shows with fewer episodes (e.g. 20 to skip brand-new shows). Default 0.
onlyWithEmailNoOnly podcasts with a contact email. Keep only shows that publish a contact email in their RSS feed (itunes:owner, managingEditor or the show description).
run_max_itemsNoOptional. Most results to return from this call (default from PANDA_MAX_ITEMS, 50). Also limits how many results the Actor produces and charges for, unless you set its own max field.
activeWithinDaysNoActive within (days). Keep only shows that published an episode in the last N days. 0 = include inactive shows. Default 90.
run_timeout_secsNoOptional. Seconds to wait for results (default from PANDA_TIMEOUT_SECS, 120; max 300).
guestFriendlyOnlyNoOnly podcasts that feature guests. Keep only shows where at least 30% of the last 20 episodes look like interviews (guest names, 'with', 'feat.', or podcast:person guest tags).
run_max_charge_usdNoOptional. Hard spending cap for this call in USD (default from PANDA_MAX_CHARGE_USD, 0.50).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover safety (readOnly, non-destructive, open-world), while the description adds substantial context they do not: it runs Apify Actor pandadad0214/podcast-leads-finder on the caller's own account, costs $0.004 per podcast found, filters like onlyWithEmail/guestFriendlyOnly apply before billing, and emails come only from RSS feeds and are never guessed. It also discloses runtime (5-15s typical, 300s timeout cap) and the {actor, count, items} return envelope.

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?

It is front-loaded with purpose, then differentiation, then parameters, then runtime/billing, then return fields in a logical order, and nearly every sentence carries decision-relevant information. It is dense rather than lean, with mild redundancy between the behavior paragraph and the per-parameter notes on run_max_items, run_max_charge_usd, and maxResults.

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?

For a 13-parameter, no-output-schema tool with pay-per-result billing, the description covers the essentials an agent needs: what is returned per item, how filters affect billing, spend and item caps, timeout recovery guidance, and the response envelope. Nothing material is left to inference 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?

With 100% schema coverage the baseline is 3, and the description earns above that by explaining cross-parameter behavior the schema does not: keywords are searched separately and de-duplicated, deepSearch trades latency for up to 3x more shows, activeWithinDays=0 includes dormant shows, and run_max_items fills maxResults and limits what is billed. Some of this repeats schema text (e.g., maxResults' cost note), which keeps it below a 5.

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?

"Find active podcasts to pitch by topic" gives a specific verb and resource, and it enumerates the returned fields (host, email, website, socials, episode count, guest-friendly signal). It explicitly contrasts itself with local_business_leads and company_team_finder, so an agent can distinguish it from siblings without opening schemas.

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?

"Use when you need a podcast guesting, PR or sponsorship list for a niche" states the target case, and the description adds two exclusions with a named alternative: no audience/download numbers, and "for general topic popularity (use topic_trends_tracker)." Both when-to-use and when-not-to-use are present.

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