Twosion MCP

Get the most recently generated daily briefing for the current account.

Twosion generates at most one briefing at a time; there is no history and no way to request a specific past date -- this always returns the latest one. Use `detail="executive"` for a fast headline-and-sentiment digest, or the default `detail="full"` for per-watchlist-term themes, tone, top stories, findings, and recommendations.

Example: "What's today's briefing?" or "give me a quick digest" -> detail="executive". "Give me the full briefing with recommendations" -> omit detail, or pass detail="full" explicitly.

Use watchlist_get_term_summaries instead when the user only wants one or a few specific watch terms rather than the whole account. Raises an error if no briefing has been generated yet for this account.

Aggregate mention counts, audience, demographics and geography for a topic -- not individual matches.

Use this when the user wants a total, a trend, or a demographic breakdown ("how much coverage", "gender/age split") rather than a list of items -- use coverage_search_mentions for that. Same query, matchMode, exclude, date range, and filter semantics as coverage_search_mentions (filter values come from coverage_search_options; never guess one). All filters must match; values within one filter match any.

Use queryString (instead of query) when recall matters: expand the topic into OR'd synonyms, abbreviations and spelling variants, e.g. (Tesla OR "Model Y") AND (recall OR retira OR NHTSA). Transcripts are speech-to-text, so exact long phrases often miss -- prefer "short phrase"~5. If a queryString returns nothing, broaden it (the response carries a hint) rather than reporting "no coverage".

Set watchlistId to analyze one watchlist's own query -- query becomes optional and, when given, narrows it. Get the id from watchlist_get_summary; never guess one.

Returns: - mentions: total, per-content-type counts, daily series. - demographics.tv: male share and age brackets. demographics.podcast: male share, median age/income, age brackets, and affinity lists (countries, cities, interests, brands, ...) whose `score` is an average across podcasts, NOT a share -- don't present as percent. - audience: TV/radio impressions and ad value (local/national), podcast/YouTube impressions, daily series. These are summed per clip -- cumulative impressions, not unique people; say so. - geography: top countries/markets by hits. Countries overlap with their markets, so don't add hits across rows. Sections with no data are omitted.

Example: "How much TV coverage did our Tesla recall get, and what's the audience skew?" -> query="Tesla recall".

Get an AI-synthesized narrative, sentiment, and trend analysis for a topic.

This is an expensive, always-live LLM analysis -- it re-embeds and re-clusters matching documents on every call, with no caching. Prefer a cheaper tool first: use coverage_search_mentions when the user wants a list of actual matching clips, not a synthesis. For one watch term, use watchlist_get_term_summaries first -- it reuses a cached briefing summary when fresh; escalate to this tool only when the user explicitly wants tone, sentiment, or trend detail the cheap tool doesn't return. To compare several watchlists against each other (share of voice, overlap, velocity), use coverage_compare_queries instead.

Example: "What's the story/sentiment around Tesla pricing?" (ad hoc) -> query="Tesla pricing". Example: "What's the sentiment on my Tesla watchlist?" (known watch term, deep dive) -> watchlistId="<id from watchlist_get_summary>"; never guess a watchlistId.

Returns rule-based key findings (statements), a tone/sentiment breakdown, country facets, a daily trend, and sample matching stories -- each with its own tone, audience, and the ids of clips it groups as duplicates. Pass a story's memberIds to coverage_get_story to list every clip in it.

Compare 2 or more watchlists against each other over the same date range.

Use this instead of calling coverage_analyze_stories once per watchlist when the user wants a side-by-side comparison, not each watchlist's own analysis -- "which of my watchlists is trending" or "how much overlap is there between X and Y" need this tool, not several separate calls.

Returns, per watchlist: share of voice (hit count and audience, as a percentage of the combined total across all given watchlists) and velocity (spiking/rising/stable/declining/new); per watchlist pair: overlap (shared coverage and lift over chance); and week-over-week change across the combined set. Does not include each watchlist's own findings/tone/trend -- call coverage_analyze_stories(watchlistId=...) per watchlist for that depth.

