The Best MCP Servers in 2026: A Practical Directory

If you're asking which MCP servers to install, you probably already have an agent (Claude Code, Claude Desktop, Cursor, Windsurf, or a custom Claude Agent SDK app) and a specific job you want it to do: read your codebase, query a database, file a ticket, browse the web, or move files around safely. This directory is organized around those jobs. For each one you'll find the servers worth trying first, the install command, and a note on where it tends to fall over.

The Model Context Protocol (MCP) is the open standard Anthropic introduced for connecting AI models to external tools, data sources, and systems through a consistent client-server interface. An MCP server exposes a set of tools, resources, and prompts over a standard transport (stdio for local processes, or Streamable HTTP for remote ones). Any MCP-compatible client, Claude Code, Claude Desktop, Claude.ai's connector system, or a third-party agent, can talk to it without custom glue code. That's the whole pitch: write the integration once, and every agent that speaks MCP can use it.

By 2026 the ecosystem has moved well past the initial reference servers. There's a public MCP registry, dozens of vendor-maintained official servers (GitHub, Stripe, Sentry, Notion, Linear, and others ship their own), and a long tail of community servers of wildly varying quality. That's exactly why a directory helps: half the work of adopting MCP is filtering out servers that are unmaintained, insecure, or solving a problem you don't have.

How to evaluate an MCP server before you install it

Before touching any server on this list, run it through a short checklist. This matters more with MCP than with a typical npm dependency because a misbehaving MCP server has full access to whatever tools you grant it, and a malicious one can exfiltrate data through tool outputs your model never questions.

