Ranked Reply Targeting
Define a saved Hunt from your AI assistant and pull a ranked list of the X reply targets actually worth your time — scored by reach, velocity, freshness and author fit, with bots, auto-summaries and already-replied tweets filtered out.
The X API can't post replies — that's why replies fire from the browser. But finding which tweets to reply to has always been a manual chore: a keyword search returns fifteen hits that collapse to the four worth answering, mostly after you scroll past Grok auto-summaries and dead zero-impression posts. Ranked Reply Targeting moves that filtering into the platform. You define a Hunt once, and your AI assistant returns reply targets in ranked order instead of a raw dump.
How it works
The work splits along the constraint. The platform defines and ranks; the browser consumes and fires.
- Hunts are persistent, per-site targeting definitions. A Hunt pairs a set of search keywords and optional author allow/deny filters with a semantic
target_brief(what you're looking for) andreply_intent(what you want to say), and can bind brain and post context for grounded reply drafts. - Ranking scores every search hit so you see targets, not noise. Scoring is a fast, deterministic heuristic — no per-tweet AI cost — built from four signals plus a set of exclusion gates.
- Reading happens from anywhere. The ranked targets are available read-only to your AI assistant (Claude or any MCP client), so you can triage from chat as well as from the browser.
- In the Chrome extension, a 🎯 launcher on X opens a panel: pick a saved Hunt and the same ranked targets appear in a list with their score and reason. Open any target to reply with the extension's per-tweet panel — firing stays a manual, per-reply action.
The value score
Each target carries a value_score from 0–100, combined from:
| Signal | What it measures | |---|---| | Reach | Amplification so far — weighted engagement (replies and reposts count more than likes), or impressions when available | | Velocity | Engagement per hour since posting — surfaces threads that are heating up so you can reply early | | Freshness | The early-reply slot — newer tweets rank higher, decaying over roughly a day | | Author fit | Whether the author and post look worth replying to — real account, substantive text, an open question |
What gets filtered out
Before scoring, targets are dropped (with a reason) when they are:
- Already replied to — deduped against your reply history so the same tweet never resurfaces.
- Bots or auto-summaries — Grok and common summary/thread bots are excluded by default, plus any handles in a Hunt's deny list.
- Outside the allow list — if a Hunt names an allow list, everyone else is dropped.
- Pure links — a bare URL with no substance is not a conversation.
- Dead posts — zero-engagement tweets old enough to be dead are dropped. A fresh zero-engagement tweet survives, because that's exactly the early-reply slot you want.
Usage
These tools are available to any connected MCP client (the examples use natural language; your assistant calls the tools).
Create a Hunt
Create a hunt called "Second brain builders":
keywords: "obsidian", "second brain", "personal knowledge management"
target_brief: people sharing how they organize notes and knowledge with AI
reply_intent: share my take and point to my workflow when it genuinely fits
Behind this, the assistant calls create_hunt. The Hunt persists and is retrievable by id.
Pull ranked targets
Get reply targets for the "Second brain builders" hunt
The assistant calls get_reply_targets with the Hunt id, which runs the search, ranks the hits, drops the excluded ones, and returns each survivor with its value_score, the per-signal breakdown, and a short reason like 142 eng · 0.6h old · heating fast. You can also pass a one-off query or keywords without a Hunt, and tune min_score or max_results.
Manage Hunts
list_hunts— list your saved Hunts (optionally filtered by status).get_hunt— read a single Hunt, including its keywords, filters, intent and bound context.patch_hunt— edit any field of a Hunt in place: keywords, author filters,target_brief,reply_intent, bound brain/post context, status, or expiry.delete_hunt— permanently remove a Hunt. Irreversible, and gated behind an explicit confirm so it can't fire by accident.
Tune in place, don't recreate
Tuning a Hunt is iterative. The first keyword set almost always pulls noise, and you only learn the right phrasing after seeing real targets. Instead of spinning up a fresh "v2" Hunt on every pass — which leaves stale, broad versions running and competing — you tune the one you have:
Update the "Second brain builders" hunt: drop the keyword "pkm",
add "note-taking app", and deny @somebot
The assistant calls patch_hunt. Only the fields you mention change. The very next get_reply_targets on that Hunt reflects the new set immediately — no recreation, no version sprawl.
Pause, archive, retire
A Hunt's status controls whether it's working:
| Status | Effect |
|---|---|
| active | The Hunt matches new tweets and drafts replies. |
| paused | Matching and drafting stop. The Hunt and all its history stay put — flip it back to active to resume. |
| archived | The Hunt drops off active lists but keeps its tweets_matched / replies_drafted history for the record. |
Set any of these with patch_hunt (e.g. "pause the Second brain builders hunt"). Pausing or archiving is non-destructive — replies already drafted but not yet shipped are retained, not cleared. When you genuinely want a Hunt gone for good, delete_hunt removes it; when you just want to retire a stale version while keeping its numbers, prefer archived.
Configuration
| Field | Purpose |
|---|---|
| keywords | Terms OR'd into the X search. Multi-word phrases are quoted automatically; reposts are excluded. |
| author_allow | Optional whitelist of handles. When set, only these authors are surfaced. |
| author_deny | Optional blocklist of handles, merged with the built-in bot/auto-summary denylist. |
| min_score | Drop ranked targets below this 0–100 threshold. |
| include_zero_signal | Keep zero-engagement posts even when old (off by default). |
Hunts are a Pro-plan capability. Firing a reply always stays a per-reply human action by design — the platform finds and ranks; you decide and send.