Skip to main content
Glama

neighbors

Explore the surrounding subgraph of a node by following incoming and outgoing links up to a specified depth, returning connected nodes and edges for context.

Instructions

Subgraph around a node, following links in both directions up to depth. Same sampling and link merging as get_graph.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNo
limitNo
node_idYes
max_linksNo
edge_typesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose traversal direction (both directions), depth limiting, and that sampling/link merging match get_graph. However, it does not explain what the returned subgraph contains, whether it is read-only, or any side effects or limitations beyond depth.

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 concise sentences, front-loaded with the core purpose and key traversal behavior. The clause 'Same sampling and link merging as get_graph' is efficient but somewhat reliant on the sibling description, yet it keeps the text tight.

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?

There is an output schema, so return shape is presumably covered. However, with no annotations and zero schema parameter coverage, the description should explain the parameters and perhaps the sampling semantics more fully. The tool is not overly complex, so the description gives a reasonable starting point, but an agent would still need to inspect get_graph or the schema to fully understand limit, max_links, and edge_types.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for explaining all five parameters. It only gives meaning to 'depth' and implies 'node_id' via 'around a node'. Limit, max_links, and edge_types are completely unexplained, and the reference to get_graph does not define them for this tool.

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?

The description clearly identifies the tool as retrieving a subgraph around a specific node, following links in both directions up to a depth. This distinguishes it from siblings like get_node (single node) and get_graph (probably whole graph or larger subgraph), though it does not explicitly name an alternative.

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

Usage Guidelines3/5

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

The intended use is implied by 'Subgraph around a node' and the reference to get_graph for sampling and link merging. However, there is no explicit statement of when to prefer this tool over siblings, and no exclusions or alternative suggestions.

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