# Serial Console MCP: AI for telecom equipment and any serial device (pypi · serial-console-mcp)

Let AI configure telecom gear over serial: Juniper and Cisco, Icom CI-V, Yaesu/Kenwood CAT, rotators

- Trust score: 51/100 (low)
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-21

## Components

- pypi · `serial-console-mcp`: 51/100 (this document), [markdown](https://verifymcp.io/servers/sbrunner-atx-serial-console-mcp/serial-console-mcp.md), [page](https://verifymcp.io/servers/sbrunner-atx-serial-console-mcp/serial-console-mcp)

## Channel facts

- Registry: `pypi`
- Package: `serial-console-mcp`
- Version: `0.3.2`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-21.

- **Supply Chain Security**: 50/100
  - Malware scan not yet available for this package.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it.
  - 1 of 30 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 5 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 71/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4855 tokens (~161/item across 30 items; 30 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 0/100
  - Stability not yet verified: not enough scan history yet (needs a 30-day window).
- **Tool Coverage**: 71/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 0% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 75/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 0 of 4 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "send_text" implies "send" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 30 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the Serial Console MCP: AI for telecom equipment and any… server?

Serial Console MCP: AI for telecom equipment and any… runs locally as a PyPI package, launched with uvx serial-console-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add sbrunner-atx-serial-console-mcp -- uvx serial-console-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "sbrunner-atx-serial-console-mcp": {
      "command": "uvx",
      "args": [
        "serial-console-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "sbrunner-atx-serial-console-mcp": {
      "command": "uvx",
      "args": [
        "serial-console-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add sbrunner-atx-serial-console-mcp -- uvx serial-console-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "sbrunner-atx-serial-console-mcp": {
      "type": "local",
      "command": [
        "uvx",
        "serial-console-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add sbrunner-atx-serial-console-mcp --command uvx --arg serial-console-mcp
```

### Hermes

```yaml
mcp_servers:
  sbrunner-atx-serial-console-mcp:
    command: "uvx"
    args: ["serial-console-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "sbrunner-atx-serial-console-mcp": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "serial-console-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add sbrunner-atx-serial-console-mcp -t stdio -c uvx -a serial-console-mcp
```

### Other

```json
{
  "mcpServers": {
    "sbrunner-atx-serial-console-mcp": {
      "command": "uvx",
      "args": [
        "serial-console-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-18 (score 51, 0)

- [functional regression] Security disclosure: unverified → fail

### 2026-09-17 (score 51, 0)

- [functional regression] Security disclosure: fail → unverified

### 2026-09-15 (score 51)

First indexed and scored.

## MCP tools (30)

### `list_serial_ports` (~91 tokens)

List every serial port the computer can currently see.

Call this FIRST whenever the user wants to connect to a device but hasn't given
an exact port name, or when a connection fails. Returns each port's system name
(what you pass to `connect`), a human description, and the USB hardware id, so
you can guess which one is the user's gear. Ports already open here are marked.

Output parameters:

- `result` (string)

### `list_presets` (~109 tokens)

Show the device presets `connect(preset=...)` understands, with their settings.

A preset supplies baud, data bits, parity, stop bits, flow control, the line
ending the device expects, and the prompt that ends a reply. Anything you pass
explicitly to connect overrides the preset. Families: network consoles (Cisco,
Juniper, Linux), text CAT radios (Kenwood, Elecraft, Yaesu), Icom CI-V,
rotators, Arduino, NMEA GPS.

Output parameters:

- `result` (string)

### `connect` (~898 tokens)

Open a serial port and start its background reader.

Defaults are 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control
("9600 8N1"), CR line ending, which is what most console/craft ports expect.
Give `preset` (see list_presets) to load a device family's usual settings, and
override any field explicitly, e.g. "38400 with XON/XOFF" -> baud=38400,
xonxoff=True. Several ports can be open at once; each gets a `name` and later
tools default to the most recently used one. Nothing is specific to telecom
gear: any device on a serial port works, including IoT gateways, alarm and
control panels, UPS and PDU menus and lab instruments; choose `terminal` by
what the device prints.

Args:
    port: System port name, e.g. "COM4" (Windows), "/dev/cu.usbserial-10"
        (macOS), or "/dev/ttyUSB0" (Linux). Get exact names from
        `list_serial_ports`.
    preset: Device preset name such as "cisco-console", "juniper-craft",
        "kenwood-cat", "icom-civ", "yaesu-rotator", "arduino", "nmea-gps".
    name: Nickname for this connection ("rig", "rotator"). Defaults to the
        port's short name. Use it in other tools' `connection` argument.
    baud: Baud rate. Common values: 1200, 2400, 4800, 9600, 19200, 38400,
        57600, 115200. Unknown? Use detect_baud first.
    bytesize: Data bits: 5, 6, 7, or 8. Almost always 8.
    parity: "N" none, "E" even, "O" odd. Almost always "N".
    stopbits: 1, 1.5, or 2. Almost always 1.
    rtscts: Hardware (RTS/CTS) flow control. Off unless the manual says so
        and the cable carries those lines.
    xonxoff: Software (XON/XOFF) flow control. Off by default. Never for
        binary protocols (it swallows 0x11 / 0x13 bytes).
    line_ending: Default line ending for send_text/query_text on this
        connection: "CR" (most rigs, consoles), "LF" (Unix, Arduino), "CRLF",
        or "NONE" (Kenwood-style CAT ending in ';').
    prompt: Default prompt for read_until_prompt/query_text on this
        connection, e.g. "# ", "…

Input parameters:

- `baud`
- `bytesize`
- `cols`
- `line_ending`
- `name` (string)
- `parity`
- `port` (string, required)
- `preset` (string)
- `prompt`
- `prompt_regex`
- `rows`
- `rtscts`
- `stopbits`
- `terminal`
- `xonxoff`

Output parameters:

- `result` (string)

### `reconnect_last` (~100 tokens)

Reconnect to a remembered port with the same settings as last time.

Every successful connect is remembered by name across sessions (port, baud,
flow control, line ending, prompt, preset). With no `name`, reopens the most
recently used one. Handy at the start of a chat so the user doesn't repeat the
port and baud rate. If nothing is remembered, says to use `connect` instead.

Input parameters:

- `name` (string)

Output parameters:

- `result` (string)

### `disconnect` (~64 tokens)

Close a serial port and free it for other programs.

Args:
    connection: Which connection to close (name from connect). Default: the
        current one.
    all_connections: Close every open port.

Input parameters:

- `all_connections` (boolean)
- `connection` (string)

Output parameters:

- `result` (string)

### `status` (~44 tokens)

Report every open port: settings, reader state, buffered bytes, control-line
states, capture, and which connection is current. With nothing open, lists
what reconnect_last remembers.

Output parameters:

- `result` (string)

### `send_text` (~242 tokens)

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 parameters:

- `clear_buffer_first` (boolean)
- `connection` (string)
- `data` (string, required)
- `line_ending`

Output parameters:

- `result` (string)

### `send_hex` (~185 tokens)

Send raw bytes given as hex. Writes to TX only; does NOT read.

Use for binary protocols — notably Icom CI-V, which is all hex (e.g.
"FE FE 94 E0 03 FD"; civ_build makes these). Spaces in the hex string are
ignored. To see a binary reply, call `read_available` afterward and hand the
hex to civ_parse (binary replies rarely have a text prompt, so
read_until_prompt usually isn't the right tool for these).

Args:
    hex_bytes: Bytes as hex, e.g. "FE FE 94 E0 03 FD".
    clear_buffer_first: Discard buffered RX before sending.
    connection: Which open connection (name). Default: the current one.

Input parameters:

- `clear_buffer_first` (boolean)
- `connection` (string)
- `hex_bytes` (string, required)

Output parameters:

- `result` (string)

### `read_until_prompt` (~359 tokens)

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 parameters:

- `auto_reply`
- `connection` (string)
- `prompt`
- `regex`
- `timeout` (number)

Output parameters:

- `result` (string)

### `read_available` (~111 tokens)

Drain and return whatever the device has sent, without transmitting anything.

Use for unsolicited/streaming output (syslog on a console, GPS, a sensor, a rig
in auto-info mode), or to grab a binary reply after `send_hex`. Waits up to
\`read_timeout` for the first bytes, then briefly settles so a full chunk is
captured, then returns everything buffered, as text and as hex.

Input parameters:

- `connection` (string)
- `read_timeout` (number)

Output parameters:

- `result` (string)

### `query_text` (~241 tokens)

Convenience: clear the buffer, send an ASCII command, and read the reply.

For the common "ask the device something and read its answer" case. Reads
until `prompt` (or the connection's prompt) appears; with no prompt anywhere,
or prompt="", reads until the device goes idle for a short beat (best for
line-based rigs/CAT that reply with a terminated string and no shell prompt).

Args:
    data: Command text, e.g. "show version" or "ID".
    line_ending: "CR", "CRLF", "LF", or "NONE" (see send_text). Default: the
        connection's line ending.
    prompt: Literal prompt to read until, e.g. "# " or ";". "" forces an
        idle-terminated read even if the connection has a prompt.
    read_timeout: How long to wait overall, in seconds.
    connection: Which open connection (name). Default: the current one.

Input parameters:

- `connection` (string)
- `data` (string, required)
- `line_ending`
- `prompt`
- `read_timeout` (number)

Output parameters:

- `result` (string)

### `expect` (~212 tokens)

Run a scripted sequence of send-and-wait steps in one call, like `expect`.

Use it for login flows and multi-step commands instead of one tool call per
line: [{send: "", expect: "login: "}, {send: "admin", expect: "Password:"},
{send: "<pw>", expect: "> "}, {send: "show version", expect: "> "}]. Each
step's output is returned. A step with no `send` just waits; one with no
\`expect` just sends.

Args:
    steps: The steps, in order.
    auto_reply: Triggers answered automatically while waiting, e.g.
        {"--More--": " "}.
    stop_on_timeout: Stop at the first step whose `expect` isn't seen.
    connection: Which open connection (name). Default: the current one.

Input parameters:

- `auto_reply`
- `connection` (string)
- `steps` (array, required)
- `stop_on_timeout` (boolean)

Output parameters:

- `result` (string)

### `clear_buffer` (~48 tokens)

Discard any buffered received data. Handy right before sending a command so
the next read starts clean (drops old echo, prior output, or syslog noise).

Input parameters:

- `connection` (string)

Output parameters:

- `result` (string)

### `send_keys` (~185 tokens)

Press keys by name, encoded the way a VT100/xterm terminal sends them.

Use it for what send_text can't type: Ctrl-C to interrupt a running command
(ping, monitor, a stuck process), Ctrl-Z, Esc, Tab (completion), arrows
(history, menus), Enter alone, function keys, Page Up/Down. Each item is a
key name ("ctrl-c", "esc", "tab", "enter", "up", "down", "left", "right",
"home", "end", "pgup", "pgdn", "backspace", "delete", "f1".."f12", "space"),
a single character, or "text:..." for a literal run. Nothing is read;
follow with read_until_prompt, read_available, or screen.

Input parameters:

- `connection` (string)
- `keys` (array, required)

Output parameters:

- `result` (string)

### `screen` (~132 tokens)

Show the current terminal screen of a vt100/xterm connection: what a
person at a real terminal would see right now, as rows of text, plus the
cursor position. This is how to read full-screen interfaces (BIOS setup,
RAID/BMC consoles, menu-driven switches, vi, top): press keys with
send_keys, then look at the screen again.

Args:
    reset: Clear the screen model first (after garbage, or a resize).
    connection: Which open connection (name). Default: the current one.

Input parameters:

- `connection` (string)
- `reset` (boolean)

Output parameters:

- `result` (string)

### `set_lines` (~111 tokens)

Set the DTR and/or RTS output lines and hold them.

Uses: key a transmitter whose PTT is wired to RTS or DTR (set it True to
transmit, False to stop; pulse_line is safer for that), hold an Arduino in
reset (DTR False), or tell a modem you're present. Leave a line at None to keep
it unchanged. Refused in read-only mode.

Input parameters:

- `connection` (string)
- `dtr`
- `rts`

Output parameters:

- `result` (string)

### `pulse_line` (~118 tokens)

Drive DTR or RTS to `level` for `ms` milliseconds, then restore it.

Uses: reset an Arduino (DTR, 100 ms), enter a bootloader, or key a rig's PTT
for a timed transmission (RTS or DTR per the interface's wiring). The line is
always restored, even if the wait is interrupted. Refused in read-only mode.

Input parameters:

- `connection` (string)
- `level` (boolean)
- `line` (string, required)
- `ms` (integer)

Output parameters:

- `result` (string)

### `send_break` (~67 tokens)

Send a BREAK condition (TX held low) for `ms` milliseconds.

Some consoles use BREAK to enter ROMMON or interrupt boot; some serial
devices use it as an attention signal. Refused in read-only mode.

Input parameters:

- `connection` (string)
- `ms` (integer)

Output parameters:

- `result` (string)

### `capture_start` (~150 tokens)

Start writing this connection's traffic to a file until capture_stop.

Args:
    path: File to write. Empty = an auto-named file in the app's captures
        folder. A bare name goes in that folder; an absolute path is used as is.
        Existing files are appended to.
    format: "raw" writes received bytes exactly as they arrive (a terminal
        log; echo included). "annotated" writes timestamped lines marked TX
        or RX, which is better for protocol debugging.
    connection: Which open connection (name). Default: the current one.

Input parameters:

- `connection` (string)
- `format` (string)
- `path` (string)

Output parameters:

- `result` (string)

### `capture_stop` (~29 tokens)

Stop the capture started by capture_start and report the file and size.

Input parameters:

- `connection` (string)

Output parameters:

- `result` (string)

### `get_transcript` (~94 tokens)

Return the tail of everything received on a connection since it was opened.

This is a rolling record (last 256 KB) kept regardless of what the read tools
consumed, so you can re-read output that an earlier call already returned or
that arrived between calls. Also available as the MCP resource
serial://transcript/{name}.

Input parameters:

- `connection` (string)
- `last_bytes` (integer)

Output parameters:

- `result` (string)

### `port_in_use_by` (~86 tokens)

Report which program currently holds a serial port (macOS/Linux, via lsof).

Use when connect says the port is in use, or before asking the user to close
something. On Windows the OS doesn't expose this; the usual suspects are a
terminal (PuTTY), WSJT-X, a logger, or the Arduino Serial Monitor.

Input parameters:

- `port` (string, required)

Output parameters:

- `result` (string)

### `detect_baud` (~282 tokens)

Try common baud rates on a closed port and rank them by how readable the
reply is. Use when the user doesn't know the device's rate.

Each candidate is opened briefly, `probe` (default: a bare return) is sent, and
whatever comes back is scored by its share of printable text. The right rate
yields clean text; wrong rates yield garbage or nothing. Note: opening a port
resets many Arduinos (DTR), and some devices (Kenwood CAT) only answer a real
command, so pass e.g. probe="ID;" with probe_line_ending="NONE".

Args:
    port: The port to probe (must not be open here).
    probe: Text to send at each rate. Empty sends only the line ending.
    probe_line_ending: Line ending appended to the probe ("NONE" for CAT).
    candidates: Rates to try. Default: 9600, 115200, 19200, 38400, 57600,
        4800, 2400, 1200, 230400.
    settle: Seconds to wait for a reply at each rate.

Input parameters:

- `candidates`
- `port` (string, required)
- `probe` (string)
- `probe_line_ending` (string)
- `settle` (number)

Output parameters:

- `result` (string)

### `civ_build` (~207 tokens)

Build an Icom CI-V frame as hex, ready for send_hex.

Args:
    command: Command byte(s) as hex, e.g. "03" read frequency, "04" read
        mode, "05" set frequency, "06" set mode, "1C 00" PTT, "19 00" read
        rig address.
    data: Data bytes as hex. For frequencies use civ_freq: set 14.070 MHz is
        command "05" with data "00 00 07 14 00" (BCD, low byte first).
    rig: The rig's CI-V address (IC-7300 94, IC-7610 98, IC-9700 A2, IC-705 A4).
    controller: Our address, conventionally E0.

Input parameters:

- `command` (string, required)
- `controller` (string)
- `data` (string)
- `rig` (string)

Output parameters:

- `result` (string)

### `civ_parse` (~75 tokens)

Decode Icom CI-V frames from hex (as returned by read_available).

Splits the bytes into frames, tells our own echoed command apart from the
rig's reply, and decodes frequencies (BCD), modes, OK/NG and PTT state.

Input parameters:

- `controller` (string)
- `hex_bytes` (string, required)

Output parameters:

- `result` (string)

### `civ_freq` (~74 tokens)

Convert between a frequency in MHz and CI-V BCD data bytes.

Give `mhz` to get the 5 data bytes for a set-frequency command (05), or
\`bcd_hex` (5 bytes from a reply) to get the frequency.

Input parameters:

- `bcd_hex`
- `mhz`

Output parameters:

- `result` (string)

### `cat_build` (~241 tokens)

Build a ';'-terminated text CAT command (Kenwood, Elecraft, Yaesu) for
query_text or send_text with line_ending="NONE".

Common commands: ID (rig id), FA/FB (VFO A/B frequency; empty value = read),
MD (mode; read, or set with the family's code), IF (full status), PS (power),
TX/RX, AI0 (silence auto-info), SM0 (S-meter), PC (output power).

Args:
    command: Two letters, e.g. "FA".
    value: Digits/letters to append for a set, e.g. "2" for MD2 (USB). Empty
        = read.
    frequency_mhz: For FA/FB sets: the frequency; formatted as 11 digits of
        Hz (Kenwood/Elecraft) or 9 (Yaesu).
    flavor: Which family's conventions: "kenwood" (default), "elecraft",
        "yaesu".

Input parameters:

- `command` (string, required)
- `flavor` (string)
- `frequency_mhz`
- `value` (string)

Output parameters:

- `result` (string)

### `cat_parse` (~79 tokens)

Decode ';'-terminated text CAT replies: rig id to model, FA/FB to MHz, MD
to mode name, IF to frequency/mode/VFO/split/TX state, and the ?; E; O;
error answers. Pass the text returned by query_text.

Input parameters:

- `flavor` (string)
- `reply` (string, required)

Output parameters:

- `result` (string)

### `rotator_build` (~168 tokens)

Build a Yaesu GS-232A/B rotator command for send_text (CR) or query_text.

Actions: "azimuth" (C, read), "position" (C2, read az+el), "elevation" (B),
"move" (M<az>), "move_azel" (W<az> <el>), "stop"/"stop_azimuth"/
"stop_elevation", "left"/"right"/"up"/"down" (run until stop), "speed"
(X1..X4), "help". Reads reply immediately; moves reply nothing, so read the
position afterwards to confirm.

Input parameters:

- `action` (string, required)
- `azimuth`
- `elevation`
- `speed`

Output parameters:

- `result` (string)

### `rotator_parse` (~53 tokens)

Decode a GS-232 reply into azimuth/elevation degrees ("+0180",
"+0180+0045", "AZ=180 EL=045") or the ?> rejection.

Input parameters:

- `reply` (string, required)

Output parameters:

- `result` (string)

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/sbrunner-atx-serial-console-mcp/serial-console-mcp#diagnostics

## Score history

- 2026-09-21: 51
- 2026-09-20: 51
- 2026-09-19: 51
- 2026-09-18: 51
- 2026-09-17: 51
- 2026-09-16: 51
- 2026-09-15: 51

## Common questions

### What is the Serial Console MCP: AI for telecom equipment and any… server?

Serial Console MCP: AI for telecom equipment and any… is listed in the public MCP registry as io.github.sbrunner-atx/serial-console-mcp. Let AI configure telecom gear over serial: Juniper and Cisco, Icom CI-V, Yaesu/Kenwood CAT, rotators. This page covers its PyPI package (serial-console-mcp).

### Is the Serial Console MCP: AI for telecom equipment and any… server safe to use?

Serial Console MCP: AI for telecom equipment and any… scores 51 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Serial Console MCP: AI for telecom equipment and any… server expose?

Serial Console MCP: AI for telecom equipment and any… exposes 30 tools: list_serial_ports, list_presets, connect, reconnect_last, disconnect, and 25 more. Their descriptions and schemas cost roughly 4,855 tokens of context every time the server is loaded.

### Is the Serial Console MCP: AI for telecom equipment and any… server still maintained?

Serial Console MCP: AI for telecom equipment and any… is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Serial Console MCP: AI for telecom equipment and any… server under?

Serial Console MCP: AI for telecom equipment and any… declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- PyPI project: https://pypi.org/project/serial-console-mcp/
- Socket report: https://socket.dev/pypi/package/serial-console-mcp
- Repository: https://github.com/sbrunner-atx/serial-console-mcp
- Changelog RSS feed: https://verifymcp.io/servers/sbrunner-atx-serial-console-mcp/serial-console-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/sbrunner-atx-serial-console-mcp/serial-console-mcp.json
- HTML version of this page: https://verifymcp.io/servers/sbrunner-atx-serial-console-mcp/serial-console-mcp