Does my code leave my machine?

No. The server runs as a local subprocess on your computer and makes no network requests. It reads files from disk and shells out to git, nothing else. ArchSetu never sees your code, and there is no account or API key involved.

Can the agent read files outside my project?

No. The server is launched with an explicit list of directories and refuses any path that resolves outside them, symlinks included. The model picks among those directories; it cannot widen the list. Changing what is readable means restarting the server with different arguments.

Can it change my files?

No. All 11 tools are read-only and declare themselves as such, so a client can auto-approve them without granting write access. The server has no tool that writes, moves or deletes anything.

Do I need an ArchSetu account?

No. This is the local analysis engine with an MCP front end. It is the same engine behind the hosted reports, but nothing here talks to the website.

Which languages does it handle?

The same set as the rest of ArchSetu: 47 languages recognised, 43 of them parsed for functions and structure. Repository-wide metrics cover everything it can parse; explain_file will tell you plainly when a file is in a language it does not parse.

Why would an agent need this when it can just read the files?

Reading files tells it what one file says. These tools answer questions that need the whole repository at once - which files import this one, what nothing calls, what no test reaches, who maintains it. Answering those by reading files costs an enormous amount of context and an agent usually does it partially, then guesses.

MCP server

Stop letting your agent guess.

Your coding agent reads a few files and infers the rest. It cannot cheaply know what imports the function it is about to change, what nothing calls any more, or what no test touches. ArchSetu's MCP server answers those questions directly, from a real analysis of the repository on your disk.

11 read-only tools. No network calls, no account, nothing leaves your machine.

Run it yourself to check it works

npx -y @archsetuweb/cli@latest mcp

That starts a server on stdin and stdout and waits - it is meant to be launched by an MCP client, not used by hand. Press Ctrl+C to stop it. Needs Node.js 20 or newer.

Add it to your client See the 11 tools

What changes when the agent can ask

Before an edit, not after the review

An agent about to change a shared module can find out that forty files reach it, and say so, instead of calling the change self-contained and being corrected in review.

Orientation without burning the context window

Asked to explain an unfamiliar repository, an agent can start from its real entry points and most-connected files rather than reading directories at random until it runs out of room.

Cleanup with a list instead of a hunch

Dead code, untested hotspots and undeclared imports come from the whole repository at once - the kind of question an agent otherwise answers from the handful of files it happened to open.

Add it to your client

The server is a command, so any MCP client that can launch a subprocess can use it. The last argument is the repository it may read - . for the current project, or an absolute path.

Claude Code

Run this in your project. The --scope project flag writes .mcp.json so your team gets it too; drop it to keep the server to yourself.

claude mcp add archsetu --scope project -- npx -y @archsetuweb/cli@latest mcp .

Cursor

Add to .cursor/mcp.json in your project, or ~/.cursor/mcp.json for every project.

{
  "mcpServers": {
    "archsetu": {
      "command": "npx",
      "args": ["-y", "@archsetuweb/cli@latest", "mcp", "."]
    }
  }
}

Claude Desktop

Add to claude_desktop_config.json. A desktop app has no project directory, so give it an absolute path rather than ".".

{
  "mcpServers": {
    "archsetu": {
      "command": "npx",
      "args": ["-y", "@archsetuweb/cli@latest", "mcp", "/absolute/path/to/your/repo"]
    }
  }
}

Working across several repositories? Pass --root again for each one, and the tools take a repo argument to choose between them. The server will only ever read inside the directories you name.

The 11 tools

Listed as the questions they answer, because that is what the agent is choosing between. Each returns a ranked, bounded result with repo-relative paths and line numbers - never a raw dump of the whole analysis, which would fill the context window on a single call.

What is this codebase?

repo_overview

Health score and grade, size, language mix, entry points, and the top-level risk counts. The first call for an unfamiliar repository, and the one that tells the agent which other tool is worth making.

What breaks if I change this function?

function_blast_radiusper file

How many functions reach it transitively, across how many files, which of them are entry points, and the direct callers with line numbers. The one to call before changing a signature, a return value or a name - a function with 200 callers across 12 files needs a different plan from one with two.

What breaks if I change this file?

file_blast_radiusper file

The files that import it directly, the ones that reach it transitively, and a risk level. The coarser sibling of the above, for when the whole file is moving rather than one function inside it.

What does this one file do?

explain_fileper file

Purpose, imports, exports and functions with line numbers, from parsing that single file. Fast enough to use for orientation before reading a file in full.

What here is unreachable?

dead_code

Functions with no caller anywhere in the call graph, safest-to-remove first. Candidates to verify, not a delete list.

Where is this hard to change?

complexity_hotspots

