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

No annotations are provided, so the description carries the burden. It discloses startup-config enabled and VPCS ignoring it, but lacks details on side effects like overwriting or error conditions. Partially addresses behavior.

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 are efficient and front-loaded with the main purpose. However, the structure could be improved by grouping related info. Minor waste in listing templates inline.

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 the complexity of 15 parameters and no annotations, the description covers key behavioral and usage aspects but leaves many parameter details unexplained. An output schema exists, so return values are handled externally.

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?

Of 15 parameters with 0% schema description coverage, the description adds value for template, image, and config, but does not explain cpu, ram, top, left, icon, name, delay, serial, console, ethernet, or node_type. Partial compensation.

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 'Add a node to a lab', with a specific verb and resource. It provides template examples and distinguishes from sibling tools like delete_node and get_node_config.

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 gives common templates and suggests using list_images for available images. It also explains startup-config behavior and VPCS quirk, but does not explicitly state when not to use or alternatives for node types.

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

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

With no annotations provided, the description carries full burden. It discloses key behavior: clones with topology and configs. However, it does not mention what happens if a lab with the same name exists or other side effects.

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 and front-loaded. Every sentence adds value without unnecessary wording.

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 the tool's low complexity and presence of an output schema, the description is largely adequate but could be improved by documenting the 'source_lab_path' parameter and clarifying overwrite behavior.

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% (no descriptions in schema), so description must compensate. It explains that 'name' is the clone's new name and need not include '.unl', but does not describe 'source_lab_path' at all.

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 it clones a lab, copying topology and configs. It distinguishes from sibling tools like create_lab, which creates new empty labs, and rename_lab, which renames rather than copies.

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 explicitly mentions templating use case ('Great for templating — duplicate a base lab N times'), providing clear context for when to use. However, it does not explicitly state when not to use or list alternatives.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It explains the automatic conversion of interface names and special indexing for IOL/VPCS, but does not address auth needs, rate limits, or what happens if the connection already exists or fails.

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, using a few short sentences. It front-loads the main purpose, then adds essential details and a warning. No superfluous information is present.

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 the tool's complexity (7 parameters, 5 required, no annotations), the description adequately covers the main usage scenario and interface details. However, it lacks mentions of prerequisites (lab path must be valid, nodes must exist) and error handling, making it slightly incomplete.

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%, so the description must compensate. It adds value for interface parameters by explaining index vs. name and automatic conversion. However, it does not explain 'network_name' or 'network_type', which are present in the schema but undocumented.

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 'Create a point-to-point link between two node interfaces,' which is a specific verb+resource. It also provides examples of interface indexing, making the purpose unmistakable. The existence of a sibling tool 'disconnect_nodes' naturally contrasts with this tool's function.

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 provides clear guidance: 'Use get_lab to see each node's interface map' and explicitly warns 'Do NOT connect nodes after editing them — wire the topology, then start.' While it does not mention alternative tools, it gives strong contextual cues for when to use.

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

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

No annotations are provided, so the description carries full burden. It only states the creation action without disclosing behavioral traits such as permissions, overwrite behavior, naming constraints, or side effects.

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 extremely concise with a single sentence containing all essential information. No wasted words or unnecessary details.

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 the tool's low complexity (2 parameters, output schema exists), the description is minimally adequate but lacks additional context like error conditions or relationship to labs. It covers the basics but leaves gaps.

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 description adds value by clarifying the path parameter with 'path='/' for root.' However, the name parameter remains unexplained. The description partially compensates but is incomplete.

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 the tool creates a workspace subfolder for organizing labs, using the verb 'create' and specifying the resource 'folder'. It distinguishes from sibling tools like delete_folder by focusing on creation and organization.

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 usage by noting path='/' for root, but lacks explicit guidance on when to use this tool versus alternatives like create_lab or other organizational tools. No when-not-to or exclusion criteria are provided.

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

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

