Skip to main content
Glama
Sign In
lambda-alpha-labs

Graphenium

Official
by lambda-alpha-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

trace_path

Trace connectivity and multi-hop paths across codebase architecture to map blast radius, find shortest or safest routes, and verify transitive layering.

Instructions

Trace connectivity and multi-hop paths across the codebase architecture. Use this read-only tool to map blast radius, find shortest paths, or verify transitive layering. Use this instead of query_graph or inspect_symbol when you need to prove deep, multi-hop relationships between specific components. The tool operates in five distinct modes: shortest (finds semantic or strict AST paths between source and target), safest (finds the path with highest aggregate confidence), transitive_forward (downstream reachability), transitive_reverse (upstream callers), and module_dependencies (cross-module edges). Returns a structured Markdown report detailing the traced paths, confidence scores, and edge relations. Traversal halts when depth is reached, and output is truncated to fit the budget.

Input Schema

NameRequiredDescriptionDefault
modeNoRouting mode: 'shortest' (default), 'safest', 'transitive_forward', 'transitive_reverse', or 'module_dependencies'.
depthNoMaximum traversal depth for transitive modes (default 3, max 6).
budgetNoApproximate output character budget for transitive modes (default 2000).
sourceYesStarting node ID or label. For module_dependencies, this is the source module or directory path fragment.
targetNoDestination node ID or label. Required for shortest, safest, and module_dependencies modes. For module_dependencies, this is the target module or directory path fragment.
directionNoOptional direction override for transitive modes: 'forward', 'reverse', or 'both'.
path_modeNoShortest path strategy: 'semantic' (default) prefers calls, uses, and contains style relations; 'strict' uses the exact fewest hops.
node_typesNoOptional file types to include for shortest paths, for example ['code', 'document', 'rationale'].
path_prefixNoOptional path prefix or path fragment to include for shortest paths (case-insensitive).
exclude_pathNoOptional path prefix or path fragment to exclude for shortest paths (case-insensitive).
ast_only_tuningNoAST-only tuning for shortest paths: true enables AST-only noise suppression, false disables it, omitted = auto.
exclude_relationsNoOptional relation filters to exclude for shortest paths, for example ['imports'].
include_relationsNoOptional relation filters to include for shortest paths, for example ['calls', 'uses'].
generated_code_modeNoGenerated-like code filter for shortest paths: 'include' (default), 'exclude', or 'only'.
exclude_framework_noiseNoExclude framework and import-noise bridge nodes from shortest path search. Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.23.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden and does well: it declares the tool read-only, explains that traversal halts at depth, and that output is truncated to a character budget. It stops short of describing error conditions or how confidence scores are computed, leaving a minor gap.

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 text is front-loaded with purpose, then routing guidance, then mode enumeration, then return format and limits. It is dense and information-rich, though the mode list makes it longer than strictly necessary for a first read.

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?

For a 15-parameter tool with no annotations and no output schema, the description supplies what an agent needs: mode semantics, depth/budget behavior, and the shape of the returned Markdown report. Gaps remain around failure behavior and the many shortest-path tuning filters, which are left entirely to the schema.

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 earns above that by adding semantic meaning the schema does not, such as what 'safest' optimizes for (highest aggregate confidence) and what transitive_forward vs transitive_reverse traverse. It does not explain source/target interaction beyond mode requirements, so it is not 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?

The description opens with a specific verb and resource ('Trace connectivity and multi-hop paths across the codebase architecture') and immediately distinguishes its role from siblings by naming query_graph and inspect_symbol. An agent can tell what it does without opening the schema.

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

Usage Guidelines5/5

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

It gives both positive triggers ('map blast radius, find shortest paths, or verify transitive layering') and an explicit routing rule ('use this instead of query_graph or inspect_symbol when you need to prove deep, multi-hop relationships'), then enumerates the five modes so the agent knows which variant answers which question.

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