What we check, and what we do not
16 checks. A result is recorded against one version on one date, and it expires. A badge with no expiry is a weaker claim than one with it, not a stronger one.
- Checks in the rubric
- 16
- Run on everything
- 7
- Kind-specific sets
- 3
- Version, published
- v1.0
Anchored to
- CWE
- 9 of the 16 checks name an entry in it, across 9 distinct identifiers. The other 7 are ours, because no public taxonomy covers them.
- 1 of 16
- One of them is disqualifying rather than informational: Behaviour matches the manifest. Fail that one and the listing cannot be sold. The other 15 are recorded and published, not fatal.
- 13 limits
- Every badge below publishes what it does not cover, set in the same size type as what it does. It is built in rather than switched on, so there is no version of this page without it.
Every listing
No shipped credentials
No API keys, tokens or passwords in shipped files or in repository history.
CWE-798 · CWE-540
Dependency advisories
Known vulnerable dependency versions, with severity and whether the affected path is reachable.
CWE-1395
Behaviour matches the manifest
DisqualifyingThe tools, scopes and destinations it declares are the ones it actually uses. Both directions count.
Declared egress
An explicit list of hosts it may contact, resolved rather than taken on trust.
CWE-918
Data handling disclosed
What it reads, what it writes, what it sends and to whom, stated in the listing.
Licence and provenance
Declared licence, open-source dependencies disclosed, and the tool it was built with named.
Transparency self-certification
The maker's own statement about AI transparency obligations. Recorded, not assessed by us.
agents also
Software that takes a goal, chooses its own steps and calls tools to carry them out.
MCP servers also
A program that exposes tools and data to a model through the Model Context Protocol.
URL handling
Any tool accepting a URL refuses internal and metadata addresses, including after a redirect.
CWE-918
Tool description integrity
No instructions hidden in tool descriptions, which a model reads as commands.
Command execution is bounded
A fixed set of named commands rather than an interface that runs whatever string it is handed.
CWE-78
Authentication enforced
Privileged tools require authentication and enforce it on every path, not just the documented one.
CWE-306
apps also
A tool you install and run, rather than a library you build with.
Row-level security
The database refuses rows the current user is not entitled to, verified with two accounts.
CWE-285
Object-level authorisation
Changing an identifier in a request does not return somebody else's record.
CWE-639
CORS configuration
Cross-origin access is restricted to the origins that need it.
CWE-942
How far we looked
Every listing carries one of these, on its card and on its page. It is a separate question from whether it passed: these 6 rungs say how much was done before anyone said so.
Indexed
3 of 990It exists, we found it, and its source resolves to a real place.
Does not establish Nothing else. Nobody has read it, run it, or checked who wrote it. Treat it exactly as you would a repository you found yourself.
Source verified
none yetThe listing describes the code at the source it points to, at a commit we recorded.
Does not establish Whether that code is safe, whether it works, or whether the person who published it is who they say they are.
Publisher verified
2 of 990Whoever published it proved they control the source it comes from.
Does not establish Anything about the software. A verified publisher can ship bad code, and this rung says only that the name is real.
Static scanned
985 of 990Its published package, or for a hosted server its source repository at a recorded commit, was read file by file, without running it, by every check in our current scan.
Does not establish How it behaves when it runs, or anything the scan does not read yet: several rubric checks, the repository's history, and compiled code in folders named dist or build. For a hosted server, that the endpoint runs the code that was read. The Assay Index sets out exactly what was read.
Sandbox tested
none yetIt was executed against a fixed task set in an isolated sandbox, with its filesystem, processes and network recorded.
Does not establish How it behaves on your data, on paths our task set did not reach, or after the maker ships the next version.
Monitored
none yetIt is re-tested whenever the source changes, and suspended automatically when a run regresses.
Does not establish That a change is caught the instant it lands. There is a window between a maker pushing and us re-running, and it is measured in hours.
What each badge means
Verified
Covers
- No credentials in shipped code or repository history
- No known-vulnerable dependencies on a reachable path
- Declared capabilities match observed behaviour
- Declared list of hosts it may contact
Does not cover
- Whether it is any good at your particular job
- What the maker does with data after it leaves your systems
- Whether the maker will still be maintaining it next year
- Whether using it is lawful in your industry or jurisdiction
Verified with findings
Covers
- Everything a clean pass covers, with the exceptions listed
- Each finding carries a severity and, where determinable, reachability
Does not cover
- Everything a clean pass does not cover
- Whether a finding matters for how you intend to use this
- Findings in code paths our tests did not reach
In review
Covers
- Submitted and queued. Nothing has been established yet.
Does not cover
- Everything. This badge is a queue position, not a result.
Needs re-verification
Covers
- It passed, on the date shown, against the rubric version shown.
Does not cover
- Advisories published since that date
- Any change the maker has shipped since
Not yet tested
Covers
- Nothing. It is listed and it has not been through the rubric.
Does not cover
- Everything. Treat it as you would software from anywhere else.
Re-run failed
Covers
- An earlier version passed, and its receipt stays true for the version it names
- The latest version was checked again and failed, on the date and checks shown
Does not cover
- The latest version: it is not verified, and it is off sale until a version passes
- Anything the earlier receipt did not cover when it was issued
Ask it from inside your agent
The catalogue speaks the Model Context Protocol. Point a client at this endpoint and an agent can ask what is known about a package before it installs one, without anybody opening this site. There is no key, because it serves the rubric above and the same findings printed on every listing page.
That returns the manifest, which lists the tools it serves, so this page cannot go stale about them. The one worth knowing is check_before_install: hand it a package name and it answers with the published findings, the rung the listing sits on, and the checks nobody has run.
An absent finding is not a pass. A model that reads no findings and installs on that basis has been misled by omission, so the list of unrun checks is part of every verdict rather than a footnote under it, and a package nobody has examined says exactly that in its first line.
Run it against your own code
The rubric above is served as JSON, so the standard on this page is machine-readable and anybody can hold us to it. The scanner that consumes it and applies the readable checks to a directory is written and tested, and is not published yet.
It answers 7 of the 16 checks and prints the remaining 9 as not exercised, in the same list, in the same size type.
A clean run is not a rung. The tool says so in its own output. Reading files on a disk (what npm would publish from them, or the working tree) is a subset of a static scan, and it never sees the repository history, which is where a leaked credential usually is.
The command lands here the day it is published. It carries a second verb, check, which asks the endpoint above about a package you have not installed and fails a build when nobody has examined it. Until the package is up, that endpoint is the part you can use.
Beside the rubric, every listing page carries a maintenance status, maintained, at risk or abandoned, with the release or commit date it rests on printed next to it, or not measured where there is none. How it is measured. A newly verified listing can also be the week's Verified Launch, chosen by a published rule and never mixed into ranking.
What each kind of evidence can answer
Not every listing rests on the same evidence, and a rubric that passed what it could not see would be a rubber stamp. So every row is marked, for each kind of evidence, as answerable, partly answerable or not answerable, and a listing shows a row it cannot answer as not applicable. The marks rest on the rubric run by hand on 30 listings.
Published package, read as text
The npm or PyPI package at the version the listing pins, from the registry's own tarball, integrity-checked, read as text and never run; plus the registry's advisories and publish history, and the nightly tool-description scan.
923 of the 990 listed rest on it
Source repository, read at a commit
A public repository at a named commit, read as text over HTTPS and never run. The receipt names the commit, not a package digest.
67 of the 990 listed rest on it
Remote endpoint, connection test only
A hosted server that publishes no source. A connection test sends the MCP handshake and asks for the tool list; no tool is ever called and no credential is ever sent.
No listing in the catalogue rests on it yet
Maker-submitted listing, verified in the sandbox
The exact artefact a maker submitted, with the manifest and statements they declared, scanned and run in an isolated sandbox. The receipt is signed and names the artefact's digest. Every row can be answered here; this says what each one can be answered with, not that any listing has been.
No listing in the catalogue rests on it yet
The connection test is published as scenario set mcp-connection v1.0: exactly what it sends, what counts as a pass and what it does not establish, under the digest a receipt carries.
| Row | Published package | Source repository | Remote endpoint | Maker-submitted listing |
|---|---|---|---|---|
| No shipped credentials | yes Every shipped file can be searched. Bundled and generated code produces credential-shaped strings that are not credentials, so a match is read by hand before it is published as more than a count. | yes The files at the commit can be searched, and history is there to search too. | no There are no files to read. | yes The artefact can be read in full. |
| Dependency advisories | partly The manifest is read and advisories against the package itself are checked nightly; the resolved dependency tree is not matched against an advisory database. | partly Manifests and any committed lockfile can be read; they are not matched against an advisory database, and a lockfile that was not committed is not there. | no There is no manifest to read. | yes The dependency tree can be resolved and matched against advisories. |
| Behaviour matches the manifest | no Needs a manifest a maker has declared, to hold the behaviour against. A catalogue listing has none. | no Needs a manifest a maker has declared. | no Needs a declared manifest, and behaviour cannot be observed without calling tools. | yes The maker's manifest can be held against what the run observes. |
| Declared egress | partly The hosts the code names can be listed as an inventory; the declaration the row asks for has to come from a maker. | partly An inventory of the hosts the code names, not a declaration. | no Where a hosted server connects to is not visible from outside it. | yes The declared hosts can be held against the connections the run observes. |
| Data handling disclosed | yes The README and manifest can be read for what the server reads, writes and sends. A keyword search is not enough: the hand run found it passing on the word network in a list of Docker tools. | yes The README can be read for what the server reads, writes and sends. | partly Only what the registry entry and the server's own description say. | yes The maker's statement is part of the submission. |
| Licence and provenance | yes Licence files and the declared licence are both in the package. | yes Licence files are in the repository. | no No files; a registry entry may declare one, and there is nothing to check it against. | yes Declared in the submission and checkable against the artefact. |
| Transparency self-certification | no A maker's own statement, and a catalogue listing has no maker statement. | no A maker's own statement. | no A maker's own statement. | yes The maker's statement is recorded, not assessed. |
| URL handling | partly Which tools take a URL, and what guards them, can be read; whether a guard holds after a redirect cannot be settled without running the tool. | partly Guards can be read, not exercised. | no Would mean calling a tool with a crafted address, and no tool is ever called. | yes URL-taking tools can be exercised with internal and redirecting addresses. |
| Tool description integrity | yes Tool descriptions written in JavaScript or TypeScript source are read by the pattern set. Python is read by hand only, and descriptions built at run time or compiled into a binary cannot be read at all. | yes The same pattern set reads the source; what is deployed may differ from the commit, and the receipt says which commit was read. | yes The tool list the server returns is exactly what a model reads, and the pattern set reads it. | yes The descriptions the server advertises when it runs can be read. |
| Command execution is bounded | partly Every place a process starts can be found; whether it runs a fixed program or whatever it is handed needs each site read. In the hand run, every real one ran a fixed program, and one the automated scan never saw did not. | partly Every process start can be found; whether it is bounded needs each one read. | no Nothing to read, and nothing is called. | yes Process starts can be read and exercised. |
| Authentication enforced | partly A stdio server has no endpoint to protect. For an HTTP transport the guard can be read; that it holds on every path is not settled without exercising it. | partly The guard can be read; whether the deployed server enforces it on every path cannot be settled from source. | partly The test shows whether the endpoint asks for credentials before listing tools; not whether every tool enforces them. | yes Privileged tools can be called without credentials, on every path. |
| Measured run | no Nothing on this route is ever run. | no Nothing on this route is ever run. | no Nothing is run beyond the handshake. | yes The task set can be run and measured. |
| Fails closed | no Nothing on this route is ever run. | no Nothing on this route is ever run. | no Nothing is run beyond the handshake. | yes Uncertain inputs can be exercised. |
| Row-level security | partly The database migrations an app or template ships can be read for tables left without row-level security; whether the live database enforces it needs a running application and two accounts. | partly Migrations at the commit can be read, as Assay App Audit #1 read them; whether the live database enforces row-level security needs two accounts. | no Needs two accounts. | yes Two accounts can be used. |
| Object-level authorisation | partly Shipped policies that let any caller change every row can be read; whether a request for somebody else's record is refused needs a running application and two accounts. | partly Policies at the commit can be read; whether a request for somebody else's record is refused needs a running application. | no Needs two accounts. | yes Two accounts can be used. |
| CORS configuration | partly Server code in the package, bundles included, can be read for an origin policy that answers everyone; what a deployed server sends needs requests from another origin. | partly Server code at the commit can be read for its origin policy; what the deployed server sends may differ. | no Not tested. | yes Requests can be sent from other origins. |
Where the evidence comes from
Every outside source this site asks, what it answers, how often it answered when asked, and the terms it is asked under. A share is the rows it answered out of the rows it was asked about, floored, with the date it was measured. One that cannot be measured says why.
npm registry
https://registry.npmjs.orgWhich version of an npm package is current, and for a version: its tarball and digest, whether it carries a provenance attestation, whether it runs install scripts, and who has published it.
- Coverage
- 796 of 797 (99%) npm listings the nightly job asked about, measured 30 September 2026. listing_metrics rows with a latest version recorded, of all rows, checked between 24 and 30 September 2026.
- Licence or terms
- npm Open-Source Terms: data may be replicated from the public registry through its public APIs. Their terms
- Rate limits
- No request rate is published. The terms forbid an unreasonable volume and say five million requests in a month from one party is never reasonable. Their documentation
npm downloads API
https://api.npmjs.org/downloadsHow many times an npm package was downloaded last month.
- Coverage
- 550 of 797 (69%) npm listings the nightly job asked about, measured 30 September 2026. listing_metrics rows whose download figure came from npm, of all rows.
- Licence or terms
- npm Open-Source Terms, as for the registry. Their terms
- Rate limits
- Bulk queries take at most 128 packages and 365 days, and no scoped package. No request rate is published; it refuses bursts with HTTP 429, which this site's own runs have met. Their documentation
ecosyste.ms packages API
https://packages.ecosyste.ms/api/v1Last month's downloads for an npm package, asked only where npm's own downloads API gave no figure.
- Coverage
- 231 of 247 (93%) npm listings that npm's downloads API left without a figure, measured 30 September 2026. listing_metrics rows whose download figure came from ecosyste.ms, of the rows npm did not answer. At most 40 are asked a night, so some of the other 16 may not have been asked yet.
- Licence or terms
- Its APIs are published under CC BY-SA 4.0. Their terms
- Rate limits
- No number is published. Anonymous requests share a common pool with less consistent response times; a mailto address in the request joins a polite pool. Their documentation
npm advisory endpoint (GitHub Advisory Database)
https://registry.npmjs.org/-/npm/v1/security/advisories/bulkWhether a published advisory, including a malware notice, covers an npm package at the version a listing pins.
- Coverage
- Not measured. It replies only about packages that have an advisory, so a package it does not mention cannot be told apart from one it has no data on, and the nightly job records a request that failed the same way as a reply that named nothing. As of 30 September 2026.
- Licence or terms
- The advisories come from the GitHub Advisory Database, published under CC BY 4.0; the endpoint is asked under the npm Open-Source Terms. Their terms
- Rate limits
- No limit is published for this endpoint. The npm terms' clause on unreasonable volume applies. Their documentation
PyPI JSON API
https://pypi.org/pypiFor a PyPI project: its releases, files and their sha256 digests, its declared licence and repository, and any advisories PyPI holds against a release.
- Coverage
- 18,977 of 18,977 (100%) PyPI projects requested during the 23 September 2026 ingest, measured 23 September 2026. index.fetched and index.failed (none) in sites/assay/ingested-pypi.generated.json.
- Licence or terms
- PyPI Terms of Service: abusive or excessively frequent API requests may lead to suspension of access. Their terms
- Rate limits
- No number is published; the terms allow access to be suspended for excessively frequent requests. Their documentation
PyPA advisory database, as PyPI serves it
https://pypi.org/pypi/{project}/{version}/jsonWhether an advisory, including a malware report, covers a PyPI release. It arrives in the vulnerabilities key of PyPI's own reply, and gates a package before it is listed.
- Coverage
- Not measured. The key lists only advisories that exist, so an empty list cannot be told apart from a release the database has not looked at. As of 30 September 2026.
- Licence or terms
- The PyPA advisory database is published under CC BY 4.0. Their terms
- Rate limits
- Asked through PyPI, so PyPI's terms apply. Their documentation
jsDelivr
https://data.jsdelivr.com and https://cdn.jsdelivr.netThe file list and the files of an npm package at a pinned version, or of a GitHub repository at a pinned commit, read as text by the nightly tool-description scan.
- Coverage
- Not measured. A package jsDelivr declines to serve is deferred and not recorded, so there is no count of how often it declines. 236 listings have been read through it so far, and 222 of them held code the scan could see. As of 30 September 2026.
- Licence or terms
- Free for personal and commercial use; what it serves must conform to the terms of the service it came from. Requesting unique files across hundreds of packages for more than a few minutes may be treated as abuse. Their terms
- Rate limits
- The data API imposes no rate limits but asks to hear first from anyone making 100 or more requests a minute for long periods. The CDN states no limit on bandwidth or requests. Their documentation
GitHub
https://github.com and https://raw.githubusercontent.comA public repository at a named commit, read with a shallow clone for a hosted server's listing; whether a declared source repository exists; and a maker's claim file.
- Coverage
- 321 of 400 (80%) declared repositories drawn at random from the registry's remote-only servers, measured 24 September 2026. tally.publiclyReadable of sample.size in sites/assay/registry-remote-repos.generated.json. A private repository and a missing one look the same from outside.
- Licence or terms
- GitHub Terms of Service; the content of each public repository stays under that repository's own licence. Their terms
- Rate limits
- Unauthenticated clones over HTTPS and downloads from raw.githubusercontent.com are rate limited since May 2025. GitHub publishes no number for either. Their documentation
GitLab
https://gitlab.comA maker's claim file, when the listing's declared source repository is on GitLab.
- Coverage
- Not measured. No listing has been claimed yet, through either host, so it has never been asked. As of 30 September 2026.
- Licence or terms
- GitLab Website Terms of Use. Their terms
- Rate limits
- Unauthenticated traffic to one project's raw files is limited to 800 requests a minute, within 2,000 a minute for all traffic from one address. Their documentation
Official MCP registry
https://registry.modelcontextprotocol.io/v0/serversWhich MCP servers exist and, for each at its latest version, the packages, remote endpoints, headers and source repository its publisher declared. It is the directory's population.
- Coverage
- 120 of 120 (100%) pages of 100 entries requested by the directory sweep under way, measured 30 September 2026. directory_sweep: pages read in the current sweep, with no error recorded.
- Licence or terms
- No terms of use or data licence are stated in its API documentation. It is a preview: its README warns that breaking changes or data resets may occur. Their terms
- Rate limits
- None is published in its API documentation. Their documentation
The remote servers themselves
Each server's own https address, as its registry entry declares itWhether a remote MCP server answers the handshake, and the tool list it gives when asked. No tool is ever called and no credential is ever sent.
- Coverage
- 110 of 121 (90%) connection tests run, counting an answer or a request for a key, measured 30 September 2026. remote_probes outcomes: 44 answered, 66 asked for a key, 11 did not complete.
- Licence or terms
- Each server's own. A test is only what the protocol defines for connecting: the handshake, then a request for the tool list. Their terms
- Rate limits
- This site's own limit: a visitor may test a server at most once every ten minutes, and the site runs at most 60 visitor tests an hour.
What this does not cover: whether any source is right. A source that answered is one that replied, and its reply is recorded as its own, never as this site's finding.
What the catalogue holds, and how much of the registry, counted from the same data.
Getting a listing verified
Three problems account for most first-time failures: a secret left in repository history, a manifest that does not match the software, and no declared egress. Fix those and the rest is detail.