No annotations provided, so description carries full burden. It only states creation and activation but omits critical behavioral details like whether it overwrites existing labs, error handling, or required permissions. This is insufficient for a mutation tool.

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?

Single sentence, no unnecessary words. Front-loaded with core action and side effect. Every word earns its place.

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?

Despite having an output schema, the description does not explain return values or side effects beyond opening the lab. Parameter descriptions are entirely missing. Given the tool's complexity (6 params, output schema), the description is incomplete.

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% and description does not mention any parameter. The description adds no meaning beyond the schema fields, which have no descriptions either. For a tool with 6 parameters, this is a critical 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?

Description clearly states the tool creates a new lab and opens it as the active session, with a specific verb and resource. It differentiates from siblings like clone_lab and open_lab by including the side effect of opening the lab.

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?

No guidance on when to use this tool versus alternatives such as clone_lab or open_lab. Does not mention prerequisites, constraints, or typical scenarios.

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

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

Despite no annotations, description discloses irreversibility, recursive deletion, and a blocking condition (error_folder_running). This covers key behavioral traits for a destructive operation.

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?

Two concise sentences, front-loaded with key information: action, effect, irreversibility, and blocking condition. No unnecessary words.

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?

Description covers essential behavior and constraints. With an output schema present, return values are presumably documented. Could add details on required permissions, but overall complete for a deletion tool.

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?

Only parameter folder_path has no additional explanation beyond the schema. Schema description coverage is 0%, but description does not add format, examples, or constraints. Baseline 2 as it fails to compensate.

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?

Description clearly identifies the action (delete) and resource (workspace folder), and emphasizes irreversibility and recursive deletion. Distinguishes from siblings like delete_lab and delete_node.

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?

Provides a condition when the operation is blocked (any lab running), but lacks explicit guidance on when to use this tool versus alternatives like move_lab or create_folder. It implies caution but no direct when-not.

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

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

With no annotations provided, the description carries the full burden. It discloses that nodes are stopped and wiped, the lab is unbound, and the .unl file is kept unless delete_file=true (irreversible). It also mentions it can work on running labs and is not blocked by others, providing useful behavioral context.

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 three sentences long, free of fluff, and front-loads the core purpose. Every sentence adds value: purpose, default behavior, parameter condition, and usage constraints.

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 the tool's simplicity (2 params, 1 required, no annotations, output schema exists), the description adequately covers the behavior, parameter effects, and usage context. It is complete for an agent to decide when and how to invoke it.

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%, so the description must compensate. It explains the lab_path parameter (works in root or subfolder) and the delete_file parameter default behavior and irreversibility. While it does not detail lab_path format, it provides sufficient meaning for both parameters.

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 the tool tears down a lab's running session, stops, wipes nodes, and unbinds, which is a specific verb and resource. It distinguishes from sibling tools like delete_folder or delete_node by specifying it targets labs and their sessions.

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 explains that the .unl file is kept by default and that passing delete_file=true permanently deletes it, guiding parameter usage. It also notes the tool works in root or subfolders and is not blocked by other labs. However, it does not explicitly state when to use this tool over alternatives like stop_lab.

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

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

Discloses that deletion includes links ('and its links'), warns about interface binding issues if order is wrong. No annotations present, so description carries full burden. Lacks details on reversibility or side effects on connected nodes.

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 focused sentences. Each sentence adds distinct value: purpose, usage tip, prerequisite location. No redundancy or fluff.

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?

Covers core behavior and a key usage tip. Does not mention return values (though output schema exists), error conditions, or idempotency. Adequate for a simple delete tool but leaves some ambiguity.

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 provides no parameter descriptions (0% coverage). The description does not explain the meaning or format of lab_path or node_id beyond implying node_id is an identifier. This forces the agent to infer meaning from context alone.

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 the action: 'Delete a single node from a lab (and its links).' It uses a specific verb and resource, and distinguishes from siblings like delete_lab and wipe_node. No ambiguity.

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?

