Best MCP Servers for Developers (Curated and Reviewed)

Q: Which MCP server should a developer install first?

The Filesystem server, because its safety dial is obvious: you choose the folders. It has 13 tools, nine of them read-only, and access is limited to the directories you pass as arguments or that the client supplies as roots. Mount volumes read-only in Docker and start with a directory that contains nothing you would mind losing. It is the easiest server to reason about while you learn how a client behaves.

Q: Are the official MCP reference servers production-ready?

The modelcontextprotocol/servers README calls its reference servers educational examples and explicitly says they are not production-ready solutions. That does not make them useless, but it does mean you should read the source, scope the permissions, and treat them as starting points rather than infrastructure. Several servers that older tutorials still recommend now live in an archive repository, so check the date on any tutorial before copying its config.

Q: Which MCP servers have the best access controls?

GitHub's official server has the strongest control surface: toolsets to pick groups of tools, a read-only mode that skips write tools even when you request them explicitly, documented minimum token scopes, and an enterprise path that must run locally. Sentry and GitHub also offer hosted remote endpoints with OAuth, which keeps long-lived tokens out of local config files. Everything else relies mostly on how narrowly you scope what you pass in.

Q: Is the Playwright MCP server safe to run?

Only inside a boundary you control. Its README says Playwright MCP is not a security boundary and calls browser_run_code_unsafe RCE-equivalent, and its allow and block lists do not affect redirects. Running it headless in a throwaway container against a page you serve yourself is a reasonable laboratory. Do not carry that container's flags, such as disabling the Chromium sandbox, onto your laptop.

Q: Why do some MCP servers require a specific SDK version?

Because the Python SDK had a major version change and servers are pinned to the line they were written against. The Git server's README, for example, pins mcp to a 1.x range and says its port to SDK 2.0 is in progress. A plain pip install installs 2.x, so a careless install can break a working server. Pin the dependency, and read the porting notes before upgrading.

Q: How should I reduce the blast radius of an MCP server?

Give it the narrowest credentials that work, prefer read-only modes where they exist, turn off optional capability groups you do not need, and remove servers you have not used in a month. Then watch for combinations rather than individual servers: a web-reading server plus a file-writing server is how an injected page ends up editing your files. One server per real task keeps the surface small enough to reason about.

Contents

Figure 1: Best MCP Servers for Developers (Curated and Reviewed) — few servers, narrow permissions, official maintainers

Most "best MCP servers" lists are a pile of logos and adjectives. This one is shorter and a bit grumpier. I read each project's own README, ran one server for real, and noted what each project says about risk. The ranking is my curation, not usage data.

What "Best" Means Here

A server earns a spot if it solves a daily developer problem, documents its authentication and has an official maintainer. I also care about blast radius — what the server can break if the model gets confused. Every server below runs with your permissions, and that matters more than any feature list.

One warning first. The official modelcontextprotocol/servers README calls its reference servers "educational examples... not production-ready solutions" [1]. Several servers that older tutorials still recommend — GitHub, GitLab, PostgreSQL, SQLite, Puppeteer, Redis, Sentry, Google Drive — now live in an archive repo [1]. Check the date on any tutorial before you copy its config.

The Shortlist

Server	Tools	Auth	Runs as
Filesystem	13	none (limited to allowed directories)	local stdio
Git	12	none	local stdio
Fetch	1	none	local stdio
Playwright MCP	22 by default (59 with every `--caps` group)	none	local stdio
GitHub	not counted	OAuth or personal access token	hosted remote or local
Context7	2	API key recommended	remote or npx
Sentry	not counted	OAuth or token	hosted remote or stdio
Brave Search	8	API key required	stdio (HTTP optional)

Filesystem: the one you will install first

The Filesystem server has 13 tools, from read_text_file to directory_tree. Nine of them are marked read-only. Four change things: write_file, edit_file, create_directory and move_file [1].

Access control: you pass allowed directories as arguments, or let the client supply them as roots. The README says roots completely replace server-side directories when provided [1].

Caveats [1]:

write_file overwrites and is not crash-atomic.
edit_file has a dryRun option, so use it.
move_file fails if the destination exists.

This is the best first server because the safety dial is obvious: you choose the folders. In Docker, mount volumes under /projects with the ro flag for read-only access [1].

