Returns the posts newly discovered (first stored by our crawler) since your last check, across all the profiles you are monitoring. Free to call. Each call advances a per-profile cursor, so a subsequent call only returns posts crawled after it (a feed, not a re-scan). New posts arrive when a profile's scheduled refresh crawl runs, on the cadence set by track_profile. Results are the same flattened post shape as search_outliers (stats, thumbnail, handle). Total posts are capped (limit 1–100, default 50).
A free incremental feed of new posts across every profile you monitor. Each call returns the posts first crawled since your last call, then advances a per-profile cursor, so you get a clean stream of new content rather than re-fetching whole histories and deduping them yourself. It is the read side of track_profile: monitoring keeps profiles fresh, and get_tracked_updates hands you the deltas.
Connect the Viral Outliers MCP server once and the get_tracked_updates tool becomes available to your agent alongside all other skills:
claude mcp add --transport http viral-outliers https://viraloutliers.com/api/mcp \
--header "Authorization: Bearer so_live_YOUR_KEY"In Claude.ai or ChatGPT, add a custom connector pointing at https://viraloutliers.com/api/mcp. Your agent then calls get_tracked_updates on its own whenever the task needs it.
| Name | Type | Description |
|---|---|---|
limit | number | Max posts to return, clamped 1–100 (default 50). |
It returns the posts first stored by our crawler since your last check, across all monitored profiles, in the same flattened post shape as search_outliers (stats, thumbnail, handle, outlier score). Each call advances a per-profile cursor, so the next call returns only posts crawled after this one, a feed, not a re-scan. The total is capped per call (limit 1-100, default 50).
It is free to call. The credits were already spent on the scheduled refresh crawls that discovered the posts (via track_profile); reading the resulting feed costs nothing, so you can poll it as often as your schedule needs.
Updates are keyed on when we first crawled a post, not on the post's original publish date. That is deliberate: the first refresh of a newly tracked profile does not dump its entire back catalogue into your feed as "new". You get genuinely newly discovered posts going forward, which is what makes the feed usable for alerting.
New posts appear when a monitored profile's scheduled refresh runs, on the cadence you set with track_profile, so the freshness of this feed follows directly from your monitoring cadences. Because the cursor advances per profile on each call, two consumers should not both drain the same feed; treat it as a single incremental reader per account.
New-post alerts are the flagship: on a schedule, call get_tracked_updates and, for each new post, notify the user or kick off remix_post to turn it into an adapted idea immediately. Incremental-ingestion pipelines poll the feed and push only the new posts into their own analysis or storage, with no dedup logic needed because the cursor guarantees you never see the same post twice.
It pairs naturally with the rest of the surface: a new outlier surfaced here can flow straight into get_post for a deep-dive, request_transcript for its hook, or remix_post for a niche adaptation.
Doing this without the feed means re-fetching each monitored profile's recent posts every cycle, diffing them against what you saw last time, and maintaining your own per-profile cursor and dedup store, all while paying for each re-fetch. It is easy to either miss posts or reprocess the same ones.
get_tracked_updates collapses that into one free, cursor-backed call across all monitored profiles at once. The dedup and the "what is actually new" logic are handled server-side and keyed on first-crawl time, so you receive a clean, ordered stream of new content and spend your credits only on the monitoring refreshes that produce it, not on the reads.
This skill is free and never spends credits.
Call get_tracked_updates. It returns the posts first seen since your last call across every monitored profile, then advances a cursor so the next call returns only newer posts: a clean incremental feed instead of re-fetching a profile's whole history.
Updates are keyed on when we first crawled a post, not its original publish date, so the first refresh of a profile does not dump its entire back catalogue as "new". You get genuinely newly discovered posts going forward.
Reading get_tracked_updates is free, and no dedup is needed on your side: each call advances a per-profile cursor so you never see the same post twice. You pay only for the scheduled refresh crawls (via track_profile) that discover the posts in the first place, not for pulling the feed.
Also available as a REST API endpoint.
Related topics: incremental content feed API · new post detection · social media change monitoring · new post alerts API · incremental social media ingestion