GNS3 Network Simulator MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have distinct purposes, but some overlap exists. For example, gns3_send_console_commands and gns3_apply_config_template both configure devices, potentially causing confusion. However, descriptions clarify that the former sends raw commands while the latter uses templates, aiding disambiguation.
Naming Consistency5/5
All tools follow a consistent gns3_verb_noun naming pattern, such as gns3_add_link, gns3_list_nodes, and gns3_start_capture. This uniformity makes the tool set predictable and easy to navigate, with no deviations in style.
Tool Count3/5
With 42 tools, the count is borderline high for a network simulator server. While it covers many operations, it may feel heavy and could overwhelm agents, though the domain complexity might justify some of this breadth.
Completeness5/5
The tool set provides comprehensive coverage for GNS3 network simulation, including project management (create, open, close, delete), node operations (add, start, stop, configure), topology management (links, shapes, annotations), and advanced features like snapshots and packet capture. No obvious gaps are present.
Average 2.9/5 across 42 of 42 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under 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?
No annotations are provided, so the description carries full burden. It states the action ('Add a shape') but lacks critical behavioral details: whether this is a mutation (likely yes), authentication requirements (implied by username/password params but not stated), error handling, or what the output contains. The description doesn't contradict annotations (none exist), but it's insufficient for a tool with 11 parameters.
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 brief but poorly structured. The first sentence states the purpose clearly, but the parameter documentation is incomplete and formatted as a simple list without grouping or prioritization. It's concise but not effectively organized, with wasted space on partial param details.
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 complexity (11 parameters, no annotations, schema coverage 0%), the description is highly incomplete. It lacks behavioral context, ignores most parameters, and doesn't leverage the output schema (which exists but isn't referenced). For a mutation tool in a network topology context, this leaves the agent under-informed about usage and effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only documents 3 parameters (shape_type, color, fill_color) out of 11, ignoring key ones like project_id, x, y, width, height, and server_url. The parameter explanations are minimal (e.g., 'Border color (hex format)'), leaving most semantics undefined. This fails to address the low coverage gap.
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's purpose: 'Add a shape (rectangle or ellipse) to the topology.' It specifies the verb ('Add'), resource ('shape'), and types ('rectangle or ellipse'). However, it doesn't explicitly differentiate from sibling tools like gns3_add_text_annotation or gns3_add_node, which also add visual elements to the 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. There's no mention of prerequisites (e.g., needing an open project), comparison to other shape-related tools (none exist in siblings), or typical use cases. The agent must infer usage from the purpose alone.
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 carries full burden but only states the action without behavioral details. It doesn't disclose if starting requires authentication (implied by username/password params), potential side effects (e.g., network activation), rate limits, or error conditions. The description is minimal, leaving critical behavior opaque.
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 with zero wasted words. It directly states the tool's purpose without redundancy or fluff, making it highly concise and well-structured for quick scanning.
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's complexity (mutation operation with 5 parameters, no annotations, but has an output schema), the description is incomplete. It lacks context on authentication, operational behavior, error handling, and parameter meanings. The output schema may cover return values, but the description doesn't provide enough for safe or effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'project_id' or 'node_id' refer to, why 'server_url' defaults to localhost, or when 'username'/'password' are needed. With 5 parameters (2 required), this leaves significant gaps in understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a specific node' clearly states the action (start) and resource (node), but it's vague about what 'start' means operationally (e.g., power on, initialize) and doesn't distinguish from siblings like 'gns3_start_all_nodes' (bulk vs. specific) or 'gns3_reload_node' (restart vs. initial start). It avoids tautology but lacks specificity.
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. It doesn't mention prerequisites (e.g., node must be stopped), contrast with 'gns3_start_all_nodes' for bulk operations, or specify contexts like post-configuration. The agent must infer usage from the name alone.
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 carries full burden but only states the action without behavioral details. It doesn't disclose if stopping is reversible, requires specific permissions, affects other nodes, or has side effects like data loss. For a mutation tool, this is a significant gap.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for its limited content, though brevity here reflects under-specification rather than optimal clarity.
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?
For a mutation tool with no annotations, 5 parameters at 0% schema coverage, and an output schema (which reduces need for return value explanation), the description is incomplete. It lacks behavioral context, parameter semantics, and usage guidance, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'project_id' or 'node_id' represent, or the purpose of authentication parameters. With 5 parameters undocumented, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop a specific node' clearly states the action (stop) and target (node), but it's vague about what 'stop' means operationally and doesn't differentiate from siblings like 'gns3_suspend_node' or 'gns3_stop_all_nodes'. It's better than a tautology but lacks specificity.
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 like 'gns3_suspend_node' or 'gns3_stop_all_nodes'. The description implies usage for stopping a node but offers no context about prerequisites, dependencies, or exclusions.
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 full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't address critical aspects like required permissions, whether changes are reversible, error handling, or rate limits. The description adds minimal context beyond the basic action, leaving significant gaps 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 extremely concise with two brief sentences that are front-loaded and waste no words. Every sentence serves a purpose: the first states the core action, and the second clarifies the update behavior. This is efficient and well-structured for its limited content.
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's complexity (8 parameters, mutation operation, no annotations) and 0% schema description coverage, the description is incomplete. While an output schema exists (which helps), the description lacks essential context about parameters, usage scenarios, behavioral traits, and differentiation from siblings. For a mutation tool with many parameters, this minimal description is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 8 undocumented parameters. It only vaguely references 'specified parameters' without explaining what parameters exist or their meanings (e.g., project_id, name, auto_close). This fails to provide meaningful semantic context beyond what the bare schema already shows through property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'update' and resource 'project settings', which is clear but minimal. It distinguishes from siblings like 'gns3_create_project' or 'gns3_delete_project' by focusing on modification rather than creation or deletion, but doesn't explicitly differentiate from similar tools like 'gns3_update_node'. The purpose is understandable but lacks specificity about what 'settings' entails.
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. The description doesn't mention prerequisites (e.g., project must exist), when not to use it (e.g., for creation vs. update), or refer to sibling tools like 'gns3_get_project' for checking current settings. The partial guidance about 'only specified parameters will be updated' hints at usage but is insufficient for comprehensive decision-making.
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 of behavioral disclosure. It states the tool creates a snapshot/backup, implying a write operation, but doesn't cover critical aspects like whether it overwrites existing snapshots with the same name, requires authentication, has side effects on project availability, or provides success/failure responses. This is inadequate for a mutation tool with zero annotation coverage.
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 brief and front-loaded, consisting of two clear sentences that directly state the tool's purpose and what it captures. There's no wasted text, though it could be slightly more structured (e.g., separating purpose from details).
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's complexity (a mutation operation with 5 parameters, no annotations, and 0% schema coverage), the description is incomplete. It lacks parameter explanations, behavioral details, usage context, and output information (though an output schema exists, which mitigates this slightly). For a backup/creation tool in a system with many siblings, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description doesn't mention any parameters, failing to compensate for this gap. It doesn't explain what 'project_id' or 'snapshot_name' represent, or the purpose of 'server_url', 'username', and 'password', leaving the agent to guess based on naming alone.
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's purpose with a specific verb ('Create') and resource ('snapshot (backup) of a project'), and explains what it captures ('current state of all nodes and configuration'). However, it doesn't explicitly differentiate from sibling tools like 'gns3_restore_snapshot' or 'gns3_list_snapshots', which would be needed for a score of 5.
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 doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to sibling tools like 'gns3_restore_snapshot' or 'gns3_delete_snapshot', leaving the agent to infer usage from context alone.
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 full burden for behavioral disclosure. It states the action is 'permanently' destructive, which is useful, but lacks details on permissions required, error conditions (e.g., if snapshot doesn't exist), side effects, or what the output schema returns. This is inadequate for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Delete a snapshot permanently' is front-loaded and directly conveys the core action. Every word earns its place, making it highly concise and well-structured.
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 a destructive tool with 5 parameters (0% schema coverage), no annotations, and an output schema (which reduces need to describe returns), the description is incomplete. It lacks parameter explanations, usage context, and sufficient behavioral details (e.g., authentication needs, error handling), making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description adds no information about parameters—it doesn't explain what 'project_id', 'snapshot_id', 'server_url', 'username', or 'password' are for, their formats, or relationships. This fails to compensate for the schema gap.
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 'Delete a snapshot permanently' clearly states the action (delete) and resource (snapshot), with 'permanently' adding specificity about the nature of the deletion. It distinguishes from sibling tools like 'gns3_restore_snapshot' and 'gns3_create_snapshot' by focusing on removal rather than creation or restoration.
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 doesn't mention prerequisites (e.g., needing an existing snapshot), exclusions (e.g., not for deleting projects), or comparisons to related tools like 'gns3_delete_project' or 'gns3_restore_snapshot'.
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 full burden but offers minimal behavioral insight. 'Open... for editing' implies a write operation that may lock the project or require specific permissions, but these details aren't disclosed. No information about side effects, authentication needs, or error conditions is included.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a straightforward operation and front-loads the essential information.
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 4 parameters with 0% schema coverage, no annotations, and an output schema (which helps but isn't described), the description is inadequate. It doesn't explain parameter meanings, behavioral implications, or usage context, leaving significant gaps for a tool that likely modifies project state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any parameters. It doesn't explain what 'project_id' represents, when 'server_url' differs from default, or why 'username'/'password' might be needed. The description fails to compensate for the complete lack of schema documentation.
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 ('Open') and resource ('an existing GNS3 project') with the purpose 'for editing'. It distinguishes from siblings like 'gns3_get_project' (read-only) and 'gns3_create_project' (new creation), but doesn't explicitly mention these distinctions in the description text itself.
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 doesn't mention prerequisites (e.g., project must exist), when not to use it, or how it differs from related tools like 'gns3_get_project' or 'gns3_update_project'.
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 full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires authentication, potential side effects (e.g., temporary disruption), rate limits, or what the output contains. For a mutation tool (reload implies state change), this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and front-loaded with the core action. Every word earns its place, with no wasted text, making it easy to parse quickly.
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 complexity (a mutation tool with 5 parameters, 0% schema coverage, and no annotations), the description is incomplete. While an output schema exists (which helps), the description lacks crucial context about authentication needs, error conditions, and parameter meanings, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description provides no information about parameters beyond what's implied by the tool name (node). It doesn't explain what 'project_id', 'node_id', 'server_url', 'username', or 'password' mean or how to use them, failing to compensate for the schema gap.
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 ('reload a node') and clarifies what reload means ('restart without stopping'), which distinguishes it from stop/start operations. However, it doesn't explicitly differentiate from siblings like 'gns3_start_node' or 'gns3_restart_node' (if such exists), though the clarification about 'without stopping' helps.
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 like 'gns3_start_node', 'gns3_stop_node', or 'gns3_restart_node' (if applicable). The description only explains what the tool does, not when it's appropriate compared to other node control tools in the sibling list.
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 mentions the tool's purpose but lacks critical behavioral details: it doesn't specify if this is a mutation (likely yes, given 'Add'), what permissions are needed, if it's idempotent, or how it interacts with the GNS3 server. The description adds minimal value beyond the basic action.
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 short sentences, front-loaded with the core action. Every word contributes to the purpose, with no wasted text, making it efficient and easy to parse.
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 high complexity (8 parameters, 0% schema coverage, no annotations) and an output schema (which helps), the description is incomplete. It lacks behavioral context for a mutation tool, parameter explanations, and integration details with the GNS3 ecosystem, leaving significant gaps for an agent to understand full usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 8 parameters. It only implies 'text' and 'topology' (via 'project_id'), but doesn't explain parameters like x, y, rotation, server_url, username, or password. The description adds little meaning beyond what the schema names suggest, failing to address the coverage gap.
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 ('Add text annotation') and target ('to the topology'), with a specific purpose ('documenting networks and adding labels'). It distinguishes from siblings like gns3_add_shape by specifying text annotations, but doesn't explicitly contrast with all similar tools.
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 minimal guidance with 'Useful for documenting networks and adding labels,' which gives some context but lacks explicit when-to-use rules, prerequisites, or alternatives among siblings like gns3_add_shape. No exclusions or detailed usage scenarios are provided.
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 of behavioral disclosure. It mentions that 'All nodes will be stopped,' which implies a destructive effect, but doesn't clarify if this is reversible, what permissions are needed, or if there are side effects like saving changes. This is inadequate for a mutation tool with zero annotation coverage.
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 short sentences that directly state the action and a key behavioral consequence. It is front-loaded and wastes no words, making it easy to parse quickly.
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's complexity (a mutation with 4 parameters) and the absence of annotations, the description is incomplete. It lacks details on parameters, usage context, and behavioral nuances, though the presence of an output schema mitigates the need to explain return values. This is insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no information about the four parameters (project_id, server_url, username, password), such as their purposes, formats, or authentication requirements, leaving them entirely unexplained.
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 ('Close an open project') and specifies the resource ('project'), which distinguishes it from sibling tools like 'gns3_delete_project' or 'gns3_open_project'. However, it doesn't explicitly differentiate from 'gns3_stop_all_nodes' in terms of scope, as both involve stopping nodes.
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 like 'gns3_delete_project' (which removes the project) or 'gns3_stop_all_nodes' (which stops nodes without closing the project). It also lacks prerequisites, such as requiring the project to be open first.
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 states 'Delete' which implies a destructive mutation, but doesn't disclose behavioral traits such as whether deletion is permanent, requires specific permissions, affects connected nodes, or has side effects. This leaves significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information.
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 complexity (destructive operation with 5 parameters, 0% schema coverage, no annotations, but with an output schema), the description is incomplete. It lacks crucial details about behavior, parameter meanings, and usage context. The output schema may cover return values, but the description doesn't address mutation risks or operational guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description adds no information about parameters beyond what's implied by the tool name (e.g., 'link_id' is needed). It doesn't explain what 'project_id' or 'link_id' represent, or the purpose of authentication fields like 'username' and 'password'.
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 ('Delete') and resource ('a link between nodes'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'gns3_delete_node' or 'gns3_list_links', but the verb 'Delete' versus 'List' provides some implicit distinction.
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 doesn't mention prerequisites (e.g., needing an existing link), exclusions, or comparisons to sibling tools like 'gns3_list_links' for checking links first or 'gns3_delete_node' which might affect links.
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 of behavioral disclosure. It mentions that 'All links connected to this node will also be deleted,' which adds useful context about side effects. However, it doesn't cover other critical behaviors like whether deletion is reversible, authentication requirements, or error handling, leaving significant gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that are front-loaded and waste no words. Every sentence adds value by stating the core action and a key side effect, making it efficient and well-structured.
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's complexity as a destructive operation with no annotations, 0% schema coverage, and 5 parameters, the description is incomplete. It lacks details on authentication, error scenarios, output format (though an output schema exists), and differentiation from siblings, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters are documented in the schema. The description adds no information about parameters like 'project_id' or 'node_id,' failing to compensate for the lack of schema documentation. This leaves parameters largely unexplained.
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 ('Delete') and resource ('a node from the project'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'gns3_delete_link' or 'gns3_delete_project', which also perform deletion operations on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like 'gns3_delete_link' or 'gns3_delete_project', nor does it mention any prerequisites or context for deletion. It lacks explicit usage instructions or exclusions.
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 of behavioral disclosure. It states the tool returns 'complete project configuration and statistics,' which hints at read-only behavior, but doesn't explicitly confirm it's non-destructive or detail authentication needs, rate limits, or error handling. For a tool with server_url, username, and password parameters, this lack of context is a significant gap.
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 and front-loaded, with two sentences that directly state the tool's purpose and return value. There's no wasted language, but it could be more structured by explicitly separating purpose from behavioral details. It efficiently conveys core information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, but with an output schema), the description is minimally adequate. The output schema likely covers return values, reducing the need for description details. However, it lacks context on authentication, server interaction, and sibling differentiation, making it incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about parameters beyond implying 'project_id' is needed for a specific project. It doesn't explain the purpose of server_url, username, or password, leaving their semantics undocumented. With 4 parameters and low coverage, the description fails to compensate adequately.
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's purpose: 'Get detailed information about a specific project.' It specifies the verb ('Get') and resource ('project'), and distinguishes it from sibling tools like 'gns3_list_projects' by focusing on a single project. However, it doesn't explicitly differentiate from 'gns3_get_node' or 'gns3_get_topology' which also retrieve information, so it's not fully specific about what makes this tool unique.
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 doesn't mention prerequisites like needing an existing project ID, nor does it compare it to siblings like 'gns3_list_projects' for listing all projects or 'gns3_get_node' for node details. The agent must infer usage from the tool name and parameters alone.
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 mentions the tool lists projects 'with detailed status' and shows specific fields (name, ID, counts, status), but does not disclose behavioral traits such as authentication requirements (implied by username/password parameters), rate limits, pagination, or error handling. This is inadequate for a tool with authentication parameters.
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 and front-loaded, with two concise sentences. The first sentence states the core purpose, and the second elaborates on output details, with no 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?
Given the tool's moderate complexity (list operation with authentication parameters), no annotations, and an output schema (which handles return values), the description is partially complete. It explains what the tool does and output fields but lacks crucial context like parameter semantics and behavioral transparency, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the three parameters (server_url, username, password), failing to explain their purposes, formats, or authentication implications. The description focuses on output details instead, leaving parameters undocumented.
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's purpose: 'List all projects on the GNS3 server with detailed status.' It specifies the verb ('List'), resource ('projects'), and scope ('all'), but does not explicitly differentiate from sibling tools like 'gns3_get_project' (which retrieves a single project) or 'gns3_get_topology' (which may provide different structural details).
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. The description does not mention sibling tools like 'gns3_get_project' for single-project details or 'gns3_get_topology' for topology-specific data, leaving the agent without context for tool selection.
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 of behavioral disclosure. While it states the action ('Start packet capture'), it lacks critical behavioral details: it doesn't mention that this is a write/mutation operation (starting capture implies changing state), doesn't specify required permissions or authentication (though some parameters suggest auth needs), and omits details like rate limits, side effects, or what happens if capture is already running. The description adds some context (e.g., file naming and data link type), but overall behavioral transparency is inadequate for a tool with no 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 concise and well-structured: it starts with the core purpose, adds a helpful note about Wireshark analysis, and lists key parameters with brief explanations. There's no wasted text, and it's front-loaded with the main action. However, the parameter explanations are minimal and could be more integrated, slightly affecting structure.
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 complexity (7 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic action and some parameters but lacks comprehensive guidance. The presence of an output schema means the description doesn't need to explain return values, but it still falls short in addressing behavioral aspects and parameter semantics, making it adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only covers 2 out of 7 parameters ('capture_file_name' and 'data_link_type'), providing basic semantics like file naming conventions and default values. However, it misses critical parameters like 'project_id', 'link_id', 'server_url', 'username', and 'password', leaving their purpose and usage unclear. The description adds some value but fails to adequately compensate for the low schema coverage.
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's purpose: 'Start packet capture on a link.' It specifies the verb ('Start') and resource ('packet capture on a link'), which is specific and actionable. However, it doesn't explicitly differentiate from sibling tools like 'gns3_stop_capture' beyond the obvious start/stop distinction, missing an opportunity for clearer sibling differentiation.
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 minimal usage guidance. It mentions that captured packets can be analyzed with Wireshark, which hints at the tool's purpose, but offers no explicit guidance on when to use this tool versus alternatives (e.g., compared to other capture-related tools or network monitoring methods). There's no mention of prerequisites, context, or exclusions, leaving the agent with little direction.
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. 'Stop all nodes' implies a destructive/mutative operation, but the description doesn't disclose behavioral traits like whether this requires authentication, what happens to running processes, if it's reversible, rate limits, or error conditions. It only states the basic action without context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple action and front-loads the core purpose immediately.
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 complexity (destructive operation with 4 parameters), no annotations, 0% schema coverage, but with an output schema (which might help), the description is incomplete. It lacks essential context about authentication needs, project state requirements, behavioral effects, and parameter meanings, making it insufficient for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but doesn't mention any parameters. It doesn't explain what 'project_id' refers to, that 'server_url' defaults to localhost, or that 'username'/'password' are optional for authentication. With 4 parameters completely undocumented in both schema and description, this is inadequate.
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 ('Stop all nodes') and the target resource ('in a project'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'gns3_stop_node' (which stops individual nodes) or 'gns3_suspend_node' (which might have different behavior).
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. The description doesn't mention prerequisites (e.g., project must be open), exclusions (e.g., cannot stop suspended nodes), or when to prefer this over stopping nodes individually with 'gns3_stop_node'.
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 of behavioral disclosure. It states the action but doesn't explain what stopping a capture entails—e.g., whether it saves data, requires specific permissions, or has side effects like freeing resources. This leaves significant gaps for an agent to understand the tool's 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 a single, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficiently conveys the core action, making it easy to parse and understand quickly.
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's complexity (involving network captures and multiple parameters) and the lack of annotations, the description is insufficient. It doesn't address behavioral aspects, parameter meanings, or usage context, and while an output schema exists, the description doesn't provide enough information for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters, but it adds no information beyond the action. Parameters like 'project_id', 'link_id', and authentication fields ('username', 'password') are undocumented, leaving their purposes unclear to the agent.
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 ('Stop packet capture') and the target ('on a link'), which is specific and unambiguous. It distinguishes itself from siblings like 'gns3_start_capture' by indicating the opposite operation, though it doesn't explicitly mention this distinction in the text.
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 when a capture is already running or what happens if invoked incorrectly. It lacks context about prerequisites or related tools like 'gns3_start_capture' for initiating captures.
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 full burden for behavioral disclosure. It states the tool creates a link but doesn't mention whether this is a mutating operation (likely yes), what permissions are needed, whether links can be modified after creation, or what happens on failure (e.g., if nodes don't exist). The description adds minimal behavioral context beyond the basic action.
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 concise with two sentences: one stating the purpose and another listing key parameters. The structure is front-loaded with the main action. However, the parameter listing uses a comma-separated format that could be slightly clearer, and it doesn't group related parameters effectively.
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 complexity (10 parameters, 3 required, 0% schema coverage, no annotations, but with output schema), the description is moderately complete. It covers the core action and some parameters but misses many others and behavioral aspects. The presence of an output schema helps, but the description should do more to compensate for the lack of annotations and poor schema documentation.
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 explains 4 parameters (node_a_id, node_b_id, adapter_a, port_a, adapter_b, port_b) with basic semantics, but ignores 6 others (project_id, server_url, username, password, and defaults for adapter/port parameters). The description adds value for some parameters but leaves most undocumented, resulting in partial compensation.
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 ('Create a link') and resource ('between two nodes'), which is specific and unambiguous. It distinguishes itself from sibling tools like 'gns3_delete_link' by being a creation operation rather than deletion. However, it doesn't explicitly differentiate from other connection-related tools that might exist in the broader context.
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. There's no mention of prerequisites (e.g., nodes must exist), constraints (e.g., cannot link a node to itself), or comparison to sibling tools like 'gns3_list_links' for checking existing links. The agent must infer usage from the tool name alone.
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 of behavioral disclosure. While 'configure' implies a write/mutation operation, the description lacks critical behavioral details: it doesn't specify whether this requires authentication (though parameters suggest it might), what happens on failure (e.g., partial execution), whether configurations are applied immediately or saved, or any rate limits. The optional 'save_config' parameter hints at persistence behavior, but this isn't explained in the description text itself.
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 and front-loaded: the first sentence clearly states the purpose, followed by a structured 'Args:' section. However, the 'Args:' formatting is slightly verbose for a tool description (it mimics code documentation), and the second sentence could be more integrated. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation, no annotations) and the presence of an output schema (which relieves the description from explaining return values), the description is moderately complete. It covers the core operation and key parameter details but misses authentication context, error handling, and sibling tool differentiation. For a bulk configuration tool in a network simulation context, more guidance on usage and behavior would be beneficial.
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 partially documents the 'configurations' parameter by listing its keys ('node_id', 'commands', 'save_config'), which adds value beyond the schema's generic object type. However, it omits the other four parameters ('project_id', 'server_url', 'username', 'password'), leaving them undocumented. Since it covers only 1 of 5 parameters in detail, the compensation is incomplete, warranting a baseline score.
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's purpose: 'Configure multiple nodes in one operation.' This specifies the verb ('configure'), resource ('nodes'), and scope ('multiple...in one operation'). However, it doesn't explicitly differentiate from sibling tools like 'gns3_update_node' (singular) or 'gns3_send_console_commands' (which might also configure nodes), so it doesn't reach the highest clarity level.
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 doesn't mention when bulk configuration is preferred over individual node updates, nor does it reference sibling tools like 'gns3_update_node' or 'gns3_send_console_commands' that might serve similar purposes. The only implied usage is for configuring multiple nodes simultaneously, but this is already covered in the purpose statement.
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 full burden but offers limited behavioral insight. It states the duplicate will have 'the same configuration' and be placed at an offset, but doesn't disclose whether this is a destructive operation, what permissions are needed, whether the original node remains unchanged, or what happens to node connections/links. For a mutation tool with zero annotation coverage, this is insufficient.
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 - just two sentences with zero wasted words. It's front-loaded with the core purpose and follows with placement detail. Every sentence earns its place by providing essential information about what the tool does and how positioning works.
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 7 parameters with 0% schema coverage and no annotations, but with an output schema present (which reduces need to describe return values), the description is minimally adequate. It covers the core action and placement but lacks details about authentication, project context, error conditions, or relationship to other nodes/links. For a node duplication operation in a network simulation context, more guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal parameter context. It mentions 'specified offset' which relates to 'x' and 'y' parameters, but doesn't explain the 7 parameters overall. Critical parameters like 'project_id' and 'node_id' (the two required ones) get no explanation, nor do authentication parameters ('username', 'password') or 'server_url'. The description doesn't adequately compensate for the schema gap.
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's purpose: 'Duplicate a node with the same configuration' - this is a specific verb (duplicate) and resource (node). It distinguishes from siblings like 'gns3_add_node' (create new) and 'gns3_update_node' (modify existing), but doesn't explicitly contrast with 'gns3_duplicate_project' which duplicates entire projects.
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 minimal guidance: 'The duplicate will be placed at the specified offset from the original' implies usage for spatial positioning. However, it doesn't explain when to use this vs. alternatives like 'gns3_add_node' for creating new nodes from scratch, or 'gns3_duplicate_project' for broader duplication. No prerequisites or exclusions are mentioned.
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 mentions the return content ('complete node configuration including ports and properties'), which adds some behavioral context. However, it lacks details on authentication needs (username/password parameters), error handling, or rate limits. For a tool with 5 parameters and no annotations, this is insufficient.
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 appropriately sized with two sentences that are front-loaded and waste-free. The first sentence states the purpose, and the second adds key behavioral detail about the return value. Every sentence earns its place.
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 5 parameters with 0% schema coverage and no annotations, but with an output schema present, the description is moderately complete. It explains what the tool does and what it returns, but fails to clarify parameter usage or behavioral nuances. The output schema reduces the need to detail return values, but gaps remain in parameter and behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain any parameters—what 'project_id' or 'node_id' represent, or why 'server_url', 'username', and 'password' are needed. The description adds no meaning beyond the schema, failing to address the coverage gap.
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's purpose: 'Get detailed information about a specific node' with the verb 'Get' and resource 'node'. It distinguishes from siblings like 'gns3_list_nodes' (which lists multiple nodes) and 'gns3_get_node_config' (which might focus on configuration only). However, it doesn't explicitly contrast with all siblings, so it's not a perfect 5.
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 doesn't mention when to choose this over 'gns3_get_node_config' or 'gns3_list_nodes', nor does it specify prerequisites like needing an existing node. Usage is implied by the name but not explicitly stated.
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 of behavioral disclosure. It states the tool is a read operation ('Get') and returns data in 'one call', but lacks details on authentication needs (despite username/password parameters), rate limits, error handling, or whether it's idempotent. This is insufficient for a tool with authentication parameters.
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 appropriately sized and front-loaded: the first sentence states the core purpose, and the second adds useful scope clarification. Both sentences earn their place with no wasted words, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, authentication, no annotations) and the presence of an output schema (which handles return values), the description is partially complete. It covers the high-level purpose but lacks crucial details like parameter explanations and behavioral context, leaving gaps for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'project' but doesn't explain the four parameters (project_id, server_url, username, password) or their roles. The description adds no meaning beyond what the bare schema provides, failing to address authentication semantics or server connectivity.
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's purpose: 'Get complete network topology for a project' specifies the verb ('Get') and resource ('network topology'), and 'Returns all nodes, links, and project information in one call' elaborates on scope. It distinguishes from siblings like gns3_get_node or gns3_list_nodes by emphasizing 'complete' topology, but doesn't explicitly contrast them.
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 is provided. The description implies it's for retrieving comprehensive topology data, but it doesn't mention when to choose this over more specific tools like gns3_get_project or gns3_list_nodes, nor does it state prerequisites or exclusions.
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 mentions that appliances are 'pre-configured device definitions that can be installed,' hinting at read-only behavior for listing, but doesn't disclose critical traits like authentication requirements (implied by username/password parameters), rate limits, or what the output contains. For a tool with no annotations, this 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 appropriately sized with two concise sentences that are front-loaded: the first states the action, and the second clarifies the resource. There is zero wasted text, making it efficient 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?
Given the tool's low complexity (a list operation) and the presence of an output schema (which handles return values), the description is somewhat complete for basic understanding. However, with no annotations, 0% schema coverage, and three parameters, it lacks details on authentication, server interaction, and parameter usage, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the three parameters (server_url, username, password), such as their purposes, formats, or defaults. It fails to compensate for the low coverage, leaving parameters semantically undefined.
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 resource ('all available appliances'), providing a specific action. It distinguishes from siblings like 'gns3_list_templates' or 'gns3_list_nodes' by focusing on appliances, though it doesn't explicitly contrast them. The explanation of appliances as 'pre-configured device definitions that can be installed' adds useful context.
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. It doesn't mention prerequisites like server connectivity, authentication needs, or how it differs from other list tools (e.g., 'gns3_list_templates' for templates vs. appliances). The description implies usage for retrieving appliance data but lacks explicit context or exclusions.
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 mentions the tool lists compute servers and shows specific fields (ID, name, protocol, host, port, status), which is helpful. However, it doesn't disclose behavioral traits like whether this is a read-only operation, potential authentication requirements (implied by username/password parameters but not explained), rate limits, or error conditions. The description adds some value but leaves significant gaps for a tool with authentication parameters.
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 just two sentences that directly state the tool's purpose and output format. Every word earns its place, and the information is front-loaded with no unnecessary verbiage or redundancy.
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 that there's an output schema (which should document return values), the description doesn't need to explain return details. However, for a tool with 3 parameters (including authentication-related ones) and 0% schema coverage, the description should provide more context about parameter usage and behavioral expectations. The description covers the basic purpose but leaves important gaps around parameters and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description mentions no parameters at all, failing to explain the three input parameters (server_url, username, password) that appear in the schema. This leaves the agent guessing about authentication requirements and server configuration, which is inadequate given the low schema coverage.
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 ('List all available compute servers') and specifies the resource type ('compute servers'), including examples of what types are included ('local, VMs, remote'). It distinguishes from siblings like 'gns3_list_nodes' or 'gns3_list_projects' by focusing specifically on compute servers, but doesn't explicitly contrast with these alternatives.
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 like 'gns3_get_server_info' or other list tools. It mentions what the tool does but offers no context about prerequisites, timing, or comparison with sibling tools that might provide overlapping or complementary functionality.
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 of behavioral disclosure. While it mentions what information is shown, it doesn't describe critical behaviors like whether this is a read-only operation (implied by 'List' but not explicit), authentication requirements (though parameters suggest optional credentials), potential rate limits, or how the data is formatted/returned. The description adds minimal behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured—two short sentences that efficiently convey the core functionality. Every word earns its place with no redundancy or fluff. It's front-loaded with the main purpose and follows up with specific details about what's shown.
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 that there's an output schema (which should document return values) and no annotations, the description provides basic but incomplete context. For a listing tool with 4 parameters (including authentication-related ones), the description should ideally mention the required project context and optional authentication, but it doesn't. The presence of an output schema helps, but the description leaves too many usage questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description doesn't mention any parameters at all—it doesn't explain what 'project_id' refers to, why 'server_url' has a default, or when 'username' and 'password' are needed. With 4 parameters (1 required) completely undocumented in both schema and description, this is a significant gap in parameter semantics.
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's purpose with a specific verb ('List') and resource ('all links (connections) in a project'), and specifies what information is shown ('link endpoints, ports, and status'). However, it doesn't explicitly differentiate from sibling tools like 'gns3_get_topology' or 'gns3_list_nodes', which might also provide link information in different contexts.
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. With siblings like 'gns3_get_topology' (which might include link data) and 'gns3_list_nodes' (which could relate to link endpoints), there's no indication of when this specific listing tool is preferred or what distinguishes it from other listing or retrieval tools in the GNS3 ecosystem.
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 of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention authentication needs (username/password parameters), rate limits, pagination, or what the output contains. For a tool with 4 parameters including auth fields, this is insufficient.
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, clear sentence with no wasted words. It's front-loaded with the core action and resource, making it highly efficient 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?
Given the tool has an output schema (which handles return values), no annotations, and 4 parameters with 0% schema coverage, the description is incomplete. It adequately states the basic purpose but lacks parameter explanations, usage context, and behavioral details needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only mentions 'project' implicitly via 'for a project', but doesn't clarify the required 'project_id' parameter or optional 'server_url', 'username', and 'password' parameters. This leaves most parameters undocumented.
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 ('List all snapshots') and resource ('for a project'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'gns3_get_project' or 'gns3_list_projects' which also list project-related information, so it doesn't reach the highest score.
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 doesn't mention prerequisites like needing an open project or compare it to other snapshot-related tools like 'gns3_create_snapshot' or 'gns3_restore_snapshot', leaving the agent with no 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?
No annotations are provided, so the description carries full burden. It states the action ('List') but doesn't disclose behavioral traits like authentication needs (implied by username/password params), rate limits, pagination, or what the output contains. The description is minimal and lacks operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two concise sentences. It's front-loaded with the core purpose and adds a brief explanatory note. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a list operation) and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks details on authentication, server interaction, and parameter semantics, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the 3 parameters (server_url, username, password), their purposes, or how they affect the listing. The description fails to explain parameter relevance or usage.
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 resource ('all available device templates'), and explains what templates are used for. However, it doesn't differentiate from sibling list tools like 'gns3_list_appliances' or 'gns3_list_nodes' beyond the resource type.
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 versus alternatives is provided. The description mentions templates are 'used to create new nodes quickly,' which hints at a workflow but doesn't specify prerequisites, timing, or contrast with other listing tools.
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 of behavioral disclosure. It states the action ('Start all nodes') but doesn't describe what 'start' entails (e.g., powering on virtual devices), potential side effects, authentication needs (implied by username/password params but not explained), error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, clear sentence with zero wasted words. It's appropriately sized for the tool's apparent simplicity and front-loaded with the core action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values) but no annotations and 4 parameters with 0% schema coverage, the description is incomplete. It covers the basic purpose but lacks parameter explanations, behavioral details, and usage context. For a mutation tool that likely affects system state, this leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'project' but doesn't clarify what 'project_id' represents or how to obtain it. It doesn't address 'server_url', 'username', or 'password' at all, leaving all 4 parameters with minimal semantic context beyond their names in the schema.
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 ('Start all nodes') and resource ('in a project'), providing a specific verb+resource combination. It distinguishes from sibling tools like 'gns3_start_node' (singular) and 'gns3_stop_all_nodes' (opposite action), though it doesn't explicitly mention these distinctions in the text.
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 doesn't mention prerequisites (e.g., project must be open), when-not-to-use scenarios, or comparisons to sibling tools like 'gns3_start_node' for individual nodes or 'gns3_stop_all_nodes' for stopping.
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 full burden but offers minimal behavioral insight. It mentions what the tool checks but doesn't disclose whether it's read-only or has side effects, authentication requirements (though parameters suggest optional auth), rate limits, or what happens during validation (e.g., if it modifies the topology). The description is functional but lacks critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: two sentences that directly state the purpose and specific checks. Every word earns its place with zero redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation with 4 parameters), no annotations, and an output schema (which handles return values), the description is minimally complete. It covers the core purpose but lacks parameter semantics, usage context, and behavioral details. The output schema mitigates some gaps, but overall it's adequate with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'project_id' refers to, when 'server_url' should be changed from default, or how 'username' and 'password' affect validation (e.g., for authenticated servers). With 4 parameters (1 required) and no schema descriptions, this is a significant gap.
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's purpose: 'Validate network topology for common issues' with specific examples ('disconnected nodes, missing links, and configuration problems'). It uses a specific verb ('validate') and resource ('network topology'), but doesn't explicitly differentiate from sibling tools like gns3_get_topology or gns3_list_nodes that might provide related information.
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 doesn't mention prerequisites (e.g., needing an existing project), compare it to sibling tools like gns3_get_topology (which retrieves topology data) or gns3_list_nodes (which lists nodes), or specify when validation is appropriate (e.g., after topology changes).
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 full burden but only mentions the console method and config_type options. It lacks critical behavioral details: authentication requirements (username/password parameters), whether this is read-only or has side effects, rate limits, or what the output contains. The description doesn't contradict annotations, but is insufficient for a mutation-sensitive context.
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 brief and front-loaded with the core purpose, followed by a parameter note. However, the Args section could be integrated more smoothly, and the single-sentence structure is efficient but leaves gaps in completeness.
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 6 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is moderately complete. It covers the tool's purpose and one parameter, but misses authentication details, server interaction context, and doesn't leverage the output schema to explain return values. For a configuration retrieval tool, this is minimal but not entirely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but only explains 'config_type' (with enum values). It ignores the other 5 parameters (project_id, node_id, server_url, username, password), leaving their purposes and formats undocumented. This partial coverage fails to address the majority of input semantics.
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 ('Get device configuration') and method ('via console'), which is specific and distinguishes it from other configuration-related tools like 'gns3_apply_config_template' or 'gns3_bulk_configure_nodes'. However, it doesn't explicitly differentiate from 'gns3_get_node', which might retrieve node metadata rather than configuration.
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 configuration from Cisco-style devices, but doesn't specify when to use this tool versus alternatives like 'gns3_send_console_commands' for manual configuration access or other getters. No explicit 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.
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 of behavioral disclosure. It states the tool creates a project but doesn't mention whether this requires authentication, what happens on success/failure, if it's idempotent, or any side effects like file system changes. The description lacks critical behavioral context for a creation operation in a network simulation environment.
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 purpose statement followed by a parameter list. Each parameter explanation is brief and to the point. The only minor inefficiency is the omission of the three authentication-related parameters, but otherwise it's appropriately sized and front-loaded with the main 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?
For a creation tool with 8 parameters, 0% schema description coverage, no annotations, but with an output schema, the description does an adequate job. It explains the core parameters well but misses authentication details. The presence of an output schema means return values are documented elsewhere, reducing the burden on the description. However, the lack of behavioral context for a creation operation is a notable gap.
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 provides a helpful parameter list with brief explanations for 5 parameters (name, auto_close, auto_open, auto_start, path), which adds significant value beyond the schema's 0% description coverage. However, it omits 3 other parameters from the schema (server_url, username, password), leaving authentication and connection details undocumented. The provided explanations are clear but incomplete.
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 ('Create a new GNS3 project') with the specific resource ('GNS3 project'), making the purpose immediately understandable. It distinguishes itself from siblings like 'gns3_duplicate_project' or 'gns3_update_project' by focusing on creation rather than modification or duplication. However, it doesn't explicitly contrast with these alternatives in the description text itself.
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 like 'gns3_duplicate_project' or 'gns3_update_project'. There's no mention of prerequisites, such as server connectivity or authentication requirements, nor any context about when creation is appropriate versus other project operations. The agent must infer usage from the tool name alone.
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 describes a read-only listing operation ('List all nodes'), which implies non-destructive behavior, but doesn't disclose authentication needs (e.g., username/password parameters), rate limits, pagination, or error handling. For a tool with authentication parameters, this leaves significant behavioral gaps, though it's not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource, followed by details on returned fields. Every word contributes meaning without redundancy, making it efficiently structured and easy to parse. No wasted verbiage or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing operation with authentication parameters), no annotations, and an output schema (which handles return values), the description is partially complete. It covers the purpose and output fields but lacks guidance on usage, parameter details, and behavioral aspects like authentication. This leaves gaps for an AI agent to infer correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'in a project', which hints at the 'project_id' parameter, but doesn't explain the other three parameters (server_url, username, password) or their purposes. With 4 parameters total and only one implicitly addressed, the description adds minimal semantic value beyond the bare schema.
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 ('List all nodes') and resource ('in a project'), specifying what information is returned ('Shows node name, type, status, console port, and position'). It distinguishes from siblings like 'gns3_get_node' (singular) and 'gns3_get_topology' (broader scope), but doesn't explicitly name alternatives. This makes the purpose specific and actionable, though not maximally differentiated.
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 context by specifying 'in a project', suggesting it's for retrieving device lists within a specific project. However, it provides no explicit guidance on when to use this versus alternatives like 'gns3_get_topology' or 'gns3_list_projects', nor does it mention prerequisites or exclusions. The context is clear but lacks comparative or conditional advice.
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 full burden but offers minimal behavioral insight. It mentions Telnet as the protocol and hints at device-specific behaviors (e.g., 'Cisco' for config mode), but lacks critical details like error handling, command execution order, timeout behaviors beyond boot, or whether this is a read-only or mutating operation. For an 11-parameter tool with no annotations, this is insufficient.
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 followed by a bullet-point Args section, making it easy to scan. It's appropriately sized for an 11-parameter tool, though the Args section could be more complete to cover all parameters without adding unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no annotations, 0% schema coverage, but with an output schema), the description is partially adequate. The Args section helps, but it doesn't fully compensate for the lack of annotations and incomplete parameter coverage. The output schema existence reduces the need to describe return values, but behavioral and usage gaps remain.
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 provides a helpful Args section explaining 6 parameters (commands, wait_for_boot, boot_timeout, enter_config_mode, save_config, enable_password), which adds significant value beyond the schema's 0% description coverage. However, it omits explanations for the other 5 parameters (project_id, node_id, server_url, username, password), leaving gaps in understanding their roles and requirements.
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 ('Send commands') and target ('to a node's console via Telnet'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'gns3_apply_config_template' or 'gns3_bulk_configure_nodes' which might also involve sending commands, leaving some ambiguity about when this specific tool is preferred.
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 doesn't mention prerequisites like needing a running node or compare it to sibling tools like 'gns3_apply_config_template' for configuration tasks, leaving the agent to guess based on 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 of behavioral disclosure. It mentions that suspension 'pauses execution' and 'saves state', which hints at a non-destructive pause, but fails to detail critical aspects like permissions required, whether the node must be running first, error conditions, or what the saved state entails. This leaves significant gaps 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 a single, efficient sentence that front-loads the core action and adds clarifying detail in parentheses. Every word serves a purpose with zero waste, making it highly concise and well-structured.
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 that there's an output schema (which handles return values), no annotations, and a moderate parameter count, the description is minimally adequate. It covers the basic action but lacks details on behavior, usage context, and parameter meanings, leaving room for improvement in 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, but it adds no parameter information beyond what the schema names imply. The description doesn't explain what 'project_id' or 'node_id' refer to, or the purpose of authentication fields. However, with 5 parameters and 2 required, the baseline is 3 as the schema provides structure without descriptions.
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 ('suspend a node') and specifies what suspension entails ('pause execution, save state'), providing a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools like 'gns3_stop_node' or 'gns3_reload_node', which prevents a perfect score.
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 such as 'gns3_stop_node' or 'gns3_reload_node'. The description lacks context about prerequisites, timing, or exclusions, offering only basic functional information.
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 full burden but offers minimal behavioral context. It states 'Update' implies mutation but doesn't disclose permission requirements, whether changes are reversible, error conditions, or what happens to unspecified properties. The description doesn't contradict annotations (none exist), but fails to provide needed behavioral transparency.
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 a clear purpose statement followed by parameter explanations. Every sentence adds value, though the parameter section could be more complete. The formatting with 'Args:' section helps readability.
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?
For a mutation tool with 9 parameters, 0% schema coverage, no annotations, but with an output schema, the description is moderately complete. It explains some parameters and the basic purpose, but lacks behavioral context, usage guidelines, and coverage of all parameters. The output schema reduces the need to describe return values, but significant gaps remain.
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 meaningful context for 4 parameters (name, x, y, properties) that have 0% schema description coverage, explaining what they control. However, it omits the other 5 parameters (project_id, node_id, server_url, username, password) which are critical for operation. Given the low schema coverage (0%), the description partially compensates but leaves significant gaps.
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 ('Update') and resource ('node settings and properties'), making the purpose immediately understandable. It distinguishes from siblings like 'gns3_get_node' (read) and 'gns3_add_node' (create), though it doesn't explicitly mention these alternatives in the description itself.
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. There's no mention of prerequisites (e.g., needing an existing node), when not to use it, or how it differs from similar tools like 'gns3_duplicate_node' or 'gns3_reload_node'.
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 states the tool adds a node, implying a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it's idempotent, error handling, or what happens on success/failure. The mention of default values for some parameters adds minimal context but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a structured Args section. It's efficient with minimal waste, though the Args formatting is slightly verbose. Every sentence earns its place by providing necessary parameter details.
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 9 parameters with 0% schema coverage and no annotations, the description partially compensates by documenting 6 parameters and implying a write operation. An output schema exists, so return values needn't be explained. However, for a mutation tool with many parameters, the gaps in parameter documentation and lack of behavioral context make it only minimally adequate.
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 lists 6 parameters (project_id, node_name, template_id, x, y, compute_id) with brief explanations, covering 6 out of 9 total parameters. However, it omits server_url, username, and password, leaving them undocumented. The explanations are basic (e.g., 'Name for the new node') and don't add deep semantic value beyond naming.
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 ('Add a network device/node') and target ('to a project using a template'), which is specific and distinguishes it from siblings like 'gns3_add_link' or 'gns3_add_shape'. However, it doesn't explicitly differentiate from 'gns3_duplicate_node' or 'gns3_update_node', which also involve nodes, so it's not a perfect 5.
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 mentioning 'use gns3_list_templates to get available templates', which suggests a prerequisite step. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'gns3_duplicate_node' or 'gns3_update_node', nor does it specify exclusions or edge 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?
With no annotations provided, the description carries full burden but only states the basic operation. It doesn't disclose behavioral traits like whether duplication requires specific permissions, if the original project remains unchanged, whether the new project is automatically opened, potential performance impacts for large projects, or error conditions (e.g., duplicate name conflicts).
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 perfectly concise with two sentences that directly communicate the core functionality. The first sentence states the primary action, and the second clarifies the scope of duplication. Every word earns its place with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (duplication operation with 6 parameters), no annotations, and an output schema (which handles return values), the description provides minimal but functional context. It explains what the tool does at a high level but lacks crucial details about parameters, behavioral constraints, and usage scenarios that would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 6 parameters, the description provides no parameter information beyond what's implied by the tool name. It mentions 'new name' but doesn't explain project_id format, server_url conventions, authentication requirements (username/password), or path parameter purpose. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('duplicate', 'creates exact copy') and resources ('existing project', 'all nodes and configurations'). It distinguishes itself from sibling tools like gns3_create_project (which creates new projects) and gns3_duplicate_node (which duplicates individual nodes).
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 doesn't mention prerequisites (e.g., needing an existing project), compare with gns3_create_project for new projects, or specify use cases like creating project templates or backups.
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 mentions the return content ('server version, supported features, and system information') but lacks behavioral details: no indication of authentication needs (though parameters suggest optional credentials), rate limits, error conditions, or whether it's read-only (implied by 'Get' but not explicit). For a tool with no annotations, this is a significant gap, scoring 2.
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 appropriately sized and front-loaded: two sentences with zero waste. The first sentence states the purpose, and the second clarifies the return values. Every word earns its place, making it efficient and well-structured, scoring 5.
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 low complexity (a simple read operation), 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is reasonably complete. It explains what the tool does and what it returns, and the output schema likely covers return values. However, it lacks details on authentication behavior and parameter usage, keeping it from a 5. Overall, it's adequate but not fully comprehensive.
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 adds no parameter information beyond what the schema shows (server_url, username, password). The schema itself documents defaults and types, but the description doesn't explain parameter purposes, such as when to provide credentials or server URL variations. With 3 parameters and 0% coverage, baseline is low, but the description fails to add meaningful semantics, resulting in a minimal score of 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's purpose: 'Get GNS3 server version and information' specifies the verb ('Get') and resource ('GNS3 server version and information'). It distinguishes from siblings like 'gns3_get_node' or 'gns3_get_project' by focusing on server-level metadata rather than project or node details. However, it doesn't explicitly contrast with all sibling 'get' tools, keeping it at 4 rather than 5.
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. The description doesn't mention prerequisites, timing, or comparison to other tools like 'gns3_list_computes' or 'gns3_get_topology' for server-related queries. It simply states what it does without context, scoring 2 for lack of usage direction.
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 mentions the tool's purpose and constraints (Dynamips/IOS only), but lacks details on behavioral traits like authentication needs (implied by username/password params), rate limits, error handling, or what the output contains. It adds some value but is incomplete for a tool with 6 parameters and no annotation coverage.
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 and front-loaded: the first sentence states the core purpose, and the second adds important constraints. The Args section is brief but could be more integrated. Overall, it's efficient with minimal waste, though the structure could be slightly more cohesive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, but with an output schema), the description is moderately complete. It covers the purpose and key constraint, but lacks details on parameter meanings beyond 'auto_compute', behavioral context, and doesn't leverage the output schema to explain return values. It's adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only documents one parameter ('auto_compute') in the Args section, leaving the other 5 parameters (project_id, node_id, server_url, username, password) unexplained. This partial coverage is insufficient given the low schema coverage, resulting in a score of 2.
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's purpose: 'Get idle-pc values for Dynamips routers to reduce CPU usage.' It specifies the verb ('Get'), resource ('idle-pc values'), and target ('Dynamips routers'), and distinguishes itself from siblings by focusing on CPU optimization for a specific router type. However, it doesn't explicitly differentiate from all possible siblings, keeping it at a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: 'Only works with Dynamips/IOS routers.' This gives explicit guidance on applicability, helping the agent avoid misuse on non-Dynamips routers. It doesn't mention alternatives or exclusions beyond this, so it's not a full 5.
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. The WARNING about current project state loss is a critical behavioral trait that informs the destructive nature of the operation, adding significant value beyond basic function. It doesn't cover other aspects like authentication needs or response format, but the warning is a key safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences: one stating the purpose and another providing a critical warning. Every word earns its place, and the warning is front-loaded for immediate visibility, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with 5 parameters) and no annotations, the description is incomplete. It covers the destructive behavior via the warning but lacks details on parameters, authentication, or output (though an output schema exists, reducing the need to explain return values). For a tool with significant risk, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 5 parameters. It mentions 'project' and 'snapshot' implicitly through the action, but doesn't explain what 'project_id' or 'snapshot_id' are, nor does it cover 'server_url', 'username', or 'password'. This leaves most parameter meanings unclear, failing to adequately supplement the schema.
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 'Restore' and the resource 'project from a snapshot', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'gns3_create_snapshot' or 'gns3_list_snapshots' beyond the restore action, which is why it doesn't reach a perfect score.
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 WARNING provides implicit guidance that this tool should be used cautiously due to data loss, suggesting it's for reverting to a saved state. However, it lacks explicit when-to-use rules, alternatives (e.g., vs. 'gns3_duplicate_project'), or prerequisites, leaving usage context somewhat vague.
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 full burden but lacks critical behavioral details. It doesn't disclose whether this is a read-only or mutating operation (though 'apply' suggests mutation), what permissions are needed, how errors are handled, or whether configuration changes are immediate/permanent. The save_config parameter hints at persistence behavior, but this isn't explained in the description.
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 purpose statement, bulleted template list, and parameter explanations. Every sentence adds value, though the template list is lengthy (could be summarized). It's 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with 0% schema coverage, no annotations, but an output schema exists, the description partially compensates by explaining 3 parameters and listing templates. However, it misses critical context about the other parameters, authentication needs, and mutation behavior. The output schema likely handles return values, but the description doesn't mention what success/failure looks like.
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?
With 0% schema description coverage, the description adds significant value by explaining template_name (with 12 specific examples) and template_params ('varies by template'), and clarifying save_config's purpose. However, it doesn't cover the other 5 parameters (project_id, node_id, server_url, username, password), leaving important context gaps about target selection and authentication.
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 specific action ('Apply a pre-built configuration template to a device') and distinguishes it from siblings by focusing on template-based configuration rather than direct commands or other operations. It lists 12 specific template types, making the purpose highly concrete and differentiated.
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 context through the template list (e.g., use 'ospf' for OSPF routing configuration), but doesn't explicitly state when to choose this tool over alternatives like gns3_send_console_commands or gns3_bulk_configure_nodes. 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.
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 effectively communicates the destructive nature ('permanently delete'), irreversible consequences ('cannot be undone'), and scope of impact ('all its files'). However, it doesn't mention authentication requirements, rate limits, or error conditions that might be relevant for this destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core action and scope, while the second provides critical warning information. No wasted words, and the warning is appropriately front-loaded for emphasis.
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?
For a destructive tool with no annotations, the description adequately covers the irreversible nature and scope of deletion. The presence of an output schema means return values don't need explanation. However, the complete lack of parameter information (0% schema coverage with no compensation in description) and missing behavioral details like authentication requirements create significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description provides no information about any parameters. It doesn't mention project_id (the required parameter), server_url, username, or password. The description fails to compensate for the complete lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('permanently delete'), the resource ('a project'), and the scope ('and all its files'). It distinguishes itself from sibling tools like gns3_close_project (which likely closes without deletion) and gns3_delete_snapshot (which deletes snapshots, not entire projects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (for permanent deletion) through the 'WARNING' statement, which implies it should only be used when irreversible deletion is intended. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like gns3_close_project for temporary closure.
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:

[![gns3-mcp-server MCP server](https://glama.ai/mcp/servers/Wael-Rd/gns3-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Wael-Rd/gns3-mcp-server)

Score Badge

Copy to your README.md:

[![gns3-mcp-server MCP server](https://glama.ai/mcp/servers/Wael-Rd/gns3-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Wael-Rd/gns3-mcp-server)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Wael-Rd/gns3-mcp-server'

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