Skip to main content
Glama

brain_neighbors

Retrieve neighboring nodes in a merged knowledge graph up to a specified depth, including cross-layer links between Obsidian vault and code projects.

Instructions

Neighbors of a node up to depth hops (BFS, max 50 results). Includes cross-layer links between vault knowledge and code.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
depthNo
node_idYes

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, the description carries the full burden and does disclose two useful traits: BFS traversal order and a hard 50-result cap (truncation behavior). It omits error/edge-case behavior (missing node, depth limits) and whether the cap silently truncates or errors.

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 short sentences with zero filler, and the core operation is front-loaded ahead of the supplementary cross-layer note. Not padded, though slightly terse for a 0%-coverage schema.

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?

An output schema exists so return values need not be described, and the description covers traversal semantics and the result cap. For a simple two-parameter read tool this is nearly complete, with only usage routing and node_id semantics missing.

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 coverage is 0%, so the description must compensate. It clarifies that `depth` means hop count, adding real meaning beyond the bare integer schema, but says nothing about `node_id` format/naming or acceptable depth ranges, leaving the required parameter undocumented.

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?

States a specific operation (retrieve neighbors of a node) with the traversal method (BFS) and result cap (max 50). The resource is clear, but it does not distinguish itself from siblings like brain_path or brain_context, which may also traverse graph structure.

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

Usage Guidelines2/5

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

No explicit when-to-use guidance or alternatives are given. An agent must infer that this is for local neighborhood exploration rather than path-finding (brain_path) or global search (brain_search), but the description never says so.

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