Skip to main content
Glama

Particle Podcast Get Episode Timeseries

particle_podcast_get_episode_timeseries
Read-only

Time-bucketed episode counts — the purpose-built answer to "how often is X discussed over time". Counts episodes matching the same filters as particle_podcast_list_episodes (person, company, entity, podcast, keyword, language, duration, transcript availability) per day, week, or month, plus range totals. keyword_search additionally counts matching transcript segments per bucket (exact counts); semantic_search does the same by meaning, with the same similarity threshold as particle_podcast_search_transcripts (lower bounds for pathologically broad queries), and requires published_after. The two cannot be combined.

Use this for appearance, publication, or topic trend lines instead of paging particle_podcast_list_episodes, particle_podcast_find_mentions, or particle_podcast_search_transcripts once per period. For how often a person, company or brand is mentioned, use particle_podcast_get_mention_trends: it leaves ad reads out, where this tool counts an episode for a company or entity named only in its ad reads, and it says which podcasts carried the mentions. Buckets are UTC-aligned, zero-filled, and Monday-aligned for weeks; ranges are capped at 1000 buckets. At least one of podcast_slug, person_slug, company_slug, entity_slug, keyword_search, semantic_search, guest_occupation, or guest_field is required.

The guest_ filters count episodes by their guests' expertise (resolve the words to codes with particle_expertise_resolve first; on unresolved_reference, resolve and retry): guest_field alone charts how often a field's experts are booked; with company_slug it charts the company's episodes featuring those experts. They are episode-level and never check who spoke: with keyword_search, a matching segment counts when its episode had such a guest, even if the host said the words. For who said a keyword, use particle_podcast_get_share_of_voice with keyword_search.

Input Schema

NameRequiredDescriptionDefault
roleNoRole filter when person_slug, company_slug, or entity_slug is set.
intervalNoBucket width. Weeks start on Monday; all buckets are UTC-aligned. Defaults to week.
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 (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 (e.g. 'sam-altman'). Counts episodes featuring the person as a speaker — and, when the person has a linked knowledge-graph entity, episodes that mention them.
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 count episodes with a completed transcript.
keyword_searchNoKeyword filter over transcript content. Double-quoted substrings must appear as exact phrases; unquoted terms must all appear in one transcript segment. Adds per-bucket mention counts to the response. Cannot be combined with semantic_search.
guest_seniorityNoOnly episodes with a guest at this seniority or above.
published_afterNoInclusive range start as an ISO 8601 date or date-time. Omit to aggregate all time.
semantic_searchNoVector-similarity filter by meaning over transcript content — the counting twin of particle_podcast_search_transcripts' semantic_search, using the same similarity threshold. Describe the topic the way you'd say it to a colleague; paraphrase tolerant. Adds per-bucket mention counts to the response. Requires published_after (ranges up to ~2 years). Cannot be combined with keyword_search.
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_beforeNoRange end as an ISO 8601 date or date-time. Defaults to now.

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. 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."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, non-destructive, openWorld), yet the description adds substantial non-obvious behavior: UTC-aligned zero-filled buckets, Monday-aligned weeks, a 1000-bucket cap, the ~2-year range limit on semantic search, the 'lower bounds for pathologically broad queries' caveat, and the requirement that at least one filter be supplied. It even explains the guest_ filters' episode-level semantics and the unresolved_reference retry flow.

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 purpose and the when-to-use contrast before dense operational detail; the three paragraphs follow a logical progression (what it computes, when to pick it, how the guest_ filters behave). It is long, but nearly every sentence carries a decision-relevant constraint, so the length is mostly earned rather than padded.

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 22-parameter, zero-required, no-output-schema tool, the description covers the gaps that matter: it explains what the response is (per-bucket counts plus range totals and per-bucket transcript mention counts), the at-least-one-filter precondition, and the keyword/semantic mutual exclusion. Nothing an agent needs to invoke it correctly is missing.

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, but the description adds cross-parameter meaning the schema cannot: guest_field alone charts a field's expert bookings whereas guest_field + company_slug charts company episodes with those experts, and guest_ filters never check who actually spoke. It also clarifies that keyword_search and semantic_search each attach per-bucket mention counts to the response.

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 — time-bucketed episode counts per day/week/month plus range totals — and immediately frames the use case ('how often is X discussed over time'). It explicitly names the siblings it supersedes (particle_podcast_list_episodes, particle_podcast_find_mentions, particle_podcast_search_transcripts) and the related tool it is not (particle_podcast_get_mention_trends).

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 routing rules: use this for trend lines 'instead of paging' the list/search tools, use get_mention_trends when the question is about brand mentions, and get_share_of_voice when the question is who said a keyword. It also states the selection constraint (keyword_search vs semantic_search cannot be combined, semantic requires published_after) and the minimum filter requirement.

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