How we check
Checked by machine. Signed. Graded by exam.
Every record in the index is machine-checked, labeled with the tier it earned, scored by a documented formula and — where verified — cryptographically signed. This page is the citation source for anyone, human or agent, auditing us.
1. Liveness checks — does the door exist?
The index is built by crawling the registries where invokable software is listed (the official MCP registry, Smithery, npm, Glama, and more) every week. For each record we check whether the package resolves on its registry (npm, PyPI), whether a remote endpoint actually answers, whether the repository is alive, and whether a declared contract — the tool schemas or spec the software publishes — is present. What a record can do is read from that declared contract, never inferred from a README or a marketing page. If the contract doesn't declare it, we don't claim it.
Every record carries exactly one of four labels, and we never blur them: execution-verified (we ran it and its contract held), static-verified (the machine checks passed), not yet verified (listed, but unmeasured — never presented as failure, never as success), and failed verification(we checked, and it didn't hold).
2. Scoring — a formula, not a model
Search returns one answer with evidence, or an honest no. The ranker is a documented formula: same query, same answer, always explainable. Relevance comes from hits on names, declared tool names and descriptions. Authority comes from the verification score, freshness and cross-registry corroboration — and is capped, so it can never outvote relevance. A confident answer must cover most of the query; when a vendor is named, that vendor's own verified record leads; when any verified record qualifies, unverified candidates appear only as labeled alternatives. When nothing qualifies, we say so.
3. Signed records — Ed25519, verifiable offline
Verified records receive an Ed25519-signed trust passport: a dated certificate of what was checked, signed with our private key and verifiable by anyone against the published public key. Four envelope fields are appended — signature, signedAt, signedBy (always unfragile.ai) and version. To verify: detach those four, serialise the rest with sorted keys, UTF-8 encode, and check the signature. Change one character and it visibly breaks.
// Verify an Unfragile trust passport, offline.
// npm install @noble/ed25519 safe-stable-stringify
import * as ed from "@noble/ed25519";
import { sha512 } from "@noble/hashes/sha512";
import stringify from "safe-stable-stringify";
ed.hashes.sha512 = sha512;
const { publicKey } = await fetch(
"https://unfragile.ai/api/v1/trust-passport-public-key"
).then((r) => r.json());
// The endpoint returns { passport, _links } — verify the INNER object.
const { passport } = await fetch("https://unfragile.ai/api/v1/passport/cursor")
.then((r) => r.json());
const { signature, signedAt, signedBy, version, ...payload } = passport;
const canonical = new TextEncoder().encode(stringify(payload));
const ok = await ed.verifyAsync(
Uint8Array.from(Buffer.from(signature, "base64")),
canonical,
Uint8Array.from(Buffer.from(publicKey, "base64"))
);
console.log(ok ? "✓ verified" : "✗ tampered or unsigned");4. The golden set — ranked by exam, not by feel
Every change to the ranker must pass a golden set: a versioned exam of real queries with known-correct expectations — picks, official-door leads, and required abstentions on junk. The weekly pipeline runs the exam and fails loudly if quality drops. Every failure observed in the wild becomes a new exam question, in public: the engine is never finished.
Freshness
The pipeline re-crawls, re-verifies, re-scores and rebuilds the public index every week; the index computes from the same live data.