How do I use change-impact-assistant?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@change-impact-assistant analyze my uncommitted changes and list what else might be affected" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

change-impact-assistant

by tanvi0102

Overview Schema Source Related Servers Discussions Admin

Python

Local

Change Impact Assistant

An MCP server that answers one question for a developer or an AI coding agent: "I just changed this — what else might I need to check?"

It combines two independent signals:

Static code structure — reads the codebase with Python's built-in ast module to find which files/functions import or call each other right now.
Git co-change history — reads the repo's commit history to find files that have changed together in the past, even when nothing in the code connects them.

Neither signal alone is enough: static analysis misses config files, docs, or tests that always change alongside a piece of code but never import it; history alone misses brand-new code with no track record. Combining both catches more than either does on its own.

This is a small, original Python implementation of both ideas, built from scratch and kept intentionally simple.

Example

Given a change to payment_service.py:

HIGH CONFIDENCE
- invoice_service.py
  Reason: calls refund (changed in payment_service.py)

MEDIUM CONFIDENCE
- checkout_api.py
  Reason: imports payment_service.py, but doesn't call refund directly
- test_refunds.py
  Reason: changed together with payment_service.py in 4 of its last 6 changes (67%)

REVIEW SUGGESTED
- payment_config.yaml
  Reason: changed together with payment_service.py in 1 of its last 6 changes (17%)

invoice_service.py is HIGH because it actually calls the function that changed. checkout_api.py imports the file but calls a different, unchanged function, so it's demoted to MEDIUM rather than being blanket-flagged. test_refunds.py has no code connection at all — the only reason it's here is git history. payment_config.yaml is the same idea, weaker signal.

Related MCP server: Scrooge

Install

Requires Python 3.10+ and Git.

python3 -m venv .venv
source .venv/bin/activate
pip install -e .

Usage

Command line:

python -m impact_assistant analyze /path/to/your/repo

This reads git diff in that repo and prints the tiered report. Useful flags:

--against HEAD~1 — compare against a specific ref instead of the working tree vs HEAD
--since "1 year ago" — limit how far back co-change history looks
--file some/file.py — analyze a specific file instead of the live diff (repeatable)

As an MCP server (for Claude Code, Claude Desktop, or any MCP-compatible AI assistant), add to .mcp.json:

{
  "mcpServers": {
    "change-impact-assistant": {
      "command": "/path/to/change-impact-assistant/.venv/bin/mcp",
      "args": ["run", "/path/to/change-impact-assistant/src/impact_assistant/server.py"]
    }
  }
}

This exposes 5 tools: analyze_current_change, explain_affected_file, get_static_impact, get_historical_impact, get_changed_files.

Interactively, with the official MCP Inspector:

mcp dev --with-editable . src/impact_assistant/server.py

How it works

File	Role
`codegraph.py`	Builds a static "what imports/calls what" map of the codebase using `ast`.
`cochange.py`	Reads `git log` and counts which files have historically changed together.
`symboldiff.py`	Compares old vs. new versions of a changed file to find which specific function/class changed, instead of treating any edit as "the whole file is different."
`gitdiff.py`	Wraps `git diff` to find what's currently changed.
`report.py`	Merges the above into one tiered, evidence-backed report — the core original logic.
`cli.py`	Command-line entry point.
`server.py`	MCP server exposing the same logic as tools an AI assistant can call directly.

Known simplifications (deliberate, not oversights)

File/function names, not full scope resolution. Calls and imports are matched by name across the whole codebase. Two files with a same-named function can be conflated. A real type checker would resolve this exactly; this trades some precision for staying simple.
Change unit = one commit, not a PR/merge-aware grouping. A history with many small fixup commits per PR will look noisier than a tool that groups by PR.
Top-level functions/classes only for symbol-level diffing — a changed method inside a class shows up as "the class changed," not the specific method.
Python codebases only.
No persistent cache — the code graph and git history are rebuilt on every call. Fine for small/medium repos (verified under 100ms even on a ~6,500-commit, 37-file real project); would need caching for much larger ones.

Testing

pip install -e ".[dev]"
pytest tests/

Tests build a small, deterministic fake project with a hand-crafted git history (see tests/conftest.py) so results are reproducible. The tool has also been run against a real, unrelated open-source project (psf/requests) during development, which surfaced and led to fixing two real bugs that a synthetic test alone didn't catch.

License

MIT — see LICENSE.

Available Tools

5 tools

analyze_current_changeA

Analyze the repo's current uncommitted git diff and report files that might also need attention, tiered by confidence (HIGH / MEDIUM / REVIEW SUGGESTED) with a plain-English reason for each. against compares to a specific ref instead of HEAD (e.g. "HEAD~1").

ParametersJSON Schema

