Skip to main content
Glama

console

Run batch console operations (send commands, wait for output, read responses, send keystrokes) on GNS3 network nodes for initial setup or when SSH is not available.

Instructions

Execute console operations (BATCH-ONLY)

v0.47.0: Batch-only console tool. Individual console tools removed (aggressive consolidation).

IMPORTANT: Prefer SSH tools when available! Console tools are primarily for:

  • Initial device configuration (enabling SSH, creating users)

  • Troubleshooting when SSH is unavailable

  • Devices without SSH support (VPCS, simple switches)

Two-phase execution:

  1. VALIDATE ALL operations (check nodes exist, required params present)

  2. EXECUTE ALL operations (only if all valid, sequential execution)

Each operation supports all parameters from the underlying console tool:

  • "send": Send data to console { "type": "send", "node_name": "R1", "data": "show version\n", "raw": false // optional }

  • "send_and_wait": Send command and wait for pattern { "type": "send_and_wait", "node_name": "R1", "command": "show ip interface brief\n", // optional (v0.49.0: omit for wait-only mode) "wait_pattern": "Router#", // optional "timeout": 30, // optional "raw": false, // optional "handle_pagination": true, // optional (v0.53.4: auto-handle --More--) "pagination_patterns": ["--More--", "---(more)---"], // optional (custom patterns) "pagination_key": " " // optional (default: space, can use "\n" for enter) } Wait-only mode (v0.49.0): Omit "command" to just wait for pattern without sending anything. Useful for monitoring boot sequences or waiting for specific output to appear.

  • "read": Read console output (NOTE: returns empty if nothing sent yet - this is normal) { "type": "read", "node_name": "R1", "mode": "diff", // optional: diff/last_page/num_pages/all "pages": 1, // optional, only with mode="num_pages" "pattern": "error", // optional grep pattern "case_insensitive": true, // optional "invert": false, // optional "before": 0, // optional context lines "after": 0, // optional context lines "context": 0 // optional context lines (overrides before/after) } IMPORTANT: Console buffer may be empty on first read (QEMU nodes don't output until prompted). Use 'send_and_wait' to explicitly send a command and read the response, or send commands first with 'send'.

  • "keystroke": Send special keystroke { "type": "keystroke", "node_name": "R1", "key": "enter" // up/down/enter/ctrl_c/etc }

Args: operations: List of operation dictionaries (see examples above)

Returns: JSON with execution results: { "completed": [0, 1, 2], // Indices of successful operations "failed": [3], // Indices of failed operations "results": [ { "operation_index": 0, "success": true, "operation_type": "send_and_wait", "node_name": "R1", "result": {...} // Operation-specific result }, ... ], "total_operations": 4, "execution_time": 5.3 }

Examples: # Multiple commands on one node: >>> console(operations=[ ... {"type": "send_and_wait", "node_name": "R1", "command": "show version\n", "wait_pattern": "Router#"}, ... {"type": "send_and_wait", "node_name": "R1", "command": "show ip route\n", "wait_pattern": "Router#"}, ... {"type": "read", "node_name": "R1", "mode": "diff"} ... ])

# Same command on multiple nodes:
>>> console(operations=[
...     {"type": "send_and_wait", "node_name": "R1", "command": "show ip int brief\n", "wait_pattern": "#"},
...     {"type": "send_and_wait", "node_name": "R2", "command": "show ip int brief\n", "wait_pattern": "#"},
...     {"type": "send_and_wait", "node_name": "R3", "command": "show ip int brief\n", "wait_pattern": "#"}
... ])

# Mixed operations:
>>> console(operations=[
...     {"type": "send", "node_name": "R1", "data": "\n"},  # Wake console
...     {"type": "read", "node_name": "R1", "mode": "last_page"},  # Check prompt
...     {"type": "send_and_wait", "node_name": "R1", "command": "show version\n", "wait_pattern": "#"},
...     {"type": "keystroke", "node_name": "R1", "key": "ctrl_c"}  # Cancel if needed
... ])

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationsYesList of console operations (send/send_and_wait/read/keystroke)

Output Schema

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

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