Skip to main content
Glama

Particle Podcast Get Mention Trends

particle_podcast_get_mention_trends
Read-only

How a person's, company's or entity's podcast mentions are moving, for tracking it week over week. To find what is rising across all podcasts rather than track a subject you already know, use particle_podcast_get_entity_chart. Two modes:

  • compare (default): which podcasts mentioned it in a window (default the last 7 days, at most 90) and how each compares with the equal-length window before it: episode and mention line counts in both, the delta, and a label. A show in both windows is continuing; one only in the previous is dropped. A show only in the current window is judged against the lookback before it (lookback_days, default 90): new when it never mentioned the subject there, published at least four episodes there, and has two or more mention lines now; returning when it mentioned the subject earlier in the lookback; passing for a single line; newly_tracked when it published too little in the lookback to tell. Totals for both windows count every podcast. Filter with change, order with sort (rising and falling for the biggest movers), and page with cursor. Answers "which shows talked about Nike this week versus last?" in one call, and, with change="new" (sorted by popularity unless sort is set), "which podcasts started talking about Nike this month?" or "which mentioned Nike for the first time?": read what the leading shows said with particle_podcast_find_mentions. Since 2026-10-23, new no longer means every show absent from the previous window; that set is now new, returning, passing and newly_tracked together.

  • timeseries: mention counts per day, week or month over a range (omit published_after for all time), each bucket with its episodes, mention lines and distinct podcasts. Answers "is it rising?". podcast_slug charts one show. breakdown splits each bucket by a speaker statement characteristics label (breakdown="sentiment": is it spoken of more negatively this quarter?), and speaker_statement_characteristics counts only the mentions said that way ({"temporal_orientation": ["future"]}: are predictions about it rising?); both need published_after, at most 365 days back.

Mentions inside ad reads are left out unless include_ads, so a brand that advertises heavily is measured by what shows say about it. The newest day fills in over about a day as episodes are processed, so a window ending now reads slightly low and the current bucket is marked partial: compare full buckets.

Podcast slugs in the response work with particle_podcast_find_mentions (with the same dates as since and until, to read what a show said) and particle_podcast_list_episodes. Not for the mention lines themselves (particle_podcast_find_mentions), appearance or topic trends by role or keyword (particle_podcast_get_episode_timeseries, which counts an episode for a company named only in its ad reads), or a split by who said it (particle_podcast_get_share_of_voice). To be told about new mentions as they air, create an alert with particle_alert_create.

Input Schema

