There are directories listing over five thousand MCP servers right now. Most of them are weekend projects, thin wrappers around a single API call, or abandoned repos with a README and nothing else.
You do not need five thousand servers. You need about six. Here is the short list I actually keep in my own config, organized by what they are for.
If you are new to the protocol itself, read What Is the Model Context Protocol and Why It Matters first. This post assumes you know what an MCP server is and just want to know which ones deserve a slot.
How I picked
Three filters, applied ruthlessly:
- Maintained. Commits in the last month, issues getting answered. An MCP server that lags behind its upstream API breaks silently, and you find out mid-task.
- Earns its context. Every server you add injects tool definitions into the model's context window. A server with 40 tools you never use is paying rent in tokens on every single request.
- Does something the model cannot fake. Reading live data, touching real systems, running real browsers. If the model could plausibly answer without the tool, the server is decoration.
That last filter kills most of the directory.
For coding
GitHub MCP server
The official one, from GitHub. It gives the model real access to issues, pull requests, code search, and CI status across your repos.
The practical win is triage. "Look at the three open issues labeled bug, check whether any of them were fixed by last week's PRs, and draft a comment on each" is a five-minute manual chore that becomes one sentence. Because it is first-party, it tracks GitHub's API changes instead of trailing them.
One warning: it exposes a lot of tools. If your client supports enabling a subset, do that. You probably want issues and PRs, not the full firehose.
Filesystem server
The reference filesystem server from the official modelcontextprotocol repo. It is boring, and that is the compliment. Scoped read and write access to directories you explicitly allow, nothing else.
If you use Claude Desktop rather than an agentic editor, this is the difference between pasting files into chat and just saying "read the config in ~/projects/app and fix the port clash." Agentic tools like Claude Code have file access built in, so skip it there.
Playwright MCP
Microsoft's Playwright server drives a real browser: navigate, click, fill forms, screenshot, read the accessibility tree. For frontend work it closes the loop that pure code generation leaves open. The model writes the component, opens the page, sees the layout break, and fixes it without you describing the bug.
It is heavier than everything else on this list. A browser has to launch, pages have to load. Use it when you need interaction with a page, not when you just need the content of one. For content, keep reading.
Context7
Context7 by Upstash solves a specific, annoying problem: models confidently write code against API versions that no longer exist. It pulls current, version-specific documentation for thousands of libraries into context on demand.
Adding "use context7" to a prompt about a fast-moving framework saves you the round trip of pasting deprecation errors back into chat. Narrow tool, does one thing, does it well.
For search and web access
link.sc MCP server
Disclosure up front: this is ours, so weigh my opinion accordingly. But web access is the capability I use more than every other server on this list combined, and it is the one where quality varies most.
Plenty of fetch servers are a thin wrapper around a plain HTTP GET. They work until they meet a JavaScript-rendered page, a Cloudflare challenge, or a bot wall, which in 2026 describes a large share of the useful web. The link.sc server exposes two tools, fetch and search, backed by an escalation ladder: a fast HTTP client with real browser TLS fingerprints first, a stealth headless browser when that fails, a hardened browser for the sites that fight hardest. You get clean markdown either way, sized for a context window instead of bloated raw HTML.
The other differentiator is hosting. It runs as a remote server at https://mcp.link.sc/, so there is no npm package to install, no local process to babysit. Add the URL and an API key to Claude Desktop or Claude Code and you are done in about a minute. The step-by-step guide covers each client, and there is a broader walkthrough for Cursor and Windsurf too.
If you would rather assemble your own, a search-only server backed by the Brave Search API is a reasonable free-tier starting point. We wrote up how to get a Brave API key if you go that route. You will still want a real fetch tool beside it, because search results without page contents just tell the model where the answer lives.
For data access
PostgreSQL MCP server
A Postgres server with read-only credentials turns "write me a query to find churned accounts" into "find churned accounts." The model inspects the schema, writes the SQL, runs it, and reasons about the rows that come back.
The setup rule is non-negotiable: create a dedicated read-only database role for it. Never hand an MCP server your application credentials. The model will happily run whatever it is allowed to run, and you want "allowed" to mean SELECT.
Sentry MCP
Sentry's hosted server lets the model pull real stack traces and error frequency instead of debugging from your paraphrase of an exception. "Look at the top unresolved issue in production and tell me the likely cause" works because the model reads the actual trace. If you use a different error tracker, look for its first-party server; the pattern matters more than the vendor.
The list at a glance
| Server | Category | Hosted or local | Best for |
|---|---|---|---|
| GitHub | Coding | Hosted | Issues, PRs, code search |
| Filesystem | Coding | Local | File access in chat clients |
| Playwright | Coding | Local | Browser automation, UI testing |
| Context7 | Coding | Hosted | Current library docs |
| link.sc | Search and web | Hosted | Fetch any URL, live web search |
| PostgreSQL | Data | Local | Read-only database queries |
| Sentry | Data | Hosted | Production error context |
What to skip
Skip servers that duplicate what your client already does. Claude Code does not need a filesystem server or a shell server.
Skip the kitchen-sink aggregators that expose 60 tools across 12 services. Tool definitions consume context on every request, and models pick tools less reliably as the menu grows. In my experience, quality of tool selection drops noticeably somewhere past 15 to 20 available tools.
And skip anything unmaintained, no matter how good the README looks. An MCP server is a dependency with live credentials attached. Treat it with the same suspicion you would treat any package you give your keys to.
Start with two or three servers that match your actual work, use them for a week, and only then add more. The best MCP setup is the smallest one that removes the copy-paste from your day.
Give your AI assistant real web access in about a minute: create a free key at link.sc/register and connect the hosted MCP server at mcp.link.sc.