• Who maintains it. Prefer servers published by the vendor whose product it wraps (Stripe's own MCP server for Stripe, GitHub's own for GitHub) over third-party reimplementations. Vendor-maintained servers get updated when the underlying API changes; community forks often don't.
• What scopes it asks for. A GitHub server that wants a fine-grained personal access token scoped to specific repos is safer than one that wants a classic token with full account access. Always create a dedicated token for the MCP server rather than reusing your daily-driver credentials.
• Local (stdio) vs remote (HTTP). Local servers run as a subprocess on your machine and typically only see the credentials you pass in an environment variable. Remote servers run on someone else's infrastructure and see every request you send them. For anything touching source code or financial data, prefer local stdio servers unless the remote host is your own organization's deployment.
• How it handles destructive actions. Good servers make destructive tools (delete, force-push, drop table) explicit and separate from read tools, so you can grant read-only access without accidentally handing over write access too. Check the tool list before wiring it into an agent that runs unattended.
• Recent commit activity. MCP is young enough that "last commit two years ago" (which in this space can mean stale within months of the protocol's own spec revisions) is a real red flag, not a nitpick.

With that filter in place, here's the shortlist by category.

Filesystem and local dev environment

Filesystem server (official reference implementation). The first MCP server most people run. It exposes read, write, move, and search tools scoped to directories you explicitly allow-list, which is the key safety feature: the model can't wander outside the paths you name.

npx -y @modelcontextprotocol/server-filesystem /path/to/project

Use this when you want an agent to work inside a sandboxed folder without giving it shell access. It's the safer alternative to a general-purpose shell tool when the task is "read and edit files in this directory," nothing more.

Git server. Wraps local git operations (status, diff, log, commit, branch) as MCP tools instead of shelling out. Useful in agent setups where you want structured git operations with clear tool boundaries rather than an agent constructing raw git commands, which is where most git accidents happen.

Desktop Commander (or similar shell-and-files servers). A step up from the filesystem server: adds process execution, more flexible file search, and terminal-style operations. Worth it once your workflow outgrows "just edit files" into "run the build, read the output, edit again." Treat it with the same caution as giving an agent a real shell, because that's what it is.

If you're working inside Claude Code itself, note that a lot of what these servers do (file edits, running commands) is already native to the CLI. MCP filesystem and shell servers earn their keep mainly in Claude Desktop, custom Agent SDK apps, or other clients that don't have built-in file and shell tools.

Source control and code hosting

GitHub's official MCP server. Covers issues, pull requests, repository search, file contents, and Actions status through GitHub's API rather than git plumbing. This is the one to reach for when the task is "look at open PRs," "file an issue," or "check why the last CI run failed" rather than local git history work.

claude mcp add --transport http github https://api.githubcopilot.com/mcp/

(Exact install syntax varies by client; check your client's MCP docs for the current recommended transport. GitHub has offered both a hosted remote server and a local Docker-based one, remote is simpler if you trust GitHub's hosting for your repo data.)

GitLab's equivalent server exists for teams on GitLab and covers a similar surface: merge requests, issues, pipelines.

Scope the token tightly. A read-only, repo-scoped token is enough for "summarize open issues"; only grant write scopes to agents you've reviewed for how they use write tools, and never on a repo with force-push enabled unless you've disabled MCP write access to protected branches.

Databases

Postgres MCP server. Read-only by default in most implementations: run a query, get schema info, inspect table structure. This is the server that turns "look at the orders table and tell me why refunds spiked" into an actual conversation instead of you pasting query results by hand.

npx -y @modelcontextprotocol/server-postgres "postgresql://user:pass@host:5432/dbname"

Two rules that matter more here than anywhere else on this list: point it at a read replica or a connection string with a read-only role whenever the agent doesn't need to write, and never point it at a production primary with a superuser credential. Models are good at writing correct SQL and occasionally bad at knowing when a query is expensive; a read-only role protects you from both slow queries and destructive ones.

SQLite server. Same idea, scoped to a local .db file. Handy for prototyping or for agents working against an embedded database in a small app, with none of the network-credential concerns of Postgres.

Vendor-specific database servers (Supabase, PlanetScale, MongoDB, and others ship or endorse their own) are worth checking before reaching for a generic driver-based server, since they tend to expose product-specific concepts (Supabase row-level security, Mongo aggregation pipelines) that a generic SQL server can't.

Web search and browsing

Brave Search MCP server. A straightforward web-search tool: query in, ranked results out. Good default when your agent needs to look something up and you don't need full page rendering, just search results with snippets.

npx -y @modelcontextprotocol/server-brave-search

Requires a Brave Search API key. Other search-provider servers (Exa, Tavily, and similar) follow the same shape and differ mainly in result quality and whether they return raw snippets or pre-summarized content, worth A/B testing against your actual query patterns rather than picking on reputation alone.

Playwright MCP server. This is the one to reach for when search results aren't enough and the agent needs to actually operate a browser: click through a multi-step flow, fill a form, wait for a dynamic page to render, or take a screenshot for visual verification. It exposes Playwright's browser automation as MCP tools, so the model gets structured actions (navigate, click, type, snapshot) instead of having to write and execute browser-automation code itself.

npx -y @playwright/mcp

Puppeteer-based alternatives exist too. If you already have Playwright in your stack for end-to-end tests, using the same engine for your agent's browsing keeps behavior consistent between what your tests exercise and what your agent automates.

Fetch server. The lightest option: given a URL, fetch the page and convert it to clean markdown for the model to read. No JavaScript execution, no clicking, just "get me the content of this page." Cheaper and faster than a full browser server when the target page doesn't need JS to render.

Team tools: issues, docs, chat

Linear's official MCP server. Create and update issues, search by project or assignee, move things across workflow states, straight from a conversation with your agent. This is one of the categories where the productivity gain is obvious and immediate: "file a bug for the checkout timeout I just found and assign it to the payments team" becomes a single instruction instead of a context switch to another app.

Notion's official MCP server. Read and write pages and databases. Strong fit for agents that need to pull specs, write meeting notes, or keep a running log of decisions inside a team's existing Notion workspace rather than a separate file the team won't check.

Slack MCP server. Post messages, search channel history, read threads. Useful for agents that need to notify a channel when a job finishes or pull context from a discussion before acting. Be deliberate about which channels and scopes you grant; a bot token with access to every private channel is more blast radius than most workflows need.

Sentry's official MCP server. Pull error details, stack traces, and issue context directly into an agent's working memory when debugging a production incident. This one is worth calling out specifically because it shortens one of the most common developer loops: see an alert, open Sentry, copy the stack trace, paste it into your AI chat. With the MCP server, the agent can just ask Sentry for the issue directly.

Payments and commerce

Stripe's official MCP server. Exposes read tools (list charges, look up a customer, check subscription status) and, depending on configuration, write tools for creating payment links or refunds. Because this touches real money, treat the write tools the way you'd treat a payments API key in code: least privilege, sandbox mode for anything you're testing, and a human in the loop before any refund or charge actually fires in production. Most teams are well served running this in read-only mode for support and reporting agents and keeping write access out of anything that runs unattended.

Design and observability

Figma's MCP server. Reads design files, components, and specs, useful for agents that generate frontend code from a design and need the exact spacing, color, and component values rather than a screenshot approximation.

Sentry (also listed above) doubles as an observability entry point, and several teams pair it with a logging or metrics server (Datadog and similar vendors have shipped their own) so an agent debugging an incident can pull logs, traces, and error data in one session instead of tab-switching between three dashboards.

Memory and knowledge servers

Memory server (official reference implementation). A simple knowledge-graph store: the agent can save facts as entities and relations and retrieve them in later sessions. This is the building block behind a lot of "the agent remembers what we discussed last week" behavior, though most production setups now build custom memory layers on top of a real vector or graph database instead of the reference implementation, which is intentionally minimal.

Everything server. Not a production tool, this is Anthropic's own reference server that implements every MCP primitive (tools, resources, prompts, sampling) for testing MCP clients against a known-good implementation. If you're building your own MCP server or client, run your work against this one first before pointing it at anything real.

How to actually pick, in order

1. Start with one server that maps to your most repeated manual task. If you copy-paste GitHub issue text into your agent daily, install the GitHub server first. Don't install ten servers on day one; each one is additional attack surface and additional tokens spent on tool definitions the model has to read on every turn.
2. Prefer official, vendor-maintained servers over community reimplementations for anything touching credentials: payments, source control, cloud infrastructure.
3. Scope every credential to the minimum the task needs. Read-only database roles, fine-grained GitHub tokens, sandboxed Stripe keys. This is the single highest-leverage security decision in the whole MCP setup.
4. Separate read-heavy agents from write-capable ones. An agent that summarizes your inbox doesn't need the same Slack token as one that's allowed to post. If your client supports per-server or per-tool permission gating (Claude Code does, through its permissions settings), use it.
5. Re-audit quarterly. MCP servers get new tools added in minor version bumps. A server you approved for read-only search six months ago may have since added a write tool you never reviewed. Check the tool list again after upgrades, don't assume it's frozen.

FAQ

What is an MCP server, in one sentence? It's a small program that exposes a defined set of tools, data resources, or prompts to an AI model over a standard protocol, so any MCP-compatible client can use it without custom integration code.

Do I need to write my own MCP server, or can I use existing ones? For anything covered in this directory, use an existing server. Writing your own only makes sense when you're wrapping an internal system (your company's private API, an internal database with a nonstandard schema) that no public server covers.