One wrinkle: the README recommends roots, while the 2026-07-28 spec changelog lists Roots as deprecated. Both statements are current, and I cannot tell you which will win.

Git: useful, with no seatbelt documented

Git has 12 tools. Seven read — git_status, git_diff, git_log, git_show and friends. Five write: git_commit, git_add, git_reset, git_create_branch and git_checkout [1]. The README says "currently in early development" and documents no read-only switch [1].

That makes it great for "summarize my diff" and slightly nerve-wracking for "tidy up my branches."

Its README also pins mcp>=1.29.0,<2 and says a port to SDK 2.0 is in progress [1]. Plain pip install mcp installs 2.x, so a careless install can break it.

Fetch: small, handy, slightly spicy

Fetch has one tool, fetch, with url, max_length (default 5000), start_index and raw parameters [1]. It obeys robots.txt for tool calls but not for user prompts. The README also warns that it "can access local/internal IP addresses and may represent a security risk" [1].

Why does that matter? A model that reads a hostile web page can be told to fetch an internal address. Run Fetch where internal addresses are harmless, or skip it.

Playwright MCP: the one I actually ran

This is the only server I could run here. npm, PyPI and uvx were all unreachable, but a global install of @playwright/[email protected] was already on the machine. I launched it headless and isolated over stdio, listed the tools, then drove a tiny local page.

Tools: it reported 22 by default [3]. The --caps options add 37 more: storage +17, vision +6, testing +5, devtools +4, network +3, pdf +1, config +1. The README's help text names only vision, pdf and devtools, so the docs lag the server.
How it works: it reads pages as accessibility snapshots, not screenshots [3]. After browser_navigate, I got a YAML tree with a heading, a button and a paragraph, each with a reference ID. Clicking the button by reference changed the paragraph from "not clicked" to "clicked."
Caveats: the README says "Playwright MCP is not a security boundary" and calls browser_run_code_unsafe "RCE-equivalent" [3]. Its allow and block lists do not affect redirects [3].

Chromium's sandbox failed in this root container, so I added --no-sandbox for the page drive. That is acceptable for a throwaway container and a page I served myself. Do not copy it onto your laptop.

GitHub: official, powerful, scope it down

GitHub's official server runs hosted at https://api.githubcopilot.com/mcp/, or locally via Docker or a Go binary [2]. Auth is OAuth or a personal access token. If you set a token, it takes precedence over OAuth [2].

The control surface is the best of the group [2]:

Toolsets: --toolsets (or GITHUB_TOOLSETS) picks groups of tools. The default groups are context, repos, issues, pull_requests and users, out of about 25.
Read-only mode: --read-only skips write tools even if you request them explicitly via --tools.
Scopes: minimum token scopes are repo, read:packages and read:org. The README advises rotating tokens, using one per project and running chmod 600 on config files.
Enterprise: GitHub Enterprise Server must use the local server.

My fetch of this README was truncated near the end, so I cannot give you a tool count.

Context7: fresh docs, with a disclaimer

