pnetlab-mcp-server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation5/5
Each tool targets a distinct resource and action. While console tools (run_command, console_send/read, console_close, node_console) share a domain, their purposes are clearly differentiated: high-level command execution, low-level interactive sessions, session management, and connection info retrieval. Similarly, list_images vs get_template are explained with usage guidance.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using lowercase with underscores (e.g., list_templates, open_lab, set_link_state, push_config). The one noun-like name 'node_console' still fits as a getter (get console info) and does not break the overall pattern.
Tool Count4/5
24 tools is on the higher end but appropriate for the complexity of a network emulation server. The count covers lab lifecycle, node lifecycle, link management, console interaction, and template/image introspection. It is slightly heavy but each tool justifies its existence.
Completeness4/5
The surface covers most workflow needs: open/close/get lab, add/update/delete/start/stop nodes, connect/delete links, link fault injection, console command execution, and config push. Minor gaps include no explicit lab listing/creation/deletion and no standalone network management, but these are workable through existing tools (open_lab creates labs, connect_nodes creates networks).
Average 4.5/5 across 24 of 24 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral burden. It adds context about idle detection and timeout limits, which goes beyond the schema. However, it does not disclose authentication requirements (username/password parameters), the meaning of 'idle', or whether output is consumed non-destructively. This is a partial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a useful pairing note. Every sentence contributes value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and an output schema, but the description is brief. It covers the core behavior but omits authentication context, error handling, and a clear definition of 'idle'. Given the output schema exists, return values are not fully explained though partially inferred. The description is minimally sufficient but lacks completeness for a production tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explicitly explains 'timeout' (in seconds) via backticks, but does not explain node_id, username, or password. Node_id is self-explanatory, but the auth parameters are not addressed, leaving a significant gap given low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read pending output from a node's console until it goes idle') with a specific resource (node's console). It is distinguishable from siblings like console_send (sends) and console_close (closes). The pairing instruction further reinforces its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by advising to pair with console_send for interactive sessions. However, it does not explicitly state when to avoid this tool or mention alternative tools for non-interactive output retrieval, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal an important constraint (must stop the node first), implying that deleting a running node is invalid. However, it does not explain whether deletion is permanent, whether it affects connected links, or what error behaviors might occur, which is notable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and gives a parenthetical prerequisite. Every word earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, clear action), the description gives the essential operation and prerequisite. However, it lacks details on side effects such as whether the node's configuration is deleted, what happens to connected links, or what the output schema indicates. A bit more context would make it more robust, but it remains minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes node_id only as an integer with no description (0% coverage), and the description does not elaborate on it beyond referencing 'a node'. The parameter name is self-explanatory to a degree, but the description fails to compensate for the schema gap by not specifying how to obtain node_id or its role within the lab context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a node') within the context of the open lab. This effectively differentiates it from sibling tools like delete_link, stop_node, or add_node, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(stop it first)' provides an explicit prerequisite, telling the agent when it is safe to use the tool. While it does not name alternatives or explicitly state when not to use this tool, the guideline is actionable and directly relevant to successful invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the key behavioral trait that omitting node_id stops every node in the lab, which is a significant side effect. However, it lacks any mention of whether the operation is reversible, requires special permissions, or how it handles running processes, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and the critical conditional behavior. Every word contributes, with no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description is reasonably complete. It covers both invocation modes (single node vs all nodes) and the output schema handles return details. It does not delve into side effects or prerequisites, but the simplicity of the operation makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for node_id, and coverage is 0%. The description adds meaning by explaining that omitting node_id triggers a lab-wide stop, which goes beyond the schema's bare type definition. Still, it does not elaborate on what value node_id should take (e.g., a node's integer ID) beyond the schema's type, so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('one node, or every node in the lab if node_id is omitted'). It effectively distinguishes this from sibling tools like start_node, delete_node, and update_node by explicitly naming the stop operation and its variable scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by explaining how to target a single node (provide node_id) versus all nodes (omit node_id). However, it does not explicitly compare against alternatives or mention when to use stop_node instead of delete_node or start_node, so the guidance remains implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. The verb 'List' implies a read-only operation, and the examples provide useful context about the kind of data returned. However, it does not explicitly state that it has no side effects, requires no special permissions, or is safe to call repeatedly. This is a minor gap, but acceptable for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose with illustrative examples. There is no filler or redundancy, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless listing tool with an output schema, the description is sufficiently complete. It conveys what the tool does and hints at the content of the output. The presence of an output schema covers return value details, so no further description is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects this (100% coverage). The description adds value by enumerating example network types, which helps the agent anticipate the kind of values that may appear in the output, though it does not clarify any parameter syntax since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a clear resource 'available network types', with concrete examples (bridge, pnet0..pnet9, ovs, ...). This clearly distinguishes it from sibling tools like list_templates or list_images, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The examples imply it is used to discover network types for configuration, but there is no direct 'use when' statement or mention of exclusions. Guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses important side effects: it releases the session binding and leaves the viewer account, stopping browser tracking. However, it does not clarify whether the lab itself is terminated or just detached, which limits 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The main action is front-loaded, and the second sentence adds a relevant 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description adequately covers the main behavior and a key side effect. It could mention the fate of the lab resources, but the low complexity and presence of an output schema make this description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers parameter expectations. The description adds value by clarifying that the session acted upon is the 'current' one, which is implicit state rather than a parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Leave') with a resource ('current lab session') and adds a clarifying parenthetical ('releases the session binding'). It also mentions leaving the viewer account, which distinguishes it from sibling tools like open_lab and join_viewer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when ending a lab session, but it does not explicitly state when to use it vs alternatives or when not to use it. No sibling tool is mentioned as an alternative, so guidance is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 adds value by explaining the meaning of status codes (0,1,2) and implies a read-only operation via 'Get'. It does not explicitly state side-effects or permissions, but for a read-only status endpoint this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb, resource, and key status-code meanings. It is concise with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool with an output schema, the description covers the essential semantics. It does not explicitly state whether 'per-node' means all nodes or a specific node, but the absence of parameters implies all nodes. This is a minor gap, not a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids inventing parameter details, and the empty input schema is fully documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and resource ('per-node running status'), with explicit numeric codes. It is distinguishable from sibling tools like start_node/stop_node which perform actions, and get_lab which likely returns broader lab information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this when you need node running status. However, it does not explicitly mention alternatives or when not to use it, leaving some ambiguity relative to get_lab which might also provide node status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a key behavior (closing all sessions when node_id is None), but does not mention side effects, idempotency, or error behavior. For a simple close tool, the critical behavior is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The action and conditional behavior are front-loaded, and the usage tip is concise. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the purpose, the special None case, and when to use it. Since an output schema exists, return values need not be explained. It omits prerequisites or irreversibility, but these are less critical for a close operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description fully explains the single parameter: node_id identifies the node, and None means all sessions. This directly compensates for the schema gap, adding meaningful semantics beyond the raw type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Close') and resource ('a node's console session'), and clearly distinguishes the all-sessions case when node_id is None. This differentiates it from sibling tools like console_send and console_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance with 'Good practice once you are done configuring a node.' It does not explicitly mention when not to use or name alternatives, but the timing is unambiguous and no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the output structure and the meaning of the 'installed' flag, including the .missing suffix behavior when an image is missing. This provides valuable context beyond what is expected from a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and effectively structured: the first sentence states the action, and the second explains the return structure. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple listing tool with no parameters and an output schema. The description fully covers what the tool returns and the special case of missing images, making it complete for an agent to invoke without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the baseline for parameter semantics is 4. The description adds no parameter-specific information, but none is needed; it instead explains the output structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List installed node templates') and the resource ('node templates'), and further specifies the structured entry format. It distinguishes from siblings like list_network_types and get_template by focusing on installed node templates, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting the template id is 'usable in add_node', hinting that this tool is for discovering template ids. However, it does not explicitly state when to use this tool versus alternatives like get_template or list_images, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: 'auto-opens + logs in on first use', and explains the 'newline' parameter's effect (partial line). This is helpful, but it omits other important traits like whether the action is destructive or requires a running node, so it gets a 4 rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence adds value: what it does, when to use it, and how a key parameter behaves. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema that likely describes return values, the description is reasonably complete. It covers the tool's purpose, usage context, a parameter nuance, and a follow-up tool. However, it doesn't mention prerequisites like the node being started, which would be useful for completeness in a lab environment with siblings like 'start_node' and 'stop_node'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explicitly explains 'text' (raw text), 'newline' (partial line behavior), and 'node_id' (node's console). However, 'username' and 'password' are only hinted at via 'logs in' without being explicitly tied to the parameters, leaving some ambiguity. This partial coverage warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send raw text to a node's console' with a specific verb and resource. It also distinguishes itself from the sibling 'run_command' by labeling itself as 'lower-level', making its unique role explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'use it for multi-step interactive sessions where you need to drive the prompt yourself'. It also contrasts with 'run_command' and recommends 'console_read' for reading responses, offering clear alternatives and follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It conveys that this is a read-only operation returning editable options, not modifying anything, and indicates the scope of data returned. This is sufficient behavioral context for a get-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and content, then a concise usage note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers purpose, content, and usage context. It lacks explicit prerequisites (e.g., template must be a valid template from list_templates), but this is partially implied by the sibling tool, so it is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'template' string with no description (0% coverage). The description uses 'a template' to indicate the parameter identifies the target template, but does not specify the expected format or how to obtain valid template names, leaving the agent to infer from sibling tools like list_templates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get a template's full editable options') and enumerates the content (available images, qemu versions, default field values). It also distinguishes from sibling tool list_images, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when you need more than list_images' and provides a concrete example (qemu_arch/qemu_nic/qemu_options), offering clear guidance on when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains the template_defaults mechanism, what fields are auto-applied, how explicit overrides work, the console and icon fallback behavior, and the fact that the node is added stopped. This is comprehensive and gives the agent safe expectations for a mutating create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every paragraph adds necessary behavioral detail. It is front-loaded with the core action, then explains defaults and fallbacks in a logical order. No sentences are wasted; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high parameter count (22), no annotations, and an output schema to handle return values, the description covers the essential behavioral aspects: creation, defaults, overrides, console/icon fallbacks, and initial state. It omits a few minor positional and network parameters, but overall it gives an agent enough to invoke the tool correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 key parameters type, template, template_defaults, console, icon, and the set of fields included in template defaults (image, ram, cpu, qemu_*, config_script). It doesn't cover all 22 parameters (e.g., top, left, delay, serial, ethernet, firstmac, pci_mode), but the most ambiguous and impactful ones are addressed, leaving minor positional and hardware details to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add a node to the open lab.' It clearly distinguishes this from sibling tools like update_node, delete_node, and start_node by stating the create action and the node scope. The reference to list_templates for type/template further clarifies its role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use context: it tells the agent to obtain type/template from list_templates, explains that template_defaults=True usually avoids needing list_images, and notes that the node is added stopped so start_node is needed to boot it. It doesn't explicitly contrast with update_node or delete_node, but the guidance is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses what the tool returns (network_id and endpoints) and how to use the result, adding behavioral context. It does not mention potential side effects or error conditions, but for a creation tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with the primary action first, then parameter semantics, and return usage. Every sentence contributes value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the description already explains the return value and follow-up tools, the description is complete for a link-creation tool. It also references get_lab for node IDs and lists relevant sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining src_id/dest_id as node ids from get_lab and src_if/dest_if as 0-based ethernet indices with examples. The optional 'name' parameter is not described, but it has a default in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Connect two node interfaces with a point-to-point link' – a specific verb and resource. It distinguishes itself from sibling tools like delete_link and set_link_state by focusing on creating a link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: node ids are from get_lab, interface indices are 0-based, and the returned network_id can be used with set_link_state/set_link_quality/delete_link. It does not explicitly say when not to use it, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It discloses the check=True polling behavior and diagnostic reporting for crashes, adding value beyond a generic 'start' description. It could mention prerequisites (e.g., lab must be open), but the provided detail is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary action is front-loaded, and the second sentence adds necessary detail about the optional check behavior. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the two optional parameters and existence of an output schema, the description covers the main behaviors and constraints. It misses potential error scenarios or prerequisites, but the tool's core functionality is well documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains both parameters: node_id's omission starts all nodes, and check=True enables polling for single-node starts. This compensates completely for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function with a specific verb ('Start') and resource ('node' or 'every node in the lab'), and it differentiates behavior based on node_id. This distinguishes it from siblings like stop_node and get_node_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (starting one or all nodes) and specifies that check=True applies only to single nodes. It implies usage without explicitly naming alternatives, but the lab context makes the use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It discloses that both attached interfaces are unlinked and warns about hot-unplugging if the node is running. It does not mention reversibility or whether the network object is permanently destroyed, but for a delete operation this is adequate context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: the action, the key side effect, and the critical prerequisite. No filler or repetition, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only one parameter and an output schema, the description covers the essential context: what it does, where the ID comes from, the precondition (node stopped), and the consequence of ignoring it. The warning about hot-unplugging is particularly valuable for safe operation. Nothing important is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'network_id' as an integer with no description. The description adds critical semantics by explaining it is the network_id returned by connect_nodes or readable from get_lab, making it clear where to obtain a valid value. This goes beyond the schema and fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a link' with a specific resource type ('p2p network') and layer ('topology layer'), clearly distinguishing it from sibling tools like delete_node (deletes a node) and connect_nodes (creates a link). The verb 'Delete' is precise and the object is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use: the network_id comes from connect_nodes or get_lab, and the node must be stopped before deletion. It does not explicitly mention when not to use this tool or name an alternative for deleting a node, but the prerequisite and side-effect warning give solid usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the effect of compact=True (removing cosmetic noise, thinning node data) and warns about large payloads (80-100KB). It does not explicitly state read-only semantics, but 'get' implies safe read behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose statement followed by a focused explanation of the compact mode. Every sentence earns its place with no redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and an output schema (not shown). The description fully covers the parameter's behavior and note about payload size, making it complete for selection and invocation without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains the sole parameter, compact, detailing exactly what is removed and the output structure. This adds substantial meaning beyond the bare boolean schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves the open lab's info, full topology, and node status. It clearly distinguishes itself from siblings like get_node_status by focusing on the entire lab view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Use this to see what's running and how nodes are wired.' It does not explicitly mention alternatives or when not to use it, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses key behaviors: up=True restores, up=False suspends, the device sees the port go down like a cable pull, and current state can be checked via get_lab's suspend field. This provides meaningful context beyond the bare schema, though it does not detail persistence behaviors or effects on stopped nodes beyond the 'only running nodes' note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Every sentence adds value: the up=True/False semantics, the contrast with CLI interface actions, the running-node caveat, and the get_lab state-check tip. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which reduces the need to describe return values), the description fully covers the tool's context: what it does, how to execute it (param semantics), what to expect (port down / cable pull), and how to verify the result via get_lab. For a two-parameter tool, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only parameter names and types, with no descriptions. The description compensates fully by explaining the meaning of 'up' (True restores, False suspends) and the source of network_id (from connect_nodes / get_lab). This transforms the parameters from opaque flags into actionable instructions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Bring a link up or down at the topology layer (physical-style fault injection).' It specifies the action (up/down), the resource (link), and the domain (topology layer), and distinguishes it from interface-level CLI operations, which establishes its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use this tool (fault injection at topology layer) and where to get the required network_id ('Use the network_id from connect_nodes / get_lab'). It also contrasts with a non-sibling alternative (device CLI interface disable) and notes the limitation 'Only affects running nodes.' However, it does not explicitly mention sibling tools like set_link_quality as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses important behaviors: partial fields update, and that Image/ram/qemu_* changes apply on restart rather than live. It also references add_node for field semantics. Missing details like authentication requirements or error handling, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loaded with the core action. Each sentence adds value: action, use cases, and timing. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 20 parameters and no annotations, the description provides sufficient context for correct use: partial updates, use cases, timing, and a reference to add_node for field details. It does not detail return values, but an output schema is present (per context signals), so that's not necessary. The only gap is lack of explicit error scenarios or prerequisites, but overall it is complete enough for an agent to use safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 does so by stating 'Accepts the same field names as add_node,' linking to a sibling tool's schema for meaning. The partial-update sentence clarifies optionality, and the schema's default null values reinforce that. This reference adds value beyond the bare schema, though it doesn't exhaustively document each field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Edit an existing node's fields' and specifies the key behavior of partial updates ('Only the fields you pass are changed'). It distinguishes this from adding or deleting nodes, making the purpose 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'fix a node that crashes on boot' and 'tweak ram/qemu_nic without deleting and recreating,' which also suggests the alternative of delete+create. The timing note ('take effect on the next restart, not on a running node') helps when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is a (re)join and a binding refresh, implying idempotence and a session-state change. It also explains the functional benefit. It doesn't detail side effects or auth, but for this simple operation the transparency is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the action, then give trigger conditions, then the user value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with no params and an output schema available. The description covers what it does, when to call it, and what benefit it provides, leaving no critical gaps for an agent to decide or invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description clarifies why: it uses the 'configured viewer account' and the agent's 'current lab session'. This adds context beyond the empty schema, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'join' with a clear resource ('configured viewer account') and target ('current lab session'). It also explains the outcome ('watch the live topology'), making it distinct from sibling tools that manage nodes, links, or consoles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'if you logged into the browser as the viewer before the agent opened the lab, or to refresh the viewer's binding.' This provides clear trigger conditions, and while no alternatives are mentioned, no sibling tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains what the tool returns (host:port) and clarifies a key limitation: it does not handle the telnet handshake or login. This sets accurate expectations, though it does not mention side effects or permissions, which are likely minimal for a read-only info retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two well-structured sentences. The first states the purpose, and the second provides alternative tools with a specific reason. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description fully covers its purpose, output (connection info), and relationship to related tools. An output schema exists to document the return structure, so the description need not repeat those details. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (node_id) and the schema description coverage is 0%. The description implies the parameter identifies the node ('a node's console connection info'), which is straightforward given the tool name and context, but it does not explicitly elaborate on the meaning or format of node_id. The single parameter and clear naming compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a node's console connection info (telnet/SSH host:port), using a specific verb and resource. It also explicitly distinguishes from siblings by noting that actual command execution should use run_command / console_send + console_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool: to get connection info for CLI interaction. It names alternatives (run_command, console_send, console_read) and states they handle the telnet handshake and login, making the division of responsibility clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool creates/reuses a sandbox, binds it to the session, and optionally auto-joins a viewer. This is useful context, though it does not mention potential side effects like resetting an existing session or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, each serving a distinct purpose. The first states the core behavior and prerequisite; the second adds a conditional environment-specific behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description adequately covers the action, prerequisite, and optional viewer behavior. It gives the agent enough to invoke the tool correctly without needing external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by explaining the `path` parameter: it's the lab file name with NO leading slash, and provides a concrete example ('2pc_1sw.unl'). This is far more informative than the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open a lab for editing/running' with a specific resource ('lab'), and distinguishes this from sibling tools like get_lab or close_lab by explaining it creates/reuses a sandbox and binds it to the session. The example path further anchors the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Must be called before add_node / start_node / get_lab / etc.', providing clear sequential guidance. It also gives context about auto-joining a viewer account when PNETLAB_VIEWER_USERNAME is configured, which tells the agent when an additional behavior occurs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it delivers: discloses bidirectional application, running-node-only scope, and clearing semantics via 0. These are non-obvious behavioral traits that an agent must know to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with purpose, and every sentence earns its place. It packs essential behaviors and parameter semantics into four sentences with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations, the description covers purpose, parameter semantics, scope, side effects, and clearing behavior. An output schema exists, so return-value details are not required. The tool is fully understandable for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain each parameter. It provides units for every dimension (percent, ms, kbit/s) and explains the 'pass only what you want' semantics plus the clear-by-0 behavior. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource: 'Inject impairment on a link', immediately distinguishing it from sibling tools like set_link_state. It enumerates exactly which impairments it sets (packet loss, delay, jitter, bandwidth), making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear usage context is provided: pass only dimensions you want to set, impairments apply to both directions, and only affect running nodes. It does not explicitly name alternative tools or when-not-to-use, but the guidance is enough for an agent to know how to apply it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses a critical behavioral detail: omitting a valid image causes immediate crash. It also transparently notes that behavior varies for non-QEMU types, which is valuable context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, followed by essential usage guidance and a clarification for other backends. Every sentence adds value and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and an output schema, the description fully covers the necessary context: what it lists, why you need it, and how behavior changes across backends. It is complete without needing to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter 'template' is minimally described. The description compensates with a concrete example and clarifies that template refers to a template identifier. While not exhaustive, it gives sufficient semantic meaning for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('disk images available for a template'), and provides a concrete example (mikrotik-7.23.2). It also distinguishes itself from sibling tools like list_templates by focusing on images and by linking to add_node usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before add_node to get a valid image string, and explains the consequence of not doing so (node crashes). It also clarifies behavior for non-QEMU backends, giving clear context on when and why to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the full operational behavior: opens telnet console, handles IAC handshake, logs in with default credentials, pools sessions across calls, reads until idle or wait_for regex, and requires console_close. It also exposes the '?' limitation. This goes well beyond any annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries information: behavior, credentials, examples, lifecycle, and a gotcha. It is front-loaded with the core purpose and structured with examples and an explicit 'Gotcha' section. It earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, a complex telnet lifecycle, and an output schema, the description covers purpose, usage, behavior, parameter semantics, and edge cases. The existence of an output schema covers return values, so the description doesn't need to restate them. The only minor omission is error handling, but it's not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% property descriptions, so the description is the only source of parameter meaning. It explains command via examples, wait_for via 'or wait_for regex matches', and credentials via 'default admin/empty password -- pass credentials for devices that differ.' However, the timeout parameter is not explicitly described, though its default value is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Run a single CLI command on a running node and return its output.' It gives platform-specific examples (MikroTik, IOS, VPCS) that distinguish it from sibling tools like console_send or console_read, which handle raw console I/O.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides direct usage examples for different device types and explicitly states a gotcha: 'a single ? for help often does not trigger under telnet; use run_command with the full command instead.' It also instructs to 'call console_close when finished' and explains when to use wait_for for long-running monitors, constituting clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool stores config text, enables boot injection, requires a restart, does not inject into a running node, and additionally flips the PNETLab config flag. The mention of the configs/edit quirk is a valuable behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then each sentence adds essential details: storage, boot behavior, device formats, alternatives, and a known quirk. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no annotations and an output schema, the description is remarkably complete. It covers purpose, usage, formats, side effects, and alternatives. The presence of an output schema means return values need not be explained. Overall, it fully equips an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by elaborating on the 'config' parameter with format examples (VPCS 'ip 192.168.1.1 24', IOS/IOL running-config style). 'node_id' is not detailed but its purpose is implicit from 'to a node' and the schema name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Push a startup configuration to a node (applied on next boot).' It uses a specific verb ('push') and resource ('startup configuration to a node'), and distinguishes itself from run_command by noting the config is injected during boot, not into a running node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides device-specific usage guidance (VPCS commands, IOS/IOL running-config style) and names an alternative: 'For interactive CLIs (e.g. RouterOS) prefer run_command.' It also clarifies that the node must be restarted for the config to take effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pnetlab-mcp-server MCP server](https://glama.ai/mcp/servers/raybiko-lab/pnetlab-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/raybiko-lab/pnetlab-mcp-server)

Score Badge

Copy to your README.md:

[![pnetlab-mcp-server MCP server](https://glama.ai/mcp/servers/raybiko-lab/pnetlab-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/raybiko-lab/pnetlab-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/raybiko-lab/pnetlab-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server