Are community MCP servers safe to use? Some are, many aren't actively maintained, and a few have shipped with real security problems (overly broad file access, unsafe command execution, or prompt-injection vectors in tool outputs). Check maintenance activity, read the source if it's short enough to review, and prefer official vendor servers for anything credential-bearing.

What's the difference between a local and a remote MCP server? A local server runs as a subprocess on your machine (usually over stdio) and only has access to what you explicitly configure. A remote server runs on someone else's infrastructure and you connect to it over HTTP, which means your requests, and potentially your data, pass through their systems. Local is the safer default for anything sensitive; remote is often more convenient for hosted SaaS integrations like GitHub or Stripe where a local process wouldn't add much benefit.

Can MCP servers see my entire filesystem or every message in Slack? Only if you configure them to. The filesystem server is scoped to the directories you pass as arguments. Slack, GitHub, and similar servers are scoped by the token or app permissions you grant when you connect them. The server's tool list tells you what's possible; your credential scope tells you what's actually allowed.

How many MCP servers should a typical agent setup run? Fewer than you think. Every connected server adds tool definitions to the model's context on every turn, which costs tokens and can also confuse tool selection when there's overlap (two servers that both expose a "search" tool, for instance). Most well-tuned setups run somewhere between three and eight servers, chosen for the specific workflows that agent actually handles, not "everything that might be useful someday."

Is there an official registry of MCP servers? Yes, Anthropic and the broader MCP community maintain a public registry of known servers alongside the protocol specification. Treat registry listing as a discovery mechanism, not a safety certification, the vetting checklist earlier in this article still applies to anything you find there.

Does using MCP servers slow down my agent? Each server call is a real network or subprocess round trip, so yes, there's latency compared to the model reasoning alone. The bigger cost most teams notice first is context: every connected server's tool descriptions get loaded into the model's context window, so a bloated server list can crowd out useful context and increase cost per turn even before any tool is called. Keep the active server list tight and disconnect ones you're not actively using.