NameRequiredDescriptionDefault
modeNo'compare' (default): which podcasts mentioned the subject in the window and how each compares with the equal-length window before it, with both windows' totals. 'timeseries': mention counts per day, week or month over a range, with the podcasts carrying them per bucket.
roleNoConstrain how the subject participates: guest, host, panelist, correspondent, or mention. In compare mode the lookback's earlier-mention check counts any mention whatever the role, so a first guest appearance on a show that named the subject before is 'returning', not 'new'.
sortNocompare only: 'mentions' (most current-window mention lines first), 'rising' or 'falling' (largest gain or loss from the previous window first), or 'popularity' (biggest shows first). Defaults to popularity with change 'new' or 'returning', else mentions.
limitNocompare only: podcasts per page (1-50, default 10).
changeNocompare only: keep podcasts with this label. 'new': started talking about the subject: two or more mention lines in the window, none in the lookback before it, on a show that published at least four episodes there. Use it for 'which shows started talking about X' or 'mentioned X for the first time'. 'returning': back after a gap in the lookback. 'passing': a single line, a first in the lookback. 'newly_tracked': too little published history to tell (fewer than four episodes in the lookback, which includes a monthly show over the default 90 days: pass lookback_days=180 for those). 'continuing': both windows. 'dropped': the previous window only.
cursorNocompare only: cursor from a previous response. Pass published_after and published_before as that response's window so the page lines up.
intervalNoBucket width. timeseries: defaults to week. compare: adds each podcast's counts per bucket over the current window.
languageNoOnly podcasts in this language: ISO 639-1 code (e.g. 'fr'), matched on the podcast's primary language subtag.
breakdownNotimeseries only: also split each bucket's mentions by their label on this speaker statement characteristics axis: breakdown='sentiment' answers 'is it spoken of more negatively this quarter?'. Each bucket's label shares are of its scored mentions, and a bucket with fewer than 20 is marked low sample. Mention counts are unchanged. Needs published_after, at most 365 days before published_before.
entity_slugNoKnowledge-graph entity slug from particle_entity_resolve for anything that isn't a person or company (e.g. 'germany').
guest_fieldNoOnly mentions spoken by a guest listed under this ANZSRC 2020 field of research: a code, slug or title from particle_expertise_resolve.
include_adsNoCount mentions inside ad reads too. Off by default, so a brand that advertises heavily is measured by what shows say about it, not its own ads.
person_slugNoPerson slug from particle_person_resolve (e.g. 'sam-altman'). One of person_slug, company_slug or entity_slug is required.
company_slugNoCompany slug or domain from particle_company_resolve (e.g. 'nvidia'). Resolves to the company's linked entity.
podcast_slugNotimeseries only: chart the mentions on one podcast (slug from particle_podcast_resolve). In compare mode the rows are the podcasts.
lookback_daysNocompare only: days before published_after a podcast must not have mentioned the subject in to be 'new' (7-180, default 90; never shorter than the previous window).
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 mentions spoken by a guest who knows their field in this capacity (e.g. 'public_official' for politicians). particle_expertise_resolve names the capacity an everyday word means.
guest_in_fieldNoOnly mentions spoken by a guest speaking within their own field (the guest the other guest_ filters select, when given).
guest_standingNoOnly mentions spoken by a guest whose standing is recognized this way: 'established' (conferred by others), 'self_described', or 'unverified'.
publisher_slugNoOnly mentions on podcasts of this publisher (network), by slug.
guest_seniorityNoOnly mentions spoken by a guest at this seniority or above.
published_afterNocompare: start of the current window (ISO 8601 date or date-time); defaults to 7 days before published_before, and the window may span at most 90 days. timeseries: start of the range; omit to chart all time.
guest_occupationNoOnly mentions spoken by 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. 'financial-and-investment-analysts' or 'physicians'). A word with no occupation filters by the field of research or capacity it names: 'investors' is field 350208, 'politicians' is capacity public_official.
guest_practicingNoOnly mentions spoken by a guest who still works in guest_occupation, which must be a SOC 2018 occupation or group.
published_beforeNoEnd of the current window or range: a bare date includes that whole UTC day. Defaults to now.
speaker_statement_characteristicsNotimeseries only: count only mentions said a certain way: {"temporal_orientation": ["future"]} charts predictions about the subject; {"sentiment": ["negative"]} criticism. Labels listed for one axis match any of them; axes combine with AND, so add only the axes the request names. Needs published_after, at most 365 days before published_before.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / breakdown
      Added value: +{
      +  "description": "timeseries only: also split each bucket's mentions by their label on this speaker statement characteristics axis: breakdown='sentiment' answers 'is it spoken of more negatively this quarter?'. Each bucket's label shares are of its scored mentions, and a bucket with fewer than 20 is marked low sample. Mention counts are unchanged. Needs published_after, at most 365 days before published_before.",
      +  "enum": [
      +    "sentiment",
      +    "certainty",
      +    "specificity",
      +    "temporal_orientation"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / speaker_statement_characteristics
      Added value: +{
      +  "description": "timeseries only: count only mentions said a certain way: {\"temporal_orientation\": [\"future\"]} charts predictions about the subject; {\"sentiment\": [\"negative\"]} criticism. Labels listed for one axis match any of them; axes combine with AND, so add only the axes the request names. Needs published_after, at most 365 days before published_before.",
      +  "properties": {
      +    "certainty": {
      +      "description": "How sure the speaker sounds. 'confident' for flat assertions and high conviction; 'hedged' for maybe, I think, it could, and other hedging; 'neutral' for neither.",
      +      "items": {
      +        "enum": [
      +          "hedged",
      +          "neutral",
      +          "confident"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "sentiment": {
      +      "description": "The statement's tone. 'positive' for optimistic, bullish, approving or praising lines; 'negative' for skeptical, bearish, critical or worried ones; 'neutral' for lines that clearly lean neither way.",
      +      "items": {
      +        "enum": [
      +          "negative",
      +          "neutral",
      +          "positive"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "specificity": {
      +      "description": "Whether the line commits to something concrete. 'specific' for names, numbers, dates and mechanisms (concrete claims); 'vague' for generalities; 'neutral' for neither.",
      +      "items": {
      +        "enum": [
      +          "vague",
      +          "neutral",
      +          "specific"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "temporal_orientation": {
      +      "description": "Where the line points in time. 'future' for predictions, forecasts, plans and expectations; 'past' for looking back; 'present' for how things are now.",
      +      "items": {
      +        "enum": [
      +          "past",
      +          "present",
      +          "future"
      +        ],
      +        "type": "string"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed5 schema fields changed
    • changedInput schema / properties / change / description
      Previous value: -"compare only: keep podcasts that are 'new' to the subject (current window only), 'continuing' (both windows) or 'dropped' (previous window only)."New value: +"compare only: keep podcasts with this label. 'new': started talking about the subject: two or more mention lines in the window, none in the lookback before it, on a show that published at least four episodes there. Use it for 'which shows started talking about X' or 'mentioned X for the first time'. 'returning': back after a gap in the lookback. 'passing': a single line, a first in the lookback. 'newly_tracked': too little published history to tell (fewer than four episodes in the lookback, which includes a monthly show over the default 90 days: pass lookback_days=180 for those). 'continuing': both windows. 'dropped': the previous window only."
    • changedInput schema / properties / change / enum
      Previous value: -[
      -  "new",
      -  "continuing",
      -  "dropped"
      -]New value: +[
      +  "new",
      +  "returning",
      +  "passing",
      +  "newly_tracked",
      +  "continuing",
      +  "dropped"
      +]
    • addedInput schema / properties / lookback_days
      Added value: +{
      +  "description": "compare only: days before published_after a podcast must not have mentioned the subject in to be 'new' (7-180, default 90; never shorter than the previous window).",
      +  "maximum": 180,
      +  "minimum": 7,
      +  "type": "integer"
      +}
    • changedInput schema / properties / role / description
      Previous value: -"Constrain how the subject participates: guest, host, panelist, correspondent, or mention."New value: +"Constrain how the subject participates: guest, host, panelist, correspondent, or mention. In compare mode the lookback's earlier-mention check counts any mention whatever the role, so a first guest appearance on a show that named the subject before is 'returning', not 'new'."
    • changedInput schema / properties / sort / description
      Previous value: -"compare only: 'mentions' (default, most current-window mention lines first), 'rising' or 'falling' (largest gain or loss from the previous window first), or 'popularity' (biggest shows first)."New value: +"compare only: 'mentions' (most current-window mention lines first), 'rising' or 'falling' (largest gain or loss from the previous window first), or 'popularity' (biggest shows first). Defaults to popularity with change 'new' or 'returning', else mentions."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive; the description adds substantive behavior beyond them: ad-read mentions excluded unless include_ads, the newest day filling in over ~a day with a partial-marked bucket, low-sample flags under 20 scored mentions, the 365-day cap for breakdown/characteristics modes, and the dated semantic change to 'new'. These are exactly the operational caveats annotations cannot convey.

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 sibling routing before mode detail, and each mode paragraph earns its space. It is unusually long, however, and several label definitions in the compare paragraph repeat what the schema's change/sort descriptions already state, which is the main cost.

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 27-parameter tool with no output schema, the description still conveys return shape (per-podcast rows with counts, deltas, labels, both-window totals; per-bucket series), default behaviors, and prerequisites for each mode. Nothing critical for a correct call 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 baseline is 3; the description goes further by explaining cross-parameter interactions (cursor must be reused with the original published_after/published_before, sort defaults shift with change='new'/'returning', lookback_days never shorter than the previous window, breakdown requires published_after). Much of the 'change' label text mirrors the schema, so it is additive but partly redundant.

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?

Opens with a specific verb+resource ('how a person's, company's or entity's podcast mentions are moving') and immediately names the sibling to use instead for discovery ('particle_podcast_get_entity_chart'). The two-mode breakdown further sharpens what the tool returns, so an agent can distinguish it from every listed sibling without opening schemas.

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?

Explicit when-to-use examples ('which shows talked about Nike this week versus last?'), mode selection criteria, and named alternatives for adjacent jobs (find_mentions for lines, get_episode_timeseries for role/keyword trends, get_share_of_voice for speaker splits, alert_create for ongoing monitoring). Exclusions are stated, not implied.

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