Ask a coding agent a plain question: if I change the return type of this function, what breaks. Watch what happens next. The agent opens the file. It greps the function name across the repository. It opens every file that matched, reads each one in full, and tries to hold the call sites in its head alongside the original task, the system instructions, and whatever else is already sitting in its context window. For a function called from four places, this is fine. For a function called from forty places, spread across three services, the agent is now reading tens of thousands of tokens of mostly irrelevant code to answer a question that has a small, precise answer: these fourteen call sites, these three tests, this one downstream consumer. Nothing about that process is intelligence at work. It is brute force, dressed up as reasoning because the words in between sound like reasoning. The agent is not reasoning about the codebase. It is reconstructing a map of the codebase from scratch, in its head, every time someone asks, because nobody handed it the map.
The Model Context Protocol exists to standardize how an agent reaches outside its own weights for exactly this kind of information. The mechanics of the protocol itself, why it exists, what a host, a client, and a server are, why the industry converged on it inside about a year, are covered in full in MCP: the USB-C port for AI agents. This piece assumes that ground is familiar and goes one layer deeper, into a narrower and more concrete question: what MCP codebase context actually looks like once the thing sitting behind the server is not a wrapped API for a ticketing system or a database, but a structural model of the codebase itself. What does an MCP-native second brain for a repository actually expose to an agent, and why is answering a tool call from a graph a genuinely different act than reading a file.
Origin: the same integration problem, one layer down
The general case for MCP is arithmetic. Without a shared protocol, connecting M agent applications to N tools costs M times N bespoke integrations, and a shared protocol collapses that to M plus N. That argument is usually told about tools in the ordinary sense: a CRM, a ticketing system, a database. The identical multiplication is happening one layer down, inside a narrower domain that gets less attention: the problem of getting an AI coding agent to actually understand the codebase it is working in.
Every serious coding assistant today has independently solved, or half solved, this problem, and none of that work transfers. Cursor indexes a repository its own way. GitHub Copilot builds its own retrieval layer. Other assistants lean on grep and hope, or ship a lighter version of the same idea under a different name. Each has its own definition of what counts as a symbol, its own heuristics for what code is related to what, its own blind spots around generated code, monorepos, or dynamic imports. A team that spends months getting one assistant to behave well on its monorepo gets nothing when it switches assistants, because the understanding was never a portable asset. It was built into one vendor's product, the same way a driver written for one operating system does nothing for another.
That is the M-times-N problem again, wearing different clothes, and it is a different problem from the one the Language Server Protocol already solved: one editor, many languages, hover text and go-to-definition without a plugin per language pair. LSP was built for a human clicking inside one open file. It hands back a position in a file, not a typed answer an autonomous process can act on mid-task, and it was never meant to answer a repository-wide question like what breaks if I change this. Codebase understanding exposed to an agent needs LSP's reach, one server for many consumers, aimed at a different shape of question.
If codebase understanding lives inside each agent product, N products each pay the cost of building it, and each pays it imperfectly. If it instead lives behind a server that speaks a standard protocol, one investment, parsing the repository, building the graph, keeping it current, serves every compliant client, present and future. This is already how code-intelligence tools that predate the current wave of agents are repositioning themselves. Sourcegraph's Cody was among the first coding assistants to adopt MCP, and Sourcegraph has since gone further, shipping its own MCP server that exposes cross-repository search, navigation, and commit history to, in the company's own words, any MCP-aware agent, including Claude Code, Codex, Amp, and Cursor, without a separate integration for each. GitHub took the same route with its official MCP server: code search, issue and pull-request access, and workflow status, over one protocol instead of a bespoke client per host. In both cases the move is the same: a company that spent years building code intelligence stopped shipping it only inside its own product and started shipping it as something any agent could speak to.
Present: what a codebase-aware server actually hands an agent
Once codebase understanding lives behind a server rather than inside each agent product, the next question is concrete: what does that server actually expose. Not a folder of files. A small set of typed operations that answer the questions an engineer already asks about a codebase every day, the same questions that currently send an agent off to grep and read on its own.
An MCP tool, mechanically, is nothing exotic. The specification defines one as a name, a description, and a JSON Schema for its input, discovered at runtime through a tools/list call and invoked through tools/call. What makes a tool useful has nothing to do with the wrapper. It is the question it is built to answer in one hop instead of twenty. For a codebase, four questions come up often enough to be worth their own tool.
The first is dependency queries: what does this module import, and what imports it back. This is exactly the shape of question text search cannot answer honestly, because a match on the string OrderService says nothing about whether that string is an import, a comment, or an unrelated variable that happens to collide with the name. A dependency graph already has this resolved, because the edges exist from the parser walking actual import statements and call sites, not from a substring matching a pattern, and the answer comes back as a short, exact list rather than a page of grep hits to sift by hand.
The second is symbol lookup: where is this function defined, what is its signature, who calls it, what does it call. This is the same territory a Language Server Protocol integration covers inside an editor, except exposed as something an agent can call directly mid-task rather than something a human triggers by clicking. Sourcegraph's server leans on this directly, using SCIP-based code indexing to answer go-to-definition and find-all-references across repository boundaries, not only within one open file, which is exactly the multi-file hunt the opening example described an agent doing by hand.
The third is blast radius: if I change this function's signature, delete this class, or rename this field, what breaks. This is the question the opening example was built around, and it is a graph traversal, not a search. An open-source project called CodeGraph frames the goal plainly: parse a repository into functions, classes, imports, and call chains, then expose the result as MCP tools so an agent gets structured code understanding instead of grepping through files. The answer does not have to come back as prose, either. The protocol lets a tool return a resource link, a URI pointing at an affected file, rather than the file's full contents, so the affected set is visible without every implicated file being forced into the context window just to be named.
The fourth is structural search: find every place that does this pattern, not this string. Every place that catches an exception and swallows it without logging. Every handler that writes to the database without a corresponding audit call. Tools like semgrep and ast-grep already match this way, against a syntax tree instead of literal text, as a command a human runs and reads. Exposed through MCP, the same capability becomes one step an agent can call inside a longer chain of reasoning, instead of a separate program someone has to remember to run and interpret.
None of these four are exotic capabilities invented for this piece. More than one independent project has converged on roughly the same tool surface for the same reason: these are the questions an engineer actually asks about a codebase, and each is answered by a structure parsed once, not a text match performed fresh on every call. There is a cost side to this too. Anthropic's own engineering team has written about what happens when a model must hold dozens of tool definitions in context just to pick the right one, and about having an agent write code that calls tools as ordinary functions instead, in code execution with MCP. A codebase server with four or five well-scoped tools sits on the cheap side of that tradeoff. Sixty granular endpoints for every conceivable query shape do not, no matter how well each one is built.
Reading a graph is a different act than reading a file
It is tempting to think an agent with a large enough context window does not need any of this. Paste the relevant files into the prompt, let the model read them, done. That instinct skips past two separate problems, one economic and one structural.
The economic problem is well documented by now. Chroma's context rot research, testing eighteen frontier models, found that performance degrades as input grows, often well before the window is anywhere near full: a model rated for 200,000 tokens can show real degradation by 50,000. Pasting files into a prompt is not a neutral way to supply information. It is a tax on the model's attention that gets steeper the more of it is paid, a point covered at length in context engineering and in context rot directly. Forty files pasted in to answer a blast-radius question do not just cost tokens. They actively degrade the model's ability to use the fourteen lines that actually mattered.
The structural problem matters more here. A file is text. It does not know its own callers. When an agent reads one file in full, it gets every line of that file and none of the eleven other files that call into it, unless those get pasted in too, at which point the agent is reconstructing a graph by brute force: holding a mental model of edges that were never represented as edges anywhere, thrown away at the end of the session and rebuilt from nothing next time. A tool call against an actual graph skips this, because the edges already exist as data before the question is asked. What calls this function is a lookup against a call graph. The same question answered by reading files is an inference the model must redo, expensively and imperfectly, every time.
This distinction matters more than it looks like it should for something that sounds like plumbing. Tool use is a request for a specific, typed answer to a specific question: arguments in, a structured result out. A pasted file is undifferentiated context, useful for everything and precise about nothing, and the model must extract the three facts it needed from the eight hundred lines it was handed. A structured tool call inverts that: the extraction happens once, when the graph is built, and every later question is answered by traversal instead of re-reading. It is the same shift that separates a database from a folder of text files, applied to what an agent needs to know about a codebase rather than what a company needs to know about its customers.
There is a memory dimension underneath both problems. A pasted file exists only for the session it was pasted into. Close the conversation and the agent's understanding of the codebase is gone, to be rebuilt from scratch next time exactly as it was built the time before, one more instance of the stateless-model problem covered in agent memory. A graph that persists between sessions, queried the same way each time through the same tool surface, does not have to be rediscovered on the next visit. It has to be kept current, which is a narrower and more tractable problem than starting over.
Future and impact: the protocol solves reach, not correctness
Coding agents are adopting MCP as a default extension mechanism, not an optional add-on. Cursor, Zed, and Claude Code all speak it natively today, by each project's own documentation, and as more do, the case for building codebase understanding as a server rather than a per-product feature only gets stronger. Every agent that already knows how to call an MCP tool gets a working relationship with a codebase graph for free, without its own vendor writing a line of repository-parsing code. That is the interoperability argument playing out exactly where the general case for MCP said it would: at the seam between one thing that needs context and many things capable of supplying it, addition instead of multiplication.
The honest caveat is one the general case for MCP already raised, and this narrower case inherits it directly. The protocol standardizes the connection, not the quality of what answers on the other end of it. A server that speaks flawless MCP can still be wrong, and a wrong dependency graph is more dangerous than no graph at all, because an agent that trusts a graph acts on a bad answer with the same confidence as a good one. Tell an agent nothing calls this function and it will delete the function. If the graph missed an edge, because a parser choked on a dynamic import or an index went stale the moment someone merged a branch, the agent's confident action is now wrong in a way a slower, more suspicious human skimming the same code might have caught. Freshness and determinism are not nice-to-haves here. They are the entire basis for whether an answer can be trusted enough to act on without a human re-checking it, which is the whole point of asking a graph instead of reading the code by hand.
One example of a codebase-aware MCP server built with that worry in mind is Spiderbrain, built by Perform Digital. It parses a codebase into what it calls a brain: a deterministic, source-free graph of the project's structure, meant to give an agent persistent memory and structural reasoning instead of a flat context window that resets every session. Determinism is treated as a testable property rather than a claim: the same codebase is meant to produce the same brain on every run, checked by roughly 350 automated checks on every release. Parsing itself happens on the developer's own machine, and only a source-free map, structure and scores, not the source code, is sent to Spiderbrain's EU-based servers for scoring, so the code never leaves the device. It speaks MCP to 10 or more clients, including Claude, Cursor, and Zed: the graph gets built once and is queried the same way regardless of which one an engineer opens that day. The capabilities exposed over that connection, blast-radius analysis, a real dependency and call graph, and memory that persists across sessions, are the same shape this piece has been describing in the abstract. Its command-line tool, run as npx spiderbrain, carries impact, path, and verify subcommands with JSON output for scripting, mapping conceptually onto that same tool surface: impact for blast radius, path for how two symbols connect, verify for whether the brain in hand is still the deterministic one the codebase would actually produce right now, turning the freshness worry above into something checkable rather than assumed. The mechanism behind all of it, the deterministic graph underneath it, is its own piece.
A protocol that lets one graph speak to many agents is only half the story. The other half is whether the graph deserves to be trusted, and that has nothing to do with the protocol at all. That two-part shape, a standard for reaching the graph and a separate, harder discipline for making the graph worth reaching, is a fair answer to what an MCP-native second brain actually looks like: not a chatbot that skimmed a repository once, but a server an agent can ask a precise question and trust the precise answer, because the right part was already found, correctly, before anyone asked.
Council summary
This post argues that MCP's interoperability case, one server reaching many clients instead of many clients each rebuilding the same integration, applies with unusual force to a narrow target: a codebase's own structure. It works through what that means concretely: four kinds of tool calls, dependency queries, symbol lookup, blast radius, and structural search, that a graph answers in one hop and that a fresh read of the files cannot answer without the model reconstructing the same graph itself, expensively, every session. It draws a precise line between that and simply pasting more files into a longer prompt, using Chroma's context rot findings and the mechanics of a typed MCP tool call to show why a graph query and a wall of pasted text are not the same act even when they answer the same question. It is honest about the limit: the protocol standardizes reach, not correctness, and a stale or wrongly built graph is more dangerous than no graph, because an agent acts on a confident wrong answer as readily as a right one. Spiderbrain is named as one working example built around that specific worry, deterministic by construction and checked on every release, not as proof the idea has already won. The reader's takeaway is a standing question to ask of any codebase MCP server: not just whether the wiring is standard, but what graph is actually behind it.
Comments