Zed MCP Server: Codebase Graph Setup

Zed's agent panel is fast because Zed is fast: a Rust editor with the model wired straight into the open worktree. When the agent needs context, it reads the files you have open and greps the tree. That holds up until a question depends on structure the text doesn't show: which functions call this one, what a signature change breaks, which module in another repo imports it. Grep returns matching lines. It doesn't return edges.

Symvanta supplies those edges over MCP: a live code graph where nodes are symbols and edges are calls, imports, implements, and instantiates, queried by Zed's agent like any other tool. Zed keeps reading and editing the way it already does. The graph answers the questions grep can't: exact symbol resolution, real callers, and blast radius before an edit lands.

Set up MCP servers in Zed

Zed calls MCP servers context servers, and there are two ways to get one running. The first is the extension route: open Settings > AI > MCP Servers, click Add Server in the page header, and pick Install from Extensions. The same catalog is in the command palette under zed: extensions and on the extensions directory at zed.dev filtered to context servers. GitHub, Puppeteer, Brave Search, Prisma, and Figma all ship as extensions, and most open a setup modal on install asking for whatever credential they need (the GitHub one wants a personal access token).

The second is a custom server, for anything without an extension. Add Server offers Add Local Server and Add Remote Server, and both write into the context_servers object in settings.json, which you can also edit by hand with the zed: open settings file action. A local server is a command Zed spawns over stdio. A remote server is a URL Zed talks to over HTTP:

{
  "context_servers": {
    "local-mcp-server": {
      "command": "some-command",
      "args": ["arg-1", "arg-2"],
      "env": {}
    },
    "remote-mcp-server": {
      "url": "https://example.com/mcp",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

Leave headers out of a remote entry and Zed runs the standard MCP OAuth flow in your browser on the first call, which is the path any server with real accounts behind it takes. Zed supports the tools and prompts halves of MCP and reloads a server's tool list on its own when the server changes what it offers. Approval is governed by agent.tool_permissions.default (confirm, allow, or deny, on v0.224.0 and newer), and a single tool can be named as mcp:<server>:<tool_name> when you want one exception to the default.

Symvanta is the remote shape with no headers block, because the login runs over OAuth. Here is the whole setup.

Setting up the Symvanta MCP server in Zed

1. Create a free Symvanta account at symvanta.com and connect GitHub.
2. Index the repos your agent works in. A webhook reindexes on every push, so the graph stays current without a manual trigger. Plans start at $19/month, and Pro (per-seat) ships with a 7-day trial.
3. Add Symvanta as a remote MCP server. Zed keys MCP servers under context_servers in settings.json (open it with the zed: open settings file action). A remote server uses a url field:

{
  "context_servers": {
    "symvanta": {
      "url": "https://mcp.symvanta.com/mcp"
    }
  }
}

Prefer the UI: open Settings > AI > MCP Servers (also reachable through the agent: open settings action), click Add Server in the page header, choose Add Remote Server, and paste the same URL. 4. Call any Symvanta tool. Because the config carries no Authorization header, Zed runs the standard MCP OAuth flow (2.0 with PKCE) in your browser on the first tool call. Approve the connection once and Zed holds the scoped session for later calls. There's no API key to generate and no static header to paste.

Native remote MCP over URL landed in Zed in late 2025. On an older build that only speaks stdio, bridge the same endpoint with mcp-remote: set "command": "npx" and "args": ["-y", "mcp-remote", "https://mcp.symvanta.com/mcp"] instead of the url field, and let the bridge handle the HTTP transport and OAuth.

What Zed's agent gets

Once the server is connected, Zed's agent 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 Rust service that calls into a TypeScript package keeps its edges across the language boundary. The tools above are a subset; the rest cover architecture maps, diff impact, test lookup, scope estimates, and branch-aware reads.

Blast radius before you touch a shared function

Say the agent is asked to change the signature of a validateInput helper used by both the payment flow and the auth flow, three files apart, in a repo it has only partly read. Reading and grepping finds every line containing validateInput, including a comment and an unrelated method with the same name on a different class. It doesn't say which calls are real.

With Symvanta wired in, the agent calls relate with kind: blast_radius on the function first. That returns the actual call sites across both flows, including any that route through an interface with a different name at the call site, before a single line changes. The distinction is the one we cover in blast radius analysis: a grep result is a list of matching lines, a blast radius is the graph of what depends on what. The agent plans the edit against that list, and the multi-file diff it proposes covers every real caller on the first pass.

The same pattern applies to routing: if two controllers define near-duplicate handlers for /api/users/:id, find_http_route resolves the exact one that method and path hit. For why an embeddings index and a call graph answer different questions, see code embeddings vs. code graph, and the same graph runs against real open-source repos on the architecture pages.

Frequently asked questions

Book a 15-minute demo