Does a code-graph MCP tool send my code to a server?

No. Agent-Context runs as a local process on your machine, reads only the folder you point it at, makes no network calls, and writes nothing. It returns a small structural summary (file and edge counts, dependents and dependencies), not your source code.

Does it work with Cursor or Cline, not just Claude Desktop?

Yes. The same server runs over npx, so any MCP client (Cursor, Cline, Zed, the CLI) can use it by adding it to that client's mcp.json. The one-click .mcpb format is specific to Claude Desktop, but the underlying MCP tool is portable.

Why Your AI Coding Assistant Keeps Breaking Code It Can't See (and How to Fix It)

Q: Why does my AI coding assistant break other files when it edits one?

Because the model sees your codebase as flat text, not as a dependency graph. When it edits a file, it has no view of which other files import it. It changes the file in isolation and breaks the callers it could not see. The fix is to give the model the file's dependents and dependencies (its blast radius) before it edits.

Q: What is the blast radius of a code change?

The blast radius of a file is everything affected if you change it: its dependents (files that import it and can break) and its dependencies (files it imports). Knowing the blast radius before an edit tells you the true scope of a change, which is usually larger than the diff looks.

You ask your AI coding assistant for a small change. It edits one file, says "done," and three other files quietly stop working. You did not change those files. The model did not change those files. So why are they broken?

Because the model never knew they existed. This is the single most common way AI-written code breaks in practice, and it has nothing to do with model intelligence. It is a context problem, and it has a concrete fix.

The short version An AI assistant edits files in isolation because it cannot see which other files depend on them. Give it the file's blast radius (its dependents and dependencies) before it edits, and the whole class of "it broke something unrelated" failures goes away. A free, one-click Claude Desktop extension does exactly this.

Why does AI keep breaking my code?

A codebase is a graph. Files import other files; functions call across modules; one change ripples outward along those edges. But a language model does not see the graph. It sees whatever text you (or your IDE) paste into the prompt, as a flat blob. When it edits src/db.js, it has no idea that fourteen other files import db.js and rely on its exact function signatures.

So it does the locally reasonable thing: it rewrites db.js cleanly, in isolation, and breaks every caller whose contract it just changed. From the model's point of view the task is complete. From yours, the app is on fire. The model was not dumb. It was blind.

This hits vibe-coders hardest, because the whole point of vibe coding is that you are not reading every file yourself. You are trusting the assistant to make the change. If the assistant can't see the dependency graph either, nobody can, and the breakage surfaces at runtime instead of at review.

What is "blast radius"?

The blast radius of a file is everything affected if you change it. It has two halves:

Dependents — the files that import this one. If you change its API, these can break. This is the half the model never sees and the half that causes the silent failures.
Dependencies — the files this one imports. These tell the model what helpers and contracts it is actually working with.

"What is the blast radius of this file?" is the single most useful question to answer before an edit, not after. And it is cheap to answer: it is a graph lookup, not a language task.

The fix: give the model the dependency map

I built Agent-Context (a "code graph" tool) for exactly this. It walks a project, parses imports across JavaScript, TypeScript, JSX/TSX, Python, and Go, and builds a dependency graph where nodes are files and edges are imports. Then it answers two questions an AI assistant should always ask before touching code:

blast_radius(file) — the dependents and dependencies of a file.
graph_summary() — a quick check that the repo is analyzable (file and edge counts).

The output is deliberately tiny: a compact context string designed to be injected straight into the prompt, not a sprawling graph dump.

            ~200 tokens the model reads before editing
            
### STRUCTURAL CONTEXT FOR [src/db.js]
- Dependencies (what this file uses): src/config.js, node:fs
- Dependents (what relies on this file): src/auth.js,
  src/routes/users.js, src/routes/orders.js
  ... and 11 more

Rule: if you change this file, check the dependents before
calling the task done.
            
        

An assistant that reads this before editing db.js knows there are fourteen callers to keep working. An assistant that doesn't will break them and call it done. That entire behavioral difference costs about two hundred tokens, versus the thousands you would burn (and the confusion you would cause) by pasting fourteen files in full. The value is in what it chooses not to send to the model.

Install it in Claude Desktop in one click

This used to require editing config files. It doesn't anymore. Agent-Context is now packaged as a .mcpb extension, the one-click install format for Claude Desktop:

Open Settings → Extensions and install the .mcpb file.
Set Workspace root to the repo you want analyzed.
In a normal chat, ask: "What depends on src/db.js? Use the code-graph tool."

No config files, no API key. The tool is read-only and confined to the folder you pick, so it can't wander outside your repo, and your code never leaves your machine. The same server also runs over npx, so Cursor, Cline, Zed, and the CLI can use it through their own mcp.json.

Does it actually work?

Here is a real graph_summary from a live Claude Desktop session, run over a multi-repo workspace:

1,501

files mapped (graph nodes)

5,437

dependency edges

~3.6

edges per file (how coupled it is)

From there, a single blast_radius call on any file returns the exact set of dependents to keep working before you accept a change. That is the moment the assistant stops guessing.

What it won't do (the honest part)

This is static import analysis, and it is fast precisely because it is shallow. It reads import and require edges. It does not see dynamic imports, string-based references, dependency-injection wiring, or coupling that lives over HTTP or in a database schema. It maps how your code is structured, not how it behaves at runtime.

For the everyday case — "I'm about to change this file, what imports it?" — the static graph is exactly right, and it is the context your assistant is missing today. For deeper semantic coupling you still need tests and a human. A dependency map makes the assistant less blind; it does not make it omniscient, and anyone who tells you otherwise is selling something.

The takeaway

"AI keeps breaking my code" is usually not a model problem. It is a missing-context problem: the assistant edits what it can see and breaks what it can't. Hand it the blast radius first and most of that disappears. If you want the concept rather than the tool, see context engineering in 2026; for the broader case that boring infrastructure is what actually ships, see the boring infrastructure that actually ships.

The tool is open source: Agent-Context on GitHub, with the full write-up on the project page.

FAQ

Why does my AI coding assistant break other files when it edits one?
It sees your codebase as flat text, not a dependency graph, so it has no view of which files import the one it is editing. It changes the file in isolation and breaks the callers it could not see. Give it the file's blast radius first.

What is the blast radius of a code change?
Everything affected if you change a file: its dependents (files that import it and can break) and its dependencies (files it imports). It is usually larger than the diff looks.

How do I give Claude Desktop access to my whole codebase?
Install a code-graph MCP extension. Agent-Context ships as a one-click .mcpb for Claude Desktop: install it, pick a workspace folder, and the model can call blast_radius and graph_summary. Reading is local, read-only, and confined to the folder you choose.

Does it send my code to a server?
No. It runs locally, reads only the folder you point it at, makes no network calls, and returns structural summaries (counts, dependents, dependencies), not your source.

Does it work with Cursor or Cline?
Yes, via npx in that client's mcp.json. The one-click .mcpb is Claude-Desktop-specific; the MCP tool itself is portable.