How to pick an MCP server from 60,000 without getting burned

The official Model Context Protocol registry crossed 60,000 servers this year, and it's growing by roughly 16,000 a month. A lot of that is noise: abandoned repos, thin wrappers, duplicates, and servers that were deprecated the week after they shipped. If you're wiring one into Claude, Cursor or your own agent, here's how to tell the solid ones from the junk — in about two minutes.

The signals that actually matter

1. Is it maintained?

Check the last commit or last push date. An MCP server that hasn't been touched in six months, against a protocol that changes this fast, is a risk. "Last pushed" is a better health signal than star count.

2. Remote or local — and do you want that?

A remote (hosted HTTP) server is zero-install, but you're trusting someone else's uptime and their handling of your data and keys. A local package runs on your machine — more setup, more control. Neither is "better"; match it to the task. For anything touching secrets, know where they go.

3. Is it the current version?

Registries keep deprecated entries around. A server can show up in search while the maintainer has already moved to a new one under a different name. If the listing says deprecated, find the active replacement before you wire it in.

4. Does it have real auth (if it's remote)?

A public, no-auth remote endpoint is convenient and a liability — for you and for them. Look for a token or OAuth. "No API key required" on something that touches real data is a yellow flag, not a feature.

5. Stars are a weak signal, not proof

GitHub stars tell you a repo got attention once, not that it works today or is safe. A handful of servers hold thousands of stars; the rest is a long tail. Use stars as a tiebreaker, not a filter.

Red flags, fast

• No description, or a description copied verbatim from the template.
• Last activity months ago.
• deprecated status with no pointer to a successor.
• A remote endpoint with no auth and no docs.
• A "package" that's really a thin wrapper around one API call you could make yourself.

The two-minute check

1. Last pushed — recent?
2. Remote vs local — right fit?
3. Not deprecated?
4. Auth present (if remote)?
5. Description and README make sense?

If three of those are good, it's probably fine. If two or more are bad, keep looking.

You can scan most of these signals at a glance on Serverdex — it pulls the last-push date, transport, packages, GitHub stars, license and registry status onto each server's page, across the whole registry. Useful when you're comparing three servers that all claim to do the same thing.