Skip to main content
Glama

node

Perform CRUD operations on GNS3 nodes: list, create, delete, and set state (start, stop, suspend, reload, restart). Supports wildcard patterns for bulk operations.

Instructions

Manage GNS3 nodes (CRUD operations)

v0.47.0: CRUD-style consolidation of create_node, delete_node, and set_node. v0.40.0: Enhanced with wildcard and bulk operation support.

Actions: - list: List nodes in a project - create: Create new node from template at specified coordinates - delete: Delete node from project (WARNING: destructive, cannot be undone) - set: Configure node properties and/or control state (supports wildcards/bulk)

Wildcard Patterns (for 'set' and 'delete'): - Single node: "Router1" - All nodes: "" - Prefix match: "Router" (matches Router1, Router2, RouterCore) - Suffix match: "*-Core" (matches Router-Core, Switch-Core) - Character class: "R[123]" (matches R1, R2, R3) - JSON array: '["Router1", "Router2", "Switch1"]'

Validation Rules: - name parameter requires node to be stopped - Hardware properties (ram, cpus, hdd_disk_image, adapters) apply to QEMU/IOU/Docker/Dynamips - For IOU nodes, 'adapters' maps to 'ethernet_adapters' automatically - ports parameter applies to ethernet_switch nodes only - state_action values: start, stop, suspend, reload, restart

Returns: Single node: Status message Multiple nodes: BatchOperationResult JSON with per-node success/failure

Examples: # List nodes in project >>> node(action="list", project_id="abc-123") >>> node(action="list", project_id="abc-123", format="json")

# Create new node
>>> node(action="create", template_name="Alpine Linux", x=100, y=200)
>>> node(action="create", template_name="Cisco IOSv", x=300, y=400, node_name="R1", properties={"ram": 1024})

# Delete node
>>> node(action="delete", node_name="Router1")

# Start all nodes
>>> node(action="set", node_name="*", state_action="start")

# Stop all routers
>>> node(action="set", node_name="Router*", state_action="stop")

# Configure node properties
>>> node(action="set", node_name="R1", x=100, y=200, ram=2048)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoX coordinate (top-left corner of node icon)
yNoY coordinate (top-left corner of node icon)
zNoZ-order layer for overlapping nodes
ramNoRAM in MB (QEMU nodes only)
cpusNoNumber of CPUs (QEMU nodes only)
nameNoNew name (REQUIRES node stopped)
portsNoNumber of ports (ethernet_switch nodes only)
actionYesAction: 'list' (list nodes), 'create' (new node), 'delete' (remove node), or 'set' (configure/control node)
formatNoOutput format: 'table' (default) or 'json' (for 'list' action)table
lockedNoLock position to prevent GUI moves
adaptersNoNetwork adapters (QEMU: adapters, IOU: ethernet_adapters)
parallelNoExecute operations concurrently (default: True for start/stop/suspend)
node_nameNoNode name, wildcard pattern ('*', 'Router*', 'R[123]'), or JSON array ('["R1","R2"]'). Required for 'delete' and 'set'
compute_idNoCompute server ID (for 'create')local
project_idNoProject ID (required for 'list')
propertiesNoOverride template properties for 'create' (e.g., {'ram': 512})
console_typeNoConsole type: telnet/vnc/spice
state_actionNoState control action for 'set': 'start' (boot), 'stop' (shutdown), 'suspend' (pause), 'reload' (reboot), 'restart' (stop then start)
template_nameNoTemplate name (required for 'create', e.g., 'Alpine Linux', 'Cisco IOSv')
hdd_disk_imageNoHDD disk image path (QEMU nodes only)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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.

Install Server

Other Tools

Latest Blog Posts

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