# Repowise review: a local code graph, git history and health scores behind one MCP endpoint

> Repowise indexes a repository once and serves the result to coding agents and reviewers over MCP. The core analysis runs locally without an API key, but the package is still marked alpha and licensed AGPL-3.0.

**repowise-dev/repowise** — Codebase intelligence for AI and humans: code health scores, auto-generated docs, git analytics, dead code detection, and architectural decisions via MCP.

- Repository: https://github.com/repowise-dev/repowise
- Website: https://repowise.dev
- Stars: 7,035 · Forks: 740
- Language: Python
- License: AGPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/repowise-dev-repowise

## The problem Repowise targets: agents rediscovering the same repository facts

Every question a coding agent asks about a repository has an answer that could have been computed before the agent started. Who calls this function. What breaks if I change it. Which files are actually dangerous. The README frames the failure mode directly: without an index, the agent "rediscovers that answer on every task: grep, read, re-read, forget."

Repowise is built for that gap. It indexes the code, the call graph, git history, tests and architectural decisions once, then exposes the result to an MCP host. The audience is narrow but real: teams already using an MCP-capable agent on a codebase where exploration dominates tool calls, and reviewers who want blast radius and test impact on a pull request rather than a raw diff.

The README also makes a claim worth separating from the rest. Core analysis (graph, risk, health, tests, dead code, PR review) involves zero LLM calls and runs locally. Only generated prose is optional. That distinction matters for anyone whose code cannot leave the network.

## How the index is built: tree-sitter parsing, a graph, and a git layer

The mechanism is a local index with several layers. Parsing is done with tree-sitter, and pyproject.toml lists grammars for Python, TypeScript, JavaScript, Go, Rust, Java, C++, Dart, Kotlin and Ruby. That gives symbol-level structure without executing the code.

The layers named in the README are the graph, git, decisions, health, dead-code and a structural wiki. The README describes how they relate: "The graph locates what git history flags; code health measures it; tests show what guards it; decisions explain why it exists." So the health score is not a standalone heuristic over file contents. It is a defect-validated 1 to 10 score across defect risk, maintainability and performance, computed against a call graph that knows which symbols depend on which.

The serving layer is MCP. The README says ten task-shaped tools are exposed to Claude Code, Codex, Cursor, VS Code and other MCP hosts. The design choice it calls out is that most MCP tools are built around data entities (one file, one symbol), which forces agents into long chains of sequential calls, while these are built around tasks: pass several targets in one call. Whether that holds up depends on the agent, but it is a concrete architectural bet rather than a marketing line.

Storage defaults to SQLite via DATABASE_URL=sqlite+aiosqlite:///./repowise.db, with PostgreSQL offered as an option for production deployments. A vector store path for LanceDB also appears in .env.example.

## Installing Repowise and running a first query

The README's quickstart is four lines and needs no API key. The package is on PyPI as repowise and requires Python 3.11 or newer according to pyproject.toml.

The first command installs the CLI from PyPI.

```bash
pip install repowise
```

Then move into the repository you want indexed. The init step builds the layers locally; --no-prose skips the optional model-written prose, and -y answers the prompts.

```bash
cd /path/to/your/repo
repowise init --no-prose -y
```

Starting the server exposes the index to an MCP host and a local dashboard.

```bash
repowise serve
```

The README states that init wires Claude Code automatically, and that other MCP hosts (Codex, Cursor, VS Code) need to be connected. Once connected, the README suggests asking the agent to use the get_overview tool to summarize the repository, or asking a change question such as what breaks if you change src/auth.py. The documentation notes that the optional LLM layer is configured through environment variables in .env.example, with ANTHROPIC_API_KEY described as recommended for best results and Ollama available without a key.

For contributors working from source rather than PyPI, the Makefile uses uv: uv sync --all-packages installs the workspace, and uv run pytest tests/unit/ runs the unit suite. The Node side of the monorepo requires Node 20 or newer per package.json.

## Where Repowise is the wrong tool

The first limitation is stated by the project itself. pyproject.toml carries the classifier "Development Status :: 3 - Alpha" while the version field reads 0.50.0. Release cadence is fast (v0.44.0, v0.45.0 and v0.46.0 all landed within ten days in August 2026), which is a sign of movement but also of churn. Anyone pinning this into a build pipeline should expect interface movement between minor versions.

