Skip to main content
Glama

impact

Read-only

Maps a code change's blast radius by fanning out from one or more nodes to affected or dependent code, returning ranked, deduplicated locations with reasons and dead-code markers.

Instructions

Blast radius in one call: fan out from one or more nodes to everything they affect (forward) or depend on / are used by (backward), returned as a deduped, ranked, located closure. Ranking is co-change first where the repo has git history synced, then Personalized PageRank. Each row carries path:line, the edge via reason it's in scope, and a ⊘ when the engine finds it unreachable from any entry point (likely dead). Structural import/containment fan-out is excluded, so there's no noise. A large radius comes back as the top rows plus the areas and files the rest fall in; page with offset, drill in with scope. Depth-1 in both directions is a node's immediate neighbours. Pass several comma-separated nodes to assess a whole diff at once.

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": {
      "nodes": "<nodes>"
    },
    "name": "impact"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoEvery row, uncut. Can be thousands of rows on a hub node; prefer scope/offset.
depthNoHow many hops to fan out. Default 4.
nodesYesOne or more node names/qnames, comma-separated. A diff touching N symbols is one call.
scopeNoOnly rows under this repo-relative path or project label. Use an area's scope from the footer to drill into it.
top_kNoRows to return. 0 = the engine's overview: the top 25 rows plus the areas the rest fall in, so you can drill down with `scope`.
budgetNoMax chars in the result. 0 = no cap.
offsetNoSkip the first N ranked rows to read the next page. The footer names the next offset.
directionNo'forward' (what it affects), 'backward' (what it depends on / who uses it), or 'both'. (Aliases: downstream=forward, upstream=backward.)both
live_onlyNoDrop nodes not reachable from any entry point (likely-dead code). Default False = show all, marking dead ones ⊘.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.5.4
    • addedInput schema / properties / full
      Added value: +{
      +  "default": false,
      +  "description": "Every row, uncut. Can be thousands of rows on a hub node; prefer scope/offset.",
      +  "title": "Full",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Skip the first N ranked rows to read the next page. The footer names the next offset.",
      +  "minimum": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
    • addedInput schema / properties / scope
      Added value: +{
      +  "default": "",
      +  "description": "Only rows under this repo-relative path or project label. Use an area's scope from the footer to drill into it.",
      +  "title": "Scope",
      +  "type": "string"
      +}
    • changedInput schema / properties / top_k / description
      Previous value: -"Cap the ranked result. 0 = no cap."New value: +"Rows to return. 0 = the engine's overview: the top 25 rows plus the areas the rest fall in, so you can drill down with `scope`."
  2. Changed8 schema fields changedv0.4.20
    • changedInput schema / properties / depth / default
      Previous value: -3New value: +4
    • changedInput schema / properties / depth / description
      Previous value: -"How many hops to traverse. Default 3."New value: +"How many hops to fan out. Default 4."
    • changedInput schema / properties / direction / default
      Previous value: -"downstream"New value: +"both"
    • changedInput schema / properties / direction / description
      Previous value: -"'downstream' (what it affects) or 'upstream' (what it depends on)."New value: +"'forward' (what it affects), 'backward' (what it depends on / who uses it), or 'both'. (Aliases: downstream=forward, upstream=backward.)"
    • addedInput schema / properties / live_only
      Added value: +{
      +  "default": false,
      +  "description": "Drop nodes not reachable from any entry point (likely-dead code). Default False = show all, marking dead ones ⊘.",
      +  "title": "Live Only",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / mode
      Removed value: -{
      -  "default": "table",
      -  "description": "'table' (tiered list) or 'prose' (primed prose for LLM context).",
      -  "title": "Mode",
      -  "type": "string"
      -}
    • changedInput schema / properties / nodes / description
      Previous value: -"One or more node names/qnames, comma-separated. A diff touching N files is one call."New value: +"One or more node names/qnames, comma-separated. A diff touching N symbols is one call."
    • addedInput schema / properties / top_k
      Added value: +{
      +  "default": 0,
      +  "description": "Cap the ranked result. 0 = no cap.",
      +  "maximum": 200,
      +  "minimum": 0,
      +  "title": "Top K",
      +  "type": "integer"
      +}
  3. Changed6 schema fields changedv0.4.19
    • addedInput schema / properties / budget
      Added value: +{
      +  "default": 0,
      +  "description": "Max chars in the result. 0 = no cap.",
      +  "minimum": 0,
      +  "title": "Budget",
      +  "type": "integer"
      +}
    • changedInput schema / properties / direction / description
      Previous value: -"'downstream' or 'upstream'."New value: +"'downstream' (what it affects) or 'upstream' (what it depends on)."
    • addedInput schema / properties / mode
      Added value: +{
      +  "default": "table",
      +  "description": "'table' (tiered list) or 'prose' (primed prose for LLM context).",
      +  "title": "Mode",
      +  "type": "string"
      +}
    • removedInput schema / properties / node
      Removed value: -{
      -  "description": "Node name or qname pattern to analyze.",
      -  "title": "Node",
      -  "type": "string"
      -}
    • addedInput schema / properties / nodes
      Added value: +{
      +  "description": "One or more node names/qnames, comma-separated. A diff touching N files is one call.",
      +  "title": "Nodes",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "node"
      -]New value: +[
      +  "nodes"
      +]
  4. Changed5 schema fields changedv0.1.3
    • addedInput schema / properties / depth / description
      Added value: +"How many hops to traverse. Default 3."
    • addedInput schema / properties / depth / maximum
      Added value: +10
    • addedInput schema / properties / depth / minimum
      Added value: +1
    • addedInput schema / properties / direction / description
      Added value: +"'downstream' or 'upstream'."
    • addedInput schema / properties / node / description
      Added value: +"Node name or qname pattern to analyze."
  5. First observedv0.1.2

TDQS

A4.6/5.0
Behavior5/5

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

Annotations supply only readOnlyHint, and the description supplies the substance: co-change-first then Personalized PageRank ranking, noise-free exclusion of structural import/containment fan-out, per-row payload (`path:line`, `via` edge reason, `⊘` dead markers), truncation to top rows plus area/file buckets, and paging hooks. This is exactly the extra context that lets an agent predict the output shape and cost.

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 payload and outcome first, then ranking, row format, and paging. Sentences are dense with information rather than waste, though the paging/scope paragraph partially duplicates schema descriptions and could be trimmed.

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

Completeness5/5

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

For a 9-parameter, richly-behaving analysis tool with an output schema, the description covers everything an agent needs to call it correctly: traversal direction, ranking basis, result shape, dead-code marking, truncation, and pagination. Nothing material is left for the agent to guess.

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 coverage is 100%, so the baseline is 3; the description still adds real meaning by tying `depth` to the concept of immediate neighbours, framing `direction` as impact vs. dependency, and explaining comma-separated `nodes` as whole-diff assessment. It restates offset/scope behaviour that the schema already documents, which keeps it from a 5.

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?

Opens with a concrete framing ('Blast radius in one call') and then states the operation precisely: fan out from nodes to what they affect (forward) or depend on/are used by (backward), as a deduped, ranked, located closure. The agent can tell this apart from find/read/trace without opening a schema, since the description defines the shape of the answer, not just the direction of traversal.

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?

Strong implicit routing and operational guidance: comma-separated nodes for assessing a whole diff at once, depth-1 for immediate neighbours, offset/scope for paging and drilling, top_k=0 for an overview. There is no explicit 'when not to use this, use X instead' against trace or find, so it stops short of a 5.

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