
The best MCP servers for everyday dev tasks in 2026
Most 'best MCP servers' lists are unverified directories. Here's a short, hands-on-tested shortlist for everyday dev work, and what didn't make the cut.
Claude Code CLI, official MCP reference servers (filesystem, git, fetch, memory) via npx, GitHub's github-mcp-server via remote HTTP transport (api.githubcopilot.com/mcp/)
The best MCP servers for everyday dev work are Filesystem, Git, Fetch, and Memory (the four official reference servers most relevant to daily coding tasks) plus GitHub's own actively-maintained server for issue and PR work. That's five servers, not fifty, and every setup command below was actually run, not copied from a README.
Most "best MCP servers" lists are one of two things: a directory dump with no curation, or a ranked listicle that reads like nobody tested anything. Neither tells you what to actually install today. If you're still working out what an MCP server actually does in an agentic coding workflow, start there first. This piece assumes you already know that and just want the shortlist.
The tasks below cover what a solo developer or small team hits constantly: filesystem access, git history, pulling docs into context, remembering project facts across sessions, and working GitHub issues and PRs without leaving the agent.
The shortlist
| Server | What it's for | Setup | Everyday task it solves |
|---|---|---|---|
| Filesystem | Scoped file read/write with access controls | npx -y @modelcontextprotocol/server-filesystem /path/to/project | Give an agent access to exactly one project directory, not your whole home folder |
| Git | Read, search, and manipulate git repos | npx -y @modelcontextprotocol/server-git | Let the agent inspect commit history or a diff directly instead of you pasting git log output into chat |
| Fetch | Web content fetching, converted for LLM use | npx -y @modelcontextprotocol/server-fetch | Pull a library's docs or an API reference into context without copy-pasting a whole page |
| Memory | Knowledge graph-based persistent memory | npx -y @modelcontextprotocol/server-memory | Keep project-specific facts (naming conventions, architecture decisions) available across sessions instead of re-explaining them each time |
| GitHub (official) | Issues, PRs, code, Actions, over 100 tools | claude mcp add --transport http github https://api.githubcopilot.com/mcp/ | Create a PR, triage an issue, or check a workflow run without switching to a browser tab |
The first four are official reference servers maintained directly in the modelcontextprotocol/servers repository. TypeScript-based ones run via npx, Python-based ones via uvx mcp-server-[name]. Each one ships as source in that repository too, so you can read exactly what a server does before granting it access to anything, worth doing at least once for the Filesystem server specifically, since it's the one with write access to your machine.
GitHub's server is different. It's a hosted remote endpoint, not a local process, so it connects over HTTP instead. That's why its setup command uses claude mcp add --transport http instead of npx. If you're deciding between Claude Code and another AI coding agent for this kind of workflow, our real-task comparison covers how each one handles tool integrations like these.
What's actually official, and what's quietly been archived
Here's the part most "best MCP servers" content gets wrong. Several integrations that still show up as official picks on directory sites, Slack, PostgreSQL, Google Drive, Maps, Redis, and SQLite among them, have been moved to the archived servers repository. The MCP project's own documentation is explicit that archived servers are "provided for historical reference only," not something to install expecting active maintenance.
This matters because most of the directory and leaderboard sites ranking MCP servers right now still list these as current. A "best MCP servers" post that recommends the Slack or PostgreSQL integration from the official MCP org, with no note that it's archived, is a sign the list was assembled from an old snapshot. It wasn't checked against what's actually maintained today.
GitHub is the clearest example of why this matters in practice. The server-github integration in the archived repo is exactly that, archived. GitHub's own team maintains a completely separate, actively developed server instead.
It sits at over 32,000 GitHub stars with more than a thousand commits, and it's the one in the shortlist above. An aggregator site's "GitHub MCP server" listing that points at the old integration isn't pointing at the same project.
Setting up the local servers
For the four npx-based servers, add them the same way:
claude mcp add --transport stdio filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/project
claude mcp add --transport stdio git -- npx -y @modelcontextprotocol/server-git
claude mcp add --transport stdio fetch -- npx -y @modelcontextprotocol/server-fetch
claude mcp add --transport stdio memory -- npx -y @modelcontextprotocol/server-memoryThe -- separator matters. Without it, Claude Code tries to parse the server command's own arguments (like the Filesystem server's path argument) as flags meant for claude mcp add itself, and the add fails.
For GitHub's remote server, the command is shorter, since there's no local process to launch:
claude mcp add --transport http github https://api.githubcopilot.com/mcp/This prompts for OAuth or a personal access token on first connection.
Confirming a server actually works
A server showing up in your config isn't the same as a server that's actually connected. Run claude mcp list after adding any server, local or remote, and check the status next to each name.
✔ Connected means it's live. ! Needs authentication means the OAuth or token step didn't finish.
✘ Failed to connect means something in the command or path is wrong. Most often that's a typo in the Filesystem server's path argument, or a missing environment variable for a server that needs one, worth checking both before assuming the server itself is broken.
For the local servers specifically, a ✔ Connected status confirms the process launched, not that it can actually do anything useful yet. Ask the agent to use the tool directly before trusting it in a real task: for the Filesystem server, something as simple as listing the files in the directory you scoped it to; for Git, asking it to summarize the last few commits. If the agent can't answer, the connection status was misleading, and worth checking before it silently fails mid-task later.
What's not on this list, and why
A few servers that show up constantly in "best of" roundups didn't make this one, on purpose:
Sequential Thinking and Time are the other two official reference servers. Both are real and maintained. They solve narrower problems though, structured multi-step reasoning and timezone math, that come up far less often than file, git, fetch, and GitHub access do. Worth knowing they exist, not worth leading a shortlist with.
Any archived integration, Slack, PostgreSQL, Google Drive, Redis, and SQLite included, is excluded here for one reason: it's no longer actively maintained by the MCP project. That's true no matter how often it still shows up on directory sites. A community fork might fill the gap for one of these. That's a separate, individually-verified decision though, not a default pick.
Marketplace aggregator listings like mcp.so or the various "Top 100" leaderboards aren't wrong to browse, they're comprehensive by design. But comprehensive and current aren't the same thing, and neither is a good substitute for actually running the setup command before recommending it.
Picking MCP servers is a scoping decision, not a collection exercise. Five servers that are verified, current, and matched to what you actually do daily beats fifty that might be.