Best MCP Servers for Windsurf (2026)
Four servers cover almost every real Windsurf workflow. Adding more usually makes Cascade worse, not better.

The best MCP servers for Windsurf in 2026 are a GitHub server, a live-docs server, and one data or package server — three or four total, not a collection. Windsurf's Cascade agent shares one tool budget across everything you connect, so the winning move is picking the few servers that earn their slot and skipping the rest.
Windsurf reads MCP servers from ~/.codeium/windsurf/mcp_config.json, and remote servers use a serverUrl field instead of a command. The setup is easy; the discipline is hard. Below are the servers I actually keep configured, why, and the ones I've since removed.
Start here: the tool-budget math
Every server you add competes for Cascade's attention, so fewer is better. Past roughly 40 active tools, an agent's tool selection visibly degrades — it starts calling the wrong tool or ignoring the right one. That number is well-documented for Cursor, and the same failure mode shows up in Cascade because it's the same underlying constraint: too many tool descriptions crowding the context.
That makes MCP a portfolio problem, not a checklist. The median MCP server exposes about 10 tools, so three or four servers can already sit near the ceiling — and a single large server can eat half the budget on its own. I walk through the arithmetic in the Cursor tool-limit breakdown; it applies directly to Windsurf.
Rule of thumb: add a server only when you can name the workflow it unblocks. If you can't, it's costing you tool-selection quality for nothing.
The one I'd add first: GitHub
Add a GitHub server first, because most coding work in Windsurf touches a repo, an issue, or a PR — and Cascade acting on them directly beats copy-pasting URLs. The GitHub MCP Server is GitHub's official, verified build, covering repos, issues, PRs, and Actions. It runs locally over stdio via Docker, or you can point Windsurf at GitHub's hosted remote endpoint.
One caveat that ties back to the budget: this server is large. Turn off the toolsets you don't use (Actions, security scanning) rather than shipping every tool into Cascade's context. Being official buys you real OAuth and active maintenance — that's the actual value, not raw capability.
If all you want is to stop the model hallucinating a library's API, don't reach for GitHub — reach for docs. GitMCP is a free remote server (SSE, no auth) that turns any public GitHub repo into a live documentation source. Point it at a framework's repo and Cascade answers from the real docs instead of its training cutoff. It's the cheapest hallucination fix on this list.
Data and package servers worth a slot
Add a data server only if your task genuinely reaches into a database or SaaS app — otherwise it's pure budget cost. Two are worth knowing:
- Anyquery runs SQL over local files, databases, and 40+ apps (GitHub, Notion, Chrome, Todoist), then exposes them over stdio. It's a Swiss-army knife: one server, many sources. It's community-built and needs no auth, so scope what it can read.
- Graphlit MCP Server is the heavier option — ingest and RAG over Slack, Discord, Google Drive, Jira, and Linear. It's an API-key server, community-maintained, and earns its place only if you're doing real retrieval across those sources.
For dependency work, Package Registry MCP Server searches NPM, crates.io, NuGet, PyPI, and Go registries plus GitHub Security Advisories — so Cascade suggests versions that exist and flags advisories. It's tiny and no-auth, which makes it a cheap add when you're managing dependencies.
Code-research servers: useful, but pick one
Run at most one code-research server, because they overlap heavily with a plain GitHub server. If you do a lot of cross-repo reading, Octocode wires GitHub, your local filesystem, and LSP intelligence into the agent so it can research code the way a staff engineer does. It uses OAuth and is community-built. It's genuinely useful on large codebases — but it's not cheap on the budget, and it overlaps with a plain GitHub server. Run one code-research path, not two.
Here's how I'd rank them for a typical Windsurf setup:
| Server | Transport | Auth | Add it when |
|---|---|---|---|
| GitHub MCP Server | stdio (Docker) / remote | API key | Almost always — repos, issues, PRs |
| GitMCP | remote SSE | none | You want fewer API hallucinations |
| Anyquery | stdio | none | Your task queries files/DBs/apps |
| Package Registry MCP | stdio | none | You're managing dependencies |
| Octocode | stdio | OAuth | Heavy cross-repo code research |
| Graphlit MCP Server | stdio | API key | You need RAG over team tools |
What to skip
Skip anything you're adding "just in case" — the tool budget makes speculative installs actively harmful in Windsurf. Three specific traps:
- Don't run two servers that do the same job. GitHub plus Octocode plus a third code-search server is triple-counting your budget for overlapping tools. Pick one per job.
- Don't stack every data source at once. Anyquery already spans 40+ apps; adding Graphlit on top is redundant unless you specifically need RAG.
- Don't combine a web-scraping/retrieval server with broad write access in the same session. Poisoned page content plus write credentials is the classic exfiltration path — a real risk, not a hypothetical.
The local-vs-remote choice matters here too. Roughly 90% of MCP servers run locally over stdio, and local-first is a feature: the server sees your machine and sends nothing to a third party. For Windsurf, that means most of your config is command-based; only GitMCP and GitHub's hosted mode use serverUrl. Setup details live on the Windsurf client page, and if you want a merged, budget-checked config, the config generator builds one.
For a broader ranked list beyond Windsurf, see the best MCP servers and the coding-agent picks — the reasoning carries straight over to Cascade.