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

Beyond the readOnly/idempotent annotations, it discloses concrete operational traits: 60 calls/minute per caller, pageSize 1-50 (default 10), members capped at 50, a single served knowledge cutoff, and exact failure codes (node_not_found for unknown ids, as_of_unavailable, depth_limit) plus the 'cannot-measure' rather than empty-list convention. It also states 'Free, no key.' This is far more than the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence and nearly every clause carries a constraint, error code, or limit that an agent needs. It is nonetheless a dense wall of text with mild redundancy (standing is described twice, and depth=1 is restated), which costs some readability.

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

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

There is no output schema, so the description carries the return-shape burden, and it does: node identity, standing as five separate records, as-of cutoff, provenance, and neighbours folded as counts plus a first page of typed refs. Error modes, rate limits and continuation mechanics are all covered, leaving nothing essential for a correct call.

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

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

With schema coverage at 100%, the baseline is 3, and the description meaningfully exceeds it: it explains cursor semantics ('a page limit is a cursor, never an edge'), the id-vs-cursor relationship ('Optional when cursor is given' behaviour implied), concrete id syntax examples, and the depth/pageSize constraints and their refusal codes. That is real added meaning over the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb+resource: it opens ONE maintained-record node (schema sb.node.v1) and returns its identity, standing, as-of cutoff, provenance and folded neighbours. It also bounds the operation ('depth is 1 and only 1', 'no whole-graph dump'), which clarifies scope. However, it never names the sibling it competes with (get_entity, get_record, get_corroborated), so sibling selection still requires inference.

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

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

It clearly states the entry conditions and the continuation pattern: start from a name ('entity:hormuz', 'event:strait-of-hormuz') or an id, then 'follow any returned id, or pass a returned cursor, to open the next level'. It also excludes a whole-graph dump, so the agent knows this is one-level-at-a-time. What is missing is an explicit statement of when to prefer this over the sibling node/entity tools.

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