Provides a explicit order-of-operations recommendation: 'Prefer deleting a node BEFORE re-wiring its neighbors' with a rationale about interface bindings. Also directs to use get_lab to find node_id. However, does not contrast with alternative tools like disconnect_nodes or wipe_node.

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

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

No annotations provided, so description carries full burden. It discloses that the tool deletes underlying network and for point-to-point disconnects both ends. Lacks details on permissions or reversibility but is informative.

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 concise sentences with front-loaded main action. No redundant information; every sentence adds value.

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?

Covers key behavioral details, usage guidance, and parameter format. Output schema exists but is not shown; description does not need to duplicate it. Missing only minor safety notes, but overall complete.

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%, so description must add value. It explains that node_interface can be an index or style name (e0/1, IOL formats). However, lab_path and node_id receive no additional semantics beyond property names.

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 the verb 'remove' and resource 'link on a node's interface' with the added nuance of deleting the underlying network. It distinguishes from sibling tools like connect_nodes by specifying the disconnection behavior.

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?

Provides context: when to use (to disconnect), special case for point-to-point links (only pass one side), and suggests using get_lab to see connected interfaces. Lacks explicit 'when not to use' but is adequate.

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

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

No annotations provided; description carries full burden. It discloses the export action, file saving, and return value, but lacks details on side effects, overwriting behavior, or permissions required. Adequate but not thorough.

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?

Two sentences, no wasted words, front-loaded with key action and parameter guidance. Extremely concise and structured well.

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 the tool's simplicity and presence of output schema, the description covers the essential aspects: purpose, parameters, return, and relationship to upload_lab. Minor gap: no information on error handling or input validation.

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 description coverage, the description adds meaning by explaining save_path (file/directory, defaults to current dir) and implies lab_path is the lab to export. Could be more explicit about lab_path format, but generally helpful.

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 the tool exports a lab to a .zip backup and saves it locally. It also mentions round-trips with upload_lab, providing context and differentiation from 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 usage for backup (round-trip with upload_lab) but does not explicitly state when to use or avoid this tool versus alternatives like clone_lab or export_config. It gives some guidance on save_path parameters.

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

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

With no annotations, the description discloses key behaviors: the node must be running, node_id=0 exports all, and it refreshes get_node_config. It implies the operation overwrites startup config, but could explicitly mention destructive nature.

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 purpose, each sentence adds meaningful information without redundancy or fluff.

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 2-param tool with output schema, but missing description of the required lab_path parameter. It covers the main functionality and special uses, but the lab_path omission is a notable gap.

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% per signal. Description adds value for node_id (explaining the effect of 0), but lab_path is required and not described at all, leaving a gap in understanding the parameter.

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 the tool saves a running config to startup config, using specific verb 'save' and resource 'running config to startup config'. It distinguishes from siblings by mentioning PNETLab 'Export CFG' and refreshing get_node_config.

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 specifies when to use (to persist changes, node must be running) and provides a special case (node_id=0 for all nodes). It does not explicitly name alternatives or when-not-to-use, but the context is clear.

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

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

No annotations are provided, so the description must disclose behavioral traits. It explains what is returned (metadata, nodes, networks) but does not state whether the operation is read-only, requires permissions, or has side effects.

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 sentence that efficiently conveys the core purpose and key output elements. Every part is necessary, and it is front-loaded with the main action.

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?

Although an output schema exists and the description covers key output aspects, the complete lack of parameter guidance and absence of any behavioral transparency leave gaps. For a simple tool, it is adequate but not fully comprehensive.

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?

The input schema has one required parameter 'lab_path' with no description. The description does not explain the parameter's format, examples, or how to specify it, failing to compensate for 0% schema coverage.

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 the tool retrieves a lab's full topology, including metadata, nodes with status and interface map, and networks. The verb 'Get' and specific resource distinguish it from siblings like connect_nodes.

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 a usage context by mentioning the interface map is needed for connect_nodes, but it does not provide explicit when-to-use vs when-not-to-use guidance or alternatives.

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

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