Example: "Is Tesla or Rivian getting more coverage this month?" -> watchlistIds=["<Tesla id>", "<Rivian id>"]; get both ids from watchlist_get_summary first, never guess them.

Get the full transcript and detail for one media item already found via coverage_search_mentions.

Use this after coverage_search_mentions to read the complete transcript for one specific hit -- the search tool only returns short matching excerpts (snippets), not the full text. Pass the eventId exactly as coverage_search_mentions returned it; never guess or fabricate one.

Example: user asks "show me the full transcript for that first result" -> call this tool with eventId="<id from the earlier search response>".

List every clip in one story from coverage_analyze_stories.

A story groups duplicate coverage of the same segment across stations; coverage_analyze_stories returns only its lead clip plus memberIds. Pass those memberIds here to see each clip -- station, market, air time, viewership, and excerpts -- in the same shape coverage_search_mentions returns, highest viewership first.

missingClipIds lists ids that didn't come back (usually older than the user's retention window); report them rather than guessing.

Example: "Which stations ran that second story?" -> clipIds=<that story's memberIds>.

Search the user's authorized media coverage using ordinary words or phrases.

Use this for ad hoc topics, especially when the topic is not already in the user's watchlists. Choose whether all words, any word, or the complete phrase must match; exclude unwanted terms; set an inclusive date range; sort by recency or PowerSearch viewership; group duplicate coverage; and request up to 50 matches.

Example: "Show me recent coverage about Tesla pricing" -> query="Tesla pricing". Example: "Find the exact phrase 'artificial intelligence', not crypto" -> query="artificial intelligence", matchMode="phrase", exclude=["crypto"].

Use queryString (instead of query) when recall matters: expand the topic into OR'd synonyms, abbreviations and spelling variants, e.g. (Tesla OR "Model Y") AND (recall OR retira OR NHTSA). Transcripts are speech-to-text, so exact long phrases often miss -- prefer "short phrase"~5. If a queryString returns nothing, broaden it (the response carries a hint) rather than reporting "no coverage".

Set watchlistId to search within one watchlist's own query instead of all coverage -- query becomes optional in that case (an empty query returns everything the watchlist already matches). Get the id from watchlist_get_summary; never guess one.

Narrow further with stations, markets, countries, states, mediaTypes, programs, languages, or channels (podcast/YouTube source ids). Every filter given must match; values within one filter match any. channels can't be combined with the TV/radio-only filters (stations, markets, states, programs) -- make separate calls. These fields need the exact value coverage_search_options returns, not a free-text name -- never guess a filter value; look it up first (e.g. category="stations", query="CNN").

Results include stable event IDs, source details, dates, viewership when available, and short matching excerpts. Pass `nextCursor` back as `cursor` to continue the same search. Do not modify or reuse a cursor with different search criteria. This tool returns individual matches, not daily trends or aggregate statistics -- use coverage_analyze_stories instead when the user wants a synthesized narrative, sentiment, or trend answer rather than a list of items (same query or watchlistId scoping, different question shape). Example: "show me articles about Tesla" -> this tool; "what's the sentiment on Tesla coverage?" -> coverage_analyze_stories.

Examples

An exact phrase, newest first. Prefer phrase over the default all for multi-word topics: all matches each word independently, so “Tesla pricing” also returns segments about rate hikes being “priced in” that mention Tesla elsewhere.

{
  "query": "Tesla pricing",
  "matchMode": "phrase",
  "limit": 10
}

A fixed window. Both dates are inclusive, and the default window is only the last few days — widen it before concluding a topic has no coverage.

{
  "query": "price cut",
  "matchMode": "phrase",
  "startDate": "2026-08-18",
  "endDate": "2026-09-17"
}

Biggest audience first, with advertising read-outs filtered out. exclude drops matches containing any of these terms.

{
  "query": "electric vehicle",
  "matchMode": "all",
  "exclude": [
    "insurance",
    "sponsored"
  ],
  "sort": "highest_viewership",
  "limit": 25
}

The next page. Pass back the nextCursor from the previous response and repeat every other argument unchanged — a cursor is only valid for the search that produced it.

