Repowise MCP server

English | 简体中文

---

Set it up in one line

Open Claude Code, Codex, Cursor or any MCP-capable agent in your repository and paste:

Read https://docs.repowise.dev/setup.md and set up Repowise in this repository.

The agent installs Repowise, indexes the repo with no API key, connects itself to the index, and asks you before anything costs money. To do it by hand:

uv tool install repowise          # or: pipx install repowise / pip install repowise
cd /path/to/your/repo
repowise init --yes --no-prose    # graph, git, health, dead code, docs. No key, no spend.
                                  # answers and docs: run repowise generate (one command, no re-index)
repowise serve                    # dashboard + MCP server (needs Node 20+; first run downloads the UI)

serve opens the dashboard in your browser. After a first index it starts with a short guided tour, and Setup is where you connect agents, turn on sync and add coverage or a model.

Restart Claude Code or run /mcp, then ask "What breaks if I change src/auth.py?" or "Use Repowise get_overview to summarize this repository." init wires Claude Code for this repo and adds the global repowise MCP entry when there is none; it never moves one that serves another repo. Full setup for every agent →

---

Your agent stops guessing

Without an index, an agent rediscovers your codebase on every task: grep, open a file, open three more, grep again. Repowise answers those questions ahead of time, so the agent asks once and gets on with the work.

In a measured run on django/django, an agent with Repowise made 3.8 tool calls instead of 7.2, opened 3.0 files instead of 7.2 and wrote 31.6% less, with answers just as good. That is the largest saving of the five context tools we tested. On a small local model the output cut reaches 47.9%. How it was measured →

• Your agent gets ten task-shaped MCP tools. Ask about several files at once and get callers, risk, tests, owners and the reasons behind the code in one answer. The tool list ↓
• Up to 99% less command noise. repowise distill trims test, install and git output before the agent reads it and keeps every error line. Distill →
• Context before the agent asks. Optional hooks warn it off fragile files and stale paths, and Repowise keeps your CLAUDE.md and AGENTS.md current from the index.
• See your own savings. repowise saved and the dashboard's Usage and savings page count the tokens your agent no longer has to read.

---

What it does

One index of your code, its history and its decisions, used three ways: to understand the code, to change it safely, and to keep improving it.

Understand the code

You ask	Repowise gives you
How does checkout work in this repo?	A cited answer built from the call graph and the generated docs, in one call. Search and answers
What calls this function, and what does it call?	A call graph across 28 parsed languages, every edge stamped with how it was resolved and how far to trust it, plus traced execution flows from each entry point. The graph
Can I get docs for this codebase?	A wiki for every module and file, rendered from the code's structure with no key, or written by a model when you choose. It updates incrementally after each commit. Docs
Which of our docs are wrong?	Markdown checked against the tree: every reference to a file or symbol the code no longer has, with the line to edit. Doc drift
Why is it built this way?	Decisions mined from ADRs, # WHY: comments, commit and PR history and your agent sessions, each tied to the code it governs and flagged when it goes stale. Decisions
Who knows this code?	Owners, bus factor, fading ownership when the main author goes quiet, and suggested reviewers. Ownership
Can I see the architecture?	An explorable dependency map, C4 views, and a Structurizr export, no model involved. Dashboard

Change it safely

You ask	Repowise gives you
What breaks if I change this?	Symbol-level blast radius: the callers of what you changed, the files that historically change with it but are missing from your diff, and the tests that reach it. Change risk
How risky is this PR?	Where the change ranks against your repository's own recent commits, with the reasons, as a directive your agent can act on. Change risk
Which tests should run?	The tests a diff actually exercises, from a coverage report if you have one and from the call graph if you do not. Test intelligence
Did this PR add untested lines?	Patch coverage, branch coverage on changed lines and path-scoped gates in CI, on GitHub, GitLab or any runner. CI gates
Will this API change break another repo?	HTTP, gRPC, topic and OpenAPI contracts matched across repositories, with a breaking-change guard and the consumer files it affects. Workspaces
Is anyone else editing these files?	Other open branches touching the same files or their co-change partners, each with the reason it is listed. Branch overlap
Did we just commit a secret?	Keys, tokens and risky calls found in the working tree and in full git history, with a pre-commit check and a CI gate. Security signals

Improve it continuously

You ask	Repowise gives you
What should we fix first?	A ranked queue weighing impact against effort, using churn, fan-in, coverage and bug history. Fix first
Where is the debt?	A 1 to 10 score for every file from 53 deterministic detectors, split into defect risk, maintainability and performance, validated against real bug history. Code health
Why is this slow?	N+1 queries, I/O in loops, blocking calls inside async code and quadratic loops, traced across function and file boundaries. Performance
How do I break this up safely?	Concrete refactoring plans: Extract Method, Extract Class, Move Method, Split File, Break Cycle, with the exact symbols that move and what moves with them. Ready to hand to an agent. Refactoring
What can we delete?	Unreachable files, unused exports and unused packages, each with a confidence tier and the evidence behind it. Dead code
Where do bugs keep landing?	Bug-fix commits traced to files and symbols, and a warning when your agent edits a bug magnet. Bug history
Are our tests testing anything?	Tests with no assertions, tests that only check their own mocks, and untested hotspots. Test-quality smells

