Compare

Code Graph MCP Servers Compared: Hosted, Instance, Local

· Last verified

A code graph MCP server is the part of an agent session that answers relationship questions: who calls this symbol, what does it depend on, and what does a change break before it ships. Three architectures put a graph behind the same protocol, and they differ on the details that decide the pick: where the parsing runs, who owns the index, how far past one repository the agent can see, and what a team has to operate. This page compares a hosted graph endpoint (Symvanta), the MCP server that ships with a Sourcegraph instance you run, and local open-source servers that resolve symbols through a language server, with Serena as the reference example. The Sourcegraph MCP server comparison covers that server tool by tool, and where the index lives covers the hosted versus local decision in general.

What a code graph server answers

A file server returns source text. A semantic index returns similar snippets. A code graph returns relationships between specific symbols, resolved rather than ranked: who calls a function, what a module imports, which route serves a path, what a signature change touches. The difference between resemblance and connectivity is covered in embeddings versus the code graph, and it is the line that separates the three options below from a search-only MCP server.

The exact vocabulary differs by product. Symvanta parses each repository into symbols and typed relationships: calls, imports, implements, and instantiates, plus transport edges such as HTTP call to route, SQL access to ORM model, and queue producer to consumer. An agent asks for callers with relate and kind: callers, dependencies with kind: dependencies, and impact with kind: blast_radius, and gets resolved edges with source locations back. Sourcegraph's precise navigation resolves definitions and references from SCIP indexes, which it uploads per repository, and joins a reference to a definition across repositories through the symbol's package name and version in that index (Cross-repository code navigation). A local server does the same job through the language servers on your machine, using the protocol those servers implement, LSP.

The three architectures

Hosted graph endpoint: Symvanta

Symvanta runs the whole pipeline and exposes one URL, https://mcp.symvanta.com/mcp. There is no instance to provision, no indexer to schedule, and no site configuration decision.

  • Hosting. Hosted by default, with Pro and Enterprise workspaces able to bring their own encryption key and an on-prem bundle on Enterprise for teams that need the pipeline inside their own infrastructure.
  • Authentication. OAuth 2.0 with PKCE for interactive clients, and a scoped API credential for CI runners and cloud agents that cannot complete a browser login.
  • Scope. Every repository connected to a project joins one graph, which is what makes cross-repository answers possible: consumers of a shared library, callers in another repo, a route in one service matched to an HTTP call in another.
  • Freshness and branches. Reindexing is triggered by a GitHub push webhook, tracked feature branches are indexed so a session can pin to one, and uncommitted working-tree edits go in through a ref call that overlays them.
  • Availability. Every plan includes the endpoint. Starter is $19 per month, the trial runs 7 days, and it does not ask for a credit card.

The tool set is graph-shaped throughout: find_node resolves a symbol, relate walks callers, dependencies, or blast radius, find_http_route maps a method and path to its handler, and diff_impact reports what a change set affects. The MCP endpoint page lists the client setup for each agent.

Instance search and navigation: the Sourcegraph MCP server

Sourcegraph ships an MCP server that connects an agent to a Sourcegraph instance. It became generally available on February 25, 2026, with OAuth Dynamic Client Registration enabled by default, and it runs against your own deployment: a client points at https://your-sourcegraph-instance.com/.api/mcp, not at a shared vendor endpoint (Sourcegraph changelog, MCP server GA). The documentation lists it as supported on Enterprise plans (Sourcegraph MCP server docs).

  • Hosting. The instance is the deployment. Sourcegraph Cloud provisions and manages single-tenant instances, and self-hosted runs on Docker Compose or Kubernetes in your infrastructure (Sourcegraph Cloud, self-hosted).
  • Authentication. OAuth 2.0 through Dynamic Client Registration or pre-registered clients, or Sourcegraph access tokens. The MCP#ACCESS permission gates who can use MCP at all, and it stays separate from repository permissions, so a user still reads only the repositories they already have access to.
  • Scope. The repositories indexed in the instance, filtered by each user's permissions. Precision depends on SCIP data: precise navigation resolves definitions and references from SCIP indexes uploaded per repository, and falls back to search-based navigation where a precise index is not available (Precise Code Navigation).
  • Branches. Revisions are arguments on individual tool calls, and the full endpoint adds a compare_revisions tool.
  • Tools. Three endpoints split the surface: /.api/mcp carries search, repository, history, and Deep Search reading tools, /.api/mcp/all adds go_to_definition, find_references, list_refs, and compare_revisions, and /.api/mcp/deepsearch carries the Deep Search agent tools alone.

One documentation-level difference is worth stating precisely, because it is a fair question on a comparison page: Sourcegraph's public docs describe search, navigation, history, and analysis tools, and they do not present a transitive blast-radius primitive. That is a statement about what the docs list, not a claim that an impact analysis cannot be assembled from search and code intelligence inside the agent.

Local open source: LSP-backed servers

A local code-graph server is a process you start on the same machine as the code. Serena is the clearest example: MIT licensed, installed locally, doing semantic retrieval and editing at the symbol level through language servers that implement LSP, with support for over 40 programming languages on the free backend (oraios/serena). No account, no upload, nothing to pay.

  • Hosting. Your laptop, your checkout. The client spawns the server over stdio and the language servers answer from the working copy on disk.
  • Authentication. Your operating-system account. The MCP authorization spec draws the line here: HTTP transports follow the OAuth specification, while stdio servers retrieve credentials from the environment (MCP specification, Authorization).
  • Scope. Whatever is on disk. A question that crosses a repository boundary needs both repositories checked out, both indexed, and something you build to join them.
  • Freshness. The strongest local property: the server reads the file you just saved, so there is no reindex window to wait on.
  • Setup. Real work, spread across every machine and every language: a language server per language, plus the client configuration that spawns the server.

