Best MCP Servers for Developers (2026)

The best MCP servers for developers are the handful that repay the tool-list slots they consume: GitHub's official server, a filesystem server, a docs source to stop hallucinations, and one or two SQL/code-research picks. Everything else is optional. Most of these run locally as a subprocess over stdio, so adding one is cheap to run — but not cheap to think about.

This is an opinionated developer shortlist grounded in what each server actually exposes: transport, auth, and official-vs-community, because in a young ecosystem those boring fields decide more than feature lists. For every pick I say what it does and when to skip it. Browse the full best MCP servers list or the capabilities view if your stack differs.

The tool-budget rule that decides everything

Pick fewer servers than you want to. Roughly 40 tools is where most MCP clients start losing the plot on which tool to call, and that ceiling is shared across every server you install — not per server. So the real skill isn't finding servers, it's rationing the budget.

Two facts set the constraint. Around 90% of MCP servers run locally over stdio, so running one is trivial; the cost is attention, not CPU. And a single server can eat a big slice of your budget on its own — Octocode alone ships 14 tools. Do the arithmetic before you install: three or four focused servers beats twelve, every time.

GitHub MCP Server — the one non-negotiable

If your agent touches repos, install GitHub's official server and stop shopping. It's genuinely first-party — built by GitHub, replacing the deprecated @modelcontextprotocol/server-github reference package — which is what you want for something holding a write-capable token. It covers repos, code, issues, PRs, and Actions.

It's a stdio server that runs in Docker and authenticates with a personal access token. The one thing to get right: mint a fine-grained PAT scoped to only the repos you work in, because a default token grants broad read/write across everything you can see. If your org prefers OAuth, the hosted remote variant uses it and never stores a token locally — the usual local vs remote trade-off. Token blast radius is the whole ballgame here; see MCP security: what actually matters.

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-fine-grained-pat>" }
    }
  }
}

MCP Filesystem Server — safe local file access

Add the MCP Filesystem Server so your agent can read, write, search, and move files without you pasting them into chat. It's a small Go stdio server, community-maintained, with no auth — the security model is directory scoping, not credentials.

That scoping is the point. Access is restricted to the directories you pass as arguments, and the server validates paths to block directory-traversal and resolves symlinks with checks. Pass the narrowest set of directories that gets the job done — the agent can write and delete inside them, so ~/ is a bad argument.

{
  "mcpServers": {
    "filesystem": {
      "command": "mcp-filesystem-server",
      "args": ["/path/to/project"]
    }
  }
}

GitMCP — free, zero-auth, kills library hallucinations

When your assistant invents an API a library never had, GitMCP is the fix. It turns any public GitHub repo or Pages site into a live documentation source the model fetches on demand, so answers come from the real README and docs instead of training-cutoff memory.

This is the one remote pick I keep. It's a hosted SSE service at https://gitmcp.io/docs (or https://gitmcp.io/{owner}/{repo}) with no auth — no credentials leave your machine, so it's safe by construction, but it only sees public content. It's community-maintained, not official. Grounding beats guessing: this is retrieval, not a general API bridge, and the distinction matters — see MCP vs API.

Two picks for reading and querying: Octocode and Anyquery

Add these when comprehension or querying is the actual task; both are budget-heavy, so don't run them together with everything else. Octocode is for understanding an unfamiliar codebase, not just grepping it — it wires GitHub search, local ripgrep, and LSP intelligence (Go to Definition, Find References) into one research loop across 14 tools. It's stdio, community-built, and authenticates via a GitHub OAuth device flow (octocode login), with --hostname for GitHub Enterprise.

Anyquery lets the model run SQL over files, databases, and 40+ apps — CSV, Parquet, GitHub, Notion, Chrome history, Todoist. It's a stdio, no-auth SQLite engine (brew install anyquery). One sharp edge: its executeQuery tool can run INSERT/UPDATE/DELETE on sources that support writes, so the model can mutate connected data. Point it at read-only sources unless you mean it.

Quick comparison

Server	Official?	Transport	Auth	Add it when
GitHub	Official	stdio (Docker)	PAT / OAuth (remote)	The agent touches your repos
Filesystem	Community	stdio	None (dir-scoped)	Agent edits local files
GitMCP	Community	remote SSE	None	Killing library hallucinations
Octocode	Community	stdio	GitHub OAuth	Researching unfamiliar code (14 tools)
Anyquery	Community	stdio	None	SQL across files/apps (writes possible)
Portainer	Official	stdio	API key	You run Docker/Kubernetes via Portainer

If you're on the ops side: Portainer MCP

Add Portainer MCP only if you already run Portainer to manage containers. It's the official Portainer server, generated from their OpenAPI spec, and it exposes the Portainer REST API as tools so the agent can list environments, manage GitOps workflows, and troubleshoot Docker and Kubernetes resources.

It's stdio and needs an API key (My Account → Access tokens in Portainer). Skip it entirely if you don't use Portainer — it's not a general Docker server, it's a bridge to a specific control plane. For pure coding work it's dead weight against your tool budget.

What to skip, and how to install

Skip anything that duplicates a tool you already have, skip 20-plus-tool "kitchen-sink" servers unless that server is your main workflow, and skip ops tooling like Portainer when you're just writing code. You pay attention-tax on every exposed tool whether you call it or not, so a lean set of three or four beats a crowded one that confuses tool selection.

To install, most clients take a .mcp.json (or client-specific config) with an mcpServers object — see how to add an MCP server, or start from the config generator if you'd rather not hand-write JSON. My default developer set: GitHub + Filesystem + GitMCP — three servers, well under budget, fixing the failures you actually hit. Add Octocode or Anyquery only when research or querying becomes the job, and check the servers for coding agents cut if your workflow is agent-heavy.