Skip to main content
Glama

Particle Podcast Find Mentions

particle_podcast_find_mentions
Read-only

Find dialogue lines where a specific person or company is named in podcast transcripts.

Three response modes

format="summary" (default, wide scan). Returns up to limit episodes (reverse-chronological), each with metadata + the first 10 mention-only lines (just the lines naming the entity, no surrounding dialogue). Use this to see what's been said across episodes and decide which episodes are worth reading in full. Paginate older episodes with cursor.

format="detail" (narrow drill-in). Requires episode_slug. Returns the full mention windows with context_lines of surrounding dialogue around each mention. Pass one slug for a single episode, or up to 10 comma-separated slugs (e.g. episode_slug="all-in-200,all-in-201,all-in-202") to multi-get several episodes in one call. limit/cursor don't apply.

format="compact" (screening). The same episodes as summary, each with its mention count, the strings it was mentioned as, and the segments carrying the mentions (id, title, type, first mention time) — no dialogue lines at all, the smallest shape. limit and cursor page it exactly as summary. Use it to fan out over many entities or a long date range and decide where to read; the segment ids are citations, and format="detail" with the episode slug reads the lines.

Workflow

Two patterns, depending on what you already know:

  • No specific episode in mind: call format="summary" first to scan, then call format="detail" with the slug(s) of the episodes worth reading in full. For most questions (sentiment, recurring themes, who said what when), summary alone has enough signal and the second call isn't needed.

  • Already have the episode slug (e.g. user mentioned the episode by name, or you have it from another tool like particle_podcast_get_episode or particle_podcast_search_transcripts): skip summary entirely and call format="detail" with episode_slug directly.

Examples

Wide scan, then drill in: User asks "what has All-In said about OpenAI recently?". Call format="summary", company_slug="openai", podcast_slug="all-in", since="2025-11-01", limit=20. Read the mention lines per episode; if 2-3 episodes have substantive discussion, call format="detail", episode_slug="slug1,slug2,slug3" for full context in one round-trip.

Direct drill-in: User says "In All-In #200 they discuss OpenAI's strategy — pull the full quotes". Call format="detail", episode_slug="all-in-200", company_slug="openai" directly — no summary needed.

Who said it

The guest_ filters keep only the mentions a matching guest spoke: guest_field="banking-finance-and-investment" with guest_standing="established" reads what established finance experts said about a company. When the question names who speaks ("doctors", "economists", "people in finance"), resolve the words with particle_expertise_resolve first and filter by the code; on unresolved_reference, resolve and retry rather than dropping the filter. A word no occupation names may name a capacity instead ("founders", "politicians"): pass it as guest_capacity. Each episode lists its identified speakers with their occupation codes, standing and seniority. For the split of all mentions across occupations or fields use particle_podcast_get_share_of_voice.

When NOT to use this tool

For dialogue that discusses a topic without naming a specific person or company (paraphrase-tolerant search), use particle_podcast_search_transcripts instead — that one ranks segments by relevance to a free-text query.

For how often the subject comes up, or which shows mentioned it this week versus last, use particle_podcast_get_mention_trends instead of paging this tool once per period; its podcast slugs come back here as podcast_slug to read what a show said.

Strongest first

With speaker_statement_characteristics, sort="strength" puts the episodes whose mentions carry the labels most clearly first: the most clearly negative takes on a company, the most confident predictions about a drug. This is the tool for the strongest lines about a subject; particle_podcast_search_transcripts refuses a subject without a topic and sends you here.

Required inputs

One of person_slug, company_slug, or entity_slug is required: person_slug for a person, company_slug for a company, entity_slug for any other knowledge-graph entity (places, organizations, events, concepts). Resolve a name to a slug first with particle_person_resolve, particle_company_resolve, or particle_entity_resolve. Slugs are case-insensitive on input.

How each line is said. Lines in topic and interview segments end with their speaker statement characteristics, pole labels only, e.g. _[positive · confident · future]_: sentiment (negative/positive), certainty (hedged/confident), specificity (vague/specific) and temporal orientation (past/future). A pole label means the line clearly reads that way; _[neutral]_ means it leans clearly on no axis; no brackets means the line was not read (short lines, intros, ad breaks). With output_format=json they are each line's speaker_statement_characteristics object, middle labels included.

