Skip to content
verify mcp Beta VerifyMCP is currently in beta. If you notice any issues, get in touch and we’ll put it right.

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

Available components

−17 this week 63 Trust /100

Last scanned (14 hours ago)

Scores higher than 60% of PyPI servers

Category IoT and Hardware

Trust breakdown (7 categories)

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. How we score → Why this is hard to score →

Supply Chain Security50
  • Malware scan not yet available for this package.Unverified
  • No known CVEs affecting this package version or its production dependencies.Pass
  • Runs hatchling.build at install time, a recognised build step with no custom scripting around it. View diagnostics → Pass
  • 1 of 29 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
Schema Quality & AI Usability71
  • AI-judged instruction clarity (excellent).Pass
  • 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. See how to fix → Fail
  • Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management83
  • Stability observed for 25 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage71
  • 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
  • 0% of tool parameters carry a description.Fail
  • Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Tool Safety75
  • No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
  • 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. See how to fix → Fail
  • An AI judge read all 30 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
  • Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
What we tested

Checks we ran (15)

  • Known CVEs
  • Install scripts
  • Dependency health
  • Source repository
  • Provenance
  • License
  • Maintenance
  • Security disclosure
  • Schema quality
  • Stability
  • Tool coverage
  • Injection markers
  • Destructive annotations
  • Judged manipulation
  • MCP protocol

Checks we could not complete (1)

These are gaps on our side, not findings about this package. We only credit what we can confirm, so a category made up entirely of them scores 0.

  • Malware scan in Supply Chain SecurityMalware scan not yet available for this package.

Does not apply to this package (2)

  • Endpoint SecurityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.
  • Transport & ReachabilityScored on hosted endpoints only. A package has no live endpoint of its own for us to probe.

The score does not measure everything. What the score does not measure →

Changelog

Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.

  • 5 Nov 26 −2
    • Stability: pass → 0.83 functional
  • 30 Oct 26 −15
    • Malware scan: pass → unverified ▼ security
    • Stability: 0.97 → pass security
  • 29 Oct 26 +15
    • Provenance: unverified → fail ▼ security
    • Malware scan: unverified → pass ▲ security
    • Security disclosure: unverified → fail ▼ functional
    • Stability: pass → 0.97 functional
  • 28 Oct 26 −15
    • Malware scan: pass → unverified ▼ security
    • Provenance: fail → unverified ▼ security
    • Security disclosure: fail → unverified ▼ functional
  • 23 Oct 26 0
    • Stability: 0.97 → pass security
  • 22 Oct 26 +1

    No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

  • 21 Oct 26 −1
    • Stability: pass → 0.93 functional
  • 17 Oct 26 +3
    • Stability: 0.77 → pass security
Diagnostics

Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.

Captured 5 Nov 2026 · Analysed pypi/serial-console-mcp@0.3.2

Provenance No attestation

The registry publishes no build provenance for this version, so there is nothing to verify.

Result No attestation
Ecosystem pypi
Reason No attestation published

Background: How many MCP packages publish verified provenance →

Install scripts 1 script
Hook Tier Command
build_backend Known build tool hatchling.build

Background: Why install scripts are a supply-chain risk →

Dependencies 29 packages
Packages resolved 29
Stale 1
Tree resolution Complete

Background: SBOMs and build attestations, explained →

MCP tools · 30 exposed · ~4,855 tokens

The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →

Tool Tokens
capture_start ~150

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.

NameTypeReqDescription
connectionstring––
formatstring––
pathstring––
NameTypeReqDescription
resultstringyes–

No examples provided.

capture_stop ~29

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

NameTypeReqDescription
connectionstring––
NameTypeReqDescription
resultstringyes–

No examples provided.

cat_build ~241

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".

NameTypeReqDescription
commandstringyes–
flavorstring––
frequency_mhz–––
valuestring––
NameTypeReqDescription
resultstringyes–

No examples provided.

cat_parse ~79

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.

NameTypeReqDescription
flavorstring––
replystringyes–
NameTypeReqDescription
resultstringyes–

No examples provided.

civ_build ~207

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.

NameTypeReqDescription
commandstringyes–
controllerstring––
datastring––
rigstring––
NameTypeReqDescription
resultstringyes–

No examples provided.

civ_freq ~74

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.

NameTypeReqDescription
bcd_hex–––
mhz–––
NameTypeReqDescription
resultstringyes–

No examples provided.

civ_parse ~75

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.

NameTypeReqDescription
controllerstring––
hex_bytesstringyes–
NameTypeReqDescription
resultstringyes–

No examples provided.

clear_buffer ~48

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).

NameTypeReqDescription
connectionstring––
NameTypeReqDescription
resultstringyes–

