How We Verify & Correct
Last reviewed: 4 October 2026
$ Developer documentation fails quietly. A plausible-looking package name that 404s, or a repository link that quietly points somewhere else, costs a reader an afternoon. This page documents exactly what we check before publishing, what we cannot check, and how to tell us when we got something wrong.
How we use AI, stated plainly
We use language models as drafting assistants. They help us restructure notes, check prose for internal consistency, and generate first drafts that a human then rewrites.
They are not a substitute for verification. A language model will confidently produce a package name that does not exist. That failure mode is the single most common source of errors in AI-assisted technical writing, which is why every package name and repository URL on this site is checked against the npm and GitHub APIs by the scripts described below rather than trusted from a draft.
When we cannot verify a claim, we remove it or mark it as unverified. We do not present unreproduced numbers as measurements.
What we verify before publishing
Package existence
Every package name printed in a guide is resolved against the public npm registry. Names that return 404 are not shown as install commands. Where a package name has been claimed by an unrelated party, the guide says so explicitly instead of suggesting npx.
npm view <package> versionRepository existence and popularity
Server repository URLs and star counts come from the GitHub REST API, not from a hand-maintained table. Each entry records the date it was fetched, and every server page states that date.
npm run servers:sync-statsShared-repository labelling
Many official reference servers live as subdirectories of one collection repository. That repository's star count belongs to the collection, not to an individual server, so we label it as a collection total instead of implying per-server popularity.
npm view <package> maintainersFreshness
Repository data carries a starsFetchedAt date, and package pins in guides are exact versions rather than floating latest tags, so a guide cannot silently start installing different code.
npm view <package> timeWhat we will not do
Say what could not be verified
When we cannot confirm a package, repository, or version, the guide states that plainly. A missing instruction is recoverable; a command that installs the wrong code is not.
Automation does not replace verification
Our tooling catches wrong package names and dead repository links. It does not establish that a configuration is correct for your environment, and we do not present it as if it does.
No invented measurements
We do not publish benchmark figures, success rates, or comparison numbers unless we can show the method and the raw result. If we do not have it, the page does not claim it.
Corrections are visible
When a guide is wrong, we fix it and bump the article's updated date rather than quietly rewriting it in place. Reporting a problem is the fastest route to a fix.
Some articles are deliberately not indexed
A guide under 500 words with no external citation is marked noindex and excluded from our sitemap. They stay reachable so existing links keep working, and we would rather remove a page from search results than let a thin one stand. Search this site for `noindex` to see how many are affected.
We removed fabricated figures, and that was on us
This site previously published a star rating, hardcoded star counts, and npm install commands for packages that did not exist. Those are gone, replaced by data fetched from the GitHub and npm APIs, and by pages that say so when something cannot be verified. We would rather state the limits of what we checked than imply coverage we do not have.
Reporting an error
If a command does not work, a package does not exist, or a repository link is wrong, please tell us. Include the article URL and the exact command you ran.
Corrections to package names and repository links are treated as priority, because a wrong command sends people to install the wrong code. Every article carries the date its package and repository data was last verified. Reports go to one person, so please include the article URL and the exact command you ran — that is usually enough to confirm the problem without a follow-up round trip.