If you’re looking for the best MCP servers, the shortlist most developers actually keep is usually files, git or GitHub, a read-only database, browser automation, search or fetch, and one domain-specific server. Every bigger list tends to collapse to that once real work starts.
Most MCP server roundups are the same directory in a different order. Fifteen entries, one line each, no opinion about which ones survive contact with real work.
We run one in production, listed in the official registry, and we use other people's servers daily. The pattern that shows up is not which servers are best in the abstract. It is that most servers get installed, used twice, and quietly removed, while three or four stay connected for months. This is about that difference.
What an MCP server is, briefly
Model Context Protocol is a standard way for an AI client to call tools that somebody else wrote. A server declares some tools, the client makes those tools available to the model, and the model calls them when they are relevant. That is the whole idea, and the rest is judgement. The value is that the assistant stops being a text box and starts being able to read your files, query your database, or fetch something from the web on its own.
The best MCP servers for developers
Here is the short version first.
| MCP server type | Best for | Main risk | Worth keeping if… |
|---|---|---|---|
| Filesystem | Reading and editing project files | Too-broad directory access | You regularly paste files or ask codebase questions |
| Git or GitHub | Diffs, PRs, issues, code review | Accidental writes or noisy tool overlap | You review code or triage issues weekly |
| Read-only database | Answering questions about real data | Over-privileged credentials | You ask data questions often enough to justify setup |
| Browser automation | Front-end workflows, QA, end-to-end tests | Fragile flows, high permission surface | You debug UI flows or tests in the browser |
| Search or fetch | Current docs and live web content | Prompt injection from fetched text | You need current documentation, not training cutoff guesses |
| Issue tracker | Drafting and triaging work items | Too much context for light usage | The assistant actively helps manage work |
| Media and transcripts | Video and audio knowledge workflows | Niche unless you actually use transcripts | You routinely paste transcripts into chat by hand |
If you want a faster recommendation list, this is it:
- Best general-purpose: filesystem
- Best for code review: git or GitHub
- Best for data questions: Postgres or another read-only database
- Best for web workflows: browser automation
- Best for current docs: search or fetch
- Best domain-specific pick: TranscriptFetch for video and podcast transcripts
How to choose the best MCP servers before you install them
These five questions filter out most of the directory.
Does it do something the assistant genuinely cannot do?
The good ones remove a copy and paste loop you actually perform. If your habit is pasting a stack trace, a server that reads your logs earns its slot. A server that wraps an API you touch twice a year does not.
How many tools does it add?
This is the question nobody asks, and it is the one that matters most in practice. In many MCP clients, tool definitions are included in the model’s working context for tool use, which means a large toolset can increase token use and make tool choice worse. The MCP docs explain the tool based model, even if exact behavior varies by client.
You do not need a precise benchmark to feel this. Ten servers with a dozen tools each can create a lot of overhead before you type a word, and a long tool list also makes the model choose worse, because it is picking from noise.
Our stable daily setup is small: four servers, with a tool count low enough that we know what each one is for. That is the practical pattern. The best MCP servers are usually the ones you can still name from memory.
How much can it see?
A server runs with whatever credentials you hand it. Scope them narrowly, and prefer servers that offer a read-only mode. The principle of least privilege is standard security hygiene, and GitHub's token documentation is a good reference point for how tightly scopes can and should be limited. "It can only read" is a much easier thing to reason about at 2am than "it can also write".
Is it maintained?
The protocol is young and moving. Check the last commit before you wire anything into a daily workflow, because an abandoned server is a silent breakage waiting for a client update.
Local or remote?
Local servers run as a process on your machine over stdio, which is what you want for anything touching files or git. Remote servers run over HTTP with OAuth or an API key, need no install, and work from hosted clients. Neither is better. They suit different jobs.
The servers worth a permanent slot
Organised by the job rather than by vendor, because the job is how you should decide.
Filesystem
The official filesystem server is the one almost everyone keeps. It turns "here is my code, pasted" into the assistant reading the files itself. Scope it to a project directory rather than your home folder, which is both safer and produces better answers, since the model is not wading through unrelated files.
Git and GitHub
Reading diffs, issues and pull requests without leaving the conversation changes how review feels. This is also the first place to think about write permissions: reading issues is low risk, opening pull requests automatically is a decision, not a default.
A database server
A Postgres or equivalent server lets the assistant answer questions about your data rather than about your schema file. Connect it with a read-only role. The temptation to give it write access is strong and the payoff is small compared to the failure mode.
A browser server
Browser automation servers let an assistant open a page, click through a flow, and report what happened. They earn their slot for anyone doing front-end work or writing end-to-end tests, and they are close to useless for anyone who is not.
Search and fetch
A web search or fetch server is the difference between an assistant reasoning from training data and one reading the current documentation. It is also the highest-risk category for prompt injection, since by definition it pulls in text somebody else wrote.
Your issue tracker
A Linear, Jira or Notion server is worth it if the assistant is drafting or triaging work items, and not worth it if you are just reading them.
Media and transcripts
A large share of engineering knowledge only exists as video: conference talks, launch demos, maintainers walking through their own APIs. An assistant cannot watch any of it. This is the gap our own server fills, and the honest scope of it: TranscriptFetch's MCP server gives a client five tools for fetching transcripts from YouTube, TikTok, Instagram and podcasts, searching YouTube, and listing a channel or playlist. If your work never touches video, skip it. If you routinely paste transcripts into a chat by hand, it removes that loop.
The registry, for finding the rest
The official MCP registry is the sane place to browse. It is the most reliable starting point for discovery and namespace identity. Community awesome-lists have far more entries and no quality bar at all, so treat them as a source of names to evaluate rather than recommendations.
The hidden cost: context
Worth stating plainly because it is invisible until you look for it.
Tool definitions are text. They consume context and attention when a client exposes them to the model for tool use. The exact mechanics vary by client, so it is better to avoid universal phrasing here, but the practical result is consistent: a dozen servers is a permanent tax on every conversation, paid in tokens and in the model's attention.
The practical consequence is that MCP configuration is subtractive work. Adding servers feels productive and quietly makes the assistant worse. Once a month, look at what you actually called, and disconnect the rest. Most clients let you toggle a server off without deleting the config, which makes this painless.
Security, in plain terms
Prompt injection through tool results
This is the risk people underestimate. A server returns text from a web page, an issue comment or a file, your assistant reads that text as part of its context, and the text contains instructions. Now the instructions are competing with yours. Any server that ingests content other people wrote is a channel for this, and combining one of those with a server that has write access is where it stops being theoretical.
If you want the security background, the OWASP Top 10 for LLM Applications is the best short reference for prompt injection and related tool risk.
One credential per server, scoped
Give each server its own token with the narrowest scope that works. When something misbehaves, you want to revoke one credential rather than audit everything.
Read-only until proven otherwise
Start every server read-only. Grant writes when you have a specific repeated task that needs them, not because the setup guide showed the full-access version.
Connecting one, in three clients
The protocol is the same everywhere. Only the config location differs. Using our server as the example, since it is the one we can document exactly.
Claude Code
claude mcp add --transport http transcriptfetch https://transcriptfetch.com/mcp \
--header "Authorization: Bearer tf_live_YOUR_KEY"Claude Desktop
Desktop speaks stdio, so a remote server is bridged with mcp-remote in claude_desktop_config.json:
{
"mcpServers": {
"transcriptfetch": {
"command": "npx",
"args": [
"mcp-remote",
"https://transcriptfetch.com/mcp",
"--header",
"Authorization: Bearer tf_live_YOUR_KEY"
]
}
}
}Cursor
Same shape, in .cursor/mcp.json for one project or ~/.cursor/mcp.json for all of them. Keep real keys in the global file. A project file with a key in it ends up in git history.
For fast-changing client details, check vendor documentation directly, especially Anthropic documentation and Cursor documentation.
The servers we removed after a week
More useful than another list of recommendations.
A server wrapping an API we call twice a year: never used, pure context tax. A second search server that overlapped the first: the model picked between them badly, and removing one improved answers immediately. A server whose auth expired silently, which produced confusing failures that looked like model errors for an embarrassingly long time.
The surviving set is small and boring: files, git, a read-only database, and the one that reads video. That is the shape most people converge on.
FAQ
How many MCP servers should I connect at once?
Fewer than you want to. In many clients, every connected server increases the tool surface the model has to consider on each request, so ten servers can spend a lot of tokens before you have typed anything, and a crowded tool list makes the assistant pick worse tools. Three or four that match your daily work beat fifteen that might be useful someday.
What is the difference between a local and a remote MCP server?
A local server runs as a process on your machine and talks over stdio, which means it can touch your files and needs no network auth. A remote server runs over HTTP and authenticates with OAuth or an API key, so it works from any client without installing anything, including hosted clients. Local suits filesystem and git work. Remote suits hosted APIs.
Are MCP servers safe to install?
Treat one like a dependency with credentials, because that is what it is. The specific risk people miss is prompt injection through tool results: a server returns text from a web page or an issue comment, your assistant reads it as instructions, and acts. Prefer servers you can scope to read-only, give each its own narrow credential, and be careful about combining a server that reads untrusted content with one that can write.
Do MCP servers work in editors other than Claude?
Yes. The protocol is client-agnostic, and multiple clients support MCP style server configuration or connection patterns. Product behavior changes quickly, so check the current vendor docs before assuming the config file path or setup flow is unchanged. The same server usually works in several places, with only the config location and shape differing per client.
How do I find MCP servers worth trying?
The official registry is the reliable starting point, since it is the best source for discovery and namespace identity. Community directories and awesome-lists have more entries but no quality filter, so use them to discover names and then judge each server yourself on maintenance, permission scope and how many tools it adds.