Side by side

Symvanta (hosted graph) Sourcegraph MCP server Local OSS (Serena as example)
Hosting Hosted endpoint, nothing to provision; on-prem bundle on Enterprise Your instance, Cloud or self-hosted A process on your machine, usually stdio
Authentication OAuth 2.0 (PKCE), or a scoped API credential for CI OAuth 2.0 with DCR or pre-registered clients, or access tokens; MCP#ACCESS permission Your user account; credentials from the environment
Repository scope Every repository connected to a project, joined into one graph Repositories indexed in the instance, filtered by user permissions What is on disk; cross-repo joins are yours to build
Freshness Push webhook reindex, plus a working-tree overlay for uncommitted edits The instance's indexing plus the SCIP indexes uploaded per repository Reads the working copy directly
Branch awareness Tracked feature branches, pinnable per session Revision arguments on tool calls, compare_revisions on the full endpoint Whatever the checkout has
Exact relationships relate with kind: callers, dependencies, or blast_radius go_to_definition, find_references, list_refs on the full endpoint Symbol resolution through the language server; call hierarchy depends on the server
Maintenance Vendor operates the pipeline; you maintain connections and client config You operate the instance: upgrades, indexing, site configuration You install and update a language server per language, per machine
Privacy Code is parsed on Symvanta infrastructure by default; BYOK encryption and an on-prem bundle are the private options Code stays in your instance, under your deployment and permission model Nothing leaves the machine
Setup Connect a repository, add the URL, sign in Provision or reuse an instance, index repositories, configure the site, point the client Install the server and its language servers, add a stdio command
Price Included in every plan; Starter at $19 per month Enterprise plans Free and open source; you pay in setup and machine time

How to choose

  • Choose the hosted graph if the questions cross repositories. Consumers of a shared library, callers in another service, and route matching between two codebases are the queries a single-repo index cannot answer by construction, and they are the ones a blast-radius review turns on.
  • Choose the Sourcegraph MCP server if the instance already exists. If your organization runs Sourcegraph Enterprise and wants agents to query the same indexes your engineers use, under the same permissions and admin controls, the MCP server is a direct line into that platform. The wider platform comparison sits on the Sourcegraph alternative page.
  • Choose a local server when the code cannot leave. Air-gapped networks, classified work, or a contract that forbids egress make the decision for you. A local LSP-backed server is also a reasonable fit for one developer on one moderate repository, where no cross-repo question ever comes up.
  • Consider both. A local server for the file you are editing plus a hosted graph for questions that reach past your checkout is a normal setup, because MCP clients hold several servers at once. The find callers workflow is the clearest case: the local server knows your working copy, and the graph knows the repositories you never checked out.

Honest limitations

  • Hosted. Code is parsed on Symvanta infrastructure by default, so teams with a no-egress rule need the Enterprise on-prem bundle or a local server instead. Freshness is bounded by its triggers: a push reindexes, and uncommitted edits are visible through the working-tree overlay rather than automatically. Cross-repo edges exist between repositories you connected. And a static graph cannot see runtime-only wiring, such as plugins loaded by string name or reflection-driven dispatch, so some edges are partial by nature.
  • Instance-hosted. The MCP server needs a Sourcegraph instance behind it, and the docs list it as supported on Enterprise plans, so the entry cost is the platform. Precision depends on SCIP indexes being present for the revision being queried; without one, navigation falls back to matching. And the public tool list does not present a first-class transitive impact primitive, which leaves the agent to compose one.
  • Local. The index is bounded by the checkout, so cross-repo answers are missing at the point they matter most. Language server coverage varies by language, and call hierarchy is an optional capability, so not every server exposes it. Each developer and each CI job builds its own index, which means one repository gets many indexes and no shared answer. The wider failure modes in agent retrieval do not disappear because the server is local.

Frequently asked questions

Do all three speak the same protocol?

Yes. All three are MCP servers, so an agent can hold any of them in the same session. The transport differs: a local server is usually spawned over stdio, while hosted and instance servers are reached over HTTP. The MCP authorization specification treats those transports differently, requiring OAuth for HTTP servers and environment credentials for stdio servers.

Can a hosted graph answer questions about code I have not pushed yet?

Yes, in two steps. Committed work is indexed on the push webhook, and uncommitted working-tree edits are overlaid on a synthetic revision through a ref call, so a session can query the code you are changing rather than only the last indexed commit. A local server still wins the very last inch, because it reads the file the moment you save it.

Does the Sourcegraph MCP server require Enterprise?

The documentation lists it as supported on Enterprise plans, and it always runs against a Sourcegraph instance, Cloud or self-hosted. So the real question is not the plan alone: an agent session needs an instance that is provisioned, indexed, and configured before the client can point at /.api/mcp.

When is a local code-graph server the right answer?

When code cannot leave the machine, when the team is one developer on one repository, or when the agent works offline. The trade is structural rather than temporary: the index ends where the checkout ends, so the cross-repo questions that cause the expensive failures have no data to answer from, and each machine builds its own copy of what a shared index would hold once.

Sources

Try it on your own repositories

The claim this page ends on is cheap to test on code you maintain: connect a repository, add the endpoint, and ask the agent who calls a function two services share. Start a free 7-day trial and see whether a hosted graph answers the cross-repo question your laptop cannot.

See Symvanta on your own codebase →

Keep reading