Remote vs Local MCP Code Indexes

Wiring a code-context MCP server into a coding agent takes two decisions, and most write-ups cover only the first. You pick the tool. Then you pick where its index lives: a process on your laptop reading your working copy, or an endpoint holding a parsed copy of your repositories. The protocol is identical either way. Zed's settings file shows both shapes on one page: a command with args for a server it spawns locally, a url with optional headers for one it reaches over HTTP (Zed docs, MCP). The choice reads like a deployment detail. It sets index freshness, parsing cost, how far past one repository the agent can see, and how access is controlled.

Two shapes of the same server

A local index server is a process you start. Serena is the clearest example: MIT licensed, installed on your machine, 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, and nothing to pay. You point it at a project directory and it answers from what the language server resolves.

A hosted index server is a URL. DeepWiki publishes one at https://mcp.deepwiki.com/mcp, described by Cognition's docs as "a free, remote, no-authentication-required service that provides access to public repositories" (Devin docs, DeepWiki MCP); the DeepWiki alternative page covers what its three wiki tools return. Sourcegraph runs one against your own instance at https://your-sourcegraph-instance.com/.api/mcp, "Supported on Enterprise plans" (Sourcegraph MCP server docs), where Enterprise is listed as "Starting at $16K" with credits that scale by team size (Sourcegraph pricing); the fuller picture is on the Sourcegraph Cody alternative page. Symvanta is a hosted endpoint too.

Same protocol, same tool call, different machine doing the parsing.

What the laptop pays

Building an index costs compute, and the bill lands somewhere. A language-server backend is the cheap end: the servers already exist, they update incrementally, and on a mid-size repository you will not notice them. On a large monorepo, cold-starting them competes with your build for the same cores and memory.

Semantic search is the expensive end, and it is where "local" quietly stops being local. Zilliz's claude-context is an MCP plugin that "adds semantic code search to Claude Code and other AI coding agents", and its setup asks you for two things it will not run itself: an embedding provider (an OpenAI key, among others) and a vector database, either Zilliz Cloud or a Milvus deployment you stand up (zilliztech/claude-context). The plugin is on your machine. The embedding compute and the vector store are somewhere else, because the models are large: nomic-embed-code lists 7B total parameters (nomic-ai/nomic-embed-code).

So the local line is rarely clean. The useful question about any "local" indexer is which half of the work runs on your hardware: the tool call, or the parsing and embedding behind it.

Freshness and who runs the reindex

Local wins this one outright, and it is the strongest argument in its favor. Augment puts the claim on their own product page: "Our indexer runs locally on your machine. When you make local changes, your next context query immediately reflects those changes" (Augment, Context Engine MCP). Their docs describe Local mode as indexing "in real-time as you edit, no manual sync required" (Augment docs, Context Engine MCP). An index sitting on the same disk as the file you just saved has no staleness window to close.

A hosted index starts from behind. Its natural trigger is a push, so everything between your last save and your last push is invisible to it unless the product does something about that. Symvanta reindexes on a GitHub push webhook, indexes tracked feature branches so an agent can pin a session to one, and takes uncommitted working-tree edits through a ref call that overlays them on a synthetic revision. That shrinks the window to near zero. It is still engineering someone had to do, where a local file watcher gets it free. If your agent spends its day on code you have not committed, weigh this heavily.

The edge a single-repo index cannot see

A local index is bounded by what sits on disk, and that bound stays invisible until a question crosses it. A service calling another over HTTP has a real dependency on it, and parsing repo A never reveals which handler in repo B answers that path. Same for a queue producer and the consumer draining its channel, or two services writing one table. Answering those locally means both repositories checked out, both indexed, and something joining them: the hosted architecture rebuilt by hand on a laptop.

