Best MCP servers for Claude Desktop (2026)
A tight, opinionated shortlist that respects Claude Desktop's tool budget — plus the config to run it.

The best MCP servers for Claude Desktop are the ones that pay for their tool slots: GitHub for code work, GitMCP to kill API hallucinations, Anyquery for your local data, and a package-registry server so Claude stops guessing version numbers. Claude Desktop has a tight tool budget and no native remote transport, so the winning move is a small, deliberate set of local stdio servers plus one or two remotes bridged in. This is the shortlist I actually run, why each earns its place, and what to skip.
The one constraint that decides everything: the tool budget
Every server you add spends from a shared budget, so pick fewer, better ones. Most clients start degrading tool selection somewhere around 40 exposed tools — the model gets slower and picks the wrong tool more often as the list grows. That math is covered in the Cursor tool-limit math, and Claude Desktop is no exception.
Two consequences follow. First, a single "kitchen-sink" server can blow your whole budget alone. Second, tool counts are a real selection criterion, not a footnote.
For scale: Graphlit lists 26 tools, Package Registry exposes 16, and Octocode ships 14. Add two of those and you are already near the wall. Enable servers per-project, not globally, and disable the ones you are not using this week.
How Claude Desktop loads servers (and the one gotcha)
Claude Desktop runs MCP servers as local processes over stdio, defined in one JSON file — and it has no built-in remote transport. On macOS that file is ~/Library/Application Support/Claude/claude_desktop_config.json; on Windows it is %APPDATA%\Claude\claude_desktop_config.json. If it doesn't exist, create it; Claude won't make it for you.
This is normal, not a limitation. Roughly 90% of MCP servers run locally over stdio, so a stdio-first client covers almost the whole ecosystem. The local vs remote MCP trade-off explains why local is the default.
The gotcha: remote servers (SSE/HTTP) can't be added directly. You bridge them through the mcp-remote proxy, which Claude launches as a local command that talks to the remote URL. The Claude Desktop setup page shows the exact form, and after any edit you must fully quit and reopen the app.
The shortlist: what to add and why
The servers below cover the four jobs that actually come up in a Claude Desktop chat — code, docs, data, and dependencies — without draining the tool budget. All are verified in the directory; most are local stdio, one is a remote you bridge.
| Server | Job | Transport | Tools | Auth | Official |
|---|---|---|---|---|---|
| GitHub MCP Server | Repos, issues, PRs, Actions | stdio (Docker) / remote | 7 toolsets | PAT / OAuth | Yes |
| GitMCP | Live docs from any repo | SSE (remote) | ~7 | None | No |
| Anyquery | SQL over files + 40+ apps | stdio | 3 | None | No |
| Octocode | Deep code research | stdio | 14 | OAuth | No |
| Package Registry | Package/version lookups | stdio | 16 | None | No |
| Graphlit | RAG over Slack/Drive/Jira | stdio | 26 | API key | No |
GitHub MCP Server is the anchor. It's GitHub's official server (Go, MIT) and replaces the deprecated @modelcontextprotocol/server-github reference package. Its tools are grouped into toolsets — repos, issues, pull requests, Actions — so you can enable only what you need instead of all 7 at once. Run it locally via Docker with a personal access token, or use GitHub's hosted remote (OAuth) bridged through mcp-remote.
GitMCP is the highest value-per-slot server on this list. It's a free, community, hosted remote that turns any public GitHub repo into a live documentation source, so Claude answers from real README/llms.txt/docs instead of inventing APIs. It's the fastest way to cut library hallucinations. Point it at a specific repo with https://gitmcp.io/{owner}/{repo}. No credentials, no private repos.
Anyquery is the local-data pick: a SQLite engine that runs SQL over CSV/JSON/Parquet files, databases, and 40+ apps (Notion, Chrome history, Todoist, GitHub) via plugins. One caveat that matters: its query tool can run INSERT/UPDATE/DELETE on tables that support writes, so the model can modify connected data. Keep it read-only unless you mean it.
Package Registry is the cheap insurance policy. It searches NPM, crates.io, PyPI, NuGet, and Go registries plus the GitHub Security Advisory database, so Claude stops guessing whether a version exists. No auth, 16 tools — trim to the ecosystems you use.
What to skip (for now)
Skip the heavy aggregators and duplicate servers unless you have a specific job for them. Graphlit is genuinely good for RAG across Slack, Drive, Jira, and Linear — but 26 tools plus a Graphlit account is a lot to spend on a general chat setup. Add it when knowledge-base search is the point, not as a default.
Skip Octocode unless you do serious cross-repo code research; its 14 tools (GitHub search, local ripgrep, LSP go-to-definition) overlap with GitHub MCP Server for everyday work. It's excellent for a coding-agent stack — see the best MCP servers for coding agents — but redundant next to GitHub for casual use.
Skip anything that duplicates a job you've already filled. Two GitHub servers, two doc servers, two shell servers — pick one each. Every duplicate is a tax on tool selection with no upside.
A minimal config that fits the budget
Start with two local servers and add from there. This is GitHub (Docker) plus Package Registry — enough for real code and dependency work while leaving budget to spare:
{
"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-github-pat>" }
},
"package-registry": {
"command": "npx",
"args": ["package-registry-mcp"]
}
}
}
Mint a fine-grained PAT scoped to only the repos you need — a broad token hands Claude read/write across everything. If hand-editing JSON isn't your thing, the config generator builds valid blocks per client, and each server's page carries a ready-to-paste snippet. For failures after a restart, the troubleshooting guide covers the usual suspects.