GNS3 MCP Server

Server Quality Checklist

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

Latest release: v0.54.2
Disambiguation5/5
Each tool has a clearly defined purpose: ssh and console are differentiated by use case (SSH preferred, console for initial setup), and all other tools cover distinct domains (project, node, link, drawing, file management, etc.). No two tools overlap in function.
Naming Consistency4/5
Tool names generally use lowercase words with underscores for compound names (e.g., gns3_connection, project_docs, query_resource), which is consistent. However, there is no strict verb_noun pattern; many tools are single nouns (ssh, node, console, drawing). This is acceptable but not perfectly uniform.
Tool Count5/5
With 15 tools, the set is well-scoped for managing GNS3 network simulation labs. It covers project, node, link, drawing, device access (SSH/console), TFTP, HTTP client, documentation, and tool discovery without being overwhelming or too sparse.
Completeness4/5
The tool set covers most core workflows: CRUD for projects, nodes, links, drawings; device access via console and SSH; file operations on Docker nodes; documentation; topology export; and auxiliary services (TFTP, HTTP). Minor gaps like template management or snapshot operations are missing but not critical for typical lab operations.
Average 4.3/5 across 15 of 15 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It labels itself a 'query tool' implying read-only, but does not explicitly state that it is non-destructive, what the return format is, or any effects. The referral to 'tool implementation docstring' is not part of the description and does not aid transparency.
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 very short (two sentences) and front-loaded with purpose, which is good. However, the second sentence directs users to external documentation rather than providing the information directly, reducing its immediate value.
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 that no annotations exist and the tool has an output schema, the description should cover behavioral aspects and usage context. It fails to explain when to use this tool, what side effects (if any) occur, or how the output is structured. The presence of an output schema partially compensates, but the lack of usage guidance leaves it incomplete.
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 coverage is 100% for the two parameters. The description adds minimal meaning: 'uri' parameter description merely repeats the advice to see the tool description for patterns, which is not provided. 'format' parameter is adequately described in the schema. Baseline 3 is appropriate.
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 states it is a 'Universal resource query tool' for accessing 'any GNS3 MCP resource', clearly indicating the verb (query) and resource (any GNS3 MCP resource). However, it does not differentiate itself from sibling tools like 'project' or 'node', which also query specific 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?
No guidance is provided on when to use this tool versus its siblings. It simply calls itself 'universal' without specifying that it is intended for generic or unsupported resource access, or when a specific tool is unavailable.
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?
Annotations are empty, so description must disclose behaviors. It states exports to SVG/PNG but omits details like file overwrite behavior, directory creation, authentication needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loads purpose, provides alternative usage in second sentence. No extraneous words.
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?
With 6 parameters (most undocumented), no annotations, and output schema present but not described, the description is insufficient for complete understanding of cropping behavior and edge cases.
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%. Description adds meaning for format (SVG/PNG) but does not explain crop parameters or output_path requirements beyond existence.
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?
Description clearly states verb 'Export', resource 'topology diagram', target formats 'SVG/PNG', and destination 'files on disk'. Distinguishes from using diagrams:// resource for direct access.
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?
Explicitly suggests using diagrams:// resource when direct access is sufficient, indicating when not to use this tool. No mention of alternative sibling tools like 'drawing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the server runs on port 69/udp, root directory /opt/gns3-ssh-proxy/tftp, read-write access, base64 handling for content, and JSON responses. This is sufficient for safe invocation, though file size limits are not mentioned.
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 clear sections (version, details, actions, handling, examples). While slightly verbose with multiple examples, the information is organized and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and complete input schema, the description covers all actions and parameters. Examples illustrate expected responses. No critical gaps are apparent for typical usage.
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?
Input schema has 100% coverage, but the description adds value by explaining each action's parameter requirements, providing examples, and clarifying that upload content should be raw bytes (with automatic base64 encoding). This enhances understanding beyond the schema alone.
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 'Manage TFTP server files (CRUD-style)' and enumerates five specific actions (list, upload, download, delete, status). This distinguishes it from sibling tools like ssh or node, which perform unrelated functions.
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, or when not to use it. While implied by its name, explicit usage guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists actions and their outcomes (e.g., 'auto-open' for create) but does not disclose potential side effects or safety implications (e.g., whether close saves changes). This is adequate but leaves some behavioral aspects implicit.
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 sections for actions, args, returns, and examples. It is front-loaded with the summary line. Though somewhat lengthy, each part serves a purpose and is not excessively verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's CRUD nature and the presence of an output schema mention, the description covers the key functionality. It lacks some behavioral details and does not reference sibling tools, but for a tool with this complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining action-specific parameter requirements (e.g., name required for open/create) and providing examples that illustrate parameter usage in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages GNS3 projects and enumerates specific actions (list, open, create, close), making the tool's purpose specific and unambiguous. It distinguishes itself from siblings by its focus on project-level operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage through examples and arg descriptions for each action. However, it does not explicitly mention when not to use this tool or suggest alternatives among siblings, such as project_docs for documentation-related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It explains that the tool subscribes in the background, buffers events, and supports read modes (diff/all/last). However, it omits details like buffer capacity, behavior on duplicate subscription, or whether subscription persists across calls. This is adequate but leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a brief overview, a bullet list of actions, a categorized list of event types, and multiple examples. Every section earns its place, and the most critical information (core actions) is front-loaded. No redundant or vague sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (subscribe/read/unsubscribe/status with filtering) and the presence of an output schema, the description covers all necessary context: actions, parameters, event types, examples, and project vs controller scope. It leaves no obvious gaps for an AI agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds significant value by explaining each action's purpose, providing the list of event types (e.g., node.created, log.error), and giving concrete examples. This goes beyond the schema property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Subscribe to GNS3 server event notifications and read buffered events.' It specifies the verb (subscribe/read/unsubscribe/status) and the resource (GNS3 server event notifications). The tool's function is distinct from its siblings (e.g., project, node, link), which focus on direct manipulation rather than event streaming.
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 on when to use each action (subscribe, read, unsubscribe, status) with examples. It explains project-level vs controller-level subscription. However, it does not explicitly exclude scenarios or mention when not to use this tool over alternatives (e.g., fetching current state via project/node tools instead of streaming events).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses main behaviors: read (get) and write (update) operations, expected input/output format (JSON with project_id and markdown), and includes examples. However, it doesn't specify whether update overwrites or merges content, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with clear sections: purpose, version, actions, typical content, returns, and examples. Every sentence adds value without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, full schema coverage, and presence of output schema, the description covers all necessary aspects: purpose, actions, parameters, typical content, and examples. An agent can correctly invoke the tool based on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds value through examples showing exact usage and format for each parameter, such as markdown content and default project_id behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages project documentation with CRUD operations, specifically actions 'get' and 'update'. It distinguishes from sibling tools like 'project' by focusing on documentation content.
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?
Provides typical use cases and content examples, but does not explicitly compare to alternative tools or state when to avoid using it. The implicit guidance is adequate but not explicit.
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?
Warns about the destructive nature of delete and mentions two-phase validation for batch. With empty annotations, the description carries the full burden and adequately discloses key behaviors, though permissions and side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary, actions list, return info, and examples. Front-loaded with purpose and no unnecessary text.
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 26 parameters and 5 actions, the description covers all actions with examples and mentions return format. Output schema exists for detailed returns, so this is adequate. Could be more explicit about required parameters per action, but schema handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with descriptions. The description adds value through examples that demonstrate parameter combinations and usage patterns, which is beneficial for understanding.
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 'Manage drawings (CRUD operations)' and lists specific actions (list, create, update, delete, batch). This distinguishes the tool from unrelated siblings and covers all operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit actions and examples for when to use each action, making the usage context clear. However, it does not explicitly state when not to use or alternatives, though no competing tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It details the two-phase validation and atomic execution, the structure of connection operations, and return types. It does not mention potential side effects or permissions.
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-organized with sections (Actions, Connection Operations, Examples, Returns) but is somewhat verbose, including historical rename info. Most content is earned, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two actions, batch with validation) and high schema coverage plus output schema, the description covers all necessary aspects: actions, parameters, behavior (atomicity), examples, and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant value by showing exact JSON structures for connection operations (e.g., node_a, port_a) and providing examples that clarify parameter usage beyond the schema-defined descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages network connections (links) and distinguishes it from siblings by focusing solely on link operations. The historical rename context adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two actions (list and batch) and their use cases, including the atomic two-phase execution for batch. However, it does not explicitly compare to sibling tools like gns3_connection or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses destructive nature of delete, wildcard/bulk support, and return types. Examples illustrate behavior, but error handling and edge cases could be more explicit.
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 sections for actions, wildcards, validation, and examples. It is organized and front-loaded with purpose. However, it is somewhat lengthy (including version history and detailed patterns) and could be trimmed without losing value.
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 20 parameters, no annotations, and presence of an output schema, the description covers actions, constraints, returns, and examples comprehensively. It lacks explicit error handling details but is otherwise complete for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds substantial meaning: explains wildcard patterns, validation rules linking parameters to actions, and which properties apply to which node types. Examples demonstrate usage far beyond the schema's short descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the tool manages GNS3 nodes with CRUD operations. The actions list, wildcard patterns, and examples leave no ambiguity about its purpose, distinguishing it from sibling tools that manage 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit validation rules (e.g., name requires node stopped, hardware properties per node type) and action-specific details. It also includes wildcard patterns and parallel execution defaults. However, it lacks explicit comparison to sibling tools, though not critical since siblings are different resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns tool metadata, lists possible values for categories and capabilities, and provides example calls. It does not explicitly state read-only or non-destructive behavior, but the nature of a search tool implies that. The version number and return format are given, adding 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 moderately long but well-structured with headers, bullet lists, and code examples. Each section (categories, capabilities, resource mapping, examples) adds necessary detail. It is front-loaded with the main purpose and uses markdown formatting for readability. Could be slightly more concise, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (context signal: true), the description adequately covers the tool's behavior, input parameters, and return content. It includes categories, capabilities, and resource mappings, making it complete for a discovery tool. The examples illustrate typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining each parameter's purpose with example values and context, such as the list of categories and capabilities. It also shows how to use the resource_uri parameter with concrete URIs. This improves understanding beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a tool discovery function for GNS3 MCP tools, explaining that it searches and filters by category, capability, or resource URI. This distinctly sets it apart from sibling tools that manage specific entities (e.g., node, project). The title 'search_tools' and first sentence deliver a specific verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit categories, capabilities, and resource mappings, along with multiple examples showing how to filter. It does not explicitly state when not to use or alternatives, but the context is clear: use this tool to discover other tools. Given its meta-purpose, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that 'write' does not restart the node and that 'configure_network' includes restart. It also describes return types (JSON with file contents, confirmation, or configured interfaces). However, it does not detail potential side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bulleted actions, warnings, and examples. It is concise yet thorough, with every sentence providing necessary information. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a multi-action tool with 5 parameters and no annotations, the description covers all essential aspects: actions, inputs, warnings, return values, and examples. It provides sufficient context for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds value by providing context (e.g., file_path relative to container root, content required for write, interfaces required for configure_network) and concrete examples, which go beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Docker node files with CRUD operations and specifies three distinct actions (read, write, configure_network). It distinguishes these actions with clear verbs and resources, and the examples further clarify usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using 'configure_network' for network configuration as it handles the complete workflow, and warns that 'write' does not restart the node. This provides clear guidance on when to use each action, effectively differentiating them.
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?
Discloses two-phase execution (validate then execute), sequential processing, and batch-only constraint. Lacks explicit safety warnings about destructive commands, but the examples imply configuration changes. No annotations were provided, so description carries full burden.
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?
Well-structured with sections and enumerated examples, but includes some extraneous details (e.g., TFTP server path) that could be delegated to sibling tool descriptions. Overall effective despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers operation types, two-phase execution, local execution, proxy services, and return format. Given the tool's complexity and presence of an output schema, the description is thorough and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema only lists operations array with minimal description. The description adds detailed structure for each operation dict (type, node_name, additional params), operation types, and multiple examples, providing comprehensive meaning beyond 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?
Description clearly states tool executes SSH operations in batch mode, enumerates operation types (configure, command, disconnect), and distinguishes from siblings like tftp and http_client.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly marks tool as batch-only, explains local execution use cases, and provides examples that mix local and remote operations. Alternatives like tftp and http_client are referenced for non-SSH tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels. It explains batch-only behavior, two-phase execution, sequential processing, and caveats like empty buffer on first read for QEMU nodes. Version-specific features (v0.47.0 consolidation, v0.49.0 wait-only, v0.53.4 pagination) are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections: summary, use cases, execution phases, operation types (with sub-bullets), args, returns, and examples. It is front-loaded with the key guidance about SSH preference. Slightly verbose but justified given the complexity of operation types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is highly complete given the tool's complexity (multiple operation types, batch execution, output schema). It covers the return format with a detailed JSON example, includes multiple comprehensive examples, and addresses edge cases like empty reads and wait-only mode. The output schema is provided in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the schema only describes 'operations' as a list of objects. The description adds immense value by fully documenting each operation type (send, send_and_wait, read, keystroke) with complete parameter details, defaults, version notes, and usage tips (e.g., wait-only mode, pagination handling).
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 executes console operations as a batch-only interface, specifying the verb 'execute' and resource 'console operations'. It distinguishes from siblings by explicitly recommending SSH tools for general use and listing specific scenarios for console tools (initial config, troubleshooting, unsupported devices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: 'Prefer SSH tools when available' and lists primary use cases. It also details the two-phase execution process (validate all, then execute), giving clear operational guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses all behaviors: check returns connection status with error details, retry forces re-auth and bypasses exponential backoff, reconnect clears all sessions. Return values are exemplified, providing full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for actions, args, returns, and examples. Every sentence adds value, no fluff. It is concise yet comprehensive, front-loading the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and an output schema, the description covers all necessary aspects: action descriptions, return format, usage examples. It leaves no ambiguity for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds significant meaning beyond the schema: it explains what each action does (e.g., 'bypasses exponential backoff' for retry, 'clear all sessions' for reconnect) which helps the agent select the right action. Slight deduction for not adding new parameter details beyond actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it manages GNS3 server connection with three specific actions (check, retry, reconnect). It distinguishes itself from sibling tools (ssh, notification, project, etc.) by focusing on connection management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each action: check for status, retry for re-auth bypassing backoff, reconnect after server restart or project switch. It provides clear context and differentiates between the three actions, guiding the agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: read-only actions (get, status), SSL verification options, and the reverse proxy alternative. It also explains return format and shows example responses, ensuring 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 well-structured with clear sections but is somewhat lengthy. It front-loads the purpose and actions, then adds details and examples, making it easy to scan. Could be slightly more concise but still good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple parameters, two actions, SSL, alternative proxy), the description covers all essential aspects: purpose, actions, SSL handling, alternative, return format, and examples. It is complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value by explaining action values, SSL details, timeout, and providing extensive examples that illustrate parameter usage and response structure beyond 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 it is an HTTP/HTTPS client for lab device web interfaces with CRUD-style actions. It lists specific actions (get, status) and the resource (device web interfaces), distinguishing it from sibling tools like ssh or console.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (accessing device APIs/web UIs) and offers an alternative (reverse proxy) for cases where the tool is not needed. It also explains SSL handling and shows example usage.
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 MCP server](https://glama.ai/mcp/servers/ChistokhinSV/gns3-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ChistokhinSV/gns3-mcp)

Score Badge

Copy to your README.md:

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

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/ChistokhinSV/gns3-mcp'

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