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

Graphenium

Official
by lambda-alpha-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

query_graph

Search the relational index by keywords to discover relevant nodes and explore topology when exact IDs are unknown. Returns budget-limited Markdown report for read-only initial graph discovery.

Instructions

Query the relational index with keywords to find relevant nodes and explore their topology. Use this read-only tool for initial discovery when you do not yet know the exact node IDs. If you already know the target ID, use inspect_symbol instead. To trace deep multi-hop paths, use trace_path instead. The query mechanism scores nodes by keyword match and traverses their neighborhood (BFS by default, or DFS if dfs=true). Results are rendered as a structured Markdown report. To prevent context bloat, the output is strictly truncated to fit within the provided budget (default 2000).

Input Schema

NameRequiredDescriptionDefault
dfsNoUse depth-first search instead of BFS (default false)
depthNoTraversal depth (1–6, default 3)
budgetNoApproximate output token budget (default 2000)
keywordsYesKeywords or phrase to search for (space-separated)
min_degreeNoMinimum node degree to include (filters low-degree noise)
node_typesNoOptional file types to include, e.g. ['code', 'document', 'rationale']
path_prefixNoOptional path prefix or path fragment to include (case-insensitive)
exclude_pathNoOptional path prefix or path fragment to exclude (case-insensitive)
include_testsNoInclude test/spec nodes in results. Default false (test/spec excluded).
ast_only_tuningNoAST-only tuning: true enables AST-only noise suppression, false disables it, omitted = auto
exclude_relationsNoOptional relation filters to exclude during traversal/rendering, e.g. ['imports']
include_relationsNoOptional relation filters to include during traversal/rendering, e.g. ['calls', 'uses']
generated_code_modeNoGenerated-like code filter: 'include' (default), 'exclude', or 'only'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.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 well: it declares the tool read-only, explains that scoring is keyword-based and traverses neighborhoods via BFS/DFS, and states that output is a structured Markdown report truncated to the token budget. It stops short of covering edge behaviors such as empty results, error handling, or determinism, so it is strong but not exhaustive.

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?

The description is front-loaded with purpose and usage, then adds mechanism, output format, and truncation behavior. Every sentence contributes useful information, and there is no redundant filler.

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?

Although there is no output schema, the description explains the return format as a structured Markdown report and notes budget-based truncation. Combined with the fully documented input schema and explicit alternatives, it gives an agent enough context to call the tool correctly.

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 the schema already documents all 13 parameters. The description repeats a few defaults such as BFS/DFS and budget=2000, but adds little parameter meaning beyond what the schema provides; the baseline of 3 is appropriate.

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 states a specific verb and resource: query the relational index with keywords to find nodes and explore topology. It also distinguishes the tool from siblings by naming inspect_symbol for known IDs and trace_path for deep multi-hop traversal.

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 explicitly gives the use case for this tool (initial discovery when exact node IDs are unknown) and names two alternatives with the conditions that select them. That is enough routing guidance for an agent to choose among the primary query options.

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