No annotations are present, so the description must carry the full burden. It does not disclose whether the operation is read-only (presumed) or if any permissions are required, nor what happens if the node is offline. It lacks behavioral context beyond the basic function.

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 sentence with no fluff, perfectly concise and front-loaded. Every word is necessary.

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 the tool's simplicity and presence of an output schema, the description provides the core function but lacks parameter guidance. It is minimally complete but could do more to explain usage context.

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% with 2 parameters. The description adds no information about what 'lab_path' or 'node_id' represent or how to obtain them, failing to compensate for the lack of schema descriptions.

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 the verb 'Get' and the resource 'node's current startup-config text', which distinguishes it from sibling tools like export_config or push_config. It is specific and unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives, such as when to use export_config or push_config. No context for prerequisites or exclusions is given.

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

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

The description reveals what data is returned (status, console URL, interfaces) but does not discuss behavioral aspects like whether it requires the lab to be running, authentication needs, or error responses. With no annotations, more detail would improve 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?

Single sentence, 16 words, directly communicates the core purpose and key outputs. No wasted words.

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?

While the tool has an output schema, the description omits crucial context: parameter semantics, usage prerequisites, and behavioral details. For a two-parameter tool, this leaves significant gaps in understanding.

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?

The input schema has 0% description coverage, and the tool description provides no explanation of the parameters (node_id, lab_path). The agent has no context on what values to provide for these required fields.

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 the tool gets a node's status, including specific status codes (0,1,2), console URL, and interfaces. It uses a specific verb and resource, distinguishing it from sibling tools like get_node_config.

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?

No guidance on when to use this tool versus alternatives, no prerequisites, no context about typical use cases. The description does not help the agent decide between get_node_status and sibling tools like start_node or stop_node.

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

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

Without annotations, the description carries full burden. It implies a read-only query by describing it as getting a schema, and hints at safe usage before add_node. It could explicitly state idempotency or lack of side effects, but the context is sufficient.

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 with no wasted words. First sentence states purpose, second gives usage guidance, third provides input source. Front-loaded and efficient.

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 an output schema is present, the description need not detail return values. It covers purpose, usage workflow, and input source—fully complete for a simple query tool with one parameter.

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%, so description must compensate. It explains the 'template' parameter expects a key from list_images and gives examples of returned fields, adding meaning beyond the schema's bare 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 the verb 'Get' and the resource 'node template's add-node option schema', with concrete examples of returned fields. It distinguishes from siblings by explicitly referencing add_node and list_images.

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 explicitly advises 'Use before add_node to pick correct parameters' and directs the user to 'Get template keys from list_images', providing clear when-to-use and where-to-get-input context.

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

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

No annotations provided, so description must cover behavior. It discloses the filtering of missing/uninstalled items, but does not mention side effects, authorization needs, or rate limits. Partial 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?

Single sentence that is efficient and front-loaded. No unnecessary words or repetition.

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 list tool with no parameters and an output schema, the description covers the core functionality and filtering. Could be slightly more explicit about the return format, but output schema likely handles that.

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?

Input schema has no parameters, so schema coverage is 100% trivially. Baseline for 0 parameters is 4; description needs no further elaboration on parameters.

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?

Description clearly states it lists installed node templates/images, with additional detail that missing/uninstalled ones are filtered out. This differentiates it from sibling tools like list_labs or list_running_labs.

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?

No guidance on when to use this tool versus alternatives such as get_node_config or get_template_options. The description simply states what it does without context for selection.

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

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

No annotations are provided, so the description bears full transparency burden. It discloses return fields and hints that the path is for use with open_lab/get_lab, but does not explicitly state it is non-destructive or discuss any limits. Adequate but not comprehensive.

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?