Name	Required	Description	Default
`since`	No
`against`	No
`repo_path`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral disclosure burden. It explains that the tool analyzes the diff and produces a tiered report with reasons, and it clarifies how `against` changes the comparison base. The 'analyze and report' phrasing strongly implies a non-mutating read operation, though it doesn't state read-only explicitly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The core behavior and output structure are front-loaded, and the second sentence explains the one non-obvious parameter. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description does well: it specifies the input condition, output tiers, reason format, and the `against` behavior. The main gap is the unexplained `since` parameter, but an agent can still invoke the tool correctly for the primary use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain `against` with an example, but `since` is never described and `repo_path` is only inferable from its name. This is partial compensation for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Analyze the repo's current uncommitted git diff' and report files 'that might also need attention.' It clearly differentiates the tool from siblings like get_changed_files by focusing on tiered follow-up attention rather than merely listing changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this when you need analysis of the current uncommitted diff. It also explains the `against` option as a comparison to a specific ref instead of HEAD. It doesn't explicitly name alternatives or exclusions, but the intended use case is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

explain_affected_fileA

Explain in detail why one specific file (assumed changed) has the related files it has -- the same evidence analyze_current_change uses, scoped to a single file you name.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes
`repo_path`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses the 'assumed changed' assumption and implies a read-only analysis operation via 'explain', but never explicitly states that it is non-destructive or describes the output format (no output schema exists). Moderate disclosure, with room to be more explicit about side effects and return shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the core purpose front-loaded in the first. The second sentence adds the valuable sibling reference and scoping clarification, though it partially restates the first sentence's scoping idea. Efficient overall with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an analysis tool with two parameters, no output schema, and no annotations, the description covers the core purpose and the sibling relationship well but omits expected return format and parameter details. An agent can call it correctly but will not know what the 'detail' output looks like or how to format the parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only hints at the file parameter via 'a single file you name' and says nothing about repo_path format or the relationship between the two required parameters. The self-explanatory names carry most of the meaning; the description adds little beyond them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (explain) and resource (why a single named file has its related files), and differentiates itself from siblings by referencing analyze_current_change as the source of the same evidence, scoped down. An agent can distinguish this from get_static_impact or get_historical_impact based on the explicit 'scoped to a single file' framing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context by tying itself to analyze_current_change ('the same evidence ... scoped to a single file you name'), which tells the agent this is the per-file variant. However, it does not explicitly state when NOT to use it or how it compares to get_static_impact/get_historical_impact, so routing among all four siblings is left partly to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_changed_filesB

List the .py files currently changed in the repo (uncommitted, or against a given ref).

ParametersJSON Schema

Name	Required	Description	Default
`against`	No
`repo_path`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says 'List', implying a read-only operation, but does not explicitly state that no changes are made, nor does it mention any dependencies (e.g., git installed), error conditions, or whether the output is limited to file names versus full paths. The description adds minimal behavioral context beyond the verb.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that gets straight to the point. It mentions the optional 'against' parameter in the parenthetical and does not waste words. The structure is efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given there is no output schema, the description should clarify the return format (e.g., file paths, relative/absolute). It specifies '.py files' and the set (changed), but does not describe the output content or structure. For a simple list tool this might be adequate, but the lack of any return details leaves a gap that could cause incorrect agent expectations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% since neither parameter has a description in the schema. The description only indirectly references 'against a given ref' (mapping to 'against'), but says nothing about 'repo_path', which is required. It does not compensate for the lack of schema descriptions, leaving the agent without explicit parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb (List), a specific resource (the .py files currently changed in the repo), and a scope that distinguishes it from analytical siblings. The parenthetical 'uncommitted, or against a given ref' further clarifies the operation, leaving no ambiguity about what the tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use it (to get currently changed files) but does not explicitly contrast with siblings like analyze_current_change or explain_affected_file. It does not state exclusions or when to prefer an alternative, though the distinct purpose is inferable from the naming and phrase 'currently changed'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_historical_impactC

Git-history-only evidence for one file: which files have changed alongside it before, how often, and with what confidence. No code connection required.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes
`since`	No
`repo_path`	Yes
`min_support`	No
`min_confidence`	No

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the tool is read-oriented ('evidence' from git history) and does not require code connection, but it does not explicitly state whether it is read-only, what happens if the file has no history, or what 'confidence' means operationally. The description adds minimal behavioral context beyond the high-level concept.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a tight, two-sentence summary that packs the core purpose and a key discriminator. It is front-loaded with the primary function and avoids redundancy. No unnecessary words or elaboration.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 parameters, no output schema, and no annotations, the description is far from complete. It omits parameter semantics, return format, and usage conditions. An agent cannot reliably construct a correct invocation without additional information, especially for parameters like min_support and min_confidence that have defaults but unclear effects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so parameters are only defined by type and default in the schema. The description does not explain any of the five parameters (repo_path, file, since, min_support, min_confidence). It mentions 'how often' and 'confidence' which loosely relate to min_support and min_confidence, but there is no explicit mapping or semantic explanation. The agent is left to guess parameter meanings, which is a major gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('get') and resource ('historical impact' from git history) with a precise scope: 'for one file', listing the exact outputs (which files changed alongside, how often, confidence). It also differentiates from static analysis by saying 'No code connection required', so an agent can distinguish it from tools like get_static_impact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no explicit guidance on when to choose this tool over its siblings. It implies a use case via 'No code connection required', but does not name alternatives or state conditions like 'use this when you need historical co-change evidence, use get_static_impact when you need code-level analysis'. An agent would have to infer when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_static_impactA

