Windsurf MCP Server Setup for Codebase Graphs

Cascade plans multi-step edits, and it plans them well when the context it retrieves is right. That context comes from Windsurf's local indexing and retrieval: a fast, useful default that still leaves Cascade guessing at structure once a codebase gets large or spans more than one repository. Grep and embeddings tell Cascade what looks related. They don't tell it what actually calls what, what a change breaks, or which consumer three repos away depends on the function it's about to edit.

Symvanta adds the missing layer over MCP: a live code graph with exact callers, dependencies, blast radius, and cross-repo edges, alongside semantic and text search. Cascade keeps its own retrieval and planning; it just stops guessing at the parts a graph answers directly. Nothing here replaces Cascade's index or its planning loop; it gives that loop a second, more precise source to call when the question is "who calls this" rather than "what looks similar to this."

Setting up the Symvanta MCP server in Windsurf

1. Create a free Symvanta account at symvanta.com and connect GitHub.
2. Index the repos Cascade works in. A webhook reindexes on every push, so the graph stays current without a manual trigger. Plans start at $15/month, and Pro (per-seat) ships with a 7-day trial.
3. Add Symvanta as an MCP server. Windsurf's remote-server config lives in ~/.codeium/windsurf/mcp_config.json, and a remote HTTP entry uses a serverUrl field rather than the command/args pair used for local stdio servers:

{
  "mcpServers": {
    "symvanta": {
      "serverUrl": "https://mcp.symvanta.com/mcp"
    }
  }
}

Prefer the UI: open the MCPs icon in the top right of the Cascade panel for the MCP Marketplace, or go to Settings > Cascade > MCP Servers and add a remote server with the same URL. 4. Call any Symvanta tool. The first call opens a browser window for OAuth login and hands Cascade a scoped token. There is no API key to generate or paste into the config, and no static header to manage.

What Cascade gets

Once the server is connected, Cascade has 25 tools available over MCP; the ones it reaches for most during an edit-heavy session are these:

The graph covers TypeScript, JavaScript, Python, Java, Kotlin, C#, Go, Rust, Swift, PHP, and Ruby, so a polyglot repo doesn't lose coverage at the language boundary.

Blast radius before a multi-file edit

Say Cascade is asked to change the signature of a shared validation helper used by three services. Left to its own retrieval, it greps the function name, finds a handful of call sites, edits them, and moves on, unaware of a fourth caller behind an interface or a consumer repo it never opened.

With Symvanta wired in, Cascade calls relate with kind: blast_radius on the helper before touching anything. The result comes back as real edges: which functions call it directly, which route through an interface, and which repos outside the one Cascade has open depend on it. That's the same distinction we cover in blast radius analysis: a grep result is a list of matching lines, a blast radius is the actual graph of what depends on what. Cascade plans the edit against that list instead of the grep result, and the multi-file diff it proposes covers every real caller on the first pass.

For an unfamiliar module, the same pattern runs in reverse: Cascade calls map first to get the module's skeleton, sees which files own which responsibilities, and only then drafts the plan it shows you, the way we walk real open-source repos through their own module maps on the architecture pages. Either direction, the graph call happens before the edit, not as a cleanup step after something breaks in review.

Frequently asked questions