Methodology
The Sato Score
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.
It measures how open, active, and verifiable a project is — not safety, quality, or returns.
A high score does not mean a project is safe, audited, profitable, or a good investment. It means we can verify a lot about it. A low score often just means a project is new, private, or thinly documented — not that it is bad. The score is informational, not financial advice or an endorsement.
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.
Maintenance & liveness
max 35Recency of observed activity — GitHub commits/releases, or a live check of the interface itself. Uses real activity, not the self-applied “Active” label.
Code transparency
max 20Public repository, open-source status, and a light adoption signal (stars).
Interface verifiability
max 10Machine-checkable proof the interface actually works: a probed tool inventory, an agent card, or a reproduced deploy.
Docs & demo
max 10Whether documentation and a working demo exist.
Listing transparency & provenance
max 15How complete the listing is and how much of it is sourced — every enriched field carries provenance.
Independent verification
max 10Evidence-gated only: Verified or Audited status, plus keyless on-chain corroboration — an ERC-8004 agent-registry registration read from the listing's declared address, a live x402 Bazaar seller listing, or a probed A2A agent card. Self-reported claims earn nothing.
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 ✓
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.
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.