sb_node_read

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful behavioral context by listing what the full node result contains: style, config, specials, per-breakpoint overrides, and bindings. This goes beyond the annotation and sets expectations for the response content, though it does not discuss error behavior or invalid IDs.

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 description is a single front-loaded sentence with a dash-separated list of content categories. Every word adds information, and there is no redundant phrasing or filler.

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?

For a simple one-parameter read tool with a readOnly annotation and no output schema, the description covers the key invocation context: a single node, full detail, and the major content sections returned. It is nearly sufficient but lacks explicit guidance on when to choose this over sibling read-ish tools like sb_outline, sb_look, or sb_traits_for.

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?

Schema coverage is 0%, and the only parameter 'id' is documented only as a string. The description implies the id identifies a node but does not state its format, how to obtain a valid value, or any constraints. With the schema providing no semantics, the description does not compensate for the gap.

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 states 'One node in full' and enumerates the content returned (style, config, specials, per-breakpoint overrides, bindings), clearly identifying a single-node read operation. The name and 'one node' scope distinguish it from search/list siblings like sb_catalog_search and sb_page_list, though the description never explicitly uses a verb like 'read' or 'retrieve'.

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?

The phrase 'One node in full' implies this tool is for retrieving complete node details rather than just outlines or traits, but there is no explicit when-to-use guidance or comparison with read-like siblings such as sb_outline, sb_look, or sb_traits_for. Usage context is implied, not stated.

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