There are now more MCP servers than anyone can usefully keep track of, and the lists that catalogue them are mostly undifferentiated. This is the shorter version: the ones that matter, who actually maintains them, and how to tell a good one from a risky one.
New to the idea? Start with what is an MCP server.
First, a distinction that trips people up
“Official MCP server” gets used for two different things, and the difference matters when you’re deciding what to trust.
Reference servers live in the modelcontextprotocol/servers repository and are maintained by the MCP steering group. They exist to demonstrate the protocol. The repository is explicit that these are “educational examples”, not production-ready software.
Vendor servers are built and maintained by the company behind the product. GitHub maintains its own. Microsoft maintains one for Playwright. These are the ones you’d actually put in a workflow.
There’s a third group worth knowing about: archived servers. Several well-known reference implementations, including GitHub, GitLab, Google Drive, and PostgreSQL, have moved to a separate archive repository. If you find a tutorial pointing at one of those, it’s out of date. The GitHub case is the confusing one, because the archived reference server was replaced by a much better official one from GitHub itself.
The reference set
Seven servers, maintained by the steering group, useful mostly for learning the protocol and for genuinely simple local jobs.
| Server | What it does |
|---|---|
| Filesystem | File operations with configurable access controls |
| Git | Read, search, and manipulate Git repositories |
| Fetch | Retrieves web content and converts it for LLM use |
| Memory | Knowledge-graph-based persistent memory |
| Sequential Thinking | Structured multi-step reasoning |
| Time | Time and timezone conversion |
| Everything | A test server exercising every protocol feature |
Everything is the one to know if you’re building. It exposes prompts, resources, and tools all at once, which makes it the fastest way to see what your client actually supports.
Servers maintained by the vendors
These are the ones doing real work in real workflows.
GitHub
GitHub’s official server (github/github-mcp-server, MIT licensed) covers repository browsing, issues and pull requests, GitHub Actions and build-failure analysis, security findings and Dependabot alerts, and discussions.
Notably it offers a hosted remote option at api.githubcopilot.com/mcp/ with OAuth, so there’s nothing to install. You can also run it locally via Docker, which is what you’d want for GitHub Enterprise Server.
The remote-hosted, OAuth-authenticated model is where this ecosystem is heading. Installing a subprocess to talk to a cloud service was always a workaround.
Playwright
Microsoft’s playwright-mcp drives a real browser, and its design choice is the interesting part: it works from structured accessibility snapshots rather than screenshots. No vision model in the loop.
That makes it deterministic. A screenshot-driven agent guesses at what it’s looking at; an accessibility tree tells it exactly. If you’re doing anything with browser automation, this distinction is the whole ballgame.
Slack and Brave Search
Both began as Anthropic reference implementations and were archived, then picked up by others: Slack is now maintained by Zencoder, Brave Search by Brave.
That handover pattern is healthy. It’s also a reminder to check who maintains a server before you depend on it, because the answer changes.
WordPress
Our own, for completeness: EMCP Tools exposes a WordPress site as 207 tools spanning page building, content, users, plugins, media, the database, and integrations with the plugins you already run. Free and GPL. See what is a WordPress MCP server if that’s your world.
How to judge one before connecting it
Servers vary enormously in quality, and the differences aren’t visible from a README. Five questions, roughly in order of importance:
1. What’s the worst thing it can do? Look at the most destructive tool it exposes and ask what stops it firing by accident. Good servers ship destructive tools disabled, require an explicit confirmation flag, or both. If a server can delete things and has no confirmation step anywhere, that’s your answer.
2. Whose permissions does it use? It should act as you, bounded by whatever you can already do. A server that holds its own all-powerful credential and happily does anything asked has quietly become a privilege-escalation route.
3. How many tools does it register? More is not better. Every tool definition costs context on every single request, and some clients refuse to load a server past a cap, Antigravity stops at 100. A server exposing 300 flat tools has pushed a design problem onto you.
4. Is it maintained, and by whom? Vendor-maintained beats community-maintained beats abandoned. Check the last commit, not the star count.
5. Local or remote? Local (stdio) servers run on your machine and touch nothing over the network. Remote servers need real authentication, and OAuth is the right answer.
Where this is going
Three shifts are already visible.
Remote and OAuth are becoming the default. GitHub’s hosted endpoint is the template: no install, no token pasting, revoke access like any other app.
Tool counts are being taken seriously. Curated catalogs, discovery patterns, and dispatcher modes are all responses to the same pressure, which is that context is finite and a long tool list makes a model worse rather than better.
Vendors are taking over their own servers. The reference implementations did their job by proving the protocol. The durable servers are the ones maintained by whoever owns the product.
If you’re picking servers today: prefer vendor-maintained, check the destructive tools first, and be sceptical of anything registering hundreds of tools.
Related reading
- What is an MCP server? — the protocol, in plain English
- What is a WordPress MCP server? — one server in depth
- Compact tool mode — what to do when a client caps tool counts
- The official servers repository — the reference set