Methodology & policies

How AgentSpot decides what to list, how it ranks, and the rules we will not break.

What gets listed

A project is eligible when it meets a published popularity threshold: at least 100 GitHub stars, or at least 2,500 package downloads in the last 7 days (npm, PyPI or Docker). These thresholds are configuration, not opinion, and are shown on the Get listed page too.

Eligible projects are discovered automatically by a daily pipeline, or submitted by their authors. Either way, every entry is reviewed and approved before it goes live, and every link passes automated security vetting first (HTTPS, allowlisted code hosts, no URL shorteners, age and inflation heuristics, safe-browsing checks).

Clearing the threshold is not enough

The threshold decides whether a project is big enough to list. It does not decide whether it is the kind of thing we list. Four rules do that, and we apply them at review:

• It has to be something you can use, not a list of things you could use. The test: does cloning the repository give you a working capability, or a bibliography? A collection that ships real skills alongside its index passes; an index-only repository does not — that is the same job this site does, and we are not going to list a directory inside a directory.
• No vendor product surfaces. An MCP server or SDK whose purpose is connecting customers to one company's paid service is a distribution channel, not an open-source contribution, however many stars it has. The protocol's own reference implementations and community registries are a different thing and are welcome. Being owned by a company is not the test — being a funnel to the paid product is.
• No runtime companions. Software that only works inside one agent is a feature of that agent, and the agent is already listed. This is narrow: a registry of installable skills is not a runtime companion, even when it is built for one agent, because skills in the open SKILL.md format travel to other agents that read them.
• The category has to mean something. A project must fit a category as described, not merely sit next to one. A large, excellent platform that agents can drive is not automatically a tool built for agents to call.

These rules cut both ways, and they have removed listings that comfortably cleared the star threshold. When we delist something on these grounds we keep the record, so the project is not silently rediscovered and re-added a week later.

How popularity is measured

The primary signal is GitHub stars. Where available, package downloads (npm, PyPI or container pulls, trailing 7 days) are a secondary signal. Closed-source projects without stars rank on downloads, or are marked unranked rather than pushed to the bottom.

We always display the raw numbers on every card and listing page so you can judge for yourself. Lists are ordered by popularity by default, using a normalized, log-scaled composite score in the range 0–100:

base     = 82 × log10(stars + 1) / 6
bonus    = 10 × log10(downloads + 1) / 7.4 × sourceWeight   (added, never subtracted)
momentum = 100 × 0.08 × clamp(growth%, −6, +6) / 6
score    = base + bonus + momentum

What download counts do and do not measure. A download figure is always from one named source — npm, PyPI, or Docker Hub pulls — and the badge says which. All are weekly, so they are comparable with each other and with the growth window. Docker publishes only a lifetime total, so its weekly figure is derived from our own daily snapshots and appears once a week of history exists. It is not a total install count. Projects distributed through several channels (a shell installer, Docker images, Homebrew, Nix) will read low here, because only the registry slice is counted, while a project published solely to one registry has its whole audience represented. Treat downloads as a floor rather than a measurement, and read the raw figure alongside its source label.

Container pulls are discounted for ranking. A package download is roughly one build; a container pull is one start, repeated on every restart, redeploy, node rotation, autoscale event and version bump for the life of a deployment. Counting the two as equals would reward deployment churn rather than adoption, so Docker figures earn a tenth of the bonus points a package registry would. The weight applies to the points rather than to the count — scaling a number before taking its logarithm barely changes anything, so that would have been a discount in name only. The number shown on the listing is always the real one — the discount applies only to ranking, and only because the units are not comparable.

The 100 points are a fixed budget: 82 for stars, up to 10 for downloads, and up to 8 either way for momentum — so the parts can never overflow the top of the scale and a leading project is never clipped to the same number as the one behind it. The log scale keeps a handful of mega-projects from flattening everyone else. Stars set the base and downloads only ever add to it, capped at 10 points — so a project is never ranked lower for having a download figure we can measure than for having none, and download volume can never outweigh the primary signal. A project with no stars at all, such as a closed-source tool, is scored on downloads instead of being pushed to zero. Momentum is deliberately small and saturating: star growth of 6% over 7 days or more adds 8 points and a decline that steep subtracts the same, enough to reorder neighbours but never enough to overturn the hierarchy that stars and downloads establish. A project without 7 days of history yet is neither rewarded nor punished. The score is only a sort key — it carries no editorial judgment.

Forks and derivatives

A fork is not listed beside the project it came from — that would count the same work twice and split the credit. We list the original. The exception is a derivative that has overtaken its upstream: at that point it is the version the ecosystem actually uses, so it earns the listing, and its page names and links the project it grew out of. Popularity decides which one appears; the lineage is always stated.

Can run entirely locally

Some listings carry a Can run locally badge, and every category page has a filter for it. The test is narrow and practical: is there a supported configuration in which the whole thing runs on your own hardware, with no mandatory third-party service? A project passes if it can be self-hosted and pointed at a local model — OpenClaw and open-webui do, so they qualify. A project fails if some part of it must call a service someone else operates, however good that service is: Cursor, Claude Code, and the GitHub MCP server all fail, not as a criticism but as a fact about what they need.

Entries we have not assessed carry no badge and are excluded from the filter rather than assumed either way — and the question does not apply at all to books, courses, or prompt packs, which run wherever the agent running them runs. We would rather show nothing than guess.

Growth & trending

We compute momentum from our own daily snapshots: stars gained and percent change over the trailing 7 days, or over however much history we have if that is less. Every growth figure states the window it actually measured — a listing tracked for nine days shows a nine-day change, labelled as such, rather than a nine-day change dressed up as a monthly one. GitHub does not expose historical star counts cheaply, so history accumulates from the day we first track a project. To avoid misleading you, we show no growth figure until a project has at least 7 days of snapshots — never a fake zero. The "Trending" sort and the fast-growing filter exclude entries without enough history rather than showing them as flat. Growth is a lens for exploring — it never affects whether a project is listed.

No paid rankings — ever

No payment of any kind — sponsorship, curation fee, or anything else — can affect inclusion, ordering, the popularity score, or growth metrics. Sponsored placements are clearly labeled and shown in a separate slot that sits apart from the organic list, which is never reordered. A paid curated evaluation (a future feature) buys the evaluation work, not a passing verdict or a better rank. See the disclosure page for the details we are required to state.

Freshness & corrections

Metrics refresh daily and each listing shows its last verified date. Dead projects (deleted, archived, or 404) are flagged for review. Archived software is delisted, since nobody will fix what you would be running; archived teaching material stays listed with a note, since a finished course is still a course. Spotted a mistake or a bad link? Please report it — we act quickly.