serial-console-mcp

Overview Schema Source Related Servers Discussions Admin

send_text

Send ASCII commands to a serial device, optionally clearing buffered input for a clean next read. Use this to control network gear, radios, or microcontrollers via serial console.

Instructions

Send an ASCII command to the device. Writes to TX only; does NOT read.

On an interactive console the device will ECHO this text back and then print its output; call read_until_prompt (or read_available) afterward to see it. Use clear_buffer_first=True to discard any stale/unsolicited output so the next read starts clean.

Args: data: The command text, e.g. "show version", "FA014250000", or "ID". Non-ASCII characters are sent as "?"; use send_hex for raw bytes. line_ending: What to append — "CR" (\r, most rigs), "CRLF" (\r\n), "LF" (\n, most Unix-style consoles), or "NONE". Default: the connection's line ending (from connect or its preset). clear_buffer_first: Discard buffered RX before sending. connection: Which open connection (name). Default: the current one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`connection`	No
`line_ending`	No
`clear_buffer_first`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.3.2Sep 16, 2026

addedInput schema / properties / connection

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

addedInput schema / properties / line_ending / anyOf

Added value: +[
+  {
+    "enum": [
+      "CR",
+      "CRLF",
+      "LF",
+      "NONE"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / line_ending / default
```
Previous value: -"CR"New value: +null
```

removedInput schema / properties / line_ending / enum

Removed value: -[
-  "CR",
-  "CRLF",
-  "LF",
-  "NONE"
-]

removedInput schema / properties / line_ending / type
```
Removed value: -"string"
```

First observedv0.1.0Sep 15, 2026

TDQS

A5/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses TX-only behavior, device echo behavior, stale-buffer handling, non-ASCII replacement with '?', default connection line ending, and default connection selection.

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 detailed but every sentence earns its place: purpose, behavioral notes, then a clearly structured Args section. It front-loads the most important distinction (TX only, does not read) and keeps parameter explanations compact.

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 complete for an agent to invoke this tool correctly. It covers all four parameters, the read-after-send workflow, the sibling tool to use for raw bytes, and buffer-clearing behavior; the existing output schema covers return-value expectations.

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?

The schema provides 0% description coverage, so the description must compensate, and it does. It explains data with concrete examples, defines each line_ending value including default behavior, clarifies clear_buffer_first semantics, and states the connection default.

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: 'Send an ASCII command to the device' and immediately distinguishes itself from read operations with 'Writes to TX only; does NOT read.' This clearly differentiates it from siblings like read_until_prompt, read_available, and send_hex.

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 gives explicit usage guidance: after sending, call read_until_prompt or read_available to see output, use clear_buffer_first=True to discard stale output, and use send_hex for raw bytes or non-ASCII data. These are concrete when-to-use and when-not-to-use instructions referencing sibling tools.

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