Skip to main content
Glama

Find Podcast Contacts

find_podcast_contacts
Read-onlyIdempotent

Find ACTIVE podcasts whose recent episodes cover a topic, each with the best published contact route for booking a guest or buying sponsorship. Searches episode titles and show notes across ~740k podcasts that published in the last year (from the Podcast Index open directory plus each show's own RSS feed and website). Every result carries the episodes that prove the fit, the show's activity status, and either best_route (with holder_type person / role / hosting_account_owner, its source_url and last_observed date) or route_status "none_found" with what was checked. Routes designated for your purpose rank first; a general contact or a person's published address is a labelled fallback. For a signed-in account, shows and people you recorded as contacted, declined, booked or do_not_contact are left out. Use get_podcast_profile for one show in full.

Input Schema

NameRequiredDescriptionDefault
limitNoShows per page, 1-50 (default 20).
topicYesWhat the show should be about, in plain words, e.g. "AI agents developer infrastructure" or "marathon training".
cursorNocursor_next from a previous call, for the next page.
countryNoTwo-letter country code of the show, when known, e.g. "us".
purposeYesWhat you want from the show: 'guest' (book someone onto it) or 'sponsor' (advertise on it). Routes designated for this purpose rank first.
languageNoFeed language code, e.g. "en" (matches en, en-us, en-gb).
active_onlyNoDefault true: only shows classified active (publishing on their usual cadence). false also returns overdue, hiatus and dormant shows, labelled.
require_routeNotrue = only shows that have a contact route for this purpose (designated, or a general/person fallback). Default false: shows with no route found are returned too, ranked by fit, with route_status "none_found".
include_engagedNoSigned-in accounts: default false leaves out shows you already recorded as contacted, replied or booked. true returns them, marked with your last outcome. Declined and do_not_contact are always left out.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/open-world, and the description adds substantial value on top: what 'active' means (publishing on usual cadence), the data sources (Podcast Index + RSS + website), what each result contains (proving episodes, activity status, best_route or route_status none_found), the ranking rule (designated routes first, general/person as labelled fallback), and the account-state exclusion rule.

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?

Front-loaded with the core purpose and scope sentence, then progressively narrows to result contents and the sibling pointer. Dense but every sentence earns its place; slightly long for what is ultimately a search call.

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 9-param search tool with no output schema, the description covers activity classification, source corpora, result shape (episodes, status, route or none_found), ranking, and engagement filtering - enough for an agent to call it and interpret results without further guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description reinforces the semantics of purpose (guest vs sponsor ranking), require_route, active_only, and include_engaged, but adds no syntax or format detail beyond what the schema already documents.

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?

Starts with a specific verb+resource+qualifier: 'Find ACTIVE podcasts whose recent episodes cover a topic.' The scope is made concrete with '~740k podcasts that published in the last year' and explicitly names the sibling it defers to ('Use get_podcast_profile for one show in full').

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names get_podcast_profile as the single-show alternative, and the require_route/active_only/include_engaged flags each imply when this tool is the right one. However, no explicit 'do not use this for X' exclusions beyond the sibling pointer, and the relationship to record_podcast_outreach (which consumes the outcomes this tool filters) is left implicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.