Best MCP servers for production agents
Most lists sort by GitHub stars. We run these servers in client builds and in our own workflow, so this one sorts by what happens when a call fails.
The short answer
Use the vendor-run server where one exists (GitHub, Slack, Playwright), the current MCP reference server for filesystem and fetch, and a patched fork for Postgres, never the original reference server.
Star count tells you a server was popular at some point. It says nothing about who fixed the last security report or whether a half-finished call leaves your database in a strange state.
We built MCP tools into Go4Gr8, a multi-tenant coaching platform, and the choice that mattered was scoping and auth, not feature count.
How this ranking was made
Verified
We ranked on who maintains it, its auth model and how it fails, read from each project's own repo and changelog on 14 August 2026. Every claim below links to its source.
GitHub stars were excluded on purpose. A server can be popular and unmaintained at once. The modelcontextprotocol/servers repository moved thirteen reference servers to an archive for that reason.
- Who maintains it now
- Vendor-run, a current reference server, or a fork nobody owns.
- Auth model
- OAuth against the real service, a scoped token, or one key with no limit.
- How it fails
- Whether a bad call is rejected cleanly or has a known bypass, like a read-only mode that isn't.
- Access scope
- Whether the server can be limited to one directory, one repo or one workspace, or reaches everything by default.
The seven at a glance
Read from each project's own repository and changelog on 14 August 2026.
| Server | Maintained by | Auth | Pick it when |
|---|---|---|---|
| Filesystem | MCP reference repo | Directory allowlist | An agent needs local file access |
| GitHub (official remote) | GitHub | OAuth 2.1 + PKCE | Issues, PRs, CI checks |
| Slack (official) | Slack | Hosted, workspace OAuth | Reading or posting to channels |
| Playwright | Microsoft | None (local browser) | An agent has to click through a page |
| Fetch | MCP reference repo | None | Pulling and converting a web page |
| Postgres (patched fork) | Community fork, not Anthropic | Connection string, scope it yourself | You have already read the CVE below |
| Single-maintainer hobby servers | One person, unclear cadence | Varies, often blanket keys | Almost never, in production |
The ranking
Ordered by how safely each one runs unattended.
Scoped local file access, actively maintained
Start here for any agent that reads or writes local files. Filesystem is one of seven servers still listed as current in the modelcontextprotocol/servers repository. It gets the attention the archived ones lost.
Its docs describe a simple rule: you pass an allowed-directory list at startup, and the server refuses paths outside it. That is the whole reason to use it over a shell tool with no such check.
It is still a reference server. The same project's docs call these teaching examples, not hardened software. Set the allowlist to the narrowest folder the task needs, and treat the default as no limit at all.
Best for
- Coding agents that need to read or edit a repository
- Any local task where the directory boundary is known upfront
Not for
- Multi-tenant systems where different users need different scopes at runtime
- Anything you cannot restart to change the allowlist
- Status
- Current reference server
- Access limit
- Directory allowlist at startup
Hosted by GitHub, OAuth instead of a bare key
This is the server to use for GitHub. It replaced the older reference server for good reason. GitHub's changelog announced it as generally available, hosted at api.githubcopilot.com, with nothing to install or run locally.
Login runs on OAuth 2.1 with PKCE. A client signs in through a browser once, instead of holding a long-lived access token in a config file. GitHub's own docs list this as the alternative to those tokens.
You can pick which tool group loads, so an agent triaging issues does not also get access to CI or safety settings. Load the group the task needs and leave the rest off.
Best for
- Coding agents that open PRs, triage issues or read CI results
- Teams that want to stop handing out personal access tokens
Not for
- Fully offline environments with no outbound network access
- Hosted at
- api.githubcopilot.com/mcp/
- Auth
- OAuth 2.1 + PKCE
- 03
Slack (official)
Vendor-hosted, replaced an unmaintained community version
Use Slack's own server, not the reference implementation. The original @modelcontextprotocol/server-slack shipped as an early local server. It was archived later, along with twelve other reference servers including Postgres and Google Drive.
Slack now runs its own remote, hosted server behind workspace OAuth. That moves the login out of a local config file and puts channel access under the same admin controls a workspace already uses.
Community forks of the old server still circulate and still work. The vendor-run one is the version someone is actually watching.
Best for
- Reading or posting to channels as part of an approved workspace app
- Teams already using Slack's own OAuth for other tools
Not for
- Workspaces that require every integration to be self-hosted
- Auth
- Workspace OAuth, hosted
- Predecessor status
- Archived, unmaintained
Browser automation without a vision model
Reach for this when an agent has to click through a real web page. Microsoft maintains the server directly. It drives Playwright's own browser rather than screenshots fed to a vision model.
It reads the page as a labelled snapshot, not pixels. The model reads element names and roles, rather than guessing where things sit on a picture.
Nothing here checks whether the site being automated wants a bot on it. Point it at systems you own or have permission to script, the same rule that applied before MCP existed.
Best for
- Testing your own web app from an agent
- Filling forms or extracting data from a page with no API
Not for
- Sites whose terms forbid automated access
- High-volume scraping, which needs its own infrastructure
- Maintainer
- Microsoft
- Reads pages via
- Accessibility snapshots
- 05
Fetch ↗
Plain web retrieval, kept simple on purpose
Use this when an agent just needs to pull a page and read it. Fetch is another of the seven servers still active in the reference repository. Its job is narrow: retrieve a URL and convert it to a form a model can read.
It needs no login and cannot write anything. That is why it is safe to hand to an agent with wide reach elsewhere. Little here can go wrong beyond a slow or blocked site.
Best for
- Research agents pulling public pages for context
- Any flow that needs read access with no key to manage
Not for
- Sites behind a login
- JavaScript-heavy pages that need real rendering, which is Playwright's job
- Status
- Current reference server
- Auth
- None
Only after you have moved off the original
The original @modelcontextprotocol/server-postgres is the clearest warning on this list. Its read-only mode could be bypassed with a single COMMIT statement inside the query text. A crafted input could end the read-only transaction early and run arbitrary SQL after it.
That server was archived on GitHub, npm and Docker Hub. The package still sees tens of thousands of downloads a week. Most people running it never noticed it was pulled.
Patched forks exist, listed on postgres-mcp.dev's own safety page. Whichever one you pick, put it behind a read-only database role as well as any read-only flag the server claims to have. A flag an agent's own input can defeat is not a real limit.
Best for
- Read access to a database, once behind a role Postgres itself enforces
- Teams who have already checked which fork they are running
Not for
- Any deployment still pointed at the original, archived server
- Write access from an agent with no human approval step
- Known issue
- Read-only bypass via COMMIT injection
- Original status
- Archived, still widely downloaded
- 07
Single-maintainer hobby servers
Where stars-based lists send you, and where we do not
Most stars-sorted MCP lists put a project like this near the top. Star count rewards being first and easy to demo, not being maintained. A single maintainer with no company behind it can stop responding to a security report at any point, with no notice.
This is not a named product. It is the shape to check for: one committer, a README with no safety section, and a wide key passed straight through with no limit.
Fine for a personal test on your own machine. Wrong for anything that touches a client's data or a live key.
Best for
- A weekend test of what MCP can do
- Prototyping a tool shape before writing your own
Not for
- Any server holding a live key or password
- Multi-tenant systems, where scoping mistakes reach other customers
- Maintenance risk
- Single point of failure
- Call arrivesA model decides to use the tool.
- AuthScoped token, or one shared secret?
- BoundaryCan it reach data outside its job?
- Bad inputDoes a crafted argument break the safety flag?
- OwnerWho ships the fix when it does?
The Postgres reference server failed at the fourth box. Its read-only flag did not survive a crafted query.
When you should not use an MCP server at all
MCP earns its cost when more than one AI client needs the same system, or when that number is about to grow. Wiring a server takes real work: setting the limits, watching for a bug report, and keeping it up to date.
For a single product talking to one model, plain tool calling in your own code does the same job. Fewer moving parts, one fewer process to run.
- 01One client, one system? Call your API directly and skip the protocol layer.
- 02Handling money or destructive writes? Keep a human approval step in front of the tool, whichever server you run.
- 03No one owns updating the server? That is the real cost, and it shows up as the Postgres story above.
What we run in production
MCP and agent layer
Around the agent
Multi-tenant agent tooling, where scoping was the whole product
Wiring a system into an agent?
Tell us what the server needs to touch and who else's data sits near it. We will name which of these fits and how to scope it. Scoping calls cost nothing.
Questions engineers ask
01Is the official MCP reference server always the safest choice?
No. Filesystem and Fetch are kept up to date and fine to use. Postgres is the opposite case: its reference server had a read-only bypass and was archived. Check a server's current status before assuming reference means safe.
02Should we self-host or use a vendor's hosted MCP server?
Use the vendor's hosted server when one exists, like GitHub or Slack. It puts auth, rate limits and patching on a team that owns the underlying product, not on whoever last updated a community fork.
03Why isn't [a popular community server] on this list?
We ranked on who maintains it and its auth model, not popularity. A server with many installs and one silent maintainer is exactly the pattern this ranking is built to flag, whatever its star count says.
04How do we know if an MCP server is still maintained?
Check the repo for a recent commit, a stated safety policy, and whether it has been archived. The modelcontextprotocol/servers repo moved thirteen servers to a separate archive for this reason. Archived status is a fact you can check, not a guess.
05Does a read-only flag on an MCP server actually stop writes?
Not always. The Postgres reference server's read-only mode could be ended mid-query with a COMMIT statement, letting the next line run outside it. Set read-only access at the database role level too, not only inside the server's own flag.