No examples provided.

connect ~898

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. "# ", "…

NameTypeReqDescription
baud–––
bytesize–––
cols–––
line_ending–––
namestring––
parity–––
portstringyes–
presetstring––
prompt–––
prompt_regex–––
rows–––
rtscts–––
stopbits–––
terminal–––
xonxoff–––
NameTypeReqDescription
resultstringyes–

No examples provided.

detect_baud ~282

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.

NameTypeReqDescription
candidates–––
portstringyes–
probestring––
probe_line_endingstring––
settlenumber––
NameTypeReqDescription
resultstringyes–

No examples provided.

disconnect ~64

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.

NameTypeReqDescription
all_connectionsboolean––
connectionstring––
NameTypeReqDescription
resultstringyes–

No examples provided.

expect ~212

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.

NameTypeReqDescription
auto_reply–––
connectionstring––
stepsarrayyes–
stop_on_timeoutboolean––
NameTypeReqDescription
resultstringyes–

No examples provided.

get_transcript ~94

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}.

NameTypeReqDescription
connectionstring––
last_bytesinteger––
NameTypeReqDescription
resultstringyes–

No examples provided.

list_presets ~109

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.

Input schema present but exposes no named parameters.

NameTypeReqDescription
resultstringyes–

No examples provided.

list_serial_ports ~91

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.

Input schema present but exposes no named parameters.

NameTypeReqDescription
resultstringyes–

No examples provided.

port_in_use_by ~86

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.

NameTypeReqDescription
portstringyes–
NameTypeReqDescription
resultstringyes–

No examples provided.

pulse_line ~118

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.

NameTypeReqDescription
connectionstring––
levelboolean––
linestringyes–
msinteger––
NameTypeReqDescription
resultstringyes–

No examples provided.

query_text ~241

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.

NameTypeReqDescription
connectionstring––
datastringyes–
line_ending–––
prompt–––
read_timeoutnumber––
NameTypeReqDescription
resultstringyes–

No examples provided.

read_available ~111

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.

NameTypeReqDescription
connectionstring––
read_timeoutnumber––
NameTypeReqDescription
resultstringyes–

No examples provided.

read_until_prompt ~359

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.

NameTypeReqDescription
auto_reply–––
connectionstring––
prompt–––
regex–––
timeoutnumber––
NameTypeReqDescription
resultstringyes–

No examples provided.

reconnect_last ~100

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.

NameTypeReqDescription
namestring––
NameTypeReqDescription
resultstringyes–

No examples provided.

rotator_build ~168

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.

NameTypeReqDescription
actionstringyes–
azimuth–––
elevation–––
speed–––
NameTypeReqDescription
resultstringyes–

No examples provided.

rotator_parse ~53

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

NameTypeReqDescription
replystringyes–
NameTypeReqDescription
resultstringyes–

No examples provided.

screen ~132

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.

NameTypeReqDescription
connectionstring––
resetboolean––
NameTypeReqDescription
resultstringyes–

No examples provided.

send_break ~67

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.

NameTypeReqDescription
connectionstring––
msinteger––
NameTypeReqDescription
resultstringyes–

No examples provided.

send_hex ~185

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.

NameTypeReqDescription
clear_buffer_firstboolean––
connectionstring––
hex_bytesstringyes–
NameTypeReqDescription
resultstringyes–

No examples provided.

send_keys ~185

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.

NameTypeReqDescription
connectionstring––
keysarrayyes–
NameTypeReqDescription
resultstringyes–

No examples provided.

send_text ~242

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.

NameTypeReqDescription
clear_buffer_firstboolean––
connectionstring––
datastringyes–
line_ending–––
NameTypeReqDescription
resultstringyes–

No examples provided.

set_lines ~111

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.

NameTypeReqDescription
connectionstring––
dtr–––
rts–––
NameTypeReqDescription
resultstringyes–

No examples provided.

status ~44

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.

Input schema present but exposes no named parameters.

NameTypeReqDescription
resultstringyes–

No examples provided.

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.

pypi · serial-console-mcp

# add to Claude Code
claude mcp add sbrunner-atx-serial-console-mcp -- uvx serial-console-mcp
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 63 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 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 5 November 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.

What did VerifyMCP test on the Serial Console MCP: AI for telecom equipment and any… server?

VerifyMCP ran 15 checks on Serial Console MCP: AI for telecom equipment and any…, covering Known CVEs, Install scripts, Dependency health, Source repository and 11 more. One item could not be completed, a gap on our side rather than a finding about Serial Console MCP: AI for telecom equipment and any…: Malware scan. Endpoint Security and Transport & Reachability do not apply to a PyPI package, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.