Context7 exposes two tools, resolve-library-id and query-docs, to pull up-to-date library documentation [4]. It runs as a remote URL (https://mcp.context7.com/mcp, with a Bearer API key) or through npx ctx7 setup on Node 22.13+ [4]. The README recommends an API key, says it is free and promises higher rate limits without stating them.

The README also says "we cannot guarantee the accuracy, completeness, or security of all library documentation" [4]. Projects are maintained by their owners, and the backend is private. It states no privacy policy, so do not send it anything you would not paste into a search box.

Sentry: strong for debugging, thin on documentation

Sentry hosts its server at https://mcp.sentry.dev/mcp with OAuth [5]. A stdio route exists, but the README calls it "still a work in progress" and wants an explicit token [5]. search_events and search_issues need an LLM provider [5].

The README I read names no full tool list, no license and no prompt-injection guidance. Error messages are user-generated text, so treat them as untrusted input.

Brave Search: simple, with one footgun

Brave's server has 8 tools, from brave_web_search to brave_llm_context. It needs BRAVE_API_KEY (or BRAVE_API_KEY_FILE). Stdio is the default [5].

HTTP mode (--transport http, port 8080) has no authentication, though it binds 127.0.0.1 by default [5]. BRAVE_MCP_ALLOWED_ORIGINS and BRAVE_MCP_ALLOWED_HOSTS add opt-in protection against DNS rebinding [5]. The README gives no pricing or free-tier details.

Security Basics for All of Them

Scope tokens. Give each server the narrowest token that works.
Prefer read-only modes. GitHub's --read-only and Docker's ro mounts are the clearest examples.
Turn off extras. Leave Playwright's --caps off unless you need them.
Mind the HTTP spec. The 2026-07-28 spec says HTTP servers must return 403 on a bad Origin and should bind localhost. Stdio servers should read credentials from the environment, not run OAuth.
Watch for combinations. A web-reading server plus a file-writing server is how an injected page ends up editing your files.

How to Choose

Start with Filesystem (read-only mounts) and GitHub (--read-only).
Add one server per real task: browser testing, docs lookup, error triage.
Read the README's security section before the install section.
Check the SDK version if the server is Python.
Remove anything you have not used in a month.

Common Pitfalls

Copying a tutorial config without checking the date. The archive move invalidated a lot of them [1].
Treating reference servers as production infrastructure. The README says otherwise [1].
Running Playwright with every capability group on. Each group is more surface [3].
Leaving Brave's HTTP mode unauthenticated and reachable beyond localhost [5].
Sending a full-scope GitHub token when --read-only and narrow scopes exist [2].
Pasting private code into a docs service with no stated privacy policy [4].
Trusting error text from a hosted service. It is user-generated input [5].
Ignoring the combination risk. Individually safe servers can be unsafe together.
Upgrading a Python dependency without reading the pin. SDK 2.x can break a 1.x server [1].

Best Book to Read

Cover	Book	Description	Get it
	Building Secure and Reliable Systemsby Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea and Adam Stubblefield	the least-privilege and blast-radius thinking this review applies to every server: assume the component can be compromised, then design so it cannot do much.	View on Amazon

As an Amazon Associate I earn from qualifying purchases. Links on this page are affiliate links, and I may earn a commission at no extra cost to you.

Wrapping Up

Few servers, narrow permissions, official maintainers: that is the whole recipe. Start with Filesystem and GitHub, add Playwright when you need a browser, and treat every other server as a liability until it earns its keep.

Pick one from this list, install it with the tightest settings above, and see whether you miss the rest.

If you are on the other side of this table and writing your own server, MCP server development in Python covers the build, securing an MCP server covers permissions, and how MCP transports work explains the stdio-versus-HTTP split every entry above depends on. To see which client will run them, read the MCP-capable coding assistants comparison.

Frequently Asked Questions

Which MCP server should a developer install first?

The Filesystem server, because its safety dial is obvious: you choose the folders. It has 13 tools, nine of them read-only, and access is limited to the directories you pass as arguments or that the client supplies as roots. Mount volumes read-only in Docker and start with a directory that contains nothing you would mind losing. It is the easiest server to reason about while you learn how a client behaves.

Are the official MCP reference servers production-ready?

The modelcontextprotocol/servers README calls its reference servers educational examples and explicitly says they are not production-ready solutions. That does not make them useless, but it does mean you should read the source, scope the permissions, and treat them as starting points rather than infrastructure. Several servers that older tutorials still recommend now live in an archive repository, so check the date on any tutorial before copying its config.

Which MCP servers have the best access controls?

GitHub's official server has the strongest control surface: toolsets to pick groups of tools, a read-only mode that skips write tools even when you request them explicitly, documented minimum token scopes, and an enterprise path that must run locally. Sentry and GitHub also offer hosted remote endpoints with OAuth, which keeps long-lived tokens out of local config files. Everything else relies mostly on how narrowly you scope what you pass in.

Is the Playwright MCP server safe to run?

Only inside a boundary you control. Its README says Playwright MCP is not a security boundary and calls browser_run_code_unsafe RCE-equivalent, and its allow and block lists do not affect redirects. Running it headless in a throwaway container against a page you serve yourself is a reasonable laboratory. Do not carry that container's flags, such as disabling the Chromium sandbox, onto your laptop.

Why do some MCP servers require a specific SDK version?

Because the Python SDK had a major version change and servers are pinned to the line they were written against. The Git server's README, for example, pins mcp to a 1.x range and says its port to SDK 2.0 is in progress. A plain pip install mcp installs 2.x, so a careless install can break a working server. Pin the dependency, and read the porting notes before upgrading.

How should I reduce the blast radius of an MCP server?