• Test coverage without running coverage. Most repositories never produce a coverage report. Repowise answers "is this tested, and by what" from the import and call graph, and labels every answer measured or inferred.
• It checks its own health score on your repository. After each index it reports how many of the lowest-scoring files actually had bug fixes in your recent history, so a bad score on your codebase is visible to you.
• It learns from your agent sessions. With transcript capture on, the corrections you keep repeating ("use the shared HTTP client") become tracked decisions it feeds back to the agent later. Transcripts never leave your machine.
• It writes your CLAUDE.md and AGENTS.md from the real index and keeps them current, so even an agent with no MCP support starts informed.
• It shrinks command output before your agent reads it. repowise distill pytest keeps every failure and drops the noise, and nothing is lost: an expand command restores any cut.
• New git worktrees start indexed. A linked worktree seeds its index from the base checkout instead of starting cold.
• It knows which external systems you depend on. Package manifests across PyPI, npm, Cargo, Go, NuGet, Maven and CMake feed a map of the services and libraries the code reaches.

---

Hosted, and Foresight

Everything above runs free on your own machine. repowise.dev runs it for you, private repos included, and is where Foresight arrives first: models trained on years of real commits and fixes that rank the files a fix will touch, name what a change forgot, and explain every answer, with no LLM. What Foresight does →

Already indexed locally? repowise publish puts the repo on repowise.dev in one command. It indexes your GitHub remote, so nothing is uploaded from your machine. Public repos are free.

---

Know what breaks before you merge

All of this comes from the graph and git history, with no LLM, so the same diff always gets the same answer.

• Change risk. Score any commit or branch 0 to 10 against your repository's own recent commits, with what it may break, the companion files it forgot, the tests it is missing and the tests to run. repowise risk main..HEAD (reference)
• Tests without a coverage run. Which tests reach a file and which ones a diff exercises, from a coverage report when you have one and from the call graph when you do not: 97.5% correct on which tests to run. repowise impacted-tests main..HEAD (reference)
• Bug magnets. Which files keep getting bug fixes, with a warning when your agent edits one. (reference)
• Branch overlap. Other open branches editing the same files. repowise overlap (reference)
• In CI. Patch coverage, doc drift, security and change risk as gates through the GitHub Action, a GitLab template or plain CLI, with SARIF output. No API key. Repowise in CI →

On every pull request. The free Repowise PR Bot posts one comment, edited in place on every push, with the callers outside the PR, the tests and companion files it is missing, and its change risk. A green PR gets no comment at all.

A real comment on a real PR: repowise-dev/repowise#1204 · its analysis page → · install the PR bot →

Every change, with its evidence

Each merged PR or commit becomes a Change Record: what it touched, who owns it, the tests that reach it, the contracts and decisions it crosses, and what happened after it landed. No forge API is called.

You ask	Repowise gives you
What landed in this PR, and what backs it up?	The change's evidence checklist, each item ok, attention or unknown, with an in-toto export. Change Records
Can CI hold changes to our payment code to a higher bar?	Rules in .repowise/policies.yaml, matched to components by name, tag or criticality and evaluated by repowise check, with SARIF or JUnit output. Change policy
Something broke. Which change do we read first?	Recent changes ranked against an error, a stack trace or an issue. On 43 real regressions, the change a later revert or fix named was in the top 5 for 67% of them, against 28% for ranking by shared files. Suspects
Who owns this, and are they still working on it?	Backstage-shaped components with owners from your catalog and CODEOWNERS, compared with the last 90 days of commits. Components
Can we show an auditor or an acquirer where we stand?	Evidence packs: a repository assessment, a change report for a period and a component inventory, as JSON, Markdown, HTML or CSV. Reports

---

Know exactly what to fix

Every file gets a 1 to 10 score from 53 deterministic detectors, read three ways: defect risk, maintainability and performance. Performance findings such as N+1 queries and I/O in loops are traced across functions and files.

The score is checked against real bugs. On 21 open-source projects, ranking by Repowise found 2.3x as many later-buggy files as CodeScene in the same review budget. It also checks itself on your repository after every index: "16 of the 20 lowest-health files had a bug fix in the last 6 months, 3.3x the 24% baseline."

Then it names the fix: Extract Method, Extract Class, Move Method, Split File or Break Cycle, with the exact symbols that move, ranked so a fix on a central file comes before the same fix on a leaf. Each plan has a copy-to-agent button.

repowise next                          # what to fix first, ranked by impact and effort
repowise health --refactoring-targets  # concrete plans
repowise dead-code                     # what can go, by confidence tier

Code health · Refactoring · Dead code · How it was validated →

---

Across your repositories

Real systems are more than one repository, and the expensive failures live between them. Change a backend contract and Repowise names the frontend calls that consume it, the services downstream, and the architecture rule the new dependency breaks, before it ships.

Workspace intelligence	What it answers
Contract map	Which services provide and consume each HTTP, gRPC, event, socket and data contract? Links keep their exact or candidate confidence and the source evidence.
Cross-repo blast radius	If this provider changes, which downstream services are in structural reach, and which may drift through historical co-change?
Breaking-change guard	Was an endpoint removed or an OpenAPI, proto or signature shape changed incompatibly, and which consumer files are linked to that contract?
Test impact	Which tests in the consumer repos should run for this provider change, measured from coverage or inferred from the call graph?
Architecture as code	Does the live system graph violate declared dependency rules or contain cycles? repowise workspace check gates CI.
Architecture health	How coupled is the estate? Propagation cost, the cyclic core, service roles and a deterministic 1-10 architecture score.
Federated context	One dashboard and one MCP server answer across every repository while keeping repo-level evidence.

Workspace guide and support matrix → · Keeping the index fresh →

---