The second limitation is scope. Repowise is an index over a repository, not a service that observes a running system. It cannot tell you that a function is slow in production, only that the graph considers it defect-prone or performance-risky. If your problem is runtime behaviour, profiling and tracing tools answer a different question.

The third is the test claim. The README promises a "measured or graph-inferred test run list" before merge. Graph-inferred is the honest half of that phrase: the tool selects tests based on the call graph, it does not run them, and it does not replace a full CI run. Treat the selection as a filter for fast feedback, not as a correctness guarantee.

Finally, the licensing. AGPL-3.0 is a strong copyleft licence. For internal use that is usually unremarkable, but if you intend to offer a modified Repowise as part of a network service, the licence terms are the thing to read before you build on it. The README offers a commercial option alongside AGPL-3.0.

## Repowise vs CodeGraph and other code-graph tools

The most direct comparison in the search data is Repowise vs CodeGraph, and the difference is in what sits on top of the graph. A call-graph tool typically answers structural questions: what calls this, what does this depend on. Repowise layers git history, test mapping, dead-code detection and architectural decisions over the same graph, and then serves all of it through one MCP endpoint. The claim in the README is that these are not disconnected scanners but one index feeding agent, editor, pull request and dashboard.

That integration is also the cost. Adopting Repowise means adopting its index format, its database (SQLite by default, PostgreSQL optionally) and its MCP surface. A narrower tool that only builds a graph is easier to swap out. If all you want is a dependency graph rendered as a diagram, Repowise is heavier than the problem.

The repo also ships examples/structurizr-export/ and examples/wiki-export/, which suggests the structural wiki and architecture views can be exported into formats other tools consume. That is a partial answer to lock-in, but the README does not document a full round-trip import, so treat exports as one-way.

## Licence, upgrade cost and what the repository layout implies

The licence is AGPL-3.0-or-later according to pyproject.toml, with the README noting "AGPL-3.0 or commercial." For an internal developer tool the practical question is whether you modify and redistribute it; the AGPL's network clause is the part that surprises people, and the project's own commercial option exists for that reason. This is not legal advice, and the LICENSE file in the repository root is the authority.

Upgrade cost is shaped by the release cadence. Three releases in ten days during August 2026 means the surface is still settling. The repository has guardrails that suggest the maintainers feel this too: a Makefile target generate-types-check fails if the generated TypeScript HTTP contract is stale, and a lint:shared script checks shared imports across the npm workspaces. Those exist because the Python server and the TypeScript clients (packages/types, packages/api-client, packages/web, packages/vscode) have to stay in step.

The dependency list is broad: tree-sitter grammars for ten languages, plus SDKs for Anthropic, OpenAI, Google and LiteLLM, all in the core install. That is convenient for the no-key path but it means the base package pulls provider SDKs you may never call. The last push to the repository was on 2026-08-27, so the codebase is current as of that date.

## Conclusion

Adopt Repowise if you run Claude Code, Codex or Cursor against a repository large enough that grep-and-read exploration burns tool calls, and you are comfortable with AGPL-3.0 or a commercial licence. Do not adopt it as a replacement for a CI test runner: the graph infers which tests a diff exercises, it does not execute them. Before rolling it out, run repowise init --no-prose -y on one repository, then ask your agent to use get_overview and check whether the cited files match what you know about the code.

## FAQ

### How do you use Repowise?

Install it with pip, run repowise init --no-prose -y inside the repository you want indexed, then run repowise serve and connect an MCP host such as Claude Code, Codex, Cursor or VS Code. The README says init wires Claude Code automatically.

### What is Repowise?

Repowise is a codebase intelligence layer that indexes code, call graph, git history, tests and architectural decisions once, then serves cited context, blast radius, test impact and code-health findings to humans and AI agents over MCP. Core analysis is local and deterministic, and only optional prose generation uses an LLM.

### How does Repowise compare with CodeGraph?

Repowise builds a call graph but layers git history, test mapping, dead-code detection and architectural decisions over the same index, exposed through ten task-shaped MCP tools. A tool that only produces a graph answers structural questions without the risk, health and decision layers.

## Sources

- [Official documentation](https://repowise.dev)
- [Official README](https://github.com/repowise-dev/repowise#readme)
- [Project repository](https://github.com/repowise-dev/repowise)
- [Release notes](https://github.com/repowise-dev/repowise/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/repowise-dev-repowise