serial-console-mcp

Overview Schema Source Related Servers Discussions Admin

read_until_prompt

Read serial console output until a specified prompt appears, ensuring full capture of interactive CLI responses without truncation.

Instructions

Read accumulated output until a prompt appears, or until timeout.

This is the right tool for interactive CLI sessions (routers, switches, shells). It reads from the background buffer until prompt is seen, then returns everything up to and including it, leaving anything after the prompt in the buffer for the next read. Because the reader runs continuously, large multi-page outputs are captured in full rather than being cut off by a fixed delay.

Typical flow: send_text("show version", clear_buffer_first=True) read_until_prompt(prompt="# ")

Args: prompt: The text that marks the end of output. Literal by default, e.g. "# ", "> ", "login: ", "$ ", "Password:". Prefer a prompt with its trailing space over a bare "#": the match is searched in everything received, including the echo of your own command. Default: the connection's prompt (from connect/preset), else "ends with #, >, $ or %". timeout: Max seconds to wait for the prompt to appear. regex: Treat prompt as a Python regular expression (e.g. r"[\w.-]+[#>] ?$" for a hostname-style prompt). auto_reply: Text to send automatically when a trigger shows up while waiting, e.g. {"--More--": " "} to page through long output, or {"[confirm]": "\r"}. Each occurrence is answered once. connection: Which open connection (name). Default: the current one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`regex`	No
`prompt`	No
`timeout`	No
`auto_reply`	No
`connection`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.3.2Sep 16, 2026

addedInput schema / properties / auto_reply

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Auto Reply"
+}

addedInput schema / properties / connection

Added value: +{
+  "default": "",
+  "title": "Connection",
+  "type": "string"
+}

addedInput schema / properties / prompt / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / prompt / default
```
Previous value: -"#"New value: +null
```
removedInput schema / properties / prompt / type
```
Removed value: -"string"
```

addedInput schema / properties / regex / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / regex / default
```
Previous value: -falseNew value: +null
```
removedInput schema / properties / regex / type
```
Removed value: -"boolean"
```

First observedv0.1.0Sep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden. It explains buffer behavior (returns up to and including the prompt, leaves the rest), continuous reading for full multi-page capture, and auto_reply handling. It also details prompt matching semantics, including the literal-match default and echo caveat. This is comprehensive for a non-annotated 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 well-structured: opens with the core function, then adds context, then a typical flow, then per-parameter details. Every sentence adds value, no fluff. The length is justified by the tool's complexity, and the most important usage guidance is front-loaded.

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 (5 optional parameters, auto_reply dict, connection handling) and no annotations, the description covers all necessary aspects: what it returns, buffer semantics, timeout, prompt matching details, and auto_reply. An agent has enough to invoke it correctly without external context. The presence of an output schema further reduces the need to describe return structure.

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 0%, so the description must fully document parameters. It explains prompt (with examples and default behavior), timeout (seconds), regex (with example), auto_reply (with trigger examples), and connection (with default). Each parameter gains meaning beyond the bare schema type, making this a model of parameter 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 opens with a specific verb and resource: 'Read accumulated output until a prompt appears, or until timeout.' It then specifies it's for interactive CLI sessions, which distinguishes it from sibling tools like send_text, read_available, or expect. The purpose is unambiguous and not a tautology.

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 explicitly says 'This is the right tool for interactive CLI sessions (routers, switches, shells)' and provides a typical flow with send_text. However, it does not name specific alternative tools or state when NOT to use it, leaving some inference to the agent. Still, the context is clear enough for correct selection.

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