Skip to main content
Glama

neighbors

Expand context around a page by retrieving its neighboring subgraph up to a specified depth (capped at 2) to enrich search results.

Instructions

Subgraph around a page up to depth hops (capped at 2). Use after search to expand context.

Input Schema

NameRequiredDescriptionDefault
depthNo
page_idYes
site_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

No annotations exist, so the description carries the full disclosure burden. It usefully reveals a behavior the schema does not: depth is capped at 2, a real constraint an agent needs. However it says nothing about what the subgraph contains (node properties, edge direction, truncation of large neighborhoods) or cost/latency, which matters for traversal tools.

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 the core behavior first and the routing hint second — no filler. It is arguably under-written rather than bloated, but structurally it is tight and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and 0% parameter coverage, two sentences are not enough: the return shape of the subgraph, the meaning of the identifiers, and the depth default are all absent. Adequate to guess at the call, insufficient to call it confidently.

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 all meaning must come from the description, and it only addresses `depth` — giving the hop semantics and the cap of 2. `site_id` and `page_id` remain bare names with no indication of format, and the depth default of 1 is not mentioned.

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 verb-in-effect (retrieve the subgraph) and resource (pages neighboring a given page), scoped by `depth` hops. An agent can tell it apart from get_page (single page) and search (query-based retrieval). It never spells out 'neighbors of' in the schema sense, but the wording is concrete enough to act on.

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?

'Use after search to expand context' gives one concrete triggering condition and names the preceding sibling tool. There is no guidance on when not to use it (e.g. versus get_page for a single known page) or on what the result is good for beyond generic 'context'.

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