Every week someone installs an MCP server from a list, wires it into their agent, and then spends an afternoon debugging a transport mismatch that the README does not mention. The server is not broken. It is simply older than the protocol it claims to implement.
MCP moved through three transports in about eighteen months: stdio, then SSE, then streamable HTTP. A project that was correct in the spring is not necessarily correct now. Most of the abandoned servers in every directory you can find are not malicious — they are just frozen at a version of the spec that the clients have since stopped preferring.
So here is the checklist we actually run before adding a server to this directory, in the order that eliminates candidates fastest.
1. The last commit date, not the star count
A repository with 4,000 stars and no commits in nine months is a museum. Stars accumulate and never decay, which makes them a terrible signal for whether something works today. Open the commit history and look at the most recent one: if it predates the current spec revision, everything else on this list is a formality.
2. Whether the README documents the transport
A maintained server says which transports it supports and how to configure each one. A stale one says "run this command" and nothing else, because at the time that was sufficient. When a README has no mention of transport or authentication, assume it was written before either mattered.
3. Issue volume versus issue response
Dozens of open issues with no maintainer replies is worse than a single open issue that gets answered weekly. Look at closed issues too: if the last thing closed was a bug from a year ago, the queue is being ignored rather than worked.
4. The install command still resolving
This one is mechanical. Run the documented command with `--help`. If the package was unpublished, renamed, or moved to a scoped name, you find out in ten seconds instead of twenty minutes. We check this on every entry, which is why the install command on each listing is the one the project itself publishes rather than a guess.
5. Whether it is archived, and whether anything replaced it
GitHub marks archived repositories clearly, but the more useful question is what the maintainers pointed at when they archived it. Several of the reference servers were archived because a vendor shipped an official one. Installing the archived version because it has more stars is the single most common mistake we see.
The pattern behind all five
None of these checks requires reading the source. They are all metadata, and metadata is cheap to inspect and cheap for us to keep current — which is the whole argument for a directory that dates its entries instead of one that just lists them.
If a listing on this site shows a verification date older than a month, treat the install command as a hypothesis rather than an instruction, and tell us. Re-checking one entry takes minutes; debugging an abandoned server takes an afternoon.