get_node

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

Despite readOnlyHint being present, the description adds substantial behavioral detail: full recursive subtree, maximum fidelity, every serialized field listed, no depth limit, no deduplication, and the exact return shape ({ node }, null when not found). This goes well beyond the simple read-only annotation.

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?

Three sentences, front-loaded with the primary action, followed by use cases, a distinctly named alternative, and return behavior. Every sentence earns its place with zero redundancy.

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?

The description covers the tool's high complexity (recursive subtree, fidelity, field types) and provides essential context for large trees, return format, and null behavior. No output schema exists, but the description sufficiently covers what the agent will receive.

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 100% (nodeId is fully described with type and URL fallback). The description adds no extra parameter-level semantics beyond stating 'by id', which is already implicit in the parameter name and schema. Baseline 3 applies.

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 uses a specific verb ('Return') with a clear resource ('one node by id') and explicitly distinguishes itself from get_design_context and other siblings by emphasizing 'full recursive subtree' with 'no depth limit' and 'no deduplication.'

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 explicitly states when to use this tool ('Best for inspecting a single component or a node you are about to modify') and provides a clear alternative for large trees ('prefer get_design_context'), including why (depth-limited, deduped, tokens resolved to names).

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