Skip to main content
Glama

Particle Podcast Get Share Of Voice

particle_podcast_get_share_of_voice
Read-only

Split a person's, company's or entity's podcast mentions by who said them: the speakers' occupations (SOC 2018) or fields of research (ANZSRC 2020). Answers "who is talking about NVIDIA — investors, engineers, journalists?" in one call: each group's mention lines, share, distinct speakers and episodes over a window (default the last 30 days, at most 365), optionally bucketed by day, week or month. By default it counts guests' and panelists' lines at the detailed level (Chief Executives, Financial Analysts, Dietitians), each with the top-level group it sits under. speakers="all" adds hosts, who speak most mention lines and mostly code to media; level="major" gives SOC major groups or ANZSRC divisions only; podcast_slug or publisher_slug narrows to one show or network.

keyword_search splits the lines that say a word or quoted phrase instead of an entity's mentions (who talks about prior authorization?), counting a line only when its own speaker said every word in it. Its window is at most 90 days, and a word said in too many episodes is refused with a way to narrow it. This is the per-speaker answer that particle_podcast_get_episode_timeseries with keyword_search and guest_occupation cannot give: that counts matching segments in episodes with such a guest, whoever spoke them.

Shares are of the mentions spoken by someone with an expertise read, and a person listed under several codes counts in each, so shares can sum past 100%.

HOW the subject is spoken of splits the same mentions by speaker statement characteristics: by="sentiment" (or certainty, specificity, temporal_orientation) gives one group per label, breakdown splits each occupation's lines by an axis's labels (how investors vs engineers speak of NVIDIA), and speaker_statement_characteristics counts only lines said a certain way (who makes predictions about it). Label shares are of the scored mentions, the lines that carry labels; a group with fewer than 20 is marked low sample, so read it as examples. examples (1-3) quotes the lines that most clearly carry each group's or label's label, with speaker, episode and moment link. Entities and companies only, not keyword_search. To set two to five subjects' label shares side by side (NVIDIA vs AMD vs Intel), use particle_podcast_compare_share_of_voice.

Each group's code is a guest_occupation (or guest_field) value: pass it to particle_podcast_find_mentions with the same entity to read what that group said. For a keyword, particle_podcast_search_transcripts with the same keyword_search finds candidate passages: its guest filters keep segments with such a guest, so check each matching line's speaker, and host lines are not reached that way. Not for the mention lines themselves (particle_podcast_find_mentions) or for a brand's mention volume over time and the shows carrying it (particle_podcast_get_mention_trends).

Input Schema

