com.robinsaige/verifier

What changed in the tool economy since a date: verdict flips, deaths, revivals, new servers, confirmed drift — the census diff as data. Poll this weekly to keep a local view current without re-crawling.

The FULL evidence behind the verdict for ONE server, by exact registry name — call should_i_use first for the one-word decision; call this when you want the whole record. Leads with the verdict (allow/warn/block), then the `rating` grouped as REACH (answers, latency vs population, protocol, auth), USE (tool count vs population, capability breadth, harness readiness) and TRUST (costume-farm?, duplicate inventory?, verifiability grade, drift / rug-pull, and where checkable whether its ANSWERS are true vs a public primary), a cluster tag, a distinctiveness score, and an explicit not_claimed block. Argument: name.

Find and RANK the trustworthy tool for a NEED. Describe the task in plain words ('screen a company for sanctions', 'US tariff data', 'vessel tracking') — the search is full-text over tool names AND their stored descriptions (stemmed, BM25-ranked), so your words need not appear in any tool's name. Servers come best-rated first, and EACH ROW carries its verdict (allow/warn/block), cluster, distinctiveness and the matching tool names, so you can pick without a second call. Alive, non-costume, current-protocol servers rank on top; dead / costume-farm / walled ones sink. Argument: need.

The observatory's ruled findings — each with its claim and its falsification test — plus the public corrections log (what we published, then corrected, never deleted). Call this to cite what has been established, or to see where we were wrong. No arguments.

Call this FIRST for the state of the MCP tool ecosystem in one shot: how many servers exist, how many actually answer a real handshake, how many are behind a login, the largest costume-farm concentration, AND the Tier-2 truth summary (how many server answers were re-derived against a public primary source and matched). Every number is re-derivable; grades observed/reported/derived. No arguments.

AFTER your agent calls a tool, fire-and-forget how it went — success/failure, latency, cost — so the observatory accumulates realized reliability (the one thing outside-in probing can't see: did it actually work for a real call). Anchored against our own probe: a 'worked' report on a server we saw dead is discarded. Does NOT change the current rating yet (probing stays load-bearing) — this is accumulate-ahead-of-demand. Args: server (required), tool, ok, latency_ms, cost_tokens, call_hash (a hash binding the report to a real call).

Resolve a partial or misspelled server name to its EXACT registry id before calling should_i_use / check_server. Matches a fragment against registry NAMES only (not capabilities — for 'which tool does X' use find_tools). Returns candidate exact names with each one's latest liveness outcome. Empty query rejected.

THE GATE — call this before your agent depends on a tool you don't already trust. Give an exact server registry name and get a one-word verdict — allow / warn / block — with the reason, plus the full rating underneath. 'block' = dead/unreachable/costume-farm-shaped, don't depend on it; 'warn' = usable but look first; 'allow' = safe to depend on. If you have a NEED not a name, use find_tools; if you have a fuzzy name, use resolve_server_name. Argument: name, e.g. 'com.trimtabist/us-tariff-ledger'.