Skip to main content
Glama

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. 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, or semantic_search is required.

Input Schema

TableJSON 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.
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.
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.
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.
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.
published_beforeNoRange end as an ISO 8601 date or date-time. Defaults to now.

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?

With only readOnlyHint provided, the description carries the full behavioral burden and delivers: UTC-aligned, zero-filled, Monday-aligned week buckets, a 1000-bucket cap, range totals, exact vs semantic per-bucket counts, and the same similarity threshold as search_transcripts. This goes well beyond what annotations or schema alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but well structured: opening purpose, filter parity, search-mode caveats, usage guidance, bucketing behavior, and required-filter constraint. Every sentence earns its place, and the most important identification cues are front-loaded.

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 15-parameter tool with no output schema, the description covers filters, time semantics, caps, and invocation constraints thoroughly. It falls just short of fully specifying the returned payload structure beyond 'counts', 'range totals', and per-bucket mention counts, though the high-level return contract is clear enough for correct 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by noting that filters are shared with list_episodes, that at least one of six filters is required, and that keyword/semantic searches add per-bucket mention counts. This is meaningful additional context, though not exhaustive per-parameter color.

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 precise, purpose-built definition: time-bucketed episode counts for answering 'how often is X discussed over time'. It clearly distinguishes this aggregation tool from the list/search siblings by focusing on trend lines over paging.

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?

It explicitly says to use this tool for trend lines instead of paging particle_podcast_list_episodes, particle_podcast_find_mentions, or particle_podcast_search_transcripts. It also states the required filter condition and the exclusive search-mode constraints, leaving no ambiguity about when to invoke it.

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