export_node

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It correctly indicates the tool saves config (a write operation), and mentions both single-node and all-node behaviors. However, it does not state whether the operation overwrites existing saved config, requires the lab to be closed or locked, or any error conditions (e.g., invalid node_id).

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 concise, with a clear heading sentence followed by structured parameter docs. Every sentence provides necessary information. The only small inefficiency is the parenthetical '(or all nodes)' which could be integrated more cleanly, but overall it is appropriately sized and front-loaded.

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 is adequate for a simple export tool with two parameters and a sibling list that includes other node operations. It explains both fixed and optional export behaviors. However, it omits return value details despite the presence of an output schema, and does not mention prerequisites (e.g., lab must be open, nodes must be started). This leaves some gaps for an AI agent to make mistakes.

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 description coverage is 0% for properties, so the description provides the only semantics for parameters. It describes `lab_path` as the full path to the .unl file and `node_id` as an optional integer for targeting a specific node (or omit for all). This adds value over the bare schema types, but does not clarify path format, file restrictions, or node_id validation (e.g., must exist).

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 that the tool exports a node's or all nodes' running config into the saved lab file. It specifies the target (running config) and destination (saved lab file) with a clear verb-resource pairing. The optional full-export behavior distinguishes it from node-specific operations, though it doesn't explicitly differentiate from other config management tools among siblings.

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 description implies this tool is used for exporting running configs to a lab file, providing an optional per-node or all-nodes usage pattern. However, it gives no guidance on when to use this versus alternatives like `edit_lab_node` or `open_lab`, nor does it exclude inappropriate scenarios (e.g., while the lab is locked or nodes are in a non-running state).

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