hs_rank_topk

net.hunter-seeker/hunter-seeker · Verify this server

Costs one run from your monthly quota - the only tool that does. The run is refunded on honest-empty or error, so you are billed only for a ranking you actually received. Rank the rows of a table by their likelihood of a binary (yes/no) outcome, and return the top-k highest-likelihood entities with calibrated scores. Best for: any "which of these are most likely to [convert / churn / fail / default / win / succeed / respond / be approved]" or "who should I prioritize" question where the user has tabular data and one column represents a yes/no result. Works across any domain - business, operations, health-adjacent, education, sports, research, personal. Not recommended for: continuous-value forecasting (predicting a number, not a yes/no); questions with no historical outcome column to learn from; time-series-only problems; or when the user wants a causal guarantee rather than a ranked prediction. Returns: top-k ranked entities with per-entity calibrated scores; top-decile lift; calibration + validation records; provenance (engine version + core-hash); gate_verdicts with recorded reasons; and leak_guard results naming any quarantined post-outcome columns. Honest-null: top_decile_lift, validation, leak_guard, and top_factors are LIVE as of engine 0.1.1 - they populate on a cleared finding and are returned as null on a non-finding (never fabricated) - so a null means no finding, NOT that the field is pending. top_factors are human-readable strings ("higher/lower/different <feature>"); validation is { scheme, split_fraction, n_train, n_holdout, reason? }; scheme is "holdout", "out_of_time", or "none" when the dataset was too small to hold rows back - in which case n_holdout is null (not 0) and reason states why and what would fix it; leak_guard is a list of quarantined likely-leakage columns, each with a plain-English reason. If the data cannot clear the lift >= 1.5 bar, returns a structured honest-empty result with reasons instead of weak rankings. Common mistakes: choosing an outcome column that is only known after the outcome occurs (leakage) - the tool will flag it; expecting a result when the signal is too weak - read the honest_empty reasons rather than retrying; over-inlining - inline data.rows / data.csv is capped at ~4MB / 2,000 rows / 64 columns, but your CLIENT's tool-payload budget (Claude Code ~25k tokens, Claude Desktop ~150k chars) usually binds first, so keep inline to a few hundred rows and route anything medium or larger to data.dataset_id (via hs_provide_dataset or direct_upload) or data.fetch_url.