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

Graphenium

Official
by lambda-alpha-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

inspect_symbol

Inspect a symbol to retrieve its structural neighborhood, direct callers, neighbors, and metrics so you can orient and verify changes before modifying code.

Instructions

Inspect a symbol and retrieve its structural neighborhood and metrics. Use this read-only tool as your primary orientation step before modifying a specific class, function, or module. Use this instead of query_graph when you already know the exact target ID and need its direct callers, neighbors, or a verification plan. The baseline response returns canonical node details. Use the boolean flags to append optional data blocks (for example, include_callers=true appends all incoming dependencies). Setting multiple flags to true (such as include_analysis and include_file_summary) can produce large responses; use only the flags needed for your immediate task to conserve context budget.

Input Schema

NameRequiredDescriptionDefault
targetYesNode ID or label to inspect. When include_file_summary is set, a file path or filename suffix is also accepted.
group_byNoWhen include_file_summary is true, group symbols by 'kind' (default) or 'community'.
relationNoOptional substring used to filter neighbors by relation type, for example 'calls' or 'imports'.
show_leavesNoWhen include_file_summary is true, include low-degree leaf symbols of degree 5 or less. Default false.
max_neighborsNoMaximum number of neighbors to return (default 50, minimum 1).
extracted_onlyNoWhen include_neighbors is true, show only edges with EXTRACTED confidence. Default false.
include_callersNoAppend structural references to the target: containers, imports, inheritance, and implementations. Default false.
include_analysisNoAppend the composite symbol analysis with behavioral and structural connections plus a confidence summary. Default false.
include_neighborsNoAppend direct neighbors of the target with relation types, confidence, and scores. Default false.
include_explanationNoAppend a pre-change explanation with hierarchy, community context, entry points, must-read files, and test scaffolding. Default false.
include_file_summaryNoAppend a summary of every symbol extracted from the target's source file. 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, the description carries the full burden and does state the read-only nature and the key behavioral trait: flag combinations can produce large responses and consume context budget. It does not mention error behavior, truncation, or what happens when target is ambiguous, which keeps it short of a 5.

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 purpose and routing rule, then cost advice; every sentence has a job. It runs slightly long, and the flag-advice sentence partially repeats guidance implied by the schema's default-false flags.

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 an 11-parameter tool with no output schema, the description explains the response shape (baseline node details plus appended blocks) and when to add each. Adequate for correct invocation, though the include_callers mismatch and lack of note on how group_by/show_leaves interact with include_file_summary slightly reduce confidence.

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 adds real meaning by explaining the baseline-vs-optional-block model and the cost tradeoff of setting multiple flags. One caveat: it says include_callers 'appends all incoming dependencies' while the schema says containers/imports/inheritance/implementations, a slight semantic mismatch that could mislead.

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?

States a specific verb and resource ('Inspect a symbol and retrieve its structural neighborhood and metrics') and immediately clarifies the baseline return ('canonical node details') versus optional blocks. An agent can distinguish it from query_graph, trace_path, and get_architecture_summary without opening a 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?

Explicitly names the situation to use it ('primary orientation step before modifying a specific class, function, or module') and the alternative plus the exact selection condition ('use this instead of query_graph when you already know the exact target ID'). This is a genuine routing rule, not implied guidance.

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