Current-code-only evidence for one file: who imports it, and who calls a function/class defined in it. No git history involved.

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes
`repo_path`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the scope (single file, current code) and explicitly excludes git history, which is a behavioral trait. However, it does not describe any side effects, permissions required, error handling, or what exactly constitutes 'evidence' (e.g., output format). The description is functional but lacks depth in behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the core purpose and scope. Every word adds value—'Current-code-only' and 'No git history involved' are essential qualifiers that prevent misuse. It is structurally clean and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should provide more context about what 'evidence' looks like, any prerequisites (e.g., a valid repo path), or potential limitations. It covers the core scope well but leaves gaps about expected results and usage constraints, making it incomplete for an agent that needs to call it correctly in all scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, so the description must compensate. It does not explain the parameters 'repo_path' or 'file' at all. While the parameter names are reasonably self-explanatory, the description fails to clarify expected formats, relative vs absolute paths, or any constraints. This leaves an agent to guess parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: providing evidence of who imports a file and who calls functions/classes defined in it, with a scope of 'current-code-only'. The explicit exclusion of git history distinguishes it from the sibling get_historical_impact, making its purpose unambiguous and specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool by emphasizing 'current-code-only' and 'No git history involved,' which signals it is for analyzing the current state of the codebase rather than historical changes. It lacks an explicit statement of when not to use it or which sibling to prefer, but the contrast with historical impact is clear enough for an agent to infer the typical use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv0.1.0Sep 10, 2026
- First observedanalyze_current_change
- First observedexplain_affected_file
- First observedget_changed_files
- First observedget_historical_impact
- First observedget_static_impact

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Scored 2026-09-10 03:41 across 5 tools

Disambiguation4/5

Most tools are clearly separated by their evidence source or scope: whole-diff analysis vs single-file explanation vs static vs historical. analyze_current_change and explain_affected_file are related but distinct enough in descriptions (whole set vs one file). Some minor overlap remains around which tool to pick for single-file impact evidence.

Naming Consistency4/5

Four tools use the get_* prefix and analyze_current_change/explain_affected_file use action_noun. The naming is clear and predictable, though there's a slight mix of get_ vs analyze_/explain_ verbs rather than a single uniform convention.

Tool Count5/5

Five tools tightly cover the change-impact domain: list changed files, analyze the whole diff, explain a single file, and query static or historical evidence. No redundancy and no bloat.

Completeness4/5

The main workflow is covered: list changed files, run a diff-based impact analysis, and drill into static or historical evidence per file. A possible minor gap is a way to combine static and historical evidence on demand outside the current-diff analysis.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Brain ScannerOAuth
io.github.kevin-lozada-santos
Codebase graphs, caller impact analysis, and recorded project context for AI coding agents.
Code Analysis Developer Tools Knowledge & Memory
1
SpiderbrainOAuth
ai.spiderbrain
Deterministic context layer for your codebase: change impact, blast radius, answers with receipts.
Code Analysis Developer Tools RAG Systems
13
ArchGraphOAuth
dev.archgraph
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code Analysis Software Architecture Developer Tools
2
Mapnostics
io.github.ffteema
Codebase intelligence for AI agents — dead code, blast radius, ownership.
Code Analysis Developer Tools
1

Related MCP Servers

MCP Workflow Engine
Developer Tools Code Analysis Testing & QA Tools
rubinownz111
F
license
A
quality
D
maintenance
Provides AI coding agents with dependency analysis, impact detection, and build verification tools.
Updated 8 months ago (2026-01-26 02:39 UTC)
14
-
Scrooge
Developer Tools Code Analysis Version Control
De-Cri
A
license
Not graded
quality
D
maintenance
Provides AI coding agents with pre-edit situational awareness by combining structural call graphs and co-change history to prevent incomplete edits. It surfaces files that historically change together, reducing missed coupled modules.
Updated 3 months ago (2026-05-30 10:56 UTC)
3
MIT
cms mcp
Knowledge & Memory Code Analysis
mrt150683-lgtm
A
license
Not graded
quality
B
maintenance
Exposes codebase memory as native tools for AI agents, enabling queries, feature tracing, impact analysis, and alignment verification.
Updated 2 months ago (2026-07-26 23:12 UTC)
4
AGPL 3.0
codecanvas-mcp
Code Analysis Developer Tools
donggyun112
A
license
Not graded
quality
B
maintenance
Provides local static-analysis tools for Python that let coding agents trace call paths, branch guards, side effects, and change impact, producing citation-ready answers with explicit uncertainty signals.
Updated 2 days ago (2026-09-11 03:42 UTC)
2
MIT