Skip to main content
Glama
Sign In
giancarloerra

SocratiCode

by giancarloerra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

codebase_impact

Identify the blast radius of changing a file or symbol by listing dependent files and functions that may break before refactoring, renaming, or deleting code.

Instructions

Impact Analysis — return the BLAST RADIUS for a file or symbol. Lists every file (and, where helpful, function) that could break if you change the target. Polymorphic on target: a path-like string ('src/foo.ts') triggers file-mode; a name-like string ('validateUser') triggers symbol-mode. Use this BEFORE refactoring, renaming, or deleting code to know what depends on it.

Input Schema

NameRequiredDescriptionDefault
fileNoOptional file path to disambiguate the target symbol.
depthNoHow many hops back to walk (default 3, max 10).
limitNoMaximum candidates to list when the target symbol is ambiguous. Omit to list all.
targetNoTarget file path (relative) OR symbol name.
symbolIdNoExact symbol ID (e.g. 'src/foo.ts::validateUser#10') to disambiguate.
projectPathNoAbsolute path to the project directory.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.16.1
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Maximum candidates to list when the target symbol is ambiguous. Omit to list all.",
+  "minimum": 1,
+  "type": "integer"
+}
  2. Changed3 schema fields changedv1.13.1
    • addedInput schema / properties / file
      Added value: +{
+  "description": "Optional file path to disambiguate the target symbol.",
+  "type": "string"
+}
    • addedInput schema / properties / symbolId
      Added value: +{
+  "description": "Exact symbol ID (e.g. 'src/foo.ts::validateUser#10') to disambiguate.",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "target"
-]
  3. Addedv1.8.2
  4. Removedv1.8.1
  5. Addedv1.7.2

TDQS

A4.4/5.0
Behavior4/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, and it does disclose a genuinely non-obvious behavior: polymorphic dispatch where a path-like target triggers file-mode and a name-like target triggers symbol-mode. It stays silent on prerequisites (e.g. whether the project must be indexed first) and on performance/ambiguity behavior, which slightly weakens it.

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?

Three tight sentences, front-loaded with the core effect, then the mode-switching rule, then the usage trigger. No filler and every sentence carries distinct information.

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 6-parameter, no-annotation, no-output-schema tool, the description covers purpose, target semantics, and use timing adequately. It omits return-shape expectations and any prerequisite about index state, which an agent would need to interpret results, but nothing is critically missing for invocation.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3, and the description adds real meaning beyond the schema by explaining how the `target` value's shape selects the operating mode. Other parameters (depth, limit, symbolId) are left entirely to the schema.

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 and resource ('return the BLAST RADIUS for a file or symbol') and immediately clarifies the effect ('lists every file that could break if you change the target'). This is clearly distinguishable from sibling graph/search tools like codebase_graph_query or codebase_search.

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?

Gives an explicit trigger condition: 'Use this BEFORE refactoring, renaming, or deleting code to know what depends on it.' It does not name a competing alternative tool or state when-not to use it, so it falls short of full routing guidance.

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