Methodology

What is the Sato Score, and what does it not measure?

Not a quality, security or returns grade — A 0–100 reading of how open, active and verifiable a listed product is: 380 listings carry one — 92 High, 236 Medium, 52 Low, as of 2026-09-20.

A transparent, evidence-based score (0–100) of how open, active, and verifiable a listed product is. Transparency is one of several inputs — alongside maintenance & liveness, code openness, interface verifiability, documentation, and independent verification.

This honesty is deliberate: per our trust rule, no resource is presented as safe, audited, verified, or profitable unless evidence supports it, and self-reported claims are never counted as verified.

What goes into the score (v2)

The score sums six evidence-based components. Each is computed deterministically from observed data — not from a project’s own marketing.

How liveness is scored

Maintenance & liveness (35 points) is decided by whichever evidence is strongest, not by adding sources together — a best-of, not a sum:

• ▸GitHub activity — Commit/release recency: ≤30d = 35, ≤90d = 25, ≤180d = 13, older = 5.
• ▸Live MCP handshake (strong) — A successful MCP tool-call probe within the last 14 days scores the full 35 — a parked domain can’t fake a working handshake.
• ▸Plain HTTP reachability (weak) — A fresh (≤14d) but unauthenticated “the site responds” check caps at 20 — alive, but thin evidence.
• ▸No evidence at all — Floor of 8. Not zero — we can’t verify it, but we also haven’t seen it fail.

A live handshake outranks a plain reachability check on purpose: a parked domain or a redirect page can answer HTTP, but it can’t hold a real MCP session. Deprecated listings score 0 here regardless of evidence.

Interface verifiability, in detail

This component (10 points) rewards proof the interface actually works — a machine talked to it and it responded correctly. It’s the best single credit, not a sum of all three:

• ▸Probed MCP tool inventory (10) — We called the server and it listed real tools.
• ▸A2A agent card found (8) — A live agent-card endpoint was probed and responded.
• ▸Reproduced deploy lane (8) — The documented install path was re-run and verified in an isolated container.

Tiers

Independently checked ✓

26.3% of the 308 documented installs in this directory have been reproduced in an ephemeral container by Sato Hub — 81 so far, re-checked weekly. "Verified install" means exactly that and nothing about runtime safety. Ranked list: /reliability.

A subset of listings goes beyond the score: we tested them ourselves. A listing earns the checkmark one of four ways — its documented install was reproduced in an isolated container, its verification evidence was reviewed by a human, its declared address was found registered on the ERC-8004 agent registry, or its hosted endpoint was live-probed and answered with its real tool inventory (re-checked every 14 days). None of these imply safety, quality, or returns — they prove the thing is real and behaves as documented.

Contract-level on-chain verification is live for the registration leg: for listings with a corroborated address, we read the ERC-8004 agent registry directly and confirm the registration on-chain, per listing. Deeper contract-level checks — reputation and validation sub-registries — are still roadmapped.

Reproduce this score yourself

A rubric you cannot run is a promise. Every input this score is computed from is published, per listing, at /api/export/score-inputs.json — exactly the fields the scoring function reads, nothing else, stamped with the instant the published scores were computed against. Run them through the scorer in the Sato Hub skill — a verbatim copy of the function we run, zero dependencies — and you should land on the number this site shows:

node score.mjs            # every listing
node score.mjs --slug X   # one, with its components

It exits non-zero on any disagreement. If it finds one, that is our bug, not a judgement call — and the place to say so in public is the dispute log, which any project that proves control of its own domain can file to. Reproducing a score makes it checkable; it does not make it a safety, security or audit judgment, which it is not.

Provisional scores

A listing shows “Provisional — not yet assessed” instead of a tier when we have no observable evidence at all: no activity dates, no live check of any outcome, and no sourced (provenance) fields. It isn’t based on how new the listing is — it’s gated purely on evidence. The moment any one of those lands (a commit date, a live check, a sourced field), the flag clears on its own and the listing gets a real tier.

What is deliberately not in the score yet

We do not fake what we cannot verify. These are roadmapped components, scored zero today and added only as their evidence becomes available — at which point scores recalibrate (this is v2):

• ▸Performance — Verified PnL or live-trading evidence — never self-reported.
• ▸Security — Independent audit depth.
• ▸Peer reviews — Community signal, once a review system exists.

How it’s computed and kept honest

• ▸Recomputed daily from the freshest data, after the liveness and stars refresh.
• ▸Every component is shown, so any score can be explained.
• ▸The score and its breakdown are snapshotted daily — so a resource’s trajectory over time is recorded and cannot be retroactively rewritten.
• ▸The formula is open (this page); we publish changes when weights change.
• ▸It applies only to products — agents, tools, frameworks, and infrastructure. Research & editorial listings (research papers & reports, research tools & data platforms, newsletters, communities) are not scored.

The rules this score is built to keep are written down in full on House rules. The two other published methodologies: how Preflight decides and how Sato Route chooses.

Sato Hub. "The Sato Score." Sato Hub, updated 2026-09-20, accessed 2026-09-21. https://satohub.ai/sato-score

How to cite the score and the data behind it, in plain text, APA or BibTeX: the score-inputs dataset · every open dataset is listed at /datasets.