Methodology

The four assertion states

VERIFIED

We independently observed the check pass, on this run, against this exact endpoint.

FAILED

We independently observed the check fail. We show this plainly — a failed check is not hidden or reworded.

OBSERVED_RISK

We observed a condition worth flagging that isn't a pass/fail result by itself — for example a tool description containing content aimed at an AI reader rather than a human one. It is a signal, not a verdict.

UNVERIFIED

We could not reach a verdict for this check on this run, and we say why (see the reason attached to each UNVERIFIED assertion). UNVERIFIED is never treated as a pass.

Execution status (completed / errored / skipped / blocked) is tracked separately from the four states above and is never collapsed into a pass/fail count.

"Observed, unsigned"

Some target pages show raw observations without any of the four states above and without a cryptographic signature. This happens for targets that are unclaimed, or that were disqualified from publication for a stated reason (shown on the page). These pages report what we saw, honestly — they never render a pass/fail conclusion, a score, or a status badge, because no one has claimed responsibility for the endpoint and the observation was never signed.

A note on evidence format

Signed attestations issued before this page's schema note carry free-text reason and detail strings directly inside the signed payload. Attestations signed after it carry a reason key and structured parameters instead — this website renders that key into the reader's language at request time. Both forms are equally valid, verifiable evidence; only the encoding of explanatory text changed.

What identifies the code that ran

Every signed attestation names the check-suite code that produced it. From payload version 0.3 onward it carries both a suite_commit — a repository commit — and a suite_digest taken over the git tree listing of packages/checks at that commit. The exact recipe is deliberately not restated here: the obvious paraphrase of it names a different value than the real one, so the authoritative statement is the single command each evidence page prints. Attestations signed before 0.3 carry only a suite_digest, under an older definition that pointed at an npm package which was never published; those values are shown unchanged and cannot be recomputed. The repository isn't public yet, so this digest is reproducible in principle and, for anyone outside the project, not checkable in practice today. If an envelope declares a payload version this site has no schema for, the page says exactly that instead of guessing. None of this says anything about what the checks concluded — it only identifies which code reached those conclusions.

What this doesn't do

We check what we can independently observe from the outside, on a schedule, against a live endpoint. We do not audit source code, we do not guarantee an endpoint's behavior between our runs, and a clean report is not a guarantee — it's a record of what was checked and what was seen at the time it was checked. See each report page's own coverage summary for exactly what ran and what didn't, on that run.

How often we check

Unclaimed servers are probed every 12 hours. Once claimed, a server is probed every 8 hours on the Free plan and every 15 minutes on Indie. Each target's report page shows which cycle it is currently on.

Search ordering

Search results are ordered by lexical text-match relevance — how well each word of your query matches a server's observed tool names and descriptions — with ties broken by most recent observation time. Paid tier never influences ordering. Each query word matches either its exact form or its English-stemmed form; a word prefixed with "-" excludes servers whose current toolset matches it in either form. Quoted-phrase adjacency and OR operators are not supported.