Skip to main content
Glama

reaches

Finds which nodes depend on a target within a set depth, revealing reverse dependencies and change impact. Read-only.

Instructions

Reverse reachability: which nodes depend on target within max_depth. Read-only.

Input Schema

NameRequiredDescriptionDefault
targetYesTarget node path: absolute inside workspace or repo-relative POSIX
max_bytesNoResponse budget in bytes (default 65536, max 1048576)
max_depthNoMax reverse edges (default 10, integer >= 1)
workspaceNoWorkspace path; omitted = discovery from cwd
include_type_onlyNoInclude type-only edges (default false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden, and it only contributes the phrase "Read-only" to signal safety. It says nothing about truncation when max_bytes is exhausted, how cycles are handled, whether results are ordered, or what the response looks like.

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?

Two compact sentences with the core semantics front-loaded and zero filler. The clipped "Read-only." fragment is arguably the most useful per-word signal in the whole definition.

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

Completeness3/5

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

For a five-parameter graph-traversal tool with no annotations and no output schema, the definition is minimally viable but thin. It should clarify directionality relative to 'impact', describe truncation behavior tied to max_bytes, and note how workspace discovery affects resolution.

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 a baseline of 3 applies – the schema already documents target, max_bytes, max_depth, workspace, and include_type_only with defaults and constraints. The description mentions target and max_depth, but adds no syntax, format, or interpretation guidance beyond those fields.

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?

"Reverse reachability: which nodes depend on target within max_depth" names a specific operation and resource, and the parenthetical defines what the result set actually is. It is clear on its own but never contrasts itself with the sibling 'impact' tool, which a reader would plausibly confuse with reverse dependency traversal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description contains no when-to-use or when-not-to-use guidance and names no alternatives, despite four siblings (impact, search, focus, arch_snapshot) that could plausibly cover adjacent questions. An agent must infer from the name alone that this is the reverse-direction counterpart to a forward traversal.

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