Skip to main content
Glama

topology_impact

Assess the blast radius of a symbol before refactoring with bidirectional dependency analysis, revealing what it depends on and what depends on it.

Instructions

Bidirectional BFS blast-radius analysis around a named symbol. Returns two sections: 'depends on' (outward — what the symbol depends on) and 'depended on by' (inward — what depends on this symbol). Primary use: assess blast radius before a refactor. Source is 'topology' (approximate); the topology call graph is intra-file, so for a function/method the inward section is augmented with a 'cross-file callers' block resolved via the language server (source=lsp) when one is available. mode="reachability" switches to entry-point reachability. The default package granularity follows production import edges from package-main roots plus candidate-seeded topology_routes roots; Go _test.go importers are excluded, and unsupported/polyglot workspaces are refused rather than reported as falsely unreachable. Set granularity="function" for the additive Go-only admitted partial static call graph: it uses exact callable roots, production callers, durable derived cross-file edges, and the full reachable closure. Unresolved receiver/dynamic calls, test callers, unsupported languages, and unindexed roots remain outside that lower-bound answer. Each granularity supports the default summary, path_to (one shortest root-to-target chain), and layers (SCC condensation; import cycles for package or recursion cycles for function). All outputs disclose their scope and known limitations, and responses are byte-capped. Returns a clear message when topology is disabled or the symbol is not in the index.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoOptional node kind to disambiguate a shared name: function, method, type, class, constant, variable, field, …
modeNoOptional. "reachability" switches from the default single-symbol blast-radius analysis to entry-point reachability. Go-only for now; roots/path_to/layers require this mode.
nameNoSymbol name or qualified name to analyse. Must exist in the topology index. Required unless mode="reachability".
pathNoOptional file-path substring to disambiguate when several indexed symbols share this name (case-insensitive).
depthNoBFS depth for both traversals. Default 3, max 4.
rootsNoRequires mode="reachability". package granularity accepts package directories or "main". function granularity accepts exact file.go#Symbol selectors or "main"; omit for defaults (package main roots plus candidate-seeded topology_routes roots).
layersNoRequires mode="reachability". When true, the response is an SCC condensation of the reachable subgraph — package import cycles or function recursion depending on granularity — instead of the summary.
path_toNoRequires mode="reachability". When set, the response is the single shortest root -> target chain; use a package directory for package granularity or file.go#Symbol for function granularity.
max_bytesNoApproximate byte budget per direction. Default 30000, max 100000.
max_nodesNoMaximum neighbour nodes per direction. Default 100, max 200.
edge_kindsNoOptional filter on edge kinds: calls, imports, contains, defines, inherits, implements. Defaults to imports, calls.
granularityNoRequires mode="reachability". Default package follows production import edges. function follows the admitted Go call graph outward from exact callable roots; test-file callers are excluded and unresolved/dynamic calls are disclosed.package

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv0.17.7
    • addedInput schema / properties / granularity
      Added value: +{
      +  "default": "package",
      +  "description": "Requires mode=\"reachability\". Default package follows production import edges. function follows the admitted Go call graph outward from exact callable roots; test-file callers are excluded and unresolved/dynamic calls are disclosed.",
      +  "enum": [
      +    "package",
      +    "function"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / layers
      Added value: +{
      +  "description": "Requires mode=\"reachability\". When true, the response is an SCC condensation of the reachable subgraph — package import cycles or function recursion depending on granularity — instead of the summary.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / mode
      Added value: +{
      +  "description": "Optional. \"reachability\" switches from the default single-symbol blast-radius analysis to entry-point reachability. Go-only for now; roots/path_to/layers require this mode.",
      +  "type": "string"
      +}
    • changedInput schema / properties / name / description
      Previous value: -"Symbol name or qualified name to analyse. Must exist in the topology index."New value: +"Symbol name or qualified name to analyse. Must exist in the topology index. Required unless mode=\"reachability\"."
    • addedInput schema / properties / path_to
      Added value: +{
      +  "description": "Requires mode=\"reachability\". When set, the response is the single shortest root -> target chain; use a package directory for package granularity or file.go#Symbol for function granularity.",
      +  "type": "string"
      +}
    • addedInput schema / properties / roots
      Added value: +{
      +  "description": "Requires mode=\"reachability\". package granularity accepts package directories or \"main\". function granularity accepts exact file.go#Symbol selectors or \"main\"; omit for defaults (package main roots plus candidate-seeded topology_routes roots).",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / required
      Added value: +[]
  2. First observedv0.16.6

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden, and it excels: it discloses that the topology source is approximate and intra-file, that cross-file callers come from the language server when available, that unsupported/polyglot workspaces are refused rather than falsely reported, and that every output discloses limitations and is byte-capped. This is unusually rich behavioral disclosure.

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?

The description is long, but the tool is complex with 12 parameters and no annotations. Almost every sentence contributes distinct information about modes, sources, limitations, or failure behavior. It would benefit from tighter paragraph separation, but it remains well above a minimal viable description.

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 complex tool with no output schema and no annotations, the description covers the input modes, granularities, edge kinds, source limitations, cross-file resolution, failure messages, and disclosed scope. An agent has enough context to decide when and how to invoke it and what to expect in return.

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 100%, but the description goes well beyond the schema by explaining the meaning of granularity, roots, mode, and path_to in operational terms. For example, package granularity is tied to 'production import edges from package-main roots plus candidate-seeded topology_routes roots', and function granularity is tied to an 'admitted Go-only partial static call graph' with exact callable roots.

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?

The description immediately pins down the behavior: 'Bidirectional BFS blast-radius analysis around a named symbol' and explicitly names the two output sections. It is clearly distinct from sibling topology tools like topology_search or topology_explore because it frames itself as blast-radius analysis for refactoring.

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?

It gives the primary use ('assess blast radius before a refactor') and explains when to switch modes and granularity, including Go-only and reachability constraints. It does not explicitly name sibling tools as alternatives, but the context is clear enough for an agent to choose it over related topology tools.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/plumbkit/plumb'

If you have feedback or need assistance with the MCP directory API, please join our Discord server