{
  "query": "Tesla pricing",
  "matchMode": "phrase",
  "cursor": "UzE3ODk1Nzc0NzUwMzA="
}

Resolve a human-readable name into the filter values coverage_search_mentions accepts.

Use this before calling coverage_search_mentions with stations, markets, countries, states, mediaTypes, programs, languages, or channels (use category="podcasts" for a podcast channel) -- those fields need the exact `value` this tool returns, not a free-text name; never guess a value instead of looking it up. Each result also carries a display `name` so you can confirm the right match before filtering.

Example: user asks for "Tesla coverage from CNN in Texas" -- call this tool twice, once with category="stations", query="CNN" and once with category="states", query="Texas", then pass the returned values into coverage_search_mentions's stations and states fields.

List the current user's reports, newest first.

A report is a saved, curated set of clips. Use this to find a report's id when the user refers to one by name ("my Q3 Tesla report"); never guess a report id. Returns id, title, description, creation time, status, type, clip count, and whether it is shared.

Saved queries (watchlists) are not reports -- list those with watchlist_get_summary.

Health-check tool: echoes the given message back. Replace with real tools.

Examples

Confirms the session and token are working.

{
  "message": "hello"
}

Find which watch terms are trending up or down across the whole account, ranked by mention-volume change between two equal-length windows (the last `windowDays` vs. the `windowDays` before that).

Use this for "what's spiking," "what's trending," or "what moved this week" questions about the account as a whole. This is different from watchlist_get_term_summaries, which gives a narrative/thematic summary of one specific term you already know you care about -- use this tool first to discover *which* terms are worth a closer look, then pass the returned id into watchlist_get_term_summaries(queryIds=[...]), coverage_search_mentions(watchlistId=...), or coverage_analyze_stories(watchlistId=...) for detail on any one of them.

Example: user asks "what's trending in my watchlists this week?" -- call this tool with windowDays=7 (the default), then look at the risers list.

Each entry's `dailySeries` gives a day-by-day hit count for that term across the comparison window, useful for describing the shape of a spike.

Get an overview of the current user's watchlists.

Call this first when the user references "my watchlists" or a saved topic by name -- it resolves a title like "Tesla" into the id that coverage_search_mentions (watchlistId), watchlist_get_term_summaries, and briefing_get_latest all key off. Shows how watchlists are organized into groups and standalone queries, review aggregate counts, and see which watchlists have configured alerts. The response preserves empty groups and duplicate titles -- when a watchlist ID is present, use it instead of the title to identify that watchlist reliably in follow-up workflows, since titles can repeat.

Example: user asks "what's new with my Tesla watchlist?" -- call this tool with no arguments, find the entry titled "Tesla", and use its id in the next call.

This summary does not include media-match counts, trends, query definitions, alert destinations, or alert schedules -- use watchlist_get_term_summaries for match counts and AI-generated themes, or briefing_get_latest for a full daily digest across every watchlist.

Takes no arguments.

Examples

Takes no arguments; the watchlists are the caller's own.

{}

Get AI-generated summaries of the account's watch terms: themes, dominant tone, notability, top stories and stations, and overlap with other terms.

Use this for "what's going on with this watchlist" or "summarize my X watchlist" questions about one or a few specific terms. Get term ids from watchlist_get_summary first -- never guess or fabricate a queryId; an unrecognized or unowned id is silently dropped rather than erroring, so a guessed id just produces a thinner result you could mistake for "no coverage." Omit queryIds to get every watch term in the account at once.

Example: user asks "how's my Tesla watchlist doing?" -- call watchlist_get_summary to find the Tesla term's id, then call this tool with queryIds set to that one id.

Works even when no daily briefing has ever been generated -- falls back to a live-computed summary in that case, though theme/tone/notability fields stay at their defaults until a briefing exists. Use briefing_get_latest instead for a full-account daily digest with sentiment, findings, and recommendations across every term together. If this summary isn't rich enough -- the user wants deeper tone/sentiment/trend analysis for just this one term -- escalate to coverage_analyze_stories(watchlistId=...); that tool is more expensive (always-live, no caching) so prefer this one first.