Skip to main content
Glama
Sign In
serial-hub-mcp

serial-hub-mcp

by yhuan416
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

打开串口

open

Establishes a serial port connection by path, saved profile, device IDs (sn/vid/pid), or remote ESP32 bridge endpoint and returns a connection_id for subsequent read, write, and transaction calls.

Instructions

打开一个串口连接。定位端口三选一：port（路径）/ profile（命名参数）/ sn|vid|pid（按设备标识自动找）。transport=remote 时改用 endpoint（ESP32 无线串口桥，如 tcp://esp32s3-01:7000），不使用 port/sn/vid/pid。baud_rate 默认 115200；data_bits 默认 8；stop_bits 默认 1；parity 默认 none；flow_control 默认 none。newline 设置发送默认追加的换行（write/transact 未显式指定时的默认）。成功后返回 connection_id，后续 read/write/transact 用它。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "open"
  }
}

Input Schema

NameRequiredDescriptionDefault
snNo按序列号定位（list_ports.serialNumber）
pidNo按产品 ID 定位（如 55d3、1001）
vidNo按厂商 ID 定位（如 1a86、303a）
portNo串口路径，如 /dev/ttyUSB0、/dev/ttyACM0、COM3
parityNo校验，默认 none
newlineNo发送时自动追加的换行（none 不加）
profileNo已保存的 profile 名（profile_list 查看；显式参数覆盖 profile）
endpointNo远端地址（transport=remote 时必填），如 tcp://esp32s3-01:7000
baud_rateNo波特率，默认 115200
data_bitsNo数据位，默认 8
stop_bitsNo停止位，默认 1（Node serialport 仅支持 1/2）
transportNo链路类型：serial=本机串口（默认）；remote=ESP32 无线串口桥（契约已定，当前未实现）
flow_controlNo流控，默认 none
rx_buffer_sizeNo内部 RX 缓冲上限字节数，默认 4194304 (4 MiB)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavior burden. It adds real value by disclosing that a successful call returns connection_id and that newline becomes the default for later write/transact calls, but it says nothing about failure modes, whether opening replaces an existing connection, or permission/device-access prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the localization rule, then the transport branch, then defaults, then the return value; each sentence maps to a decision the caller has to make. Mild waste in re-listing defaults already present in the schema, but overall dense and well ordered.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool with no annotations and no output schema, the description covers the important structural decisions and the connection_id return, which is otherwise undocumented. Gaps remain around error behavior, connection lifecycle, and rx_buffer_size semantics, which the description never touches.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema cannot express: the mutual exclusivity of port/profile/sn|vid|pid, and the conditional that endpoint replaces the serial-locating params under transport=remote. Defaults it restates (baud_rate, data_bits, parity, flow_control) are already documented in the schema and add no new information.

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 ("打开一个串口连接") and immediately scopes how the port is targeted. It also names the downstream consumers (read/write/transact using connection_id) and references sibling helpers (list_ports, profile_list), so the agent can tell this apart from the read/write tools without opening a schema.

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?

It gives clear selection rules among targeting parameters: pick one of port / profile / sn|vid|pid, and switch to endpoint when transport=remote (explicitly excluding port/sn/vid/pid in that case). It does not say when the tool should not be used (e.g. an already-open port, or whether to close first), so it stops short of full exclusion guidance.

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

Deploy Server

Other Tools