SuperSkill

Overview Schema Source Related Servers Discussions Admin

impact

Read-only

Deterministic code-graph impact for a file or symbol: EXTRACTED definitions, importers, INFERRED callers, and the shortest graph path to a second target. Read-only; no LLM.

Instructions

Deterministic code-graph impact for a file or symbol: EXTRACTED definitions, importers, INFERRED callers, and the shortest graph path to a second target. Read-only; no LLM.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target": "<target>"
    },
    "name": "impact"
  }
}

Input Schema

Name	Required	Description
`to`	No	Optional second file/symbol target; when given, include the shortest path between both
`root`	No	Scan root (default: cwd)
`target`	Yes	Repo-relative file path, file:<path> id, or symbol name
`workspace_path`	No	Absolute thread workspace directory; must map to this project. Omit only when the server cwd is the thread workspace.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.13.0Oct 12, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Read-only is already covered by readOnlyHint=true, but the description adds real behavioral context beyond the annotation: it is deterministic and LLM-free, and it distinguishes EXTRACTED results (definitions, importers) from INFERRED ones (callers), signaling differing confidence levels. It does not address cost, limits, or failure modes, keeping it short of a 5.

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?

A single dense sentence that front-loads the core verb and resource, then lists the return categories and the read-only guarantee. No filler, no restated name, every clause carries 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?

With no output schema, the description carries the burden of explaining returns, and it does so by naming the four result categories and the optional path output. Read-only behavior is also stated. It stops short of describing result limits, graph staleness, or empty-result behavior, which a graph analysis tool would benefit from.

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 all four parameters are already documented. The description confirms the dual-target behavior ('shortest graph path to a second target') and the file-or-symbol nature of target, matching the schema without adding syntax, format, or default guidance beyond it. Baseline 3 for a fully covered schema.

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 and resource: deterministic code-graph impact analysis for a file or symbol, and enumerates what it returns (definitions, importers, callers, shortest path). It implicitly differentiates from graph_related/graph_traverse by framing the tool around change impact, but never names those siblings, so an agent must infer the boundary.

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?

Usage is implied by the name and framing ('impact', 'no LLM'), suggesting it fits when you want deterministic blast-radius answers rather than LLM-generated ones. However, there is no explicit when-to-use statement and no mention of the sibling graph tools (graph_related, graph_traverse, extract) that an agent would otherwise have to choose between.

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