Your editor can see this.
Your AI agent can’t.

In your editor

In your editor, you press `Shift+F12` to find every caller of a function. `Shift+Alt+H` for the full call hierarchy. Right-click → Find All References to see every place a symbol is used, including the type annotations and function-pointer references a grep would miss. The language server answers in milliseconds. This is how you plan a refactor without breaking things downstream.

What Impact does

Think of Impact as the agent’s eyes on your call graph. Three queries against the same graph your editor reads from. `refs`, every place a symbol is used, including the value-passes, type annotations, and macro tokens grep misses. `deps`, what a file imports, and what imports it, one hop each way. `blast_radius`, direct importers of a file, each tagged by sensitivity, plus the symbols it exports with caller counts, plus a 0–100 risk score that blends fan-out and caller count. Same insight your editor gives you. Available to the agent over MCP. Across 26 languages. The sensitivity tagging and risk score are on top of editor parity, your editor does not give you those either.

How it actually works

Impact answers the question every developer and every agent asks before a non-trivial change: "if I touch this, what else uses it?" Three related queries, refs, deps, and blast_radius, sit under one tool name. The agent picks the right query for the question being asked; you do not have to think about which is which. All three are deterministic reads against the index, milliseconds, no LLM call.

The refs action finds every place a symbol is used. It combines two slices of the graph: the call_graph table for actual call sites (with call_type and argument_count per call) and the symbol_refs table for non-call mentions. Each result is tagged with a ref_kind so you know what you are looking at, "call" for invocations, "value" when the symbol is passed by value (.and_then(my_fn), let x = my_fn), "type_annotation" for type positions (let x: MyType), "path" for path expressions (MyMod::MyFn not invoked), and "macro_token" for identifier mentions inside macro bodies. The distinction matters for refactor safety, a function passed as a value is not a call site, but it is a reference, and a rename has to update it too. An optional file_path filter scopes results to one file. Default limit is 20, configurable up to 5000.

The deps action analyses a file's import graph in either direction. direction: "imports" walks outgoing imports (what this file uses). direction: "imported_by" walks incoming (what uses this file). direction: "both" returns both sides in one response, the default. Each result carries the file path, the line number, and a dependency_type of either "import" for runtime imports or "type_import" for type-only imports. Self-references are filtered out so you only see real cross-file edges. (Note: the direction parameter is MCP-only; the twira deps CLI command returns both sides unconditionally.)

The blast_radius action is the file-level impact answer. Pass a file path and get three things back. First, every file that directly imports the target, each tagged with a risk severity, RED, YELLOW, or GREEN, based on a content heuristic that recognises entry points, tests, configs, auth/crypto code, and shared infrastructure. Second, every symbol the file exports, with a caller_count for each. Third, an overall risk score from 0 to 100 with a level of low (0–20), medium (21–50), high (51–75), or critical (76+). The score blends the number of dependent files with the total caller count across the exported symbols, so a file used by many places carries a higher risk than one used by few. The agent runs this before suggesting a refactor; you get a clean "this change touches N files, M exported symbols, risk: high" answer instead of a guess.

A note on scope. blast_radius is one hop, it returns the files that directly import the target, not a transitive cascade through the dependency tree. The risk score and RED/YELLOW/GREEN tagging both operate on the direct importers. If you need the next hop, deps with direction: "imports" walks it manually.

Tiering: all three actions, refs, deps, and blast_radius, are Pro. The include_risk_score parameter on blast_radius still works as before (set it to false to skip the risk number and level), but the action itself is Pro either way. Impact is positioned as a single product: your editor can see this; your agent cannot; Twira gives the agent eyes, one Pro purchase, not a Free teaser plus a Pro upsell.

Setup is one step. Run twira index once on install, and the post-commit hook keeps the call graph and dependencies current. All three actions are then ready, over MCP for the agent, and at the CLI as the individual subcommands twira refs, twira deps, and twira blast-radius.

What it isn’t

• ·`blast_radius` is one hop, it shows the files that directly import a target, not a transitive cascade through the dependency tree.
• ·The call graph contains what the language can resolve statically. Calls through `eval`, reflection, or dynamic dispatch are not in it.
• ·RED, YELLOW and GREEN classify the *kind* of file that depends on your target, by path keywords (auth, crypto, api, test, docs, etc.) and content patterns (private keys, passwords, tokens). It is a "what could I break?" signal, not a likelihood-of-breakage rating.
• ·All three actions, refs, deps, and blast_radius, are Pro-tier.