tzero-mcp

analyze_change_impact

Read-onlyIdempotent

Calculate change blast radius scores (0-100) and identify downstream dependents before modifying or deleting a function, class, or module to assess refactoring risk.

Instructions

Calculates change blast radius score (0-100) and identifies downstream dependents before modifying or deleting a target function, class, or module, distinguishing from 'analyze_code_dependencies' and 'audit_code_quality' by calculating targeted refactoring risk scores rather than mapping overall import graphs or profiling code complexity.

Parameters:

target_symbol (str, required): Name of the function, class, or method being modified or refactored.
project_root (str, optional, default='.'): Root directory of the repository (default: current directory).
file_path (str, optional, default=''): Optional file path where the target symbol is defined.

Behavior:

Read-only: Scans workspace AST and dependency graphs; does not alter files.
Idempotent: Deterministic blast radius scoring for identical repository states.
100% Offline: Local AST caller/callee traversal without remote API calls.
Auth & Rate Limits: Zero authentication or API keys required; completes in <300ms.
Error Handling: Returns 0 blast radius and not-found notice if the target symbol does not exist in AST index.

Usage Guidelines:

When to use: Run prior to editing a core interface, signature, or shared utility to gauge how many downstream files and tests will be impacted.
When NOT to use: Do not use for general whole-repository dependency mapping or PageRank centrality (use 'analyze_code_dependencies' instead); do not use for auditing static code complexity and code smells (use 'audit_code_quality' instead).

Returns: Markdown report with quantitative blast radius score (0-100), risk tier (LOW/MEDIUM/HIGH/CRITICAL), affected downstream modules, and test recommendations.

Input Schema

Name	Required	Description	Default
`file_path`	No	Optional file path where the target symbol is defined.
`project_root`	No	Root directory of the repository (default: current directory).	.
`target_symbol`	Yes	Name of the function, class, or method being modified or refactored.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv7.3.2Oct 24, 2026

addedInput schema / properties / file_path

Added value: +{
+  "default": "",
+  "description": "Optional file path where the target symbol is defined.",
+  "title": "File Path",
+  "type": "string"
+}

changedInput schema / properties / project_root / description

Previous value: -"Workspace root directory containing target symbols (default: current directory)."New value: +"Root directory of the repository (default: current directory)."

changedInput schema / properties / target_symbol / description

Previous value: -"Name of the function, class, or method to analyze for change blast radius."New value: +"Name of the function, class, or method being modified or refactored."

changedInput schema / title

Previous value: -"_legacy_analyze_change_impactArguments"New value: +"analyze_change_impactArguments"

changedOutput schema / title

Previous value: -"_legacy_analyze_change_impactOutput"New value: +"analyze_change_impactOutput"

Changed5 schema fields changedv7.0.1Oct 24, 2026

removedInput schema / properties / file_path

Removed value: -{
-  "default": "",
-  "description": "Optional file path where the target symbol is defined.",
-  "title": "File Path",
-  "type": "string"
-}

changedInput schema / properties / project_root / description

Previous value: -"Root directory of the repository (default: current directory)."New value: +"Workspace root directory containing target symbols (default: current directory)."

changedInput schema / properties / target_symbol / description

Previous value: -"Name of the function, class, or method being modified or refactored."New value: +"Name of the function, class, or method to analyze for change blast radius."

changedInput schema / title

Previous value: -"analyze_change_impactArguments"New value: +"_legacy_analyze_change_impactArguments"

changedOutput schema / title

Previous value: -"analyze_change_impactOutput"New value: +"_legacy_analyze_change_impactOutput"

Changed3 schema fields changedv7.0.0Oct 23, 2026

addedInput schema / properties / file_path

Added value: +{
+  "default": "",
+  "description": "Optional file path where the target symbol is defined.",
+  "title": "File Path",
+  "type": "string"
+}

changedInput schema / properties / project_root / description

Previous value: -"Workspace root directory containing target symbols (default: current directory)."New value: +"Root directory of the repository (default: current directory)."

changedInput schema / properties / target_symbol / description

Previous value: -"Name of the function, class, or method to analyze for change blast radius."New value: +"Name of the function, class, or method being modified or refactored."

Changed2 schema fields changedv0.1.1Oct 16, 2026

addedInput schema / properties / project_root / description

Added value: +"Workspace root directory containing target symbols (default: current directory)."

addedInput schema / properties / target_symbol / description

Added value: +"Name of the function, class, or method to analyze for change blast radius."

First observedv0.1.0Oct 15, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the read-only and idempotent bullets largely restate structured data. However the description adds genuine context beyond them: sub-300ms latency, zero auth/API keys, AST-based local traversal, and the specific failure behavior (0 blast radius plus not-found notice when the symbol is absent).

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 opening sentence front-loads purpose, output, and sibling differentiation, and the Behavior/Usage sections are scannable. The only waste is the Parameters block, which duplicates the schema verbatim and could be dropped, and a Returns section that partially overlaps the output schema.

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 read-only analysis tool with full annotation coverage, complete schema, and an output schema, the description covers trigger conditions, failure mode, and performance envelope. Nothing required for correct invocation is missing; the only shortfall is that specific return-shape detail is redundant given the output schema already exists.

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 100%, so the schema already fully documents all three parameters. The description's parameter list reproduces the same wording verbatim and adds no syntax, format, or resolution-order guidance (e.g. how file_path disambiguates duplicate symbol names). Baseline 3 applies.

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+resource (calculates blast radius score, identifies downstream dependents) with an explicit scope (0-100, targeted symbol). It also names the two nearest siblings and explains the differentiating mechanism — targeted refactoring risk scoring versus import-graph mapping or complexity profiling.

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

Usage Guidelines5/5

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

Contains an explicit 'When to use' (prior to editing a core interface, signature, or shared utility) and a 'When NOT to use' that routes to both named alternatives with the reason each is preferred. An agent can select among analyze_code_dependencies, audit_code_quality, and this tool without further inference.

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

Deploy Server

analyze_change_impact

Instructions

Input Schema

Output Schema

Schema Changelog

TDQS

Other Tools