mcp-serial
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_SERIAL_MAX_TIMEOUT | No | Maximum allowed timeout in seconds for tool calls (default 120). | 120 |
| MCP_SERIAL_ALLOWED_PORTS | No | Comma-separated globs of allowed serial port paths (e.g. /dev/cu.usb*,COM3). Restricts which ports the agent may touch. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_portsC | List the serial ports currently present on this machine. Use the |
| open_portA | Open a serial port and start buffering everything it sends. Idempotent: opening an already-open port with the same settings just returns its status; different settings close and reopen it. The port stays open until close_port. |
| close_portA | Close a port opened with open_port and release it for other programs. |
| port_statusB | Show open ports with byte counters, buffered (unread) bytes and disconnect errors. |
| writeA | Send raw bytes without waiting for a reply (use query for request/response). |
| readC | Read and consume buffered data from the device (logs, sensor output, late replies). |
| read_untilA | Wait until a pattern appears (e.g. 'OK', 'ready>', 'Temperature:') and return everything up to and including it. On timeout returns whatever arrived, with matched=false. |
| queryA | Send a command and return its reply in one call. Best for request/response devices (AT modems, CLI firmware, 'PING' -> 'PONG' sketches). |
| tailA | Peek at the last lines received on a port WITHOUT consuming the read buffer. Good for checking what a device has been printing while you were doing other things. |
| clear_bufferA | Discard all buffered unread data on a port (line history for tail is kept). |
| reset_deviceA | Reboot the board by pulsing DTR/RTS and return what it prints while booting. Only works on boards that wire those lines to reset (most USB dev boards do). |
| set_control_linesA | Set the DTR / RTS modem control lines manually (bootloader entry, custom reset circuits). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| ports_resource | JSON list of serial ports present on this machine. |
TDQS
Scored across 12 tools
Each tool targets a distinct serial-port operation: open/close/status/list are lifecycle, write/read/read_until/query/tail/clear_buffer handle data flow in clearly separated ways, and reset_device/set_control_lines cover control-line actions. The descriptions explicitly call out the consumption-vs-peek and reply-vs-no-reply distinctions, so an agent should not misselect.
Most tools follow verb_noun naming (open_port, list_ports, clear_buffer), but several are bare verbs (write, read, query, tail) and port_status uses a noun phrase instead of a verb. The mix is readable but not a consistent pattern.
Twelve tools is a well-scoped size for a serial-port server. Each operation has a distinct role and the count is neither bloated nor too thin.
The surface covers the full serial workflow: enumeration, open/close/status, raw write, buffered read, pattern waits, request/response queries, monitoring without consuming, buffer clearing, device reset, and manual control-line control. No major missing operation is apparent.