The functions with the highest cyclomatic complexity, worst first, with file and line numbers.

What looks unsafe?

security_findings

Hardcoded secrets, unsafe dynamic execution, string-built SQL, insecure transport, weak cryptography, container and cloud misconfiguration, and CI workflow injection - plus secrets still recoverable from git history. Secret values are masked.

What is risky and untested?

test_risk

Complex, frequently-changed functions that no test reaches through the call graph. Static reachability, not measured coverage.

Why does this break in CI?

dependency_hygiene

Packages the code imports but never declares in a manifest - the imports that work on one machine because something else happened to install them.

Who knows this code?

ownership_risk

Bus factor, top contributors and the most frequently changed files, from a bounded window of recent git history.

Where do I start reading?

onboarding_guide

A short ordered reading list: entry points and most-connected files, each with what it does and why it matters.

What it can and cannot touch

Local only

The server is a subprocess on your machine and makes no network requests. It reads files and runs git. ArchSetu never receives your code, and no account or key is involved.

Read-only, and declared as such

There is no tool that writes, moves or deletes. All 11 are marked read-only in the protocol, so a client can auto-approve them without handing over write access.

Confined to the directories you name

Any path resolving outside the launch roots is refused, symlinks resolved first. This matters because tool arguments are chosen by a model whose context includes your repository’s own text - a README cannot talk the agent into reading your home directory.

What it will not tell you

Worth reading before you install it. Each tool states these limits in its own results too, so the agent sees them at the point of use rather than only here.

It reads code, it does not run it: Everything comes from parsing files and walking git history. Nothing is executed, no tests are run, no coverage is measured. "Untested" means no test reaches the function through the static call graph, which is not the same as uncovered.
The call graph cannot see dynamic calls: Reflection, dynamic dispatch, dependency injection, string-built module paths and calls from outside the repository are all invisible to it. So dead code is a list of candidates to verify, and blast radius is a lower bound on real impact rather than the whole of it.
Security findings are heuristics: Regex patterns over the working tree and recent commit diffs. No AST, no taint analysis, no vulnerability database. Expect false positives in test fixtures and example config, and read the cited line before believing any of them.
Results are cached, and say so: A full analysis takes seconds to minutes, so it is reused across calls rather than recomputed per question. Every result carries when it was computed and flags itself stale once the cache expires, and any tool can be called with refresh to force a fresh run.
Very large repositories are truncated: The file walk is capped. When a repository exceeds it, every result says so explicitly rather than presenting a partial analysis as a complete one.

Protocol support

The server implements MCP revision 2026-07-28, in which every request carries its own protocol version and capabilities and the server keeps no session state. It also still answers the older initialize handshake used by 2025-11-25, 2025-06-18, 2025-03-26.

Supporting both is the point. The two eras are not interoperable - a handshake-era client gets no useful error from a stateless-only server, and has no way to adapt - so a server that speaks only the current revision silently fails against every client that has not upgraded yet. This one decides per request and works with both.

Questions

Does my code leave my machine?: No. The server runs as a local subprocess on your computer and makes no network requests. It reads files from disk and shells out to git, nothing else. ArchSetu never sees your code, and there is no account or API key involved.
Can the agent read files outside my project?: No. The server is launched with an explicit list of directories and refuses any path that resolves outside them, symlinks included. The model picks among those directories; it cannot widen the list. Changing what is readable means restarting the server with different arguments.
Can it change my files?: No. All 11 tools are read-only and declare themselves as such, so a client can auto-approve them without granting write access. The server has no tool that writes, moves or deletes anything.
Which MCP version does it speak?: Both eras. It implements revision 2026-07-28, where each request carries its own protocol version and the server holds no session state, and it still answers the older initialize handshake used by 2025-11-25, 2025-06-18, 2025-03-26. Clients upgraded at different times, and a server that speaks only one era silently fails against half of them.
Do I need an ArchSetu account?: No. This is the local analysis engine with an MCP front end. It is the same engine behind the hosted reports, but nothing here talks to the website.
Which languages does it handle?: The same set as the rest of ArchSetu: 47 languages recognised, 43 of them parsed for functions and structure. Repository-wide metrics cover everything it can parse; explain_file will tell you plainly when a file is in a language it does not parse.
Why would an agent need this when it can just read the files?: Reading files tells it what one file says. These tools answer questions that need the whole repository at once - which files import this one, what nothing calls, what no test reaches, who maintains it. Answering those by reading files costs an enormous amount of context and an agent usually does it partially, then guesses.

The same engine, elsewhere

This is ArchSetu's analysis engine with an MCP front end. The @archsetuweb/cli package also runs it as a plain CLI and as a pre-commit hook.

Analyze a public repository Make a shareable report