NameRequiredDescriptionDefault
byNoGroup the speakers by 'occupation' (SOC 2018, default) or 'field' (ANZSRC 2020 fields of research), or group the counted lines by HOW they were said: 'sentiment', 'certainty', 'specificity' or 'temporal_orientation' gives one group per label (how negatively or positively NVIDIA is spoken of is by='sentiment'). Not with keyword_search.
levelNoGroup level: 'detailed' (default; detailed occupations or ANZSRC groups, each with the top-level group it sits under) or 'major' (SOC major groups or ANZSRC divisions only).
limitNoGroups to return, most mentioned first (1-50, default 10).
examplesNoAlso quote up to this many lines (0-3, default 0) for each group, or with breakdown for each of its labels: the quote, who said it, the episode and a timestamp linked to the moment. Strongest first: the lines that most clearly carry the label or read the way speaker_statement_characteristics asks; with neither, the newest. At most one per episode, from different speakers where it can. Not with keyword_search.
intervalNoAdd each group's mentions per day, week or month.
speakersNoWhose lines count: 'guests' (default; guests and panelists) or 'all' (hosts included). Hosts speak most mention lines and their own occupations dominate an 'all' split, so pass 'all' only when the hosts' voice is the question.
breakdownNoAlso split each group's lines by their label on this axis: by='occupation' with breakdown='sentiment' is how each occupation spoke of the subject. A group's breakdown shares are of its scored mentions, and a group with fewer than 20 is marked low sample. Must differ from by. Not with keyword_search.
entity_slugNoKnowledge-graph entity slug from particle_entity_resolve for anything that isn't a person or company (e.g. 'germany').
include_adsNoCount mentions inside ad reads too. Off by default: ad copy is not a speaker's voice.
person_slugNoPerson slug from particle_person_resolve (e.g. 'sam-altman'). One of person_slug, company_slug, entity_slug or keyword_search is required.
company_slugNoCompany slug or domain from particle_company_resolve (e.g. 'nvidia'). Resolves to the company's linked entity.
podcast_slugNoOnly mentions inside this podcast (slug from particle_podcast_resolve).
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.
keyword_searchNoSplit the lines that say these words instead of an entity's mentions: every word in one line, case-insensitive; wrap words in double quotes to require them adjacent and in order. Words count as spoken, so a word with two meanings counts both. Window at most 90 days.
publisher_slugNoOnly mentions on podcasts of this publisher (network), by slug.
published_afterNoOnly episodes published on or after this date (YYYY-MM-DD). Defaults to 30 days before published_before; the window may span at most 365 days for an entity and 90 for a keyword.
published_beforeNoOnly episodes published on or before this date (YYYY-MM-DD). Defaults to now.
speaker_statement_characteristicsNoCount only mentions said a certain way: {"temporal_orientation": ["future"]} splits who makes predictions about the subject; {"sentiment": ["negative"]} who criticizes it. Labels listed for one axis match any of them; axes combine with AND, so add only the axes the request names. Not with keyword_search.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • addedInput schema / properties / breakdown
      Added value: +{
      +  "description": "Also split each group's lines by their label on this axis: by='occupation' with breakdown='sentiment' is how each occupation spoke of the subject. A group's breakdown shares are of its scored mentions, and a group with fewer than 20 is marked low sample. Must differ from by. Not with keyword_search.",
      +  "enum": [
      +    "sentiment",
      +    "certainty",
      +    "specificity",
      +    "temporal_orientation"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / by / description
      Previous value: -"Group the speakers by 'occupation' (SOC 2018, default) or 'field' (ANZSRC 2020 fields of research)."New value: +"Group the speakers by 'occupation' (SOC 2018, default) or 'field' (ANZSRC 2020 fields of research), or group the counted lines by HOW they were said: 'sentiment', 'certainty', 'specificity' or 'temporal_orientation' gives one group per label (how negatively or positively NVIDIA is spoken of is by='sentiment'). Not with keyword_search."
    • changedInput schema / properties / by / enum
      Previous value: -[
      -  "occupation",
      -  "field"
      -]New value: +[
      +  "occupation",
      +  "field",
      +  "sentiment",
      +  "certainty",
      +  "specificity",
      +  "temporal_orientation"
      +]
    • addedInput schema / properties / examples
      Added value: +{
      +  "description": "Also quote up to this many lines (0-3, default 0) for each group, or with breakdown for each of its labels: the quote, who said it, the episode and a timestamp linked to the moment. Strongest first: the lines that most clearly carry the label or read the way speaker_statement_characteristics asks; with neither, the newest. At most one per episode, from different speakers where it can. Not with keyword_search.",
      +  "maximum": 3,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedInput schema / properties / level / description
      Previous value: -"Group level: 'major' (default; SOC major groups or ANZSRC divisions) or 'detailed' (detailed occupations or ANZSRC groups)."New value: +"Group level: 'detailed' (default; detailed occupations or ANZSRC groups, each with the top-level group it sits under) or 'major' (SOC major groups or ANZSRC divisions only)."
    • changedInput schema / properties / level / enum
      Previous value: -[
      -  "major",
      -  "detailed"
      -]New value: +[
      +  "detailed",
      +  "major"
      +]
    • addedInput schema / properties / speaker_statement_characteristics
      Added value: +{
      +  "description": "Count only mentions said a certain way: {\"temporal_orientation\": [\"future\"]} splits who makes predictions about the subject; {\"sentiment\": [\"negative\"]} who criticizes it. Labels listed for one axis match any of them; axes combine with AND, so add only the axes the request names. Not with keyword_search.",
      +  "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"
      +}
    • changedInput schema / properties / speakers / description
      Previous value: -"Whose lines count: 'all' (default, hosts included) or 'guests' (guests and panelists only)."New value: +"Whose lines count: 'guests' (default; guests and panelists) or 'all' (hosts included). Hosts speak most mention lines and their own occupations dominate an 'all' split, so pass 'all' only when the hosts' voice is the question."
    • changedInput schema / properties / speakers / enum
      Previous value: -[
      -  "all",
      -  "guests"
      -]New value: +[
      +  "guests",
      +  "all"
      +]
  2. Changed3 schema fields changed
    • addedInput schema / properties / keyword_search
      Added value: +{
      +  "description": "Split the lines that say these words instead of an entity's mentions: every word in one line, case-insensitive; wrap words in double quotes to require them adjacent and in order. Words count as spoken, so a word with two meanings counts both. Window at most 90 days.",
      +  "maxLength": 500,
      +  "type": "string"
      +}
    • changedInput schema / properties / person_slug / description
      Previous value: -"Person slug from particle_person_resolve (e.g. 'sam-altman'). One of person_slug, company_slug or entity_slug is required."New value: +"Person slug from particle_person_resolve (e.g. 'sam-altman'). One of person_slug, company_slug, entity_slug or keyword_search is required."
    • changedInput schema / properties / published_after / description
      Previous value: -"Only episodes published on or after this date (YYYY-MM-DD). Defaults to 30 days before published_before; the window may span at most 365 days."New value: +"Only episodes published on or after this date (YYYY-MM-DD). Defaults to 30 days before published_before; the window may span at most 365 days for an entity and 90 for a keyword."
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the read-only/safe profile, and the description goes far beyond them: shares can sum past 100% because a person counted under several codes appears in each, groups under 20 are flagged low sample, hosts 'mostly code to media', keyword queries can be refused when a word is too common, and window limits (30 default / 365 entity / 90 keyword) are disclosed. These are the non-obvious behaviors an agent must anticipate before calling.

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 the canonical example question, and each paragraph owns one mode (entity split, keyword split, HOW-they-speak split, chaining/alternatives). It is long and occasionally re-explains what enum descriptions already say (keyword window, examples ordering), which keeps it short of a 5 for an 18-parameter tool.

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 18 parameters, a nested object and no output schema, the description carries the return-shape burden itself: grouped mention lines, share, distinct speakers and episode counts, optional interval buckets, and example quotes with speaker/episode/moment link. Between the body and the complete schema, an agent has everything needed to call correctly and interpret output.

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 carries per-parameter documentation and enum meanings. The description still adds cross-parameter meaning the schema does not: which modes are mutually exclusive (keyword_search vs by/examples/breakdown/speaker_statement_characteristics), how breakdown interacts with by ('must differ'), and the practical consequence of speakers='all'. Some of it (level='major', window defaults) is repetition of schema text.

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 and resource: 'Split a person's, company's or entity's podcast mentions by who said them', then names the exact axes (SOC 2018, ANZSRC 2020) and the question it answers. It is immediately distinguishable from find_mentions (raw lines), get_mention_trends (volume over time) and compare_share_of_voice (multi-subject), which are all named.

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 routing: use compare_share_of_voice for two-to-five subjects side by side, find_mentions with the resulting guest_occupation code to read what a group said, search_transcripts for keyword passages, and an explicit 'Not for' clause pointing at find_mentions and get_mention_trends. Preconditions such as the 90-day keyword window and the exclusion of keyword_search from the statement-characteristic modes are stated inline.

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