Skip to main content
Glama

expand_node

One-hop neighbours of a known node (endpoint / Kafka topic / GraphQL operation / frontend call), with similarity scores and file paths. Read-only; no writes except a local exploration row if called within 10 min of a matching query_chains.

Instructions

One-hop neighbours of a known node (endpoint / Kafka topic / GraphQL operation / frontend call), with similarity scores and file paths. Read-only; no writes except a local exploration row if called within 10 min of a matching query_chains. Returns up to 3 matched source nodes × up to 10 neighbours (edges with score ≥ 0.08), plus a stale_warning field — call rescan if non-null.

Use AFTER query_chains when you already have a concrete node name and want to trace one hop further. Use query_chains (not this) when starting from a business term or when you don't yet know a node name. Partial, case-insensitive match against node id and raw_name; ambiguous inputs return multiple source groups.

Input Schema

NameRequiredDescriptionDefault
nameYesNode id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; short strings (e.g. 'get') will match many nodes and only the first 3 are expanded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.0.7
    • changedInput schema / properties / name / description
      Previous value: -"Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; very short strings (e.g. 'get') will match many nodes and only the first 3 are expanded."New value: +"Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; short strings (e.g. 'get') will match many nodes and only the first 3 are expanded."
    • addedInput schema / properties / name / minLength
      Added value: +2
  2. Changed1 schema field changedv1.0.6
    • changedInput schema / properties / name / description
      Previous value: -"Endpoint method name, Kafka topic name, or GraphQL operation name (partial match supported)"New value: +"Node id or raw name (endpoint method, Kafka topic, GraphQL operation, frontend call). Case-insensitive substring match against both id and raw_name. Prefer exact names copied from a prior query_chains result to avoid ambiguity; very short strings (e.g. 'get') will match many nodes and only the first 3 are expanded."
  3. Addedv1.0.3
  4. Removedv1.0.1
  5. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/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 so: it declares read-only status, discloses the one exception (a local exploration row if called within 10 min of a matching query_chains), documents result caps (3 source nodes × 10 neighbours, score ≥ 0.08), and surfaces the stale_warning field with a remediation step (call rescan). That is unusually complete 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?

Two dense, front-loaded paragraphs where the core purpose and the routing guidance come first; nearly every clause carries information (caps, threshold, stale handling). Slightly verbose but nothing is wasted.

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 shape (source groups × neighbours with scores), the cap, and the stale_warning field. An agent has everything needed to call it correctly and interpret the result.

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, but the description adds meaning beyond the schema by explaining the ambiguous-match behavior ('ambiguous inputs return multiple source groups') and reinforcing the substring semantics. It complements rather than repeats the schema.

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+resource ('One-hop neighbours of a known node'), enumerates the node types it operates on, and describes what comes back (similarity scores, file paths). It is immediately distinguishable from query_chains without opening any 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 states when to use it ('AFTER query_chains when you already have a concrete node name') and names the alternative with the condition that selects it ('Use query_chains (not this) when starting from a business term or when you don't yet know a node name'). Both the when and the when-not are covered.

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