Filtering by how a line is said. Pass speaker_statement_characteristics to keep only lines said a certain way: {"sentiment": ["negative"]} for criticism, {"specificity": ["specific"], "temporal_orientation": ["future"]} for concrete predictions, {"certainty": ["confident"], "sentiment": ["positive"], "temporal_orientation": ["future"]} for a high-conviction outlook. Put the topic, never the tone, in semantic_search. Every matched or mention line then carries labels the filter accepts.

Without a topic. On particle_podcast_search_transcripts, the filter alone with episode_slug, speaker or a guest_ filter (no semantic_search or keyword_search) returns the strongest lines said that way, at most 50, strongest first: an episode's boldest predictions, or a person's most confident claims. Their Match row reads characteristics. For the strongest lines naming a person, company or entity, pass the filter with sort: "strength" on particle_podcast_find_mentions instead.

Input Schema

NameRequiredDescriptionDefault
roleNoConstrain how the entity participates: guest, host, panelist, correspondent, or mention.
sortNoEpisode order. 'recency' (default) is newest first. 'strength' requires speaker_statement_characteristics and puts the episodes whose mentions carry those labels most clearly first (the most clearly negative takes, the most confident predictions), each episode's mentions strongest first. Pass the same sort with a cursor.
limitNoEpisodes per page (1-50, default 10). Summary and compact modes — detail returns one episode regardless.
sinceNoOnly episodes published on or after this ISO 8601 date (e.g. 2025-01-01).
untilNoOnly episodes published on or before this ISO 8601 date.
cursorNoOpaque pagination cursor from a previous summary or compact response's cursor field. Summary and compact modes.
formatNoResponse shape. 'summary' (default) returns many episodes (reverse chron) with metadata plus the first few mention-only lines per episode — use this to scan and pick episodes to drill into. 'detail' requires episode_slug and returns one episode's full mention windows with surrounding dialogue context. 'compact' returns the same episodes as summary with the mention count and the segments carrying the mentions (id, title, type, first mention time) and no dialogue — the smallest shape, for screening many entities before reading any.
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 mentions spoken by a guest listed under this ANZSRC 2020 field of research: a code, slug or title from particle_expertise_resolve.
person_slugNoPerson slug or encoded person ID from particle_person_resolve, particle_entity_resolve, or the guest tools (e.g. 'sam-altman'). One of person_slug, company_slug, or entity_slug is required.
company_slugNoCompany slug, domain, or canonical ID (e.g. 'nvidia' or 'nvidia.com'). Resolves to the company's linked entity.
episode_slugNoEpisode slug(s) or canonical ID(s). For format='detail', required: pass one slug for a single drill-in or up to 10 comma-separated slugs (e.g. 'all-in-200,all-in-201,all-in-202') for a multi-episode drill-in in one call. For format='summary' or 'compact', optional filter to one episode.
podcast_slugNoRestrict mentions to a single podcast by slug, internal ID, or numeric iTunes ID. A particle.pro or Radar show link also works.
context_linesNoSurrounding dialogue lines around each mention (1-20, default 2). Detail mode only — ignored in summary and compact.
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'.
guest_seniorityNoOnly mentions spoken by a guest at this seniority or above.
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.
speaker_statement_characteristicsNoKeep only mentions said a certain way. This tool takes no topic text: the subject is person_slug, company_slug or entity_slug, and HOW it is spoken of goes here: criticism, skepticism or bearish takes → sentiment negative; praise, optimism or bullish takes → sentiment positive; predictions or forecasts → temporal_orientation future (add specificity specific for concrete predictions); high conviction → certainty confident; hedging → certainty hedged; concrete claims → specificity specific. Who speaks goes in the guest_ filters. Labels listed for one axis match any of them; axes combine with AND, so add only the axes the request names. Every mention line carries labels the filter accepts. Needs a subject with a knowledge graph entity: one matched only by name is refused. Example, criticism of the subject: {"sentiment": ["negative"]}. To narrow to a topic as well, call particle_podcast_search_transcripts with the subject's company_slug or entity_slug, the topic in semantic_search, and this filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "Episode order. 'recency' (default) is newest first. 'strength' requires speaker_statement_characteristics and puts the episodes whose mentions carry those labels most clearly first (the most clearly negative takes, the most confident predictions), each episode's mentions strongest first. Pass the same sort with a cursor.",
      +  "enum": [
      +    "recency",
      +    "strength"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / speaker_statement_characteristics
      Added value: +{
      +  "description": "Keep only mentions said a certain way. This tool takes no topic text: the subject is person_slug, company_slug or entity_slug, and HOW it is spoken of goes here: criticism, skepticism or bearish takes → sentiment negative; praise, optimism or bullish takes → sentiment positive; predictions or forecasts → temporal_orientation future (add specificity specific for concrete predictions); high conviction → certainty confident; hedging → certainty hedged; concrete claims → specificity specific. Who speaks goes in the guest_ filters. Labels listed for one axis match any of them; axes combine with AND, so add only the axes the request names. Every mention line carries labels the filter accepts. Needs a subject with a knowledge graph entity: one matched only by name is refused. Example, criticism of the subject: {\"sentiment\": [\"negative\"]}. To narrow to a topic as well, call particle_podcast_search_transcripts with the subject's company_slug or entity_slug, the topic in semantic_search, and this filter.",
      +  "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. Changed3 schema fields changed
    • addedInput schema / properties / guest_capacity
      Added value: +{
      +  "description": "Only 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.",
      +  "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 mentions spoken by a guest listed under this occupation: a SOC 2018 or ISCO-08 code, slug or title from particle_expertise_resolve (e.g. 'financial-and-investment-analysts')."New value: +"Only 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."
    • changedInput schema / properties / guest_practicing / description
      Previous value: -"Only mentions spoken by a guest who still works in guest_occupation, which must be a detailed SOC 2018 occupation."New value: +"Only mentions spoken by a guest who still works in guest_occupation, which must be a SOC 2018 occupation or group."
  3. Changed6 schema fields changed
    • addedInput schema / properties / guest_field
      Added value: +{
      +  "description": "Only mentions spoken by a guest listed under this ANZSRC 2020 field of research: a code, slug or title from particle_expertise_resolve.",
      +  "type": "string"
      +}
    • addedInput schema / properties / guest_in_field
      Added value: +{
      +  "description": "Only mentions spoken by 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 mentions spoken by a guest listed under this occupation: a SOC 2018 or ISCO-08 code, slug or title from particle_expertise_resolve (e.g. 'financial-and-investment-analysts').",
      +  "type": "string"
      +}
    • addedInput schema / properties / guest_practicing
      Added value: +{
      +  "description": "Only mentions spoken by a guest who still works in guest_occupation, which must be a detailed SOC 2018 occupation.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / guest_seniority
      Added value: +{
      +  "description": "Only mentions spoken by a guest at this seniority or above.",
      +  "enum": [
      +    "professional",
      +    "senior",
      +    "distinguished"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / guest_standing
      Added value: +{
      +  "description": "Only mentions spoken by a guest whose standing is recognized this way: 'established' (conferred by others), 'self_described', or 'unverified'.",
      +  "enum": [
      +    "established",
      +    "self_described",
      +    "unverified"
      +  ],
      +  "type": "string"
      +}
  4. Changed6 schema fields changed
    • changedInput schema / properties / context_lines / description
      Previous value: -"Surrounding dialogue lines around each mention (1-20, default 2). Detail mode only — ignored in summary."New value: +"Surrounding dialogue lines around each mention (1-20, default 2). Detail mode only — ignored in summary and compact."
    • changedInput schema / properties / cursor / description
      Previous value: -"Opaque pagination cursor from a previous summary response's cursor field. Summary mode only."New value: +"Opaque pagination cursor from a previous summary or compact response's cursor field. Summary and compact modes."
    • changedInput schema / properties / episode_slug / description
      Previous value: -"Episode slug(s) or canonical ID(s). For format='detail', required: pass one slug for a single drill-in or up to 10 comma-separated slugs (e.g. 'all-in-200,all-in-201,all-in-202') for a multi-episode drill-in in one call. For format='summary', optional filter to one episode. A particle.pro or Radar episode link also works."New value: +"Episode slug(s) or canonical ID(s). For format='detail', required: pass one slug for a single drill-in or up to 10 comma-separated slugs (e.g. 'all-in-200,all-in-201,all-in-202') for a multi-episode drill-in in one call. For format='summary' or 'compact', optional filter to one episode."
    • changedInput schema / properties / format / description
      Previous value: -"Response shape. 'summary' (default) returns many episodes (reverse chron) with metadata plus the first few mention-only lines per episode — use this to scan and pick episodes to drill into. 'detail' requires episode_slug and returns one episode's full mention windows with surrounding dialogue context."New value: +"Response shape. 'summary' (default) returns many episodes (reverse chron) with metadata plus the first few mention-only lines per episode — use this to scan and pick episodes to drill into. 'detail' requires episode_slug and returns one episode's full mention windows with surrounding dialogue context. 'compact' returns the same episodes as summary with the mention count and the segments carrying the mentions (id, title, type, first mention time) and no dialogue — the smallest shape, for screening many entities before reading any."
    • changedInput schema / properties / format / enum
      Previous value: -[
      -  "summary",
      -  "detail"
      -]New value: +[
      +  "summary",
      +  "detail",
      +  "compact"
      +]
    • changedInput schema / properties / limit / description
      Previous value: -"Episodes per page (1-50, default 10). Summary mode only — detail returns one episode regardless."New value: +"Episodes per page (1-50, default 10). Summary and compact modes — detail returns one episode regardless."
  5. Changed2 schema fields changed
    • changedInput schema / properties / episode_slug / description
      Previous value: -"Episode slug(s) or canonical ID(s). For format='detail', required: pass one slug for a single drill-in or up to 10 comma-separated slugs (e.g. 'all-in-200,all-in-201,all-in-202') for a multi-episode drill-in in one call. For format='summary', optional filter to one episode."New value: +"Episode slug(s) or canonical ID(s). For format='detail', required: pass one slug for a single drill-in or up to 10 comma-separated slugs (e.g. 'all-in-200,all-in-201,all-in-202') for a multi-episode drill-in in one call. For format='summary', optional filter to one episode. A particle.pro or Radar episode link also works."
    • changedInput schema / properties / podcast_slug / description
      Previous value: -"Restrict mentions to a single podcast by slug, internal ID, or numeric iTunes ID."New value: +"Restrict mentions to a single podcast by slug, internal ID, or numeric iTunes ID. A particle.pro or Radar show link also works."
  6. First observed

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real behavioral detail absent from annotations: pagination by cursor, per-mode scoping, how mention lines are labeled with poles, what happens on unresolved_reference, and that a name-only match is refused. However, roughly a fifth of the text drifts into describing how a sibling tool (search_transcripts) behaves rather than this tool, which dilutes rather than informs this tool's behavior.

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

Conciseness3/5

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

The purpose and mode selection are correctly front-loaded under clear headers, and the three-mode framing is a useful spine. But the definition is long and partly redundant, and the closing "Without a topic" section is largely an essay about particle_podcast_search_transcripts rather than this tool — content that does not earn its place in this definition.

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 23-parameter, nested-object, no-output-schema tool, the description covers everything an agent needs to call it correctly: how to resolve slugs, how the modes differ, how to build the characteristics filter, how guest filters combine, and how to page. Nothing material is left to inference.

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 schema already documents each of the 23 parameters, and the baseline would be 3. The description still earns above baseline by explaining cross-parameter interactions the schema only states tersely: which mode makes episode_slug required, which modes honor limit/cursor/context_lines, that sort="strength" is only valid with speaker_statement_characteristics, and the resolve-first workflow for slugs and guest filters.

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 opening line states a specific verb+resource+scope: "Find dialogue lines where a specific person or company is named in podcast transcripts." It is immediately distinguishable from the siblings that also touch transcripts (search_transcripts for topic discussion, get_mention_trends for frequency), and those distinctions are made explicitly later.

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 guidance is given for all three modes, plus two worked workflow patterns keyed to what the agent already knows (slug in hand vs. wide scan). A dedicated "When NOT to use this tool" section names the two alternatives and the conditions that route to them, so the choice between find_mentions, search_transcripts and get_mention_trends is unambiguous.

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