get_node

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

No annotations provided, but description discloses return type (JSON with id, labels, properties or error/not-found message) and behavior for missing IDs. Lacks explicit mention of read-only nature, but implied. Minor gap for full transparency.

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?

Front-loaded purpose, followed by return info, usage advice, arg details, and examples. Every sentence adds value; no redundancy. Well-structured and concise.

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?

Given simple tool with 1 param and no annotations, description adequately covers purpose, usage, return structure (with output schema present), and examples. All essential information is present.

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 0% schema coverage, description fully explains the only parameter: 'node_id: The numeric node ID (e.g. 0, 1, 42).' Adds examples and clarifies it is numeric, going beyond the schema's integer type.

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 clearly states 'Get a single node by its ID' and specifies it returns labels and properties or a not-found message. It distinguishes from sibling tools like search_nodes_by_label and execute_gql.

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?

Explicitly says 'Use this tool when: you have a specific node ID and need its details' and 'Do NOT use this for: searching nodes by label or property (use search_nodes_by_label or execute_gql).' Provides clear when and when-not, with named alternatives.

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