DEV Community: Andrei

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

Andrei — Sun, 15 Nov 2026 11:56:34 +0000

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

Last pushed — recent?
Remote vs local — right fit?
Not deprecated?
Auth present (if remote)?
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.

How to make your MCP server show up in Google

Andrei — Sun, 15 Nov 2026 11:46:41 +0000

You built an MCP server, pushed it to the registry, maybe wrote a GitHub README — and when you search for it, nothing. Or worse: a stale third-party page ranks instead of you. MCP servers are weirdly hard to find in Google, and the reasons are fixable. Here's what actually moves the needle.

Why MCP servers are invisible

The registry is a JSON feed, not a web page. The official MCP registry is machine-readable. Google indexes pages, and a JSON entry isn't one.
GitHub repos rank for the repo name, not intent. Your repo might surface if someone searches your exact name, but not for "MCP server for X" — and external links in a GitHub README are nofollow, so your repo doesn't pass authority to your own site.
No dedicated page means nothing to rank. If the only "page" about your server is a registry row and a repo, there's nothing for Google to show for a discovery query.

What actually helps

1. Give your server a real, indexable page

A landing page or docs page on your own domain, with a clear title and a 100+ word description of what the server does and how to install it. This is the page you want to rank. One page done well beats a thin repo.

2. Write a description that matches how people search

Registries and directories pull your description. Write it for a human searching "MCP server for Postgres" or "Stripe MCP server," not for a changelog. Lead with the capability, name the integration, keep it under ~160 characters for the meta description.

3. Get listed where the listing is actually indexable

Most MCP directories exist, but many of their pages carry a noindex tag until a listing is claimed or hits a quality bar — so being "listed" isn't the same as being indexed. Check the real page: view source and look for <meta name="robots" content="noindex">. If it's there, that listing isn't helping you in search.

On Serverdex, for example, every server in the registry already has a page, but unclaimed ones are noindex until you claim them. Claiming your listing (free, one GitHub click) flips the page to indexable, adds it to the sitemap, and gives you a dofollow link back to your site — the kind of link that actually helps your own domain rank.

4. Earn a couple of real links

A dofollow link from a relevant, indexed page is worth more than ten nofollow mentions. A short dev.to post about your server, a PyPI package with your homepage set, a mention from a blog that covers MCP — those are the links Google counts. GitHub stars and nofollow README badges feel good but do not move search rankings.

5. Don't wait for the registry to do it for you

The registry's job is distribution to clients, not SEO. Search visibility is on you: one good page, an honest description, an indexable listing, and a few real links.

The quick version

One real page on your domain — 100+ words, clear title.
A description written for search intent.
A listing that is actually indexable (check for noindex).
A couple of dofollow links from indexed pages.
Ignore nofollow vanity metrics.

If you want to check whether your server already has an indexable page — and claim it — the whole registry is searchable at Serverdex.

Local vs remote MCP servers: the data says remote already won

Andrei — Sun, 15 Nov 2026 11:44:16 +0000

If you're building a Model Context Protocol (MCP) server today, the first real decision is how people run it: a local package they install, or a remote endpoint they connect to. I had a hunch the answer had shifted, so I pulled the numbers across the whole official MCP registry — 61,855 servers. The shift is bigger than I expected.

Remote already won

60% of servers are remote-only: a hosted HTTP endpoint, nothing to install.
Only ~32% ship as a local package alone.
streamable-http is now the dominant transport, well ahead of local stdio.

A year ago, "an MCP server" meant an npm or PyPI package you ran on your machine. The median server today is a URL you point a client at. (Full breakdown with charts: the data report.)

Why it's happening

Zero-install onboarding. "Paste this URL" beats "install this package, set these env vars, run this command." For non-developer users of Claude or Cursor, a local install is a wall.
You control the runtime. Secrets, rate limits, API keys and updates live on your server, not on the user's machine. You ship a fix once.
Monetization and auth. A hosted endpoint is where OAuth, usage metering and billing live. A local package can't easily do any of that.
The transport caught up. streamable-HTTP made remote MCP practical, and it's now the default.

What it means if you're building one

Default to remote unless you genuinely need local filesystem or OS access. Most servers that wrap an API should be a hosted endpoint.
Local still wins for OS-level tools — file access, local dev tooling, anything that must touch the user's machine. That's the ~32% that stay packages.
If you go remote, plan for auth and abuse early. A public no-auth endpoint is easy to ship and easy to get wrecked. streamable-HTTP plus a token is the common pattern.
Hybrid is fine. ~8% of servers ship both a package and a remote endpoint. Give people the choice if it's cheap.

The uncomfortable part

Remote means you run infrastructure forever. A local package is "publish and forget"; a hosted server is uptime, costs and on-call. That's the real trade-off behind the 60% — convenience for users, operational weight for you.

If you want to see where your server sits versus the rest of the ecosystem, every server in the registry is indexed at Serverdex: category, transport, packages and GitHub signals per server.

The State of MCP Servers: I analyzed all 61,855 of them

Andrei — Sun, 15 Nov 2026 11:27:05 +0000

I run Serverdex, a directory that indexes the official Model Context Protocol (MCP) registry. That means I have a row for every published MCP server sitting in a database — so I pulled the numbers on all 61,855 of them and wrote up the state of the ecosystem. Here's what stood out.

1. The registry 100x'd in about a year

In September 2025 the registry held a few hundred servers. It has roughly doubled month over month through 2026:

Feb 2026: 845 new servers
Jul 2026: 3,465
Sep 2026: 9,427
Oct 2026: 16,876

October 2026 alone added more servers than existed in the entire first six months. If you've felt like MCP went from "interesting protocol" to "everyone is shipping one" overnight — the data agrees.

2. Remote won

MCP started as local stdio servers: you install a package and run it yourself. That is no longer the norm.

60% of servers are remote-only — a hosted HTTP endpoint with nothing to install.
Only ~32% ship as a local package alone.
streamable-http is now the dominant transport, well ahead of local stdio.

The ecosystem has quietly shifted from "download and run" to "point your client at a URL." The median server is now something you connect to, not something you install.

3. How they ship

Of the ~24,000 servers with an installable package:

npm: 16,717
PyPI: 5,367
MCPB: 2,295
Docker (OCI): 1,794
NuGet: 175, Cargo: 129

MCP tooling is a JavaScript-first world, with Python a clear second.

4. A few giants, a long tail

There are 1.27 million combined GitHub stars across the index — but attention is brutally concentrated. 92 servers hold 1,000+ stars each, while the vast majority have none. The head is names you'd expect: Browser Use, Scrapling, Metabase, CCXT, the official GitHub MCP server.

5. Open by default

MIT is the default license of the MCP ecosystem by a wide margin (6,571 servers), with Apache-2.0 a distant second (778). The space is overwhelmingly open source.

Methodology

Numbers are from the Serverdex index of the official MCP registry, as of 15 November 2026: 61,855 published servers. Growth is by first-publication date. Languages, stars and licenses cover the servers with a resolvable public GitHub repository. "Remote-only" means a server advertises an HTTP endpoint and no installable package.

The full report — with charts and the most-starred servers — is here: The State of MCP Servers.

If you maintain an MCP server, it's probably already indexed; you can claim its page for free. And if you want a specific cut of the data (by category, by month, remote vs local over time), ask in the comments — happy to pull it.