Trust score

Every listing carries a trust score computed from the official feed and the registry’s own probes. It is transparent on purpose: the descriptor shows the four components, the drivers that moved the score and the discrete flags you can filter on. A manual blocklist handles confirmed malicious or typosquatting listings and forces the score to 0.

Derived from observable signals; no code audit performed. A high score means “well-published, alive and fresh”, not “safe”.

Components and weights

component	weight	inputs
provenance	0.30	repository URL present (+30), repository owner matches the namespace (+15), custom DNS namespace (+10), website (+10), description of 40+ characters (+5), on a base of 30
liveness	0.30	best remote: reachable → 60 + 40 × uptime_30d; not reachable → max(0, 40 × uptime_30d − 10 × consecutive_failures); unmeasured when nothing is probeable
freshness	0.20	age of the latest version: ≤30 days 100, ≤90 85, ≤180 65, ≤365 45, older 25; deprecated 10
hygiene	0.20	starts at 100, minus the findings below

The score is the weighted mean of the measured components. An unmeasured component (a local package has no liveness) is null and its weight is redistributed, so a listing is not punished for what could not be observed.

Flags

flag	meaning	hygiene
multi-version-spam	30 or more published versions at a rate of one a day or more over the listing’s life (CI republishing); a project that releases every week is not flagged	−25
duplicate-repo	repository shared by 3 or more active names (−40 at 20 or more)	−20
no-repository	no parseable repository URL	−20
no-connection	neither remotes nor packages	−40
deprecated	marked deprecated in the official registry	−10
unreachable	every remote failed 3 or more probes in a row and there is no package	via liveness
blocked	on the manual blocklist	score 0
deleted	deleted from the official registry	score not served

Unpinned package versions cost 5 hygiene points and show as a driver without a flag.

Drivers

Short, sign-prefixed strings such as +repository, +namespace-matches-repo, +uptime-99%, ~updated-95d-ago, -stale-210d, -multi-version-spam(1177), ~liveness-unmeasured. They are meant to be shown to humans and read by agents alike.

Using it

• min_trust= on search filters by score; search results are re-ranked by score (30 % of the weight).
• exclude_flags=multi-version-spam,duplicate-repo drops listings with any of those flags; flags= requires them. Both exist on REST, on the MCP search tool and in the SDK (exclude_flags, flags). Every result carries trust_flags[].
• The portal shows the breakdown on every server page and has the same filters under “trust filters”.

Blocklist

protogrid blocks listings it has confirmed as malicious or as typosquats of another server. A block is a manual decision with a recorded reason, never an automatic score. Blocked listings disappear from search, get_server answers with blocked: true and trust score 0, and get_connection refuses with 403, so an agent following protogrid never connects to them. The listing stays in the official registry; protogrid only stops recommending it.

To report a listing, or to ask about a block on your own server, write to [email protected].

Restricted listings

Some servers in the official registry are about adult content or gambling. protogrid hides them by default, for everyone: they never appear in search results (REST, MCP, portal and the /v0.1 list), and asking for one by name answers 404 not_found, exactly like a name that does not exist. This keeps protogrid, and assistants that use it, suitable for all ages.

• Listings are sorted into two categories, adult and gambling, from their own name and description (and, for gambling, from clearly named betting tools). A person corrects the mistakes the rules make.
• A signed-in account can ask to see a category by writing to [email protected] from the email of its GitHub account. A person reviews every request; only adults may ask. Each category is granted separately, and a server with both categories needs both.
• A granted account sees those servers in search and on their pages, on the portal while signed in and over REST or MCP with its API key. Anonymous calls never do.
• The owner of a server always sees it, with its quality report, alerts and every owner feature, whatever its category.
• Your account page shows which categories are shown for you.

If you think a server was put in a category by mistake, write to the same address.