Two sentences, front-loaded with the primary action, no redundant words. Efficient and clear.

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 an output schema exists (context signal), the description does not need to detail return values. It covers the input parameter and usage well, making the tool complete for its simple listing purpose.

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 has 0% description coverage. The description clarifies the 'folder' parameter beyond the schema by explaining its purpose: 'Pass a folder path to list a subfolder.' This adds meaningful usage context.

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 it 'list labs and subfolders in a workspace folder' and specifies return fields (name, full path, last-modified time). It distinguishes from siblings like list_running_labs and get_lab by its scope.

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 gives the default folder ('/') and says to pass a folder path for subfolders. It does not explicitly compare with siblings, but the context of many list-type tools makes the usage clear.

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

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

With no annotations, the description carries the full burden. It explains the condition for a lab being listed ('has an open pod') and the behavioral implication (blocks deleting .unl files). No destructive behavior or rate limits are mentioned, but it is sufficient for a read-only list tool.

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 two sentences, front-loaded with the primary purpose and return fields. Every sentence adds value with no waste.

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 output schema exists, so the description does not need to explain return values. It covers the tool's purpose, the condition for a lab being listed, and a practical use case (blocking deletions). Complete for a zero-parameter list tool.

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?

The input schema has zero parameters, so schema description coverage is 100%. The description adds no parameter details, but none are needed. Baseline 3 applies as it does not add value beyond the schema.

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 the verb 'list' and the resource 'current running lab sessions', and specifies the returned fields (lab path, session id, pod, running-node count). It distinguishes from sibling tools like 'list_labs' by focusing only on running sessions.

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 usage for checking running labs that block deletions (mentioned via 'error_lab_running'), but does not explicitly state when to use this tool versus alternatives like 'list_labs' or provide exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden for behavioral disclosure. It only mentions the prerequisite about the folder but does not describe any side effects (e.g., impact on running labs, permissions needed, reversibility, or error states). The agent has insufficient information to anticipate the tool's behavior beyond the basic move action.

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 extremely concise: two sentences with no filler. The first sentence states the primary action, and the second provides critical usage guidance. Every word earns its place.

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?

With 2 required parameters, no annotations, but an output schema present (so return values are covered externally), the description is adequate but lacks clarity on the 'lab_path' format and any preconditions (e.g., lab must exist). It covers the folder prerequisite well but omits other contextual details like error handling or state changes.

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%, so the description must compensate. It adds value for the 'folder' parameter by explaining the root case ('/'), but does not elaborate on 'lab_path' (e.g., whether it is a path, ID, or name). Partial compensation keeps it above baseline but still leaves ambiguity for one of the two required parameters.

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 the action ('Move a lab') and the destination ('into another workspace folder'), with a specific verb and resource. It distinguishes itself from sibling tools like rename_lab and clone_lab by being the only move operation, and includes a prerequisite (folder must exist) that clarifies scope.

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?

Provides explicit guidance on when and how to use the tool: the destination folder must exist first, with a reference to create_folder as a prerequisite, and a special case for the root folder ('/'). This helps the agent decide the correct sequence of tool calls.

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

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

No annotations are provided, so the description carries the full burden. It states the tool binds a lab to a session affecting subsequent tools, which is a behavioral trait. However, it lacks details on error states, permissions, or side effects like overwriting a previous binding.

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?

Two sentences with no wasted words. The first sentence defines the core function, and the second adds context. Ideal length for clarity.

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 the tool's simplicity (one param, no annotations) and presence of an output schema (which description needn't detail), the description adequately covers purpose and usage but falls short on parameter details and behavioral nuances.

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 description coverage, the description should compensate but only implies lab_path is the path to an existing lab. It adds no format, validation rules, or examples beyond the schema's type definition.

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 the action ('Bind an existing lab to the session') and the resource ('lab'), and distinguishes it from siblings by noting that most tools auto-open their lab_path, making this explicit switch tool unique.

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 explicitly says it's 'usually unnecessary' and provides the scenario for use ('useful to switch the active lab explicitly'), giving clear when-to-use and when-not-to-use guidance.

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

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

