mcp-eveng

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, with operations well-organized around labs, nodes, networks, and folders. A few tools like `edit_lab_node` and `edit_lab_nodes_by_template` have overlapping scope but are differentiated by bulk vs. single-node editing.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern (e.g., `add_lab_node`, `delete_lab_network`, `start_node`). Minor inconsistencies exist like `change_node_delay` vs. `edit_lab_node`, but overall the pattern is predictable and readable.
Tool Count4/5
With 36 tools, the surface is large but well-justified by the complexity of EVE-NG lab management (folders, labs, nodes, networks, wiring, lifecycle). Each tool covers a distinct operation, and the count feels appropriate for the domain.
Completeness5/5
The tool set covers the full lifecycle for EVE-NG: CRUD for folders, labs, nodes, and networks; node wiring; power operations; export; and status. No obvious gaps for common lab management tasks, including advanced features like bulk editing and sharing.
Average 4/5 across 35 of 36 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention that moving a file could be destructive (e.g., overwriting an existing lab at the destination), requires write permissions, or any side effects like path resolution errors. The Args section is present but does not address behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but is slightly padded by the Args format that could be condensed. It is front-loaded with a clear one-line summary then repeats data the schema already indicates (parameter names and required status).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has output schema (not shown here), the description still needs to cover completion behavior (e.g., returns success message, or raises errors for missing paths). It lacks explanation of what happens on success/failure, prerequisites, or side effects on the source file. The sibling tools indicate a rich ecosystem, yet no differentiation is provided.
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?
Schema description coverage is 0%, so the description must explain parameters. The Args section adds minimal context ('Full path to the .unl lab file' and 'Destination folder path'), which provides a bit more meaning than the schema's bare titles, but does not specify allowed formats, whether both paths must exist, or how middle folders are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 to a different folder' with a specific verb (move) and resource (lab). It distinguishes itself from sibling tools like move_folder by targeting labs (.unl files) vs. folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives (e.g., move_folder, copy operations), or what conditions must be met (e.g., lab not running, write permissions). The context for when not to use it is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the tool lists or retrieves pictures, but does not disclose side effects, read-only nature, or any behavioral traits like what happens with missing lab_path or invalid id.
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?
Description is concise with two short sentences and parameter docs in docstring style. It is front-loaded and avoids fluff, though the Args section could be more integrated.
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?
Output schema exists so return values need not be detailed, but the tool is simple (list or get a picture). The description covers the core functionality but lacks behavioral detail for error cases or examples, making it adequate but not 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?
Schema description coverage is 0%, so description must compensate. It adds meaningful context: lab_path is a full path to a .unl file, and picture_id is optional to list all or get one. However, it does not explain formats, constraints, or behavior when ids don't exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists background pictures/annotations in a lab, with the option to get one by id. This is a specific verb+resource combination, distinguishing it from siblings that focus on nodes, networks, or labs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameters but does not guide on when to use this tool vs alternatives like get_lab_topology or list_lab_nodes. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so full burden on description. States creation but omits behavioral details: is it idempotent? Does it overwrite? What errors occur if path is invalid? No side effects mentioned. Only minimal context beyond parameter list.
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 a single sentence plus a clean 'Args:' list. Every line is informative and well-structured. No redundant or filler content. Could be slightly more compact if combined, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing context about what 'empty' means in a lab (no nodes/links?), what the return value is (output schema exists but description doesn't clarify), and any prerequisites for the path. Siblings offer related creation tools (add_lab_node, add_lab_network) but no comparative context provided.
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?
Schema description coverage is 0%, so description must add value. It provides a path example ('/User1') and notes automatic '.unl' extension for name. Other parameters (version, author, etc.) are only lightly elaborated (e.g., 'free-form version string'). Adds some meaning but not fully compensating for missing schema 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?
Clearly states 'Create a new (empty) lab.' Uses a specific verb and identifies the resource. Differentiates from siblings like get_lab, edit_lab, delete_lab by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 (e.g., add_folder for folders). Lacks prerequisites such as whether the target path must exist or what happens if a lab with the same name exists. No mention of when not to use it.
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?
No annotations are provided, so the description carries full burden. It correctly states that omitting network_id lists all networks, and providing a specific id returns one network. No contradictions found. However, it does not disclose side effects (none expected for a read operation), or behavior on invalid lab paths.
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 two sentences plus an Args block. No wasted words. The main purpose is front-loaded in the first sentence. The Args block is clear and separates parameter descriptions from the main purpose.
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 there is an output schema, the description does not need to explain return format. The tool is a simple list/lookup with only 2 parameters. The description covers the dual behavior (list vs single lookup) adequately. Minor gap: no mention of what happens if lab_path is invalid.
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?
Schema description coverage is 0%, so the description must compensate. It describes lab_path as 'Full path to the .unl lab file' and network_id as 'Specific network id, or omit to list all'. This adds meaningful prose beyond the raw schema properties, but could be more precise (e.g., file extension requirement, format constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 the resource 'all networks in a lab, or get a single network by id'. It distinguishes itself from siblings like list_lab_nodes, list_lab_links, and list_lab_pictures by specifying 'networks' as the target resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like add_lab_network or delete_lab_network. It lacks context about prerequisites (e.g., lab must be open) or when to omit network_id vs provide it.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It properly indicates that the tool is destructive ('deleting saved config/VLANs') and can affect multiple nodes ('or all nodes'). However, it does not mention whether the operation is reversible, what happens to running nodes, or if there are side effects on the lab.
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 short (two sentences plus a simple 'Args' list) with no unnecessary text. The key purpose is front-loaded in the first sentence. The structured list of parameters is clear and easy to parse.
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 is destructive, has an output schema (suggesting a return value), and acts on a lab node. The description covers the core function and key parameter semantics, but lacks details on return values (the output schema is not described), error states, or preconditions (e.g., node state). Given the complexity of a destructive lab operation, it is adequate but not fully 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 coverage is 0% (no parameter descriptions in input schema), but the description provides a basic explanation for each parameter in the 'Args' section. It explains 'lab_path' as the path to the .unl file and 'node_id' as the node to wipe with the note that omitting it wipes all nodes. This adds value beyond the bare schema and defaults, achieving baseline functionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wipe one node (or all nodes)') and the purpose ('deleting saved config/VLANs so it rebuilds from image'). The verb 'wipe' combined with the resource 'node' is specific and distinguishes it from sibling tools like delete_lab_node or edit_lab_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. For example, it does not explain how 'wipe' differs from 'delete' (delete_lab_node) or when you would want to wipe rather than just restart. There is no guidance on prerequisites, such as ensuring the node is stopped before wiping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 does not disclose whether creation is allowed if the folder already exists, what happens to existing content with the same name, or any authorization requirements. The description is minimal beyond the schema details.
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 extremely concise with two sentences and a parameter list. No extraneous information. Every sentence adds value.
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 2 required params, no enums, and an output schema exists. The description is minimal but covers the basic purpose. However, given the presence of an output schema, it does not need to explain return values. More context about error cases or required permissions would improve completeness.
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?
Schema description coverage is 0%, so the description must compensate. It does explain path is 'Parent folder path, e.g. "/User1"' and name is 'Name of the new folder'. While helpful, it lacks format constraints (allowed characters, size limits). Baseline is 3 due to low coverage, but it provides some meaning beyond 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 the verb 'Create' and the resource 'new folder inside an existing EVENG folder'. It distinguishes from siblings like list_folder, move_folder, and delete_folder, which have different verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it doesn't mention prerequisites like whether the parent folder must exist or cases where create_lab might be a better choice for lab creation.
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?
No annotations are provided, so the description carries the full burden. It is a read operation (list), which is implied but not explicitly stated as read-only. It mentions the path parameter structure and default, but no behavioral details like pagination, recursion depth, or permissions needed. For a simple read tool, the default behavior hints at root listing, which is adequate but not rich.
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 short and front-loaded: the first sentence states the purpose. The Args section is a typical format. Every part adds value. Minor point: could be slightly more streamlined by removing redundant 'Args:' header if not needed, but overall concise.
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 output schema exists (not shown but noted), return values are covered elsewhere. The tool is simple with one parameter, but lacks any guidance on whether folders are recursively listed or only direct contents, and no mention of error cases (e.g., invalid path). The description is adequate for basic use but incomplete for robust agent operation.
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% with only one parameter (path). The description adds the key meaning: path is an EVENG folder path like '/' or '/User1/Folder 1', with a default of '/'. This provides critical context beyond the bare schema definition, especially since the default is documented. It is sufficient given the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists folders and labs contained in an EVENG folder, with a specific verb ('List') and resource. It distinguishes from siblings like list_labs (which lists labs from a broader context) and add_folder, delete_folder (which are mutating). However, it doesn't explicitly differentiate from list_labs beyond the folders vs. labs scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 vs. alternatives like list_labs or get_lab. The description and sibling list don't clarify that list_folder specifically scopes to the contents of a folder path, while list_labs may list labs across all folders. No when-not-to-use or context provided.
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 bears full responsibility for behavioral disclosure. The description correctly notes that only supplied fields are changed, implying partial update/patch-like behavior. However, it does not disclose whether the lab must be open/stopped, permissions required, or whether changes are reversible. For a mutation tool, this is adequate but not exhaustive.
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 structured with a clear one-sentence summary followed by an Args list. Every sentence provides value. It is not overly verbose and front-loads the purpose. Slightly redundant with the parameter list since schema already has parameter names, but the 'if changing' context adds clarity.
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 6 parameters with 0% schema coverage and no annotations, but an output schema exists. The description explains all parameters' semantics sufficiently for basic use. It does not discuss return values (which the output schema presumably covers), side effects, or prerequisites. Considering the tool complexity (editing metadata), completeness is adequate but not thorough.
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?
Schema description coverage is 0%, so the description must compensate. The description lists each parameter (lab_path, name, version, author, description, body) with brief 'if changing' semantics. It adds context beyond the schema by clarifying that optional parameters are only updated if supplied. However, it does not explain format constraints or expected values (e.g., valid version strings). Baseline 3 is appropriate given the listing but lack of depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit an existing lab's metadata' using a specific verb+resource. It adds 'only supplied fields are changed' which clarifies partial update semantics. It differentiates from siblings like create_lab or delete_lab.
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 does not explicitly state when to use this tool versus alternatives like create_lab for new labs or share_lab for permissions. However, 'Edit an existing lab's metadata' implies it is for modifying existing labs, and the sibling context provides differentiation. No exclusions or prerequisites are mentioned.
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 carry the full burden of behavioral disclosure. It correctly indicates the tool saves config (a write operation), and mentions both single-node and all-node behaviors. However, it does not state whether the operation overwrites existing saved config, requires the lab to be closed or locked, or any error conditions (e.g., invalid node_id).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear heading sentence followed by structured parameter docs. Every sentence provides necessary information. The only small inefficiency is the parenthetical '(or all nodes)' which could be integrated more cleanly, but overall it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple export tool with two parameters and a sibling list that includes other node operations. It explains both fixed and optional export behaviors. However, it omits return value details despite the presence of an output schema, and does not mention prerequisites (e.g., lab must be open, nodes must be started). This leaves some gaps for an AI agent to make mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for properties, so the description provides the only semantics for parameters. It describes `lab_path` as the full path to the .unl file and `node_id` as an optional integer for targeting a specific node (or omit for all). This adds value over the bare schema types, but does not clarify path format, file restrictions, or node_id validation (e.g., must exist).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool exports a node's or all nodes' running config into the saved lab file. It specifies the target (running config) and destination (saved lab file) with a clear verb-resource pairing. The optional full-export behavior distinguishes it from node-specific operations, though it doesn't explicitly differentiate from other config management tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used for exporting running configs to a lab file, providing an optional per-node or all-nodes usage pattern. However, it gives no guidance on when to use this versus alternatives like `edit_lab_node` or `open_lab`, nor does it exclude inappropriate scenarios (e.g., while the lab is locked or nodes are in a non-running state).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes the stop action but does not disclose impacts such as whether stopping disrupts connections, requires specific permissions, or is reversible. This leaves significant gaps in understanding the tool's effect.
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 concise with two sentences and a parameter list. Every sentence adds value. Minor improvement: the parameter list could be presented more compactly.
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 context of 2 parameters, no annotations, and low schema description coverage, the description is adequate but not complete. An output schema exists but is not used—the description does not explain the return value. More details on behavior and constraints would improve completeness.
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?
Schema description coverage is 0%, so the description must add meaning beyond the schema. It explains that node_id can be omitted to stop all nodes, but it does not clarify the format of node_id (integer or null) beyond what the schema already says. The description partly compensates for low coverage but not fully.
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 stops one node or all nodes if `node_id` is omitted. The verb 'stop' and resource 'node' are specific, and the behavior is distinct from siblings like 'start_node' and 'wipe_node'.
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 explains the basic usage (omitting node_id stops all nodes) and mentions the required lab_path parameter. However, it does not explicitly state when to use this tool over alternatives like 'wipe_node', nor does it give conditions where stopping should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states the high-level purpose without disclosing behavioral traits like whether it is read-only, requires an open lab, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence for the purpose and two short parameter descriptions—with no wasted words. It is properly front-loaded with the core action.
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 an output schema, so the description does not need to explain return values. However, it lacks contextual information such as prerequisites, whether the lab must be open, and when it is appropriate to use this tool. Given the low complexity, the description is adequate but has noticeable gaps.
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%, but the description adds meaning by providing brief descriptions for both parameters (e.g., 'Full path to the .unl lab file' and 'Id of the node'). This compensates for the lack of schema descriptions, though it does not provide format constraints or examples.
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 'Get' and the resource 'a node's ethernet/serial interfaces and what they're wired to.' This is specific and distinguishes it from sibling tools like list_lab_nodes (which lists nodes) or get_lab_topology (broader topology).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_lab_links or get_lab_topology. It does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states the action and parameter meanings but omits critical details: whether the operation is synchronous, what happens if a node is already running, error handling, or required permissions. This lack of transparency forces the agent to infer or discover 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 extremely concise—three sentences total—and front-loads the core purpose in the first line. Every sentence earns its place, with no unnecessary words or repetition.
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 existence of an output schema (not shown), the description need not explain return values. However, it lacks context about side effects (e.g., state changes), prerequisites (lab must be open?), and error conditions. For a simple start operation with two parameters, it is minimally complete but could better cover operational semantics.
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 input schema has 0% parameter description coverage, so the description's 'Args' section is essential. It explains that lab_path is the full path to a .unl file and that node_id can be omitted to start all nodes. While minimal (no type constraints or valid values), it provides enough meaning for basic usage.
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 the specific verb 'Start' and clearly identifies the resource as 'one node, or every node in the lab if `node_id` is omitted.' This directly differentiates from sibling operations like stop_node, wipe_node, etc., 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as stop_node, wipe_node, or other node operations. It does not include explicit when/when-not conditions or mention prerequisites like lab_open or node existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose traits like read-only nature, error handling, or authentication needs. It only states the operation and parameter, omitting any behavioral context beyond a generic read.
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 extremely concise at two lines, front-loading the purpose and immediately clarifying the parameter. No superfluous content.
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 one-parameter tool with an output schema, the description covers purpose and parameter adequately. However, it lacks usage context and behavioral notes, leaving slight gaps.
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%, but the description adds meaning by specifying the parameter is a full path to a .unl file and provides an example. This compensates for the schema's lack of details.
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 'Get metadata for a lab,' specifying the action (get) and resource (lab metadata). Among siblings like get_lab_topology and get_lab_links, this uniquely identifies the tool's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_lab_topology, get_lab_links). There are no exclusions, prerequisites, or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 only states that it lists types but does not disclose whether it requires authentication, is read-only, or any side effects. The brevity leaves significant behavioral 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 sentence of 90 characters with no fluff. It is front-loaded with the key action and provides concrete examples. 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?
Given the tool's simplicity (no parameters, output schema present), the description is nearly complete. It could briefly mention that the output is a list of strings, but the output schema likely covers that. Lacks a tiny bit of context about typical usage or ordering.
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 input schema has zero parameters, so baseline is 4. The description does not need to add parameter semantics; it simply describes the tool's purpose, which is sufficient.
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 the resource 'available network/cloud types' with examples (bridge, ovs, pnetX...). It distinctly differentiates from sibling tools like 'list_lab_networks' which list actual lab networks, not types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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. It does not mention prerequisites, context, or exclude cases. Given the presence of many sibling tools, this omission reduces clarity for an agent deciding which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the action and parameter formats, but omits critical behavioral details such as whether moving overwrites destinations, effects on contents, permissions required, or error handling. This leaves significant ambiguity 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. The 'Args' section is structured but adds some verbosity relative to the simplicity of the schema. Overall, it is efficient without wasted words.
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 moderate complexity with 2 parameters and an output schema, but the description lacks details on return values (not covered by output schema context signals) and behavioral edge cases. It is minimally adequate but leaves gaps that impact reliable agent invocation, especially without annotations.
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% (no descriptions in input schema), so the description must compensate. It provides clear examples for both 'path' and 'new_path', explaining the required format. However, it does not clarify edge cases like relative paths or allowed characters, keeping this from a perfect score.
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 directly states 'Move or rename an existing folder,' clearly conveying both the verb (move/rename) and the resource (folder). This distinguishes it from siblings like 'add_folder' and 'delete_folder' by specifying it modifies an existing folder.
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 stating what the tool does, and the sibling list provides context for alternatives, but it lacks explicit guidance on when not to use it (e.g., for moving labs) or prerequisites like authentication or folder existence. The 'Args' section helps but is more about parameter syntax than usage context.
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 carry the full burden of behavioral disclosure. It notes that the tool returns CPU, RAM, disk usage, and version info, indicating a read operation. However, it does not disclose potential side effects (likely none, but unstated), access requirements, or rate limits. The lack of annotations makes the description minimally adequate.
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 covers the purpose and key data points without any wasted words. Every part contributes directly to understanding, making it highly efficient.
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 zero parameters and an output schema that likely details the specific fields, the description provides enough context for most use cases. It could be slightly improved by mentioning the output format (e.g., JSON), but with the output schema present, this is not a major gap. The description covers the main purpose thoroughly.
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 schema description coverage is 100%. The description adds value by specifying exactly what data the status includes (CPU, RAM, disk, version) beyond a generic 'get status,' which helps the agent understand the expected output without needing to examine the output schema. This is above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves server status including specific metrics like CPU, RAM, disk usage, and version info. It uses a specific verb ('Get') and resource ('EVENG server status'). However, it does not explicitly differentiate from sibling tools like 'list_tools' or 'open_lab' that might return other server info, so it loses a point.
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 this is for checking system health or version details, but it provides no guidance on when to use it versus alternatives like 'list_tools' or 'open_lab'. No exclusions, prerequisites, or context for decision-making are included, leaving the agent to infer usage based on the resource name.
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, the description carries the full burden. It discloses a behavioral trait: the vendor label is a best-effort extraction from the template description because EVE-NG's API lacks an explicit field. However, it does not mention side effects, permissions, rate limits, or error handling. The disclosure is adequate but not exhaustive.
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 well-structured: a one-sentence purpose, a brief note about the vendor label, and a clear Args section. Every sentence adds value, and the essential information is front-loaded.
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 that an output schema exists, the description does not need to detail return types. It mentions the key output features (console URL/status for single node, vendor label). For a read-only list tool, this is nearly complete; a minor gap is the lack of distinction between the return format for a single node vs. a list, but it is implicitly clear.
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 schema has 0% description coverage, so the description must compensate. The Args section explains 'lab_path' as 'Full path to the .unl lab file' and 'node_id' as 'Specific node id, or omit to list all nodes.' This adds meaningful semantics beyond the schema's bare titles and types. A minor improvement could include format or validation hints.
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: 'List all nodes in a lab, or get a single node by id (includes console URL/status).' The verb 'list' or 'get' and resource 'nodes' are specific, and the tool is distinct from sibling tools like 'get_lab_topology' or 'add_lab_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only restates the purpose (list or get a node) without mentioning when not to use it or which sibling tools might be better suited for related tasks.
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?
No annotations are provided, so the description carries full burden. It discloses that the tool reads a topology from a file path but does not state whether the lab must be currently open or running, what happens if the path is invalid, or describe the return format. For a read-only tool, this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and front-loaded, containing exactly two sentences: one stating the tool's purpose and one describing the parameter. Every sentence adds value with no redundancy or 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?
The tool is simple (1 parameter, read-only) and has an output schema, reducing the need to describe return values. The description covers what the tool does and the input meaning. Minor gaps exist (e.g., behavior when lab not found) but are acceptable for a straightforward retrieval tool.
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%, so the description must compensate. It adds 'Full path to the .unl lab file' which provides format and meaning beyond the raw schema field name 'Lab Path'. The single-parameter simplicity and clear description are highly effective.
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 this tool retrieves 'the full node/network connection topology of a lab', using specific verb 'Get' and resource 'lab topology'. It distinguishes from siblings such as 'get_lab' (general lab data) and 'get_lab_links' (only links), and is appropriately scoped.
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 for retrieving topology but provides no guidance on when to use this versus alternatives like 'get_lab_links' or 'get_lab'. No exclusions or conditions stated, which is acceptable for a simple data-retrieval tool but lacks explicit differentiation.
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 full burden. It implies a read operation (Get) and mentions the input parameter but does not disclose behavior like whether the lab must already be open, if errors occur for invalid paths, or if the output is static or state-dependent. The description is adequate but lacks depth.
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 short and front-loaded with the core purpose. The Args section is well-structured for parameter documentation. It could be slightly more concise by removing the 'Args:' header if redundant, but it serves clarity.
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 one simple parameter and an output schema present (which explains return values), the description is largely complete. It could benefit from noting any lab state requirements or whether the tool is safe to use on closed labs, but the minimalism is acceptable for this low-complexity tool.
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 description adds the exact format for the lab_path parameter ('Full path to the .unl lab file'). Since schema description coverage is 0%, the description provides the only semantic guidance. The path format guidance is valuable, though no detailed restrictions (e.g., relative vs absolute) are given.
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 identifies the tool as retrieving ethernet/serial endpoints available in a lab, with a specific use case noted (useful before wiring nodes). This verb+resource combination is distinct from sibling tools like 'get_lab_topology' or 'get_node_interfaces'.
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 explicitly mentions when it is useful (before wiring nodes), which gives context for usage. However, it does not mention when not to use it or provide alternatives from the sibling list, though the sibling list is available for the agent to compare.
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 must fully disclose behavior. It clarifies that disabled tools never appear (authoritative for availability), which is key behavioral context. However, it does not state whether the list is read-only or if calling it has side effects, but given it is a list tool, that is minimally expected.
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 two sentences, one short and one longer but packed with meaning. It is front-loaded with the core purpose in the first line. Could be slightly more concise by merging the second sentence's insight, but overall efficient.
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 zero parameters, a simple output (list of tools), and no output schema needed for completeness, the description effectively explains what the tool returns and its significance. No major gaps; the sibling list shows many tools, and this one is clearly distinct for server introspection.
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 zero parameters and schema description coverage is 100%, so the parameter section inherently needs no extra explanation. The description does not add anything about parameters, but baseline of 3 is appropriate since schema fully covers them.
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 is highly specific: it states the tool lists every tool the MCP server advertises, and distinguishes itself by clarifying what 'disabled' means — a tool not registered isn't just hidden but never existed, which contrasts with potential sibling tools that might have error-handling for disabled features.
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 explicitly recommends use as a 'single authoritative check of what's actually available right now', but does not mention when NOT to use it or alternative tools for related purposes. Siblings like get_status are different in focus, so implied usage is clear but exclusions are missing.
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?
Without annotations, the description fully takes on the transparency burden. It discloses a notable behavioral trait: the vendor label is a 'best-effort' extraction from the template's description, and that EVE-NG's API has no explicit vendor field. This informs the agent of potential data quality issues. However, it does not mention other behaviors like idempotency, authentication requirements, or error cases, though for a simple read operation this may be acceptable.
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 highly concise: three short paragraphs – purpose, a critical behavioral note (vendor extraction), and the parameter definition. Each sentence serves a distinct purpose with zero redundancy. The primary purpose is front-loaded in the first line.
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 lookup tool, the description covers the main return aspects (available images, default options, vendor label) and the parameter. The existence of an output schema (context signal) suggests return values are structured, but the description does not need to reiterate the schema. It provides enough context for an agent to understand what the tool returns and its caveats.
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 0% description coverage (parameter 'template' only has a title). The tool description compensates fully by providing an 'Args:' section that defines the parameter as 'Template id' and gives concrete examples: 'e.g., "iol", "vios", "csr1000v".' This adds meaning beyond the schema and clearly informs the agent what values to use.
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: 'Get details (available images, default options) for one node template.' The verb 'get' and the resource 'node template' are specific, and the examples of what details are included (images, default options) differentiate it from siblings like list_node_templates which would list all templates without details.
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 requiring a specific template id ('for one node template') and provides an 'Args' section with example template IDs. However, it does not explicitly state when to use this tool versus alternatives (e.g., 'Use this when you need details for a specific template; for a list of all templates, use list_node_templates instead'). The guidance remains 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 carries full burden. It discloses key behavioral traits: conditional fetching of type list, cloud name resolution, default name and positions, and the exact effect of hideme. It does not mention error handling or prerequisite checks, but the main behaviors are transparently described.
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 well-structured with a clear opening sentence and an Args section. It is slightly verbose (e.g., long cloud explanation) but every detail earns its place. The note about hideme is slightly tangential but adds value. Overall, it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, only 1 required, and an existing output schema (so return values need not be explained), the description covers all parameters with usage details and behavioral caveats. It could mention that the lab must already exist, but that is implicitly assumed. The contextual completeness is high for the tool's complexity.
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%, meaning the schema itself provides no descriptions. The tool description compensates fully by detailing each parameter: lab_path is a .unl file path, network_type references list_network_types and explains cloud aliases, name defaults to 'NetX', left/top are numeric strings, hideme has explicit 0/1 semantics with a corrective note. This adds significant meaning 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 opens with a specific verb+resource: 'Add a network (bridge/cloud/ovs/pnetX) to a lab's canvas.' This clearly states the tool's purpose and distinguishes it from sibling tools like list_lab_networks, edit_lab_network, and delete_lab_network.
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 explicit guidance: explains behavior when network_type is omitted (fetches list and prompts), references list_network_types for valid values, and clarifies cloud-to-pnet mapping. It also warns what hideme does NOT do (direct-line rendering). No explicit alternatives are listed, but the add vs edit/delete distinction is clear from context.
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?
Without annotations, the description takes full responsibility for behavioral disclosure. It clearly explains the multi-step deletion process, case-insensitive substring matching, refusal of non-empty folders, and the destructive action. The only minor gap is not explicitly stating that the operation is irreversible once confirmed, though 'delete' implies destruction.
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 well-structured with a short overview sentence, critical behavioral notes, and Args section. It's concise enough (4 lines + args) but front-loads the most important info. Minor redundancy: 'Only one folder can be deleted per call' could be folded into the flow description.
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 4 parameters, no output schema, and no annotations, the description adequately covers the multi-step flow, parameter meanings, and refusal conditions. The presence of an output schema slightly reduces the need to describe return values. A small gap: it doesn't mention what success/failure looks like or error handling, but the flow explanation is sufficient for safe usage.
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?
With 0% schema description coverage, the description compensates fully by explaining each parameter: 'path' (required substring), 'search_path' (default to /), 'selection' (disambiguation when multiple matches), and 'confirm' (safeguard). It adds practical examples (e.g., '/User1/Folder 1' or 'Folder 1') that the schema doesn't provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a folder matched by path substring. It differentiates from folder operations like add_folder, move_folder, and list_folder by specifying 'delete' and safe behavior (refuses to delete non-empty folders). However, it could be more explicit about distinguishing from other delete tools like delete_lab or delete_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?
The description explicitly outlines the search-select-confirm flow, when deletion is refused (contents exist), and limits (only one folder per call). It provides clear step-by-step guidance on how to use the tool safely, including prerequisites (search_path) and confirmation parameter usage.
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 the search behavior (case-insensitive, recursive under search_path), the confirm boolean safety mechanism, and the constraint of one lab per call. It does not explicitly state that deletion is irreversible or what happens to associated resources, but provides sufficient operational context for safe use.
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 well-structured, starting with the core purpose, then the workflow, then matching details, then parameter list. All sentences add value, though the parameter bullet points could be slightly more integrated. It is appropriately sized for 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 4 parameters and search-delete flow, the description covers the essential aspects: matching semantics, confirm safety, and single-lab constraint. It does not detail error handling (e.g., no match, multiple matches without selection), but the flow is clear. The presence of an output schema reduces the need to describe return values.
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%, so the description must fully explain parameters. It does so with detailed explanations for name (with examples), search_path (default '/'), selection (for multiple matches), and confirm (set true to actually delete). This adds significant meaning beyond the bare schema definitions.
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 'Delete exactly one lab, matched by path OR name substring (case-insensitive).' It specifies the action (delete), the resource (lab), and the unique matching method, distinguishing it from sibling tools like delete_folder, delete_lab_node, etc.
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 outlines a 'Search -> select -> confirm flow,' explaining the multi-step process and the role of the confirm parameter. It notes that only one lab can be deleted per call, but does not explicitly exclude cases like deleting multiple labs or compare to alternatives like edit_lab or move_lab.
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 critical traits: matches on name only (not id), requires a confirm flag to actually delete, and supports multiple selections. This is transparent for a destructive operation. It does not mention reversibility, side effects, or permissions, but the core workflow is well disclosed.
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 reasonably concise given the amount of detail. It front-loads the core action and then uses a structured Args list. The reference to 'see module docs' is a slight brevity trade-off. The flow notation ('Search -> select -> confirm') is efficient but could be clearer. Overall, it is well-organized without being overly verbose.
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 complexity (4 parameters, multi-step confirmation, output schema exists), the description covers the main workflow, parameter meanings, and behavioral pattern. It does not discuss error conditions or what happens if no match is found, and it defers to module docs for deeper detail. Still, it provides a solid foundation for correct tool 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 compensate. It does so thoroughly by providing an Args section that explains each parameter: lab_path (full path to .unl file), name (network name or fragment), selection (numbers/names when multiple matched), and confirm (boolean to confirm deletion). This adds essential meaning beyond the schema's bare titles and types.
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 (delete), resource (network(s)), and scope (from a lab), with the specific matching mechanism (name substring, case-insensitive). This distinguishes it from sibling tools like delete_lab (which deletes a whole lab) or delete_lab_node (which deletes nodes).
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 outlines a multi-step flow (search -> select -> confirm) and explains when to use the selection parameter and confirm flag. It mentions that multiple networks can be deleted per call. However, it does not explicitly state when to choose this tool over alternatives (e.g., delete_lab_node) or when not to use it, which would improve clarity.
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 bears full burden. It discloses case-insensitive substring matching, multi-selection capability, the safety confirm flag, and the search-select-confirm flow. Missing details like error handling or prerequisites, but sufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then flow, then parameter docs. It is concise but the 'see module docs' line slightly weakens it. Still well-structured for quick understanding.
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 an output schema exists, return values need not be explained. The description covers usage flow and key parameters. However, it lacks discussion of error cases (no matches, wrong path) and prerequisites. 'See module docs' is a minor gap.
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 compensate. It explains each parameter's purpose: lab_path (full path), name (substring, required effectively), selection (numbers or exact names), confirm (safety flag). This adds crucial meaning beyond schema types and defaults.
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 deletes node(s) from a lab, using name substring matching. It distinguishes from siblings like delete_lab (whole lab) and add_lab_node (creation). The specific verb and resource are clear.
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 explains the search-select-confirm flow and emphasizes matching on name only, never ID. It implies a two-step process but doesn't explicitly contrast with alternative deletion tools (e.g., delete_lab). Sibling context is available externally, so this is still effective.
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?
The description discloses critical behavioral traits: auto-placement algorithm (left-to-right, 5 per row, 100-unit spacing, skips occupied slots), template defaulting behavior for unspecified fields, and the special image selection requirement. Since no annotations are provided, the description carries the full burden, and it does so comprehensively, with only minor gaps (e.g., no mention of whether the lab must be open first or if there are write 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded summary paragraph, followed by clear sections for template resolution logic, auto-placement algorithm, and parameter documentation. While it's on the longer side, every sentence adds distinct value. Could be slightly tightened (e.g., 'this works the same way for every vendor's templates' is somewhat redundant), but overall efficient for the 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 13 parameters (1 required), no annotations, and an output schema (which the description doesn't need to document), the description thoroughly covers the tool's behavior, template resolution workflow, auto-placement, and all parameter semantics. Minor gaps: no explicit mention of error states beyond 'no matches cancels', and no note on whether the lab must be pre-opened. Still, very complete for a complex tool.
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%, meaning the schema provides no descriptions for any of the 13 parameters. The description compensates fully by explaining every parameter in detail: 'template' as substring search, 'selection' for disambiguation, 'node_type' defaults, 'name' defaults, 'image' auto-fill behavior, 'config' and 'console' defaults, canvas position auto-placement logic, and RAM/CPU/ethernet defaulting to template values. This is excellent semantic 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 begins with a clear verb+resource statement: 'Add a node to a lab's canvas', and specifies two key behaviors (template resolution by search, auto-placement). This distinguishes it from siblings like 'edit_lab_node', 'delete_lab_node', or 'list_lab_nodes' which cover different node operations.
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 a detailed, step-by-step guide for using the tool: explains the template search behavior (case-insensitive substring match, edge cases for empty, no matches, exactly one match, multiple matches requiring selection), and when 'image' must be explicitly provided ('if the template has more than one image'). This gives explicit context for when and how to use the tool effectively.
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 bears full responsibility, and it excels. It discloses that nodes will be stopped before the change, that the operation requires explicit confirmation, and explains the incrementing-delay logic in bulk mode. No behavioral surprises are left unaddressed.
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 well-structured with an overview, mode breakdown, and Args list. It is somewhat verbose (repetition of defaults like 'default 10'), but the complexity of the tool (two modes, confirmation workflow) justifies the length. It is front-loaded with the core purpose.
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 8 parameters, no annotations, and an output schema that isn't described (but exists), the description covers all behavioral aspects: confirmation flow, node-stopping, default values, and both single and bulk modes. The tool's interaction model is fully 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?
Schema description coverage is 0%, so the description must fully compensate. It does so with a detailed Args section covering all 8 parameters, their defaults, relationships (e.g., node_id overrides bulk), and usage patterns. Each parameter's meaning is clearly explained beyond the schema's bare types.
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: 'Change a node's startup delay'. It explains single-node and bulk modes, making the verb-resource relationship explicit. While siblings like 'edit_lab_node' exist, this tool's specific focus on delay distinguishes it adequately.
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 guidance on when to use each mode (node_id vs bulk, names vs order) and describes the required confirmation step. It does not explicitly compare to sibling tools like 'edit_lab_node', but the instructions are sufficient for correct invocation in 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?
No annotations are provided, so the description carries full burden. It transparently discloses that node-to-node connections are implemented via a hidden bridge network (mimicking GUI behavior), and that on Community edition, nodes are automatically stopped before wiring. The description also mentions scoping to ethernet interfaces and auto-pick behavior.
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 well-structured into paragraphs and a parameter list, but it is moderately lengthy. Most sentences add value, though some parenthetical clarifications could be slightly tightened. Overall, it remains clear and front-loaded with the core behavior.
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 7 parameters, no annotations, and moderate complexity (mutual exclusivity, auto-pick, edition differences), the description is complete. It covers all edge cases (auto-pick, community vs. PRO, visual differences) and provides enough context for an agent to invoke the tool correctly without needing to consult external documentation.
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 all 7 parameters. It does so comprehensively: explaining lab_path, node_id, interface/target_interface (name, index, or omit), and the exclusive mutual exclusion between target_node_id and network_id/network_name pairs, including context on why they differ in canvas appearance.
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 connects one node's interface to another node or to an existing network. It distinguishes between two modes (node-to-node vs. node-to-network) and explains the visual/canvas behavior, differentiating it from sibling tools like add_lab_network or edit_lab_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?
The description explicitly explains the two usage paths (target_node_id vs. network_id/network_name) and provides detailed context on when to use each. It also covers auto-picking interfaces, EVE-NG edition differences (PRO vs. Community) with stop-if-needed behavior, referencing sibling-like behavior from edit_lab_node for clarity.
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 fully discloses behavioral traits: recursive walking, handling EVE-NG API limitations, loop protection, max depth/folder ceilings, and skipping '..' entries. This is comprehensive and transparent about side effects and constraints.
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 well-structured with a clear first sentence stating core purpose, followed by key behavioral details, then an Args section for parameters. Every sentence adds value. Minor improvement: could be slightly tighter (e.g., 'Always recursive' is already implied).
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 tool complexity (recursive listing, API limitations, loop protection), the description is comprehensive. It explains behavior, constraints, and parameter semantics fully. The output schema exists, so return values aren't needed.
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 description adds significant meaning beyond the schema: explains `path` default ('/') and its role as starting folder, describes `search` as case-insensitive substring matching with same convention as sibling tools, and clarifies empty default matches all. This compensates fully for the 0% schema 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 'Recursively list every lab under `path`', providing a specific verb and resource. It distinguishes from siblings like 'list_folder' by emphasizing recursive behavior and the lab focus.
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 explains 'Always recursive' behavior and that it lists labs, not folders. It doesn't explicitly state when not to use this tool vs. alternatives (e.g., `list_folder` for non-recursive folder listing), but context hints at differentiation. Could explicitly state when to use `list_folder` instead.
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 fully shoulders the burden of disclosing behavior. It details the case-insensitive substring search, the behavior for no matches (>20, exactly one, multiple), the preservation of existing shares, and the final confirmation using specific words. This is thorough and leaves little ambiguity.
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 appropriately sized for the complexity. It starts with a concise main statement, then uses paragraph blocks to explain the search/selection logic and the confirmation step. Each sentence adds value, though some minor redundancy could be trimmed. Overall well-structured and 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?
Given 4 parameters, no annotations, and the existence of an output schema, the description is complete. It covers the entire user interaction from search to confirmation, explains all parameter behaviors, and hints at the output (though the output schema handles that). No gaps remain.
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 provide parameter meaning. It does so excellently: for each parameter (lab_path, search, selection, confirm) it gives a precise, context-rich explanation including examples ('all', 'accept'/'yes'). This fully compensates for the empty schema 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 action: 'Share a lab with one or more users, added to whoever it's already shared with.' The verb 'share' and resource 'lab with users' are specific and distinctive. Among sibling tools, this is the only sharing-related operation, so it is well-differentiated.
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 extensive guidance on how to use the tool, detailing the search, selection, and confirmation flow. It explains edge cases like empty search, 'all' shortcut, multiple matches, and that existing shares are preserved. While there are no explicit exclusions or alternative tools to mention, the usage context is very clear and actionable.
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?
Even though no annotations are provided to set a baseline, the description goes well beyond minimal expectations for behavioral disclosure. It explicitly states the tool is read-only ('Read-only'), clarifies there is no side-effect or session mechanism ('every change [...] is its own direct call, no prior "open" needed'), describes search behavior (recursive, case-insensitive substring match), and specifies the output includes lock status and suggested next steps. This level of detail is exemplary for a tool lacking annotations.
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 efficiently structured with short sentences and a logical flow: purpose first, then behavioral caveats, then search behavior, then parameter details. Every sentence adds value. It could be improved by moving the parameter docs to a more standardized format or removing redundancy in the sibling-tool reference, but overall it's well-proportioned.
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 tool's moderate complexity (3 parameters, but no required ones) and the presence of an output schema (meaning the description doesn't need to explain return format), the description is remarkably complete. It covers purpose, behavioral constraints, search semantics, disambiguation mechanics, and parameter semantics—all within a compact space. No critical gaps remain for an agent to use this 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?
Despite a 0% schema description coverage (the schema provides no human-readable parameter descriptions), the description's parameter documentation (Args section) adds substantial meaning beyond the bare schema. It clarifies `name` is 'Required' (despite the schema not marking it required, the description states it's required behaviorally), `search_path` defaults to '/', and `selection` is only needed when multiple labs match. The description explains the behavioral semantics of each parameter, though it could further specify the format for `name` and `selection` (e.g., what 'full name/path' looks like).
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 immediately states the tool's core purpose: 'Look up a lab by path or name substring, report its lock status, and suggest next steps.' It clearly distinguishes itself from siblings like `delete_lab`, `create_lab`, and `get_lab` by emphasizing that this is a read-only lookup operation that reports lock status and suggests next steps, not a mutation or a simple fetch. It also explicitly differentiates from any 'open for editing' session concept.
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 explicitly tells the agent when to use this tool ('Look up a lab...report its lock status, and suggest next steps.') and when not to ('Read-only -- there is no "open for editing" session'). It also provides clear guidance on usage patterns: how search works ('recursively under `search_path`; matching is case-insensitive substring'), what happens with multiple matches ('they're listed and you pick one'), and how disambiguation works ('via `selection`'). It even name-drops a sibling (`delete_lab`) to clarify search behavior.
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?
No annotations were provided, so the description bears full responsibility for disclosing behavior. It comprehensively details the disambiguation process, the node selection mechanism, the component-specific handling (icon vs image searches and scopes), the interactive prompting for missing args, the lack of server-side session, and the mandatory node-stop before applying changes. This is exceptionally thorough.
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 long but well-structured, using clear sections and bullet-style paragraphs. It is front-loaded with the primary purpose. However, it could be slightly more concise by reducing repetition (e.g., the interactive prompting concept is explained multiple times). Every sentence earns its place, but the length is at the upper edge of practicality.
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 tool's complexity (12 parameters, multi-step flow, component-specific logic, confirmation requirement) and the complete absence of annotations, the description is remarkably complete. It covers template resolution, node selection, component change semantics, icon/image scoping, interactive prompting, and confirmation. The output schema exists, so return value details are not needed.
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 compensate for the 12 parameters. It does so by explaining each parameter's purpose, constraints (e.g., 'at least one of vendor or template'), search behavior (case-insensitive substring), selection logic, and special cases (icon/image value is unused). The explanation is richer than any schema alone could provide.
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 it bulk-edits interfaces/cpu/memory/icon/image across nodes of exactly one template. It specifies the verb ('Bulk-edit'), the resource ('nodes of exactly one template'), and the scope of allowed changes. This distinguishes it from other lab editing tools (e.g., edit_lab_node, edit_lab) and from listing tools.
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: it requires at least one of vendor or template, explains how disambiguation works if multiple templates match, and describes the multi-step prompting flow. It also states that the tool never targets more than one template per call, and implies that for single-node edits, edit_lab_node might be more appropriate. The final confirmation step is clearly documented.
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?
Without annotations, the description carries the full burden. It discloses the default filtering behavior (only templates with images), the side effect of the include_without_images parameter changing result set content, and the extracted vendor label limitation (best-effort, not an API field). This is thorough and accurate.
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 efficient, with a concise main sentence and a bullet for the parameter. It front-loads the key action (listing templates with vendor context). The one extra detail about the vendor label extraction is valuable but slightly elongates the description. Still, very well-structured.
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 tool's simplicity (one optional boolean parameter, no complex output), the description fully clarifies behavior, default filtering, parameter use, and data provenance for the vendor field. No gaps remain; the agent can confidently use this tool.
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%, so the description must compensate for the undocumented include_without_images parameter. It does so excellently, explaining both that passing true shows the full catalog (including templates without images) and that those templates cannot be used to add a node, adding meaning far beyond the schema's title and 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 clearly states the tool lists node templates with vendor context, specifying that by default only templates with installed images are shown. The mention of the best-effort vendor label extracted from the description adds precision, and the tool is easily distinguished from siblings like list_node_templates (singular) or other list_ functions.
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 the include_without_images parameter, explaining that by default only usable templates are listed and passing true reveals the full catalog, including those that cannot be used to add a node. This helps the agent decide when a broader view is needed.
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?
Despite no annotations being provided (so description carries full burden), the description thoroughly discloses behavioral traits: partial-update semantics, the critical timing constraint for visibility (must be set after creation and wiring, not at creation), and that this is what connect_interface uses internally. It even confirms this against a working reference implementation. This is exemplary transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is optimally concise: a one-sentence overview of the edit action and partial-update semantics, a reference to sibling patterns, a key behavioral note about connect_interface usage, then a cleanly organized Args section. No superfluous information. Every sentence serves a purpose.
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 11 parameters (complex), no annotations, and 0% schema description coverage, but the description fully compensates. It provides comprehensive parameter documentation, usage context (partial-update, timing constraint), and cross-references to sibling tools. The output schema exists but the description doesn't need to cover return values.
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%, meaning the schema has no descriptions at all. The description fully compensates by documenting every parameter with type info (0/1 for visibility/hideme, 'e.g. Solid' for style) and usage context. The visibility parameter gets special treatment with the timing caveat. The arg docstring effectively replicates and enhances the schema, justifying a top score.
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 action (edit an existing network by id) and the resource (lab network). It distinguishes from siblings by noting it follows the same partial-update pattern as edit_lab/edit_lab_node, and differentiates from creation tools by the critical timing detail about visibility. The verb 'edit' combined with 'partial-update' 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'Only supplied fields are changed' establishes the partial-update semantics. It explicitly names sibling tools 'connect_interface' as an internal user and gives a concrete use case (setting visibility=0 on a node-to-node bridge). It even includes a confirmed implementation detail about timing (must be done after creation and wiring, not at creation time), which prevents misuse.
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 fully covers behavioral traits: only supplied fields are changed, automatic stopping of node before edit, duplicate name behavior (returns confirmation_required), and explicit list of fields including exclusions (uuid). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: purpose, field list, sibling differentiation, automatic behavior, duplicate name handling, then formal Args. Every sentence adds value; no redundancy. Despite length (26 params), it is efficient and front-loaded with key info.
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 26 parameters, no annotations, and an output schema (implied), the description is complete: covers all field meanings, edge cases (duplicate names, automatic stop), and references related tools. Provides sufficient context for correct 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 coverage is 0%, but the description includes a comprehensive Args block explaining each parameter's meaning, including constraints (e.g., image must be valid, console types listed). This adds significant context beyond the minimal schema types, fully compensating for the lack of schema 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 'Edit an existing node by id. Only supplied fields are changed.' It specifies the resource (node) and distinguishes itself from sibling tools by explicitly naming edit_lab_nodes_by_template for bulk edits and change_node_delay for delay-specific operations.
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 when-to-use (single node editing) and when-not-to-use (referring to sibling tools). Also details prerequisites (node must be stopped, but tool handles it automatically) and special cases (duplicate name handling with confirm_duplicate_name). This gives the agent clear decision support.
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:

[![mcp_eveng MCP server](https://glama.ai/mcp/servers/madmickstar/mcp_eveng/badges/card.svg)](https://glama.ai/mcp/servers/madmickstar/mcp_eveng)

Score Badge

Copy to your README.md:

[![mcp_eveng MCP server](https://glama.ai/mcp/servers/madmickstar/mcp_eveng/badges/score.svg)](https://glama.ai/mcp/servers/madmickstar/mcp_eveng)

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/madmickstar/mcp_eveng'

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