The vendor shipping the local indexer says this out loud. Augment's docs recommend Remote mode for "Cross-repo context" and "CI/server environments" (Augment docs, Context Engine MCP). Their local indexer is good at the machine it runs on; their answer for the code on the other side of the call is the hosted one. Symvanta links repositories inside a project and matches HTTP call sites to the routes they hit, queue producers to their consumers, and SQL access to the ORM model that owns the table. The tool-by-tool version of that sits on the Augment Code alternative page.

One index, every seat

Eight developers running a local indexer build eight indexes of one repository on eight machines, each paying its own parse, and none can answer a question for anyone else. Give each developer a second agent and you have sixteen.

A hosted index is parsed once and read by everyone holding a token. That matters most for the callers with no laptop attached: a CI job checking the blast radius of a diff before it merges, or a scheduled agent opening a pull request overnight. Augment's docs point CI and server environments at Remote mode for exactly this. A stdio server in CI means checking out and indexing the repository on every run, so a two-second query rides behind a cold parse each time.

One shared index also means one shared answer. When your agent and a colleague's agent disagree about who calls a function, that is a bug in one of two local indexes, and nobody will ever find it.

Auth is the part people skip

The MCP authorization spec draws this line for you: "Implementations using an HTTP-based transport SHOULD conform to this specification. Implementations using an STDIO transport SHOULD NOT follow this specification, and instead retrieve credentials from the environment" (MCP specification, Authorization).

Read that as an access-control statement. A local server's permission model is your user account. It reads whatever you can read, and its only credential is whatever sits in its environment. On your own laptop that is usually right. It is also nothing an administrator can scope, audit, or revoke.

The HTTP side is built on OAuth 2.1. Clients must implement PKCE, tokens must carry a resource parameter naming the server they were issued for (RFC 8707), servers must reject tokens issued for anyone else, and 403 is reserved for "Invalid scopes or insufficient permissions" (MCP specification, Authorization). Sourcegraph's server supports OAuth 2.0 through Dynamic Client Registration or pre-registered clients, and organizations requiring administrator approval can disable dynamic registration (Sourcegraph MCP server docs). Symvanta runs OAuth 2.0 with PKCE, which is why the Zed setup carries no Authorization header to paste: the browser flow issues a scoped session, and the account that owns it can revoke it.

When local is the right call

Some code cannot leave the building. Air-gapped networks and classified work, or a contract that forbids egress in writing. That is policy, and no freshness or cross-repo argument outranks it. A local LSP-backed server is the entire answer there, and Serena's free language-server backend costs nothing and asks for no account.

One developer on one repository of moderate size gets little from a hosted index, because the questions needing cross-repo edges never come up. A weekend project does not want an account or a billing relationship. An agent working offline, on a plane or behind a captive portal, needs the index on the same disk as the code. In each of these, the hosted version is overhead.

The two also compose. A local symbol server for the file you are editing plus a hosted graph for questions reaching past your checkout is a reasonable setup, and MCP clients hold several servers at once by design.

Where the index belongs

Local's advantages are properties of one machine: unsaved-code freshness, zero egress, no account. Hosted's are properties of a team: cross-repo edges, one parse for eight seats, an agent running in CI, a token an administrator can revoke. No amount of tuning a laptop index produces the second list.

That is the case for defaulting to hosted. A code index has the same shape as CI: expensive to build, cheap to read, wasteful to duplicate per laptop, and useful to more callers than the person who triggered it. Nobody runs their test suite only on the machine that wrote the code. The freshness gap is the one genuine cost, and it yields to engineering: push webhooks, branch-aware indexing, and a working-tree overlay for edits that have not landed. The cross-repo gap on the local side does not yield the same way, because the missing data is a repository you never had.

Symvanta is that bet: your repositories parsed into a graph of symbols and edges, reached over an authenticated MCP endpoint by whichever agent asks, current on every push and pinnable to a branch. The claim is cheap to test, and it should be tested on code you maintain. Connect one repository, point your agent at the endpoint, and ask what breaks if you change a function two services share. Seven days is plenty of time to find out whether that beats what your laptop gives you.