Despite no annotations, the description discloses key behaviors: config is stored and loads on next boot (delayed effect), IOL L2 switches require specific command order, VPCS nodes ignore startup-config. This fully informs the agent of consequences.

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, each serving a distinct purpose: main action, IOL caveat, VPCS caveat. Front-loaded with purpose, no redundant phrasing.

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?

Provides important behavioral context and usage caveats, but lacks any parameter descriptions. Given the tool has 3 required parameters and an output schema, the description is incomplete without parameter guidance.

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 description coverage, the description must explain parameters, but it does not. No information about what the config string should contain, how to specify node_id, or format of lab_path. This is a critical 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 clearly states the action 'push a startup-config' and the target resource 'to a node'. It distinguishes from sibling tools like export_config or get_node_config by specifying it's for pushing a startup config that loads on next boot.

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?

Provides explicit guidance on when to use (push startup config) and when not to use (VPCS nodes ignore startup-config). Also gives a critical workaround for IOL L2 switches regarding 'vtp mode transparent' before VLAN entries.

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

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

With no annotations, the description fully covers behavior: it is a read-only operation, returns a PNG, can type commands first, and warns about console contention and the need to close browser tabs. No contradictions.

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 three sentences of essential information. It front-loads the main purpose and packs details efficiently without wasted words.

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 prerequisites, usage patterns, and typical use cases. It does not detail error conditions or response format, but 'returns a PNG image' is sufficient for a straightforward read tool. No output schema exists, so more detail could help, but it is adequate.

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?

Despite 0% schema coverage, the description adds meaning by explaining the 'commands' parameter (list of lines to type). 'node_id' and 'lab_path' are left implicit but are standard and understandable from context. The description compensates well for the schema's lack of descriptions.

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 it reads a node's LIVE console as a screenshot, returning a PNG image. It explicitly distinguishes itself from send_console, which is a sibling tool for writing. Specific use cases like verifying 'show' commands are listed.

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 provides explicit when-to-use guidance: for reading console output, especially after typing commands. It gives a key pattern (type+read in one call to avoid contention). Prerequisites (node must be running, close browser console tab) are stated. However, it does not explicitly state when not to use.

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

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

Despite no annotations, the description adds behavioral detail: PNETLab sanitizes names by stripping special characters, and the new name must be passed without .unl extension. However, it does not mention potential side effects, permissions, or whether the lab must be stopped.

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?

Two concise sentences. First states purpose, second provides critical usage detail. No unnecessary words.

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?

Description covers core rename action and a key behavior (sanitization), but omits error conditions, return values (though output schema exists), and prerequisites like lab existence or state. Acceptable for a simple operation but not thorough.

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%, so description must compensate. It adds meaning to 'new_name' (omit .unl extension) but provides no guidance on 'lab_path' format (e.g., full path or relative). Only one of two parameters gets partial clarification.

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?

Description clearly states the tool renames a lab by changing its .unl filename, which is a specific verb-resource pair. It distinguishes itself from siblings like clone_lab or move_lab by focusing on renaming behavior.

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?

No guidance on when to use this tool vs alternatives like move_lab or clone_lab. No context about prerequisites or scenarios where renaming is appropriate.

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

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

