Skip to main content
Glama

Particle Podcast List Episodes

particle_podcast_list_episodes
Read-only

List episodes across the catalog with rich filters: by podcast, person, company, language, date range, duration, or transcript availability.

By default it lists the episodes we have ingested. Pass transcript_status with podcast_slug to reach the show's back catalogue — older episodes discovered in its feed but not transcribed, marked requestable. Their transcript, segments, speakers and entities do not exist until one is requested.

Use this for episode-level discovery when you only need metadata (title, duration, speakers, counts). For dialogue around a person in any episode, use particle_podcast_find_mentions. For ranked retrieval by topic, use particle_podcast_search_transcripts.

The guest_ filters list episodes by their guests' expertise (resolve the words to codes with particle_expertise_resolve first; on unresolved_reference, resolve and retry): guest_occupation="cardiologists" with guest_practicing=true lists episodes with a practicing cardiologist as a guest, and guest_capacity="executive_founder" lists episodes with a founder as a guest.

Input Schema

NameRequiredDescriptionDefault
roleNoRole filter when person_slug or company_slug is set.
limitNoEpisodes per page (1-50, default 10).
cursorNoOpaque pagination cursor from a previous response.
languageNoRestrict to episodes of podcasts in this language — ISO 639-1 code (e.g. 'fr'). Matches the podcast's primary language subtag, so 'fr' covers 'fr-FR'.
entity_slugNoKnowledge-graph entity slug from particle_entity_resolve for the long tail that isn't a person or company — places, organizations, events, products, concepts (e.g. 'germany'). Use person_slug for people and company_slug for companies.
guest_fieldNoOnly episodes with a guest listed under this ANZSRC 2020 field of research: a code, slug or title from particle_expertise_resolve (e.g. 'banking-finance-and-investment').
person_slugNoPerson slug or encoded person ID from particle_person_resolve, particle_entity_resolve, or the guest tools (e.g. 'sam-altman'). Episodes featuring or mentioning the person.
company_slugNoCompany slug, domain, or ID. Resolves to the linked entity.
max_durationNoMaximum episode duration in seconds.
min_durationNoMinimum episode duration in seconds.
podcast_slugNoPodcast slug, internal ID, or numeric iTunes ID. Restrict to one podcast. A particle.pro or Radar show link also works.
output_formatNoOutput serialization. 'markdown' (default) returns the LLM-facing rendering. 'json' returns the structured payload as JSON text — use only for programmatic chaining where exact field extraction matters; the JSON shape is larger and noisier for an LLM to read.
guest_capacityNoOnly episodes with a guest who knows their field in this capacity (e.g. 'executive_founder' for founders). It narrows the other filters; particle_expertise_resolve names the capacity an everyday word means.
guest_in_fieldNoOnly episodes with a guest speaking within their own field (the guest the other guest_ filters select, when given).
guest_standingNoOnly episodes with a guest whose standing is recognized this way: 'established' (conferred by others), 'self_described', or 'unverified'.
has_transcriptNoOnly include episodes with a completed transcript. Superseded by transcript_status=transcribed; do not pass both.
guest_seniorityNoOnly episodes with a guest at this seniority or above.
published_afterNoISO 8601 date or date-time.
guest_occupationNoOnly episodes with a guest listed under this occupation: a SOC 2018 or ISCO-08 code, slug or title from particle_expertise_resolve, or a SOC group or everyday name (e.g. 'cardiologists', '29-1212', 'physicians' or 'doctors'). A word with no occupation filters by the field of research or capacity it names: 'oncologists' is field 3211, 'founders' is capacity executive_founder.
guest_practicingNoOnly episodes with a guest who still works in guest_occupation, which must be a SOC 2018 occupation or group (e.g. '29-1212' or 'physicians').
published_beforeNoISO 8601 date or date-time.
transcript_statusNoFilter by where episodes stand on the way to a transcript. Omitted lists the episodes we have ingested. any, untranscribed and requestable also list the podcast's back catalogue — episodes discovered in its feed but not transcribed — and require podcast_slug: any lists every discovered episode, untranscribed those without a transcript, requestable back-catalogue episodes whose transcript can be requested. transcribed lists episodes with a transcript.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / guest_capacity
      Added value: +{
      +  "description": "Only episodes with a guest who knows their field in this capacity (e.g. 'executive_founder' for founders). It narrows the other filters; particle_expertise_resolve names the capacity an everyday word means.",
      +  "enum": [
      +    "researcher",
      +    "licensed_professional",
      +    "practitioner",
      +    "executive_founder",
      +    "public_official",
      +    "journalist_analyst",
      +    "creator_entertainer",
      +    "athlete_coach",
      +    "clergy",
      +    "firsthand",
      +    "layperson"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / guest_occupation / description
      Previous value: -"Only episodes with a guest listed under this occupation: a SOC 2018 or ISCO-08 code, slug or title from particle_expertise_resolve (e.g. 'cardiologists' or '29-1212')."New value: +"Only episodes with a guest listed under this occupation: a SOC 2018 or ISCO-08 code, slug or title from particle_expertise_resolve, or a SOC group or everyday name (e.g. 'cardiologists', '29-1212', 'physicians' or 'doctors'). A word with no occupation filters by the field of research or capacity it names: 'oncologists' is field 3211, 'founders' is capacity executive_founder."
    • changedInput schema / properties / guest_practicing / description
      Previous value: -"Only episodes with a guest who still works in guest_occupation, which must be a detailed SOC 2018 occupation (e.g. '29-1212')."New value: +"Only episodes with a guest who still works in guest_occupation, which must be a SOC 2018 occupation or group (e.g. '29-1212' or 'physicians')."
  2. Changed6 schema fields changed
    • addedInput schema / properties / guest_field
      Added value: +{
      +  "description": "Only episodes with a guest listed under this ANZSRC 2020 field of research: a code, slug or title from particle_expertise_resolve (e.g. 'banking-finance-and-investment').",
      +  "type": "string"
      +}
    • addedInput schema / properties / guest_in_field
      Added value: +{
      +  "description": "Only episodes with a guest speaking within their own field (the guest the other guest_ filters select, when given).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / guest_occupation
      Added value: +{
      +  "description": "Only episodes with a guest listed under this occupation: a SOC 2018 or ISCO-08 code, slug or title from particle_expertise_resolve (e.g. 'cardiologists' or '29-1212').",
      +  "type": "string"
      +}
    • addedInput schema / properties / guest_practicing
      Added value: +{
      +  "description": "Only episodes with a guest who still works in guest_occupation, which must be a detailed SOC 2018 occupation (e.g. '29-1212').",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / guest_seniority
      Added value: +{
      +  "description": "Only episodes with a guest at this seniority or above.",
      +  "enum": [
      +    "professional",
      +    "senior",
      +    "distinguished"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / guest_standing
      Added value: +{
      +  "description": "Only episodes with a guest whose standing is recognized this way: 'established' (conferred by others), 'self_described', or 'unverified'.",
      +  "enum": [
      +    "established",
      +    "self_described",
      +    "unverified"
      +  ],
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / properties / has_transcript / description
      Previous value: -"Only include episodes with a completed transcript."New value: +"Only include episodes with a completed transcript. Superseded by transcript_status=transcribed; do not pass both."
    • addedInput schema / properties / transcript_status
      Added value: +{
      +  "description": "Filter by where episodes stand on the way to a transcript. Omitted lists the episodes we have ingested. any, untranscribed and requestable also list the podcast's back catalogue — episodes discovered in its feed but not transcribed — and require podcast_slug: any lists every discovered episode, untranscribed those without a transcript, requestable back-catalogue episodes whose transcript can be requested. transcribed lists episodes with a transcript.",
      +  "enum": [
      +    "any",
      +    "transcribed",
      +    "untranscribed",
      +    "requestable"
      +  ],
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / podcast_slug / description
      Previous value: -"Podcast slug, internal ID, or numeric iTunes ID. Restrict to one podcast."New value: +"Podcast slug, internal ID, or numeric iTunes ID. Restrict to one podcast. A particle.pro or Radar show link also works."
  5. First observed

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/no-destruction, and the description goes well beyond them: it discloses that the default lists only ingested episodes, that transcript_status with podcast_slug reaches untranscribed back-catalogue episodes marked requestable, and that transcript, segments, speakers and entities do not exist until a request is made. It also explains output_format trade-offs for chaining.

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 purpose and default behavior, then alternatives, then the nuanced filter semantics — a sensible ordering for a 22-parameter tool. Some sentences are dense and could be tightened, but none are filler given the parameter surface area.

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

Completeness4/5

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

For a 22-param, no-output-schema tool the description covers the hard parts: default scope, back-catalogue lifecycle, sibling routing, and the guest-filter resolution chain. It names some return fields in passing ('title, duration, speakers, counts') but stops short of describing the overall response shape, which is the only real gap.

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 baseline is 3, and the description adds real meaning on top: worked examples of filter combination (guest_occupation="cardiologists" with guest_practicing=true; guest_capacity="executive_founder"), the requirement to resolve words to codes via particle_expertise_resolve first, and the unresolved_reference retry behavior. It does not touch every one of the 22 params, but the ones it covers are the non-obvious ones.

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 ('List episodes across the catalog') plus the filterable dimensions, and explicitly distinguishes itself from two sibling tools (particle_podcast_find_mentions for dialogue, particle_podcast_search_transcripts for ranked topic retrieval). An agent can place it correctly without opening any 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?

Gives explicit when-to-use conditions ('episode-level discovery when you only need metadata') and names the two alternatives with the conditions that select them. It also states the default mode versus the transcript_status + podcast_slug path for reaching the back catalogue, and the prerequisite resolve-and-retry flow for the guest_ filters.

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