How the ranking works
Every project gets a score out of 100 from public signals with published weights. The score sets the order; the review explains the project.
- Adoption15%
- Momentum10%
- Freshness15%
- Maintenance15%
- Verified build30%
- Docs5%
- Agent-ready5%
- Privacy5%
On this page
Signals and weights
A signal we cannot measure yet is left out and its weight goes to the others, so no project loses points for something we have not checked.
| Signal | Weight | What it looks at | Shown as | Status |
|---|---|---|---|---|
| Adoption | 15% | GitHub stars, log-scaled, ranked half within the category and half across the list | widely used, popular, known, niche | Live |
| Momentum | 10% | stars gained in the last 30 days, ranked within the category | surging, rising, steady, flat | Coming |
| Freshness | 15% | last commit (full marks under 90 days, zero at a year) and last release | active, recent, slowing, quiet | Live |
| Maintenance | 15% | issues closed vs opened, release cadence, commits in 90 days | healthy, fair, patchy, weak | Live |
| Verified build | 30% | we start it in CI and wait for a healthy response | passes, untested, fails | Coming |
| Docs | 5% | install section, environment docs, upgrade notes | thorough, good, thin, missing | Coming |
| Agent-ready | 5% | CLAUDE.md, AGENTS.md, skills, llms.txt | ready, partly, minimal, none | Live |
| Privacy | 5% | no telemetry or opt-out, works fully offline | private, mostly private, some telemetry, leaky | Coming |
Penalties: no license −10. Coming: data must leave your host −10 · unpatched security advisory −20. Archived projects are removed. The weights are our judgment, not science.
Where the data comes from
- Projects are found in curated lists, app stores and template galleries, then fact-checked on GitHub: stars, last commit, license, Docker files.
- Each review is written from the project's own README and never copied from other lists: what it does, what it needs, and strengths and weaknesses you can check.
- Reviews are rewritten when the README or the latest release changes. Projects with no commits for 12 months are marked stale, and archived ones drop off.
- A project's own claim, such as "an alternative to Cursor" in its README, is labelled as its claim.
Health facts
Each project page has a Health box. Nothing in it changes the score.
- Releases
- GitHub releases in the last 12 months, pre-releases left out, and the days since the latest one.
- Top contributor
- The share of the last 52 weeks of commits on the default branch made by one person, from GitHub's contributor stats. Bots and coding-agent accounts such as Claude and Codex are left out. A high share means the project leans on one person.
- Security advisories
- The project's own published GitHub security advisories from the last 12 months, and how many GitHub rates critical or high. Publishing advisories is good practice, so the count alone says little.
- Package advisories
- When the repo's root manifest names a package on npm, PyPI, crates.io or Go, and deps.dev links that package back to the repo, the known advisories (from OSV) for its latest version.
- OpenSSF Scorecard
- The score from OpenSSF's public Scorecard API, which covers only some repos.
Releases update at every refresh; the other facts are read again about every two days. A fact we could not read says "Not checked".
Safety checks
MCP servers and skills, rules and plugins have a Safety checks section on their project page: up to 18 checks, each one pass, fail or N/A, with a link to the file line or registry page we read it from. The summary reads "Checks passed: 12 of 13" with the date. A check that does not apply drops out of the count. Nothing here changes the score.
Our report State of MCP servers and agent skills, Q4 2026 has the totals across the lists and the incidents behind the newest checks.
The format follows the OpenSSF Scorecard (opens in a new tab): each check has a name and a rule and lists its limits, with no overall grade. The checks themselves come from Scorecard, Anthropic's guidance on skills for enterprise (opens in a new tab) and the issue codes of Snyk's agent scanner.
| No. | Check | Applies to | Passes when |
|---|---|---|---|
| 01 | Package points back to this repo | MCP servers | The npm or PyPI package its README installs names this repo as its source. |
| 02 | Listed in the official MCP Registry under the owner's name | MCP servers | The registry lists it under the owner's GitHub name or a domain the owner holds. The registry checks who published a server. It does not look at the code. |
| 03 | Latest release has build provenance | MCP servers | npm or PyPI shows a provenance attestation for the latest release. Provenance shows where a release was built and says nothing about what the code does. |
| 04 | No advisories at CVSS 7 or higher | MCP servers, and skills with a lockfile | None on the latest release, none in the dependencies it installs where a fixed version is out (the repo's lockfile when there is no package), and none of the repo's own advisories left without a patch. We cannot tell whether the affected code is ever reached. |
| 05 | No install-time scripts | MCP servers | The npm package runs no preinstall, install or postinstall script, and the PyPI release is not source-only. |
| 06 | No hardcoded keys or tokens | Both | No line in the repo matches a known key format. We leave out test folders and documented placeholders. |
| 07 | No binaries or archives in agent or server folders | Both | No executables, .zip, .tar, .jar or .wasm files where the agent or the server reads code. Images and other media are fine. |
| 08 | No dangerous CI workflow | Repos with GitHub Actions | No pull_request_target or workflow_run job that runs code from a pull request, no untrusted text such as an issue title inside a run step, and no write-all token. A workflow without a top-level permissions block only gets a note. |
| 09 | No download-and-run lines | Both | No file the agent reads pipes a downloaded script into a shell (curl piped to sh, and the like), installers from the vendor's own site included. Install lines in a README do not count. |
| 10 | HTTPS endpoints, no credentials in shipped config | MCP servers and plugins | Remote URLs in server.json, .mcp.json and plugin.json use HTTPS, and no header or environment value there looks like a key. |
| 11 | No hidden Unicode in agent-facing text | Both | No characters a person cannot see but a model reads: tag characters, zero-width spaces, text-direction controls. Emoji joiners and the joiners Persian and Indic scripts need are fine. |
| 12 | No override, concealment or secret-file instructions | Skills | No "ignore previous instructions", no "do not tell the user", no instructions hidden in HTML comments, and no instruction to read files such as ~/.ssh or .env. Quotes and code blocks do not count, since guard skills quote these on purpose. |
| 13 | A private way to report a vulnerability | Both | A security policy, or GitHub's private vulnerability reporting switched on. |
| 14 | Maintained | Both | Not archived, with a commit or release in the last 90 days (MCP servers) or 12 months (skills). |
| 15 | No fake prerequisite or installer steps | Both | No file the agent reads asks you to open a password-protected archive, run a script from a paste site, download from a bare IP address, or turn off download protection (such as removing the macOS quarantine flag). These are the steps the 2026 ClawHub skill attacks used to hide what they fetched. |
| 16 | No email recipients added since the last checked version, no hidden BCC | Both | The email addresses in the server's code (or a skill's scripts) are the same as at the last check, and no mail is BCC'd to a fixed address. One 2025 release of an email MCP server added a single BCC line. A version we have not compared yet is N/A, and an addition stays flagged until a person reviews it. We list new web hosts in the code next to the checks, as a fact. |
| 17 | No shell commands built from input, no unchecked URL opening | MCP servers | The server's code does not build a shell command from a variable, start a child process with the shell turned on, or open a URL in the browser without checking it starts with http(s). A 2025 flaw in an MCP login helper ran a URL from a server as a command. |
| 18 | HTTP endpoints check auth or stay on localhost | MCP servers | A server with an HTTP or SSE transport checks a token or key in its code, or listens only on localhost by default. Servers that talk over stdio are N/A. We cannot see auth set up outside the code, such as a proxy or a gateway. |
Next to the checks the page lists facts that are neither pass nor fail: whether the project bundles scripts, hooks, a bin folder or an MCP config file, whether it calls other MCP tools, the domains its agent files link to, and the web hosts in its code that are new since the last check. Any of them can be fine, and you decide what matters for your setup.
Pinned to a version
Each result names what it read: the commit, the npm or PyPI version with the registry's integrity hash, and a content hash of the files (sha256 over each file's path and sha256, paths sorted, as git archive writes them). When a new version's result differs from the one before, the page shows the date and both versions. The same fields are in the API under safety.
We show a new hardcoded key, download-and-run line, installer step or added email recipient only after a person has read it. Until then that check reads N/A with a note.
How the results are read
We read public data only: the files on the default branch (with gitleaks, OpenSSF Scorecard and osv-scanner), npm, PyPI, the official MCP Registry, deps.dev, OSV and the repo's own GitHub advisories. We never run a project's code. We run the checks once a week, so a fix in the repo shows up at the next read.
How often a flag is wrong
15%
of the lines the four newest checks flagged were wrong at the latest read.
We read every line the four newest checks flag, at the commit they flagged it. On 14 October 2026, across 54 MCP servers and skills, 4 of the 27 flagged lines were wrong (15%): all four were a maintainer script at the root of one repo, not code the server runs. For each earlier miss we fixed the rule before the check went live.
What we cannot check
- What an MCP server's tools say once it runs. Tool descriptions built at runtime, and tools that change after you install them, need the live server.
- Private alerts. Only maintainers see Dependabot and code-scanning alerts.
- What the code does: network traffic, system calls, content a skill downloads when it runs, or whether a vulnerable function is ever called.
- Tool annotations such as read-only. The MCP spec says clients must not trust them, so we do not show them as permissions.
When a result is wrong
Each list has a "Safety check is wrong" form on GitHub. A person reads every report. When a check was wrong, the project page shows the correction and its reason next to the check.
Independence
Nobody can pay for a place.
Sponsors, affiliate links and tips, if any, are labelled and never touch the order. Archestack sells none of the tools it lists.
Hiring has no say in the order either. Teams behind the stack lists open roles at the teams that build listed projects; a team with open roles ranks the same as one without.
Corrections and opt-outs
Every list has forms on GitHub to add a project, fix a wrong fact or opt out (handled within 24 hours): Best of Vibe Coding (opens in a new tab) or Best of Open-Source AI (opens in a new tab). You can reuse all the data under CC BY 4.0 from data.json, the API or the YAML in each list's data folder on GitHub: best-of-vibe-coding/data (opens in a new tab), best-of-ai/data (opens in a new tab).
Method changes
- 2026-10-14: the star-growth anomaly penalty is dropped, since a star chart cannot tell a big launch from bought stars
- 2026-10-13: Maintenance weighs 15% (was 10%) and Momentum 10% (was 15%), so steady upkeep counts more than a burst of stars
- 2026-10-12: penalties we do not check yet are marked coming; only "no license" has ever been applied
- 2026-10-09: Docker alone earns no points, medals mark places 1–3 instead of score bands
Rankings: Best of Vibe Coding and Best of Open-Source AI.