Windsurf with MCP servers: catching up to Cline's tool ecosystem
Published 2026-03-04 by Owner
Windsurf added MCP server support in November 2025. The capability brings Windsurf closer to feature parity with Cline on the external integrations dimension. Setup is similar; the ecosystem of available servers is smaller. Here’s what works.
Setup
In Windsurf:
- Settings → Cascade → MCP Servers
- Add server via JSON or via the (limited) marketplace
- Configure permissions per server
- Restart Cascade for the server to be available
JSON config format matches the standard MCP convention:
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost:5432/myapp_dev"
]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GH_TOKEN}"
}
}
}
}
The env substitution from your shell environment is convenient — you don’t paste tokens into the JSON.
What works well
After a few months of use:
Postgres MCP. Same setup as in Cline. Windsurf’s Cascade picks up the schema and uses it during code generation. Quality of generated SQL is comparable across the two tools.
GitHub MCP. Asking Cascade about your repos, issues, PRs works well. The GitHub MCP server is mature and stable.
Filesystem MCP. Used cautiously (you don’t want Cascade reading arbitrary files), this gives the agent broader file operations than the default.
What works less well
Long-running MCP servers. Cascade’s lifecycle assumes servers start quickly. MCP servers that take >10 seconds to initialize sometimes fail to connect. Workaround: pre-warm the server before opening Windsurf.
Custom MCP servers. The MCP SDK works fine, but Windsurf’s UI for adding non-marketplace servers is more friction than Cline’s. You’re editing JSON; there’s no per-tool permissions interface yet.
Servers that require user interaction during startup. OAuth flows, certificate prompts — these don’t work cleanly. The MCP server has to be already authenticated.
Comparison to Cline’s MCP support
Cline 3.5 added an MCP marketplace. Windsurf’s marketplace is smaller (~10 servers vs Cline’s ~25). Cline has finer-grained permissions per server. Windsurf has the basics.
For a user already deep in Cline’s MCP ecosystem, switching to Windsurf for MCP-heavy work is a downgrade. For users new to MCP who happen to use Windsurf, it’s enough to start.
A specific use case that works
I’ve been using Windsurf + Postgres MCP on a Django project. The flow:
- Cascade can introspect the database schema during code generation
- When asked to write a migration, Cascade reads the current schema and produces a correct migration
- When asked to write a query, Cascade uses the actual column names (no hallucinated columns)
- When asked to debug a query, Cascade can run EXPLAIN against the dev database
This eliminates a class of error that’s common without the integration: code that references columns that don’t exist or queries against tables that don’t exist.
Productivity gain isn’t dramatic, but the error rate drops noticeably. About 1 in 8 queries Cascade produced without MCP had a hallucinated column reference. With MCP: about 1 in 40.
A use case that doesn’t work yet
I tried using Windsurf’s MCP for a Linear integration (project management tool). The Linear MCP server exists; Windsurf can connect to it. But Cascade’s tool use within MCP isn’t quite as fluent as Cline’s — it sometimes makes wrong API calls or misinterprets responses.
After a few frustrating sessions, I went back to using Linear’s web UI for project work and Windsurf for code work. The integration was technically working but not productively.
This may be a Cascade-specific limitation that will improve with model updates. For now, expect uneven results from less-common MCP servers.
Permissions
Windsurf’s MCP permissions are coarser than Cline’s. You can enable or disable a server, but the granular permissions (filesystem scope, network allowlist) aren’t exposed in the UI yet. The MCP servers themselves enforce their own scopes via constructor arguments (e.g., the Postgres server only connects to the URL you provide), but Windsurf doesn’t add an additional layer.
For trusted servers (the official MCP-protocol ones), this is fine. For third-party servers, you’re trusting the server’s own implementation. Be selective.
Cost implications
MCP servers add tokens to the conversation. The schema browse, tool calls, and tool responses all count. For Postgres MCP specifically, expect 1-3k extra tokens per session.
Cascade’s pricing is per-credit (Flow/prompt credits). MCP usage burns credits faster than non-MCP usage. The savings on quality (fewer wrong queries, fewer roundtrip iterations) usually outweighs the extra token cost, but it’s worth noting.
What I’d recommend
For Windsurf users who haven’t tried MCP:
- Start with one server (Postgres or Filesystem are good first picks)
- Use it for two weeks
- Decide if the value justifies the setup time
For most users, the answer will be yes. The integration improves Cascade’s code generation in measurable ways.
For users who need broader MCP support than Windsurf provides, Cline is currently better positioned. The gap may close; Windsurf’s team has signaled MCP is a priority.
Worth migrating tools for?
If MCP support is your primary concern and Cline does what you need, switch to Cline. If you’re using Windsurf for other reasons (Cascade’s workflow fits you better, your team standardized on Windsurf), the MCP support is good enough not to be a blocker.
The category isn’t yet a “right tool only” decision. Both Windsurf and Cline have credible MCP implementations now. Pick based on the larger fit of the tool to your workflow, not on MCP-specific differentiators.