How Unfragile verifies and answers

The corpus is built by crawling the registries where invokable software is listed (the official MCP registry, Smithery, npm, Glama) every week. What a server can do is read from its declared tool schemas— the machine-readable contract it publishes — never inferred from its README or marketing page. If the contract doesn't declare it, we don't claim it.

Identity is resolved by a human-curated table, never by name similarity: relistings of the same software are marked as duplicates with written evidence, and an independent third-party server for a vendor is treated as its own software — listed separately, attributed, never merged.

Every record carries exactly one of four labels, and we never blur them:

• execution-verified — we ran it and its contract held.
• static-verified — machine checks passed: the package exists and is live at its registry, the repository resolves, the declared contract is present.
• not yet verified — listed, but unmeasured. Absence of measurement is never presented as failure — and never as success.
• failed verification— we checked, and it didn't hold.

Verification is per record, never averaged: an entity page shows a tier on every door, and no entity-level checkmark exists anywhere on this site.

Verified records receive an Ed25519-signed trust passport: a certificate of what was checked and when, signed with our private key and verifiable offline by anyone against our published public key. Change one character of the passport and the signature visibly breaks. The seal proves the passport is authentically ours and untampered; the testing behind it is documented on this page.

Search on Unfragile returns one answer with evidence, or an honest no. The ranker is a documented formula, not a model: same query, same answer, always explainable. In brief:

• Relevance comes from keyword hits on names, declared tool names (ground truth), and descriptions.
• Authority comes from the verification score, freshness, and cross-registry corroboration — and is capped, so it can never outvote relevance.
• Coverage law: a confident answer must cover most of the query. One matching word never carries a junk query — the engine abstains instead.
• Official doors lead: when a query names a vendor, that vendor's own verified record earns the lead — matched by exact publisher identity, never by substring tricks.
• Verified-first: when any verified record qualifies, the answer is one. Unverified candidates appear only as labeled alternatives.

When nothing qualifies, we say so. An honest abstention is a feature: it is the difference between an answer engine and a guess engine.

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 automatically and fails loudly if quality drops. Failures observed in the wild become new exam questions — the exam only grows.

The pipeline re-crawls, re-verifies, re-scores, and rebuilds the public index every week, and the census computes from the same live index. Every record shows when it was last published and last verified. Nothing on this site answers from stale memory.

We never sell placement, and no commercial relationship can change a score or an answer. Vendors may pay for verification of their own record — never for position. We also never build, host, or operate the software we rank: we test, sign, answer, and route. Every other registry has a horse in the race; not having one is the product.

Cite answers by linking their page (for example unfragile.ai/stripe) and census figures by linking the census. Attribute to "Unfragile". Machine consumers should use /api/answer?q=… — same index, same answer, JSON.