With no annotations, the description fully discloses behavioral traits: write-only (no output read back), one connection allowed, commands sent with Enter, requires running node, and Guacamole tunnel usage. This exceeds expectations for a tool without annotations.

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 dense paragraph, but it front-loads the key purpose and differentiators. Every sentence adds value (examples, constraints, write-only warning). It could be slightly more structured (e.g., bullet points), but it remains concise without fluff.

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 the tool's complexity (3 required params, write-only behavior, multiple command types), the description covers all essential aspects: purpose, usage, constraints, examples, and verification steps. Despite having an output schema (not shown), the description explains the write-only nature, making completeness high.

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%, but the description compensates well by explaining the commands parameter with detailed examples (IOS and VPCS command sequences). It implies lab_path and node_id by context, but does not explicitly describe their format or purpose. However, the examples and usage instructions add significant meaning beyond the raw schema.

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 the tool types commands on a node's LIVE console via Guacamole tunnel, and explicitly differentiates it from push_config by listing specific use cases like VPCS IPs and IOL dot1Q subinterface IPs. The verb 'Type commands' and resource 'live console' are specific, and sibling differentiation is present by naming what push_config cannot do.

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 provides explicit when-to-use (push_config limitations, live write mem, VPCS), prerequisites (node must be running, close other console tabs), and examples for IOS and VPCS. It also says to verify with export_config/get_node_config, offering a clear alternative for reading output. No exclusions are missing.

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

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

No annotations provided, so description carries full burden. It only states the basic action, missing details like idempotency, behavior for already-running nodes, or whether it returns a result.

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?

Single sentence is concise, but underspecified for a tool with one parameter and lacking behavioral context. It is front-loaded, but could add essential details without being verbose.

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 the simplicity (1 param, output schema present), the description is incomplete: no parameter explanation, no output description, no usage context. Fails to provide sufficient information for correct invocation.

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%, yet the description does not explain the 'lab_path' parameter at all. No hint on format or meaning, leaving the agent to guess.

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?

Description clearly states the action (start) and resource (all nodes in a lab). Distinguishes from sibling 'start_node' which starts a single node, and 'stop_all' is the inverse operation.

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?

No guidance on when to use this tool versus alternatives like 'start_node'. No prerequisites or conditions mentioned. Implied usage is vague.

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

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

No annotations are provided, and the description does not disclose behavioral traits (e.g., whether the tool blocks until the node is ready, if it triggers an asynchronous operation, or what state changes occur). The one-word verb 'start' implies mutation but lacks detail.

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 concise sentence with no fluff. However, it is too minimal to be helpful, sacrificing completeness for brevity.

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 the complexity (many sibling tools, no parameter descriptions, and an existing output schema not referenced), the description is incomplete. It does not explain return values, prerequisites, or the tool's role in the broader workflow.

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?

The input schema has 0% description coverage, and the description adds no meaning to the parameters 'lab_path' or 'node_id'. The agent receives no hints about their format, purpose, or constraints.

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 the action ('start') and resource ('a single node in a lab'). However, it does not distinguish from sibling tools like 'start_all' or provide context on what 'start' entails (e.g., power on vs. initialize).

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?

No guidance on when to use this tool versus alternatives (e.g., 'start_all' for batch operations). No prerequisites or conditions for use are mentioned.

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

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

No annotations are provided, so the description must carry the full burden. It only states the basic effect without disclosing behavioral traits such as whether the lab remains running, permission requirements, reversibility, or impact on connected nodes. Critical context for safe usage is missing.

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 very concise at one sentence. While it does not waste words, it is too brief to convey necessary details. For a simple tool, minimalism is acceptable but here it omits important context, making it less effective.

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 the tool's complexity (one parameter, multiple siblings, output schema present), the description is incomplete. It does not explain the return value (output schema), how the lab path is resolved, or differentiate from similar tools. Significant gaps remain.

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?

The input schema has a single parameter 'lab_path' with no description. The description does not elaborate on this parameter's format, purpose, or constraints. With 0% schema coverage, the description should compensate but fails to add any value beyond the schema.

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 'Stop all nodes in a lab' clearly states the action and resource. However, it does not differentiate from siblings like 'stop_lab' (which may stop the entire lab) or 'stop_node' (specific node). The verb and resource are specific, but lack distinguishing context.

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?

No guidance is provided on when to use this tool versus alternatives. For instance, it does not clarify when to use 'stop_all' instead of 'stop_lab' or 'stop_node', nor does it mention prerequisites or side effects like lab state after stopping all nodes.

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

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

