Verifier is answering right now. Last checked 4 min ago. It exposes 8 tools.
MCP tool observatory: do registry servers answer, and are their answers true? No key.
Uptime history
81 days of history · worst day 88%
81 days agonow
100.0%
Uptime 24h
91 of 91 checks
8
Tools
read from the server
450 ms
Response time
average over 24h
open, no key
Access
streamable-http
What changed 14
Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 14 August 2026. No other catalogue keeps this.
15 Aug
2 tools changed the parameters they ask for3 times that day
find_tools, should_i_use
15 Aug
a tool appeared
changes_since
15 Aug
a tool description was rewritten
find_tools
14 Aug
4 tools appeared
find_tools, report_call, resolve_server_name and 1 more
14 Aug
2 tool descriptions were rewritten3 times that day
check_server, find_tools
14 Aug
a tool disappeared
find_servers
14 Aug
a tool changed the parameters it asks for
check_server
and 2 more, back to 14 August 2026
Tools have disappeared from this server
A tool that vanishes takes a piece of your agent with it, and the change arrives silently. Watch this server and every such change lands in your inbox.
Connect this server
Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 4 min ago.
run in your terminal
claude mcp add verifier --transport http https://robinsaige.com/mcpSettings → Connectors → Add custom connector, then paste this address
https://robinsaige.com/mcp~/.codex/config.toml
[mcp_servers.verifier]
url = "https://robinsaige.com/mcp".cursor/mcp.json
{
"mcpServers": {
"verifier": {
"url": "https://robinsaige.com/mcp"
}
}
}.vscode/mcp.json
{
"servers": {
"verifier": {
"type": "http",
"url": "https://robinsaige.com/mcp"
}
}
}Available tools 8
Read directly from the server with tools/list, grouped by what they act on.
If a tool disappears, we record the date.
changes
changes_since
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.
findings
list_findings
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.
registry
registry_pulse
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.
report
report_call
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
resolve_server_name
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.
server
check_server
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.
should
should_i_use
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'.
tools
find_tools
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.
Tools removed
Tools this server used to expose. Anything built against them stopped working on the day they went.
find_servers
removed 14 Aug 2026
Endpoints
| URL | Transport | State | Latency | Checked |
|---|---|---|---|---|
| https://robinsaige.com/mcp | streamable-http | answering | 445 ms | 4 min ago |
Alternatives to Verifier
same job, measured the same wayOpen MCP Registry
by onticx
Search and discover MCP servers from the MCP Registry.
Search MCP Registry
by onticx
Search and discover MCP servers from the MCP Registry.
Publish MCP Server
by marlenezw
An MCP server that helps developers publish their MCP servers to the registry
MCP Server MCP Registry
by formulahendry
MCP Server for MCP Registry to discover and search for available MCP servers in the registry
MCP Liveness
by agentwares
Does an MCP server work for a stock client? By registry name or URL. Tool drift too. Free, no key.
agent-as-model
by fernandogarzaaa
A true MCP server where the agent is the model and the API key. No API keys.
MCP Registry Server
by com-mcp
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
Toolcairn MCP
by neurynae
MCP server for tool discovery: find, compare, and verify tools across 35+ registries.
Verifier — questions
Answers built from our own checks of this server.
What can Verifier do?
It exposes 8 tools, read directly from the server on our last check. Among them: changes_since, check_server, find_tools, list_findings, registry_pulse, report_call and 2 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README.
How MCP servers expose tools in the first place →
Is Verifier working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 91 of 91 checks got a reply (100.0%), average response time 450 ms. The bar chart above shows every period we have measured.
Did Verifier ever remove tools?
Yes. find_servers is no longer exposed — we recorded the date each one disappeared. A tool vanishing usually means a breaking change for anything that depended on it.
How do I connect Verifier?
Copy the ready config from this page. We generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each in the form that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does Verifier need an API key?
No. Verifier completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 8 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is Verifier?
It answers our handshake in 450 ms on average, which is faster than 28% of all working MCP servers we measure. The comparison comes from our own checks across the whole registry, every 15 minutes.