pnetlab-mcp-server

console_send

Send raw text to a node's console for interactive multi-step sessions, with automatic login on first use.

Instructions

Send raw text to a node's console (auto-opens + logs in on first use). Lower-level than run_command: use it for multi-step interactive sessions where you need to drive the prompt yourself. Set newline=False to send a partial line (e.g. before reading). Read the response with console_read.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "node_id": "<node_id>",
      "text": "<text>"
    },
    "name": "console_send"
  }
}

Input Schema

Name	Required	Default
`text`	Yes
`newline`	No
`node_id`	Yes
`password`	No
`username`	No	admin

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.1Jul 31, 2026

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: 'auto-opens + logs in on first use', and explains the 'newline' parameter's effect (partial line). This is helpful, but it omits other important traits like whether the action is destructive or requires a running node, so it gets a 4 rather than a 5.

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 three sentences, front-loaded with the primary action, and every sentence adds value: what it does, when to use it, and how a key parameter behaves. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no annotations, and an output schema that likely describes return values, the description is reasonably complete. It covers the tool's purpose, usage context, a parameter nuance, and a follow-up tool. However, it doesn't mention prerequisites like the node being started, which would be useful for completeness in a lab environment with siblings like 'start_node' and 'stop_node'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the description must compensate. It explicitly explains 'text' (raw text), 'newline' (partial line behavior), and 'node_id' (node's console). However, 'username' and 'password' are only hinted at via 'logs in' without being explicitly tied to the parameters, leaving some ambiguity. This partial coverage warrants a 3.

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 function: 'Send raw text to a node's console' with a specific verb and resource. It also distinguishes itself from the sibling 'run_command' by labeling itself as 'lower-level', making its unique role explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'use it for multi-step interactive sessions where you need to drive the prompt yourself'. It also contrasts with 'run_command' and recommends 'console_read' for reading responses, offering clear alternatives and follow-up actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.