Skip to main content
Glama
Sign In

particle-pro

by pro.particle
OverviewDiscussionsAdmin

Particle Podcast Get Episode

particle_podcast_get_episode
Read-only

Return a bundled overview of one podcast episode: title, podcast, speakers (with entity slugs), top mentioned entities, and segment/clip counts.

By default the response is lean — counts plus the top mentioned entities. Request optional sections via include: 'segments' for the structural outline with timestamps, 'entities' for the complete entity list, 'clips' for engagement-ranked highlight clips, 'topics' for topic classifications with slugs, 'guest_expertise' for each guest's expertise and whether they spoke within their field, 'speaker_statement_characteristics' for how the episode's lines were said (label shares overall and per speaker, who is most hedged or forward-looking, and a few of its strongest predictions, confident claims, criticism and optimism lines), or 'transcript' for the dialogue transcript (narrow it by speaker or time range via transcript_speaker / transcript_start / transcript_end — full transcripts are large).

For "every line about X in this episode" use particle_podcast_find_mentions with episode_slug instead — that returns the dialogue around each mention with is_mention flags. For the ad reads inside the episode use particle_podcast_get_episode_ads (premium).

Input Schema

NameRequiredDescriptionDefault
includeNoOptional response sections: 'transcript' (bounded dialogue transcript — large for long episodes; narrow it with the transcript_* sub-params), 'segments' (structural outline with timestamps), 'entities' (complete mentioned-entity list instead of the top 20), 'clips' (engagement-ranked highlight clips), 'topics' (topic classifications with slugs), 'related' (the five episodes from OTHER shows most related to this one — slug, show, score, band; for the full ranked list with the basis behind each match call particle_podcast_list_related_episodes), 'guest_expertise' (each guest's expertise read and how the episode used it: whether they spoke within their field, whether the appearance was promotional, how they were introduced), 'speaker_statement_characteristics' (how the lines were said: label shares overall and per identified speaker, who is most hedged or forward-looking, and up to 5 of its strongest predictions, confident claims, criticism and optimism lines). Default response is lean — request only what you need.
episode_slugYesEpisode slug or canonical ID. A particle.pro or Radar episode link also works.
transcript_endNoTranscript range end in seconds. Lines that overlap the range are returned whole.
transcript_startNoTranscript range start in seconds. Lines that overlap the range are returned whole.
transcript_formatNoTranscript format for include=transcript. Defaults to text.
transcript_speakerNoFilter the transcript to one speaker: a name, a person slug or ID, or an entity slug or ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / include / description
      Previous value: -"Optional response sections: 'transcript' (bounded dialogue transcript — large for long episodes; narrow it with the transcript_* sub-params), 'segments' (structural outline with timestamps), 'entities' (complete mentioned-entity list instead of the top 20), 'clips' (engagement-ranked highlight clips), 'topics' (topic classifications with slugs), 'related' (the five episodes from OTHER shows most related to this one — slug, show, score, band; for the full ranked list with the basis behind each match call particle_podcast_list_related_episodes), 'guest_expertise' (each guest's expertise read and how the episode used it: whether they spoke within their field, whether the appearance was promotional, how they were introduced). Default response is lean — request only what you need."New value: +"Optional response sections: 'transcript' (bounded dialogue transcript — large for long episodes; narrow it with the transcript_* sub-params), 'segments' (structural outline with timestamps), 'entities' (complete mentioned-entity list instead of the top 20), 'clips' (engagement-ranked highlight clips), 'topics' (topic classifications with slugs), 'related' (the five episodes from OTHER shows most related to this one — slug, show, score, band; for the full ranked list with the basis behind each match call particle_podcast_list_related_episodes), 'guest_expertise' (each guest's expertise read and how the episode used it: whether they spoke within their field, whether the appearance was promotional, how they were introduced), 'speaker_statement_characteristics' (how the lines were said: label shares overall and per identified speaker, who is most hedged or forward-looking, and up to 5 of its strongest predictions, confident claims, criticism and optimism lines). Default response is lean — request only what you need."
    • changedInput schema / properties / include / items / enum
      Previous value: -[
-  "transcript",
-  "segments",
-  "entities",
-  "clips",
-  "topics",
-  "related",
-  "guest_expertise"
-]New value: +[
+  "transcript",
+  "segments",
+  "entities",
+  "clips",
+  "topics",
+  "related",
+  "guest_expertise",
+  "speaker_statement_characteristics"
+]
  2. Changed3 schema fields changed
    • changedInput schema / properties / transcript_end / description
      Previous value: -"Transcript end clip in seconds."New value: +"Transcript range end in seconds. Lines that overlap the range are returned whole."
    • changedInput schema / properties / transcript_speaker / description
      Previous value: -"Filter the transcript to one speaker (name or entity slug)."New value: +"Filter the transcript to one speaker: a name, a person slug or ID, or an entity slug or ID."
    • changedInput schema / properties / transcript_start / description
      Previous value: -"Transcript start clip in seconds."New value: +"Transcript range start in seconds. Lines that overlap the range are returned whole."
  3. Changed2 schema fields changed
    • changedInput schema / properties / include / description
      Previous value: -"Optional response sections: 'transcript' (bounded dialogue transcript — large for long episodes; narrow it with the transcript_* sub-params), 'segments' (structural outline with timestamps), 'entities' (complete mentioned-entity list instead of the top 20), 'clips' (engagement-ranked highlight clips), 'topics' (topic classifications with slugs), 'related' (the five episodes from OTHER shows most related to this one — slug, show, score, band; for the full ranked list with the basis behind each match call particle_podcast_list_related_episodes). Default response is lean — request only what you need."New value: +"Optional response sections: 'transcript' (bounded dialogue transcript — large for long episodes; narrow it with the transcript_* sub-params), 'segments' (structural outline with timestamps), 'entities' (complete mentioned-entity list instead of the top 20), 'clips' (engagement-ranked highlight clips), 'topics' (topic classifications with slugs), 'related' (the five episodes from OTHER shows most related to this one — slug, show, score, band; for the full ranked list with the basis behind each match call particle_podcast_list_related_episodes), 'guest_expertise' (each guest's expertise read and how the episode used it: whether they spoke within their field, whether the appearance was promotional, how they were introduced). Default response is lean — request only what you need."
    • changedInput schema / properties / include / items / enum
      Previous value: -[
-  "transcript",
-  "segments",
-  "entities",
-  "clips",
-  "topics",
-  "related"
-]New value: +[
+  "transcript",
+  "segments",
+  "entities",
+  "clips",
+  "topics",
+  "related",
+  "guest_expertise"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / episode_slug / description
      Previous value: -"Episode slug or canonical ID."New value: +"Episode slug or canonical ID. A particle.pro or Radar episode link also works."
  5. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly/openWorld/non-destructive, so the description's real contribution is pay-per-section behavior: lean by default, opt-in sections via `include`, and the warning that full transcripts are large and should be narrowed by speaker/time range. It stops short of any rate-limit, auth, or premium-status note for this tool itself, which keeps it off a 5.

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-loads purpose and default behavior, then routes to alternatives — a sensible order. The long inline enumeration of every `include` value largely duplicates the schema enum description, which is the one place it spends words it doesn't need to.

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 no output schema and six parameters, the description covers what comes back, what the lean default contains, how to expand it, and the size caveat on transcripts — enough for an agent to call this correctly and avoid over-fetching. The only omission ('related' in the prose include list) is fully covered by the schema.

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 description coverage is 100%, so the schema carries the baseline; the description still adds practical meaning by framing `include` as an opt-in cost/benefit tradeoff and by explaining that transcript_speaker/transcript_start/transcript_end exist to bound a large payload. Minor gap: the prose enumeration of `include` values omits 'related', which only the schema mentions.

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?

Names a specific verb and resource ('Return a bundled overview of one podcast episode') and immediately enumerates the returned fields (title, podcast, speakers with slugs, top entities, segment/clip counts). It also explicitly differentiates itself from two siblings, so an agent can pick it 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 an explicit default ('response is lean — counts plus top mentioned entities') and tells the agent exactly which alternative to use for adjacent needs: 'every line about X' → particle_podcast_find_mentions with episode_slug, and ad reads → particle_podcast_get_episode_ads (premium). The when/when-not/alternatives routing is complete.

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

All particle-pro toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources