Skip to main content
Glama
mambalabsdev

Podcast Guest and Host Finder MCP Server

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Podcast Guest and Host Finder MCP Server

Smithery Glama score MCP Registry npm version npm downloads license mcpservers.org

An MCP server for the Mamba Labs Podcast Guest and Host Finder actor on Apify. Give it a topic, or Apple Podcasts links and RSS feeds. Each run returns one row per show with what you need to pitch it.

What's Inside

Related MCP server: Sponsorable MCP server

What it does

Each row carries the host, the owner name and email the show publishes in its own RSS feed, episode count and cadence, an active flag, the share of episodes that name a guest, recent guest names (from podcast:person tags or episode titles), companies named beside guests, and the contact and be a guest pages on the show website. Shows come from the Apple Podcasts catalog for a topic, or from the links you give. A show whose feed cannot be read comes back free with Apple catalog fields only.

All of the work runs on Apify. This package is a thin client that starts the actor run, waits for it, and hands back the dataset rows.

Quick start

You need Node.js 18 or newer and an Apify account with an API token.

Add this to your Claude Desktop config (claude_desktop_config.json), Cursor, or any MCP client:

{
  "mcpServers": {
    "mamba-podcast-guest-host-finder": {
      "command": "npx",
      "args": [
        "-y",
        "@mambalabsdev/mcp-podcast-guest-host-finder"
      ],
      "env": {
        "APIFY_TOKEN": "your-apify-token"
      }
    }
  }
}

Restart the client. The find_podcasts tool appears.

Prerequisites

Example prompts

  • "Find 25 active B2B sales podcasts that interview guests, with the host email and the be a guest page."

  • "Who were the recent guests on these three podcasts, and which companies were they from?"

  • "List SaaS marketing podcasts that published in the last 90 days."

Tool

find_podcasts. One tool. Example arguments:

{
  "topic": "B2B sales",
  "max_podcasts": "25",
  "active_within_days": "90",
  "guest_shows_only": "true"
}

Inputs

Every buyer facing input of the actor, unchanged. Omitted inputs take the actor's own defaults. Numbers and booleans are sent as strings.

Input

Type

Description

topic

string

What the podcasts are about

topics

array

More topics, up to 20

podcast_urls

array

Apple Podcasts links or RSS feed URLs, up to 200

country

string

Apple Podcasts catalog country. Default us

max_podcasts

string

Shows per topic, 1 to 200. Default 25

episodes_to_read

string

Newest episodes read per show, 5 to 300. Default 50

active_within_days

string

Only shows with an episode in this many days

min_episodes

string

Only shows with at least this many episodes

guest_shows_only

string

true or false. Default false

find_contact_page

string

true or false. Default true

max_charge_usd

string

Optional cost cap for the run

Pricing

Pay per event on Apify, billed to your Apify account. Prices in USD.

Event

Free plan

Bronze

Silver

Gold

podcast-row, per show with its feed read

$0.004

$0.0038

$0.0036

$0.0034

apify-actor-start, per run start

$0.0005

$0.0005

$0.0005

$0.0005

A show whose feed could not be read, no results rows, and error rows are free.

Your keys

The actor needs no key. It reads the Apple iTunes Search API, public RSS feeds, and one page of each show website, and holds no key of any kind. Mamba Labs pays the platform and proxy costs of the run.

Full actor documentation

apify.com/mambalabs/podcast-guest-host-finder

License

MIT. See LICENSE.

Available Tools

1 tool
find_podcastsFind podcasts and their hostsA
Read-only

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.

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.

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev1.0.0
    • First observedfind_podcasts
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 1 tool

Disambiguation4/5

With only one tool there is no risk of selecting the wrong tool, so agent-facing ambiguity is minimal. However, the tool internally overloads two modes (topic search vs. podcast_urls lookup) plus multiple filters inside a single entry point, which pushes some ambiguity into parameter interpretation rather than eliminating it.

Naming Consistency4/5

The single name find_podcasts follows a clean snake_case verb_noun convention and clearly states the resource being retrieved. There is no second name to establish a pattern, so consistency can only be judged on adherence to that convention, which it satisfies.

Tool Count3/5

One tool for a read-only discovery/enrichment purpose is defensible, but the surface is functionally a mega-tool that bundles search, feed parsing, guest extraction, and website contact discovery. Splitting search from enrichment would make the set easier to reason about; as-is it sits at the thin end of the spectrum.

Completeness4/5

For a read-only podcast prospecting domain, the single tool covers search, per-show metadata, guest signals, and contact pages, which is a broad lifecycle for discovery. Minor gaps remain: no pagination/cursor for expanding result sets and no way to fetch a single show's full record outside a bulk run.

Maintenance

ActivityNo data
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • mcp-listen-notes

    pipeworx-io
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables searching podcasts, episodes, curated content, and people, as well as retrieving top podcasts via the Listen Notes API.
    15 npm
    MIT

  • Sponsorable MCP server

    sponsorable
    A
    license
    Not graded
    quality
    C
    maintenance
    Connects a podcast-sponsorship database to AI assistants, allowing users to search for brands that sponsor podcasts and reveal buyer contacts by name and email.
    MIT

  • Apple Podcasts MCP

    conorbronsdon
    A
    license
    A
    quality
    B
    maintenance
    Owner-side Apple Podcasts analytics over the Podcasts Connect Reporter protocol: plays, unique and engaged listeners, followers, and per-episode listening for a show you own. Not the public iTunes catalog — this is the data Apple's hosting API does not expose.
    4
    14 npm
    1
    Apache 2.0

  • podcast-recommendations

    surendranb
    A
    license
    A
    quality
    A
    maintenance
    Enables AI agents to discover long-tail podcasts through randomized probe queries, trend lookups, and RSS feed peeks, providing cadence, episode length, and feed details without requiring API keys.
    6
    MIT