Discloses destructive behavior (stops nodes, destroys pods) and cross-user capability. No annotations exist, so description covers key behavioral traits. Lacks details on permissions, reversibility, or output structure.

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?

Two sentences, front-loaded with action and effect. No wasted words; efficient and clear.

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?

Covers purpose, usage context, and prerequisite discovery. For a single-parameter tool with output schema, it provides sufficient context for correct invocation, though could mention output format or async behavior.

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 0% means description must explain lab_path, but it only mentions finding running labs via list_running_labs. Does not explicitly define lab_path as the identifier for the lab to stop, leaving ambiguity.

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 the tool stops a running lab across all sessions/pods, distinguishing it from siblings like stop_node or stop_all. It specifies the action and scope.

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?

Provides explicit use case: clearing 'error_lab_running' before deleting a lab. References list_running_labs for discovery. Does not explicitly contrast with stop_all or stop_node, but context implies lab-level scope.

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

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

No annotations are provided, and the description does not disclose behavioral traits such as whether stopping a node is safe, reversible, or affects other lab components. The simple verb 'stop' leaves uncertainty.

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 very short (one sentence) with no wasted words. However, it could be improved by adding brief parameter context without becoming lengthy.

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 stop action, the description is acceptably complete given the presence of an output schema. However, it lacks details on node status prerequisites or the effect of stopping, which would improve completeness.

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%, and the description does not explain the 'lab_path' or 'node_id' parameters beyond implicit context. The schema provides only titles, so the description adds minimal value.

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 the action ('stop') and resource ('single node in a lab'), distinguishing it from siblings like 'stop_all' and 'stop_lab'.

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?

No guidance on when to use this tool versus alternatives such as 'stop_all' or 'stop_lab', nor any prerequisites or context about node state.

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

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

No annotations are provided, so the description carries the full burden. It mentions the zip is produced by download_lab, implying a specific format, and states the folder must exist. However, it does not disclose what happens on invalid zip, overwrite behavior, or if the lab can be imported into non-empty folders.

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 two sentences, no wasted words. The first sentence states the primary action and source, and the second explains parameters and prerequisite. It is front-loaded and efficient.

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 the tool has 2 parameters, an output schema (presumably covering return values), and no nested objects, the description covers the essential purpose, inputs, and a key prerequisite. It does not mention error cases or overwrite behavior, but these are not critical for basic usage.

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%, but the description explains both parameters: zip_file_path as the local path to the .zip and folder as the destination with default '/'. It adds the constraint that the folder must already exist, which is not in the schema.

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 the tool imports a lab from a .zip file produced by download_lab into a workspace folder. It distinguishes itself from siblings like create_lab (creates from scratch) and download_lab (exports). The verb 'import' and resource 'lab' are specific.

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 specifies when to use the tool (importing a previously downloaded lab) and notes a prerequisite (folder must already exist). It implies an alternative by referencing download_lab, but does not explicitly state when not to use it or list other alternatives.

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

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

No annotations provided, so description carries full burden. It discloses main behavioral traits: destructive wipe, reboot from startup config, and an additional side effect of freeing a stuck console line. Lacks detail on permissions or error scenarios but is sufficiently transparent for most cases.

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, each adding value. Front-loaded with main action, followed by use cases and an extra side effect. No fluff.

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 2 parameters and existence of output schema, the description covers purpose, usage, and an important side effect. No need to explain return values due to output schema.

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 description does not elaborate on parameters beyond their names. However, 'lab_path' and 'node_id' are self-explanatory from context. Description would benefit from clarifying expected formats or constraints.

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 the tool wipes a node by clearing NVRAM/runtime state, causing a reboot from startup-config. It distinguishes from siblings like delete_node or push_config by specifying 'factory-reset' and 'reload config'.

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 gives two use cases: factory-reset a device and force a pushed config to reload, plus frees a stuck console line. However, it does not mention when NOT to use it, such as when needing to preserve runtime state.

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