Skip to main content
Glama

particle_podcast_resolve

Read-only

Find a podcast by free-text title, exact slug, iTunes ID, or RSS feed URL. Returns slug, title, episode count, bias, and the top recurring speakers (with entity slugs). Use the slug as the agent-facing handle to feed into other podcast tools (particle_podcast_find_mentions, particle_podcast_list_episodes, particle_podcast_get_sponsors).

Free-text matching is forgiving — typos, missing or extra words, and pasted episode titles all work. Results are ordered best-match-first; text matches carry a match_quality field, and an empty list means the catalog has no plausible candidate.

With all identifiers omitted, returns the most recently updated podcasts — useful for browsing the catalog when you don't have a name in mind. Narrow free-text browsing with topic_slug (topic concentration, descendants included), suitability_tier, or min_popularity (global popularity percentile over charting podcasts).

Optional hydrations attach extra data to each result in the same call:

  • include: ["external_links"]: third-party platform presences (directories, social profiles, video channels, publisher websites) with resolved URLs and audience metrics.

  • include: ["suitability"]: per-category brand-suitability breakdown (12 categories with prevalence, treatment, derived risk level, reasoning, and evidence excerpts) — premium-grade data, requires a plan with premium endpoints. The high-level suitability_tier enum (SAFE / LIMITED / SENSITIVE / UNSAFE) is rendered on every result without opt-in.

  • include: ["ratings_summary"]: listener-review aggregate (average stars, count, per-platform breakdown).

  • include: ["bias"]: full political-bias analysis (the high-level bias enum is always rendered without opt-in).

  • include: ["rankings"]: current chart positions across sources/countries/categories — premium-grade data, requires a plan with premium endpoints. For movers and history use particle_podcast_get_rankings.

  • include: ["format"]: the show's format profile — how often episodes feature guests, detected production formats (interview, panel, call_in, solo_narrated), ad and video presence, episode-length distribution, publishing cadence, and the publish-day pattern.

  • recent_episodes: N: inline this many of each result's most recent episodes (slug, title, published_at, duration) — skip the follow-up particle_podcast_list_episodes call when you only need the most recent tail.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugNoExact slug match for a known handle (e.g. 'all-in').
limitNoMaximum candidates to return (1-25, default 5).
queryNoFree-text search across podcast titles and descriptions (case-insensitive partial match). Omit to fall back to the most recently updated podcasts.
includeNoOptional non-parameterized hydrations to attach to each result. 'external_links' adds third-party platform presences (directories, social profiles, video channels, publisher websites). 'suitability' adds the per-category brand-suitability breakdown (premium-grade data — requires a plan with premium endpoints). 'ratings_summary' adds the listener-review aggregate. 'bias' adds the full political-bias analysis. 'rankings' adds current chart positions (premium-grade data — requires a plan with premium endpoints). 'format' adds the format profile (guest frequency, interview/panel/call-in/solo formats, ads, video, episode length, cadence, publish days). 'related' adds the five most related shows (slug, score, band) — for the full ranked list with the basis behind each pair call particle_podcast_list_related. 'recommended_guests' adds the five guests the show could book next — people who have guested on its related shows but never on it (person slug, score, band, and the related shows that booked them); the booking pipeline. 'recommended_sponsors' adds the five advertisers the show could pitch — sponsors that run on its related shows but not on it (sponsor, linked company, score, band, ads and most recent ad across those shows, and which shows); the prospecting list (premium-grade data — requires a plan with premium endpoints). The high-level suitability_tier and bias enums are always rendered without opt-in. Off by default; opt in only when needed.
rss_urlNoCanonical RSS feed URL. Resolves directly to the matching podcast.
itunes_idNoNumeric Apple Podcasts / iTunes ID (e.g. '1502871393'). Resolves directly to the matching podcast.
topic_slugNoFilter candidates by topic (slug from particle_topic_browse, e.g. 'technology/artificial-intelligence'). Matches podcasts where the topic — or any of its descendants — accounts for a meaningful share of episodes, ranked by concentration.
min_popularityNoRestrict candidates to podcasts whose global popularity percentile is at least this value (0-1]. Popularity is a cume_dist ranking over currently-charting podcasts; non-charting podcasts are excluded when set. Omit or 0 to disable.
recent_episodesNoInline this many of each result's most recent episodes (slug, title, published_at, duration). 0 (default) means none — call particle_podcast_list_episodes if you need more than the inline tail. Capped at 25.
suitability_tierNoFilter candidates by brand-suitability tier. Podcasts without a suitability analysis are excluded when set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals important behavior: forgiving free-text matching, best-match-first ordering, the match_quality marker, empty-list semantics, the recently-updated fallback when no identifiers are provided, and premium-endpoint requirements for certain hydrations. It also clarifies that high-level bias and suitability enums are always returned without opt-in. No contradiction with the annotations.

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?

The description is front-loaded with the core purpose and return fields, then organized into scannable bullets for hydrations. It is fairly long, but the complexity of 10 optional parameters and 7 include options justifies the length. Some redundancy with the schema's include descriptions keeps it from being maximally concise.

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?

Given that there is no output schema, the description carries the burden of explaining return behavior and does so thoroughly: lookup modes, returned fields, matching tolerance, empty-list meaning, browsing mode, filters, hydration options, premium-plan caveats, and downstream tool usage. Minor gaps like error behavior for invalid exact identifiers do not undermine selection and 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?

The input schema already describes all 10 parameters in detail (100% coverage), so the baseline is 3. The description adds some extra parameter-selection guidance, such as the all-identifiers-omitted browsing mode, the agent-facing slug handle, and grouping topic_slug/suitability_tier/min_popularity as narrowing filters. However, much of the hydration detail repeats the schema, so it does not reach 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?

The description opens with a specific lookup verb and resource: 'Find a podcast by free-text title, exact slug, iTunes ID, or RSS feed URL.' It also states the returned payload (slug, title, episode count, bias, recurring speakers) and positions the slug as the handle for downstream podcast tools, making its role distinct from the other resolve-type siblings.

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?

The description explains when to use the tool for identifier-based lookup, when to browse by omitting identifiers, and how to narrow browsing via topic_slug, suitability_tier, or min_popularity. It explicitly routes follow-up work to sibling tools, e.g. using particle_podcast_get_rankings for movers/history, particle_podcast_list_episodes for more episodes, and particle_podcast_find_mentions/list_episodes/get_sponsors once a slug is resolved.

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.

Resources