What changes when Cascade can see the board
Windsurf's Cascade agent already has the codebase open. Without MCP, it has no idea what task you're working on, what the acceptance criteria are, or whether the bug it's fixing is even assigned to you — that context lives in a browser tab you have to describe by hand. With WKFGo's MCP server connected, Cascade can call get_context_pack before it writes a line of code and update_status after it's done, in the same conversation where it's editing files.
Config: ~/.codeium/windsurf/mcp_config.json
Windsurf doesn't support a one-click deep link for MCP install — the config is a JSON file you edit directly, unlike Cursor's cursor:// scheme. Open Windsurf Settings → Cascade → MCP Servers, or edit the file directly:
{
"mcpServers": {
"wkfgo": {
"serverUrl": "https://YOUR_INSTANCE/api/mcp",
"headers": {
"Authorization": "Bearer wk_YOUR_KEY"
}
}
}
}
Note the key name: Windsurf's config uses serverUrl, not url. It's a small thing, but it's the single most common reason a working Cursor config copy-pasted into Windsurf fails silently — the field WKFGo needs simply isn't there. Get your wk_… personal key from Settings → Integrations → Connect your AI IDE; one key per developer, never a shared admin token.
Verifying the connection
Restart Windsurf after editing the config — it only reads MCP servers at startup. Then in Cascade, ask:
"Use list_tasks to show what's assigned to me."
An empty or forbidden response almost always means one of two things: the JSON is malformed (trailing comma is the usual culprit), or the key's FeatureAccess doesn't cover the project you're asking about. It's rarely the network — the MCP endpoint is the same one Cursor and Claude Code use successfully.
A working loop inside Cascade
The pattern that holds up in practice: before starting a change, get_context_pack({taskId}) pulls acceptance criteria, related wiki pages, and dependencies into the conversation — Cascade then writes code against real constraints instead of guessing from a vague task title. When the change is ready, submit_for_review moves the task and links the branch, and log_time records the session without a separate timer app.
get_context_pack → write the change → submit_for_review → log_time
None of this requires a slash command or a special mode — it's the same tool-calling loop Cascade already uses for file edits, just pointed at a different server.
Common mistakes
Assuming url and serverUrl are interchangeable. They're not, across IDEs. Each MCP client picked its own field name for the same concept — Cursor and Claude Code use url, Windsurf uses serverUrl, Gemini CLI uses httpUrl. Copying a snippet between IDEs without checking the key name is the most common setup failure.
One developer testing, the rest still in the browser. MCP only pays off once the whole team uses it — a half-adopted integration means the board is current for some tasks and stale for others, which is worse than a consistently stale board because nobody knows which half to trust.
Skipping the FeatureAccess check. The MCP key inherits the same project permissions as the web login. A contractor without finance access gets forbidden on finance tools through MCP too — that's not a bug to route around, it's the access model working as designed.
FAQ
Does this work with Windsurf's local/self-hosted mode?
Yes — MCP is a client-side connection to your WKFGo instance's /api/mcp endpoint; where Windsurf itself runs doesn't matter.
Can I use the same key in Windsurf and Cursor at once? Yes, a personal key isn't tied to one client. Using separate keys per machine makes revoking one device easier if a laptop is lost.
Does this replace WKFGo's Git integration?
No — linking commits to tasks still happens through the TASK-<id> convention in commit messages, independent of whether Cascade or a human wrote the commit.