Skip to main content
Glama
pzalutski-pixel

javalens-mcp

by pzalutski-pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

analyze_change_impact

Trace the blast radius of changing a Java symbol: list every affected file and call site by depth or full transitive callers, including potential matches.

Instructions

Analyze the blast radius of changing a symbol.

USAGE: analyze_change_impact(filePath="path/to/File.java", line=10, column=5) OUTPUT: All files and call sites affected, grouped by file. Every reference at every depth is listed and counted; nothing is cut. A place JDT could not confirm is listed in potentialMatches with its depth, and the member holding it is followed no further.

Options:

  • depth: How many levels of callers to follow, 1 to 3 (default 1); any other depth is INVALID_PARAMETER depth=1: direct references only depth=2: references + callers of those references depth=3: three levels deep

  • transitive: full reverse closure over the project call graph (default false). No depth ceiling; follows calls, instantiations, field accesses, and override declarations (callers through an interface or superclass count). Returns affectedMethods + affectedFiles instead of callSites. Supports project methods, fields, and types.

  • maxResults: cap on affectedMethods in transitive mode (default 200)

potentialMatches, present only when there are any, holds the places JDT's search reports as possible matches but cannot confirm, because a type or name there does not resolve (a missing dependency or a compile error): count is their exact number, and locations lists them, as many as the results it stands beside may list. They are never counted or listed as results.

Requires load_project to be called first.

Input Schema

NameRequiredDescriptionDefault
lineYesZero-based line number
depthNoLevels of transitive callers to follow, 1 to 3 (default 1)
columnYesZero-based column number
filePathYesFile containing the symbol
maxResultsNoCap on affectedMethods in transitive mode (default 200)
transitiveNoFull reverse closure over the project graph, no depth ceiling (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.3
    • changedInput schema / properties / depth / description
      Previous value: -"Levels of transitive callers to follow (default 1, max 3)"New value: +"Levels of transitive callers to follow, 1 to 3 (default 1)"
  2. Changed2 schema fields changedv1.5.0
    • addedInput schema / properties / maxResults
      Added value: +{
+  "description": "Cap on affectedMethods in transitive mode (default 200)",
+  "type": "integer"
+}
    • addedInput schema / properties / transitive
      Added value: +{
+  "description": "Full reverse closure over the project graph, no depth ceiling (default false)",
+  "type": "boolean"
+}
  3. Addedv1.3.4
  4. Removedv1.3.3
  5. First observedv1.2.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses that nothing is cut ("every reference at every depth is listed and counted"), explains the potentialMatches caveat for unconfirmed JDT matches and that they are never counted as results, defines the transitive node types followed (calls, instantiations, field accesses, override declarations), and notes INVALID_PARAMETER for out-of-range depth. This is rich behavioral context beyond any structured field.

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?

Front-loaded with the purpose and organized under USAGE, OUTPUT, and Options headings, so it is easy to scan. It is longer than average, and the potentialMatches paragraph contains some convoluted phrasing ("as many as the results it stands beside may list"), but nearly every sentence earns its place for a 6-parameter tool with no 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 tool with no output schema and no annotations, the description adequately explains return shapes (callSites vs affectedMethods/affectedFiles), the potentialMatches structure, mode behavior, and the load_project prerequisite. It omits exact output field shapes and any performance/large-project caveats, leaving minor gaps.

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

Parameters5/5

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

Schema coverage is already 100%, but the description goes well past the schema: it enumerates the meaning of depth=1, 2, and 3, states that any other value is invalid, clarifies that maxResults applies only to affectedMethods in transitive mode, and specifies that transitive returns affectedMethods + affectedFiles instead of callSites. This adds substantial semantics over the raw parameter definitions.

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

Purpose4/5

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

States a specific verb+resource ("Analyze the blast radius of changing a symbol") and defines the scope as all files/call sites affected, grouped by file. This distinguishes it from narrow siblings like find_references or get_call_hierarchy_incoming, though it never names a sibling to route between them. Clear and non-tautological.

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 an explicit invocation example and a prerequisite ("Requires load_project to be called first"), plus mode-selection guidance distinguishing depth=1/2/3 semantics and when to use transitive closure. It does not explicitly say when to prefer this over find_references or get_call_hierarchy_incoming, so it stops short of full when/when-not/alternatives routing.

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

Deploy Server

Other Tools