Impact Analysis with GitNexus

When to Use

• "Is it safe to change this function?"
• "What will break if I modify X?"
• "Show me the blast radius"
• "Who uses this code?"
• Before making non-trivial code changes
• Before committing, to understand what your changes affect

Bind the repository first

Impact analysis is the gate that authorizes an edit, so it must answer for the repository you are about to edit.

Call list_repos {} before the first tool call. With one indexed repository, use the examples below as written. With more than one, pass repo on every call: an omitted repo normally errors, but under an MCP policy with a configured default it resolves to that default silently. If you cannot tell which repository is meant, stop and ask, every result below an ambiguous identity inherits the ambiguity. list_repos is paginated, so page with offset: pagination.nextOffset until hasMore is false before concluding a repository is absent.

detect_changes takes worktree when your changes are in a linked worktree the MCP server was not launched from. The server auto-detects a worktree only when it was launched from inside one; otherwise git diff runs in the wrong checkout and reports zero changed symbols, a false clean check that carries none of the degradation flags described below. In the CLI fallbacks, --repo . means the current checkout; pass the intended repository path instead when you are not standing in it.

State the bound identity with your risk report:

Repository: <name> (<path>)   Worktree: <path>   Index: <commit>, <n> behind HEAD

Workflow