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

serial-hub-mcp

by yhuan416
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

RX 直落盘（大流量抓取）

dump_to_file

Stream serial receive data directly to a file instead of through MCP, optionally clearing old buffer first, and return the path plus a tail preview. Stops on match, byte limit, idle timeout, or budget.

Instructions

把 Rx（可选先清缓冲）边收边写入文件，返回文件路径与结尾预览——大流量/长日志不经过 MCP 搬运。 结束条件优先级：match(字节) 出现 > 达到 max_bytes > 静默 idle_timeout_ms > budget_ms 耗尽。默认文件按天归档到 ~/.cache/serial-hub-mcp/dumps/。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connection_id": "<connection_id>"
    },
    "name": "dump_to_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
dirNo输出目录（path 未给时用 dir）
pathNo输出文件路径（默认按天归档到 dumps 目录）
flushNo先清旧缓冲再开始，默认 false
matchNo出现即停的匹配串（字节级）
budget_msNo采集预算（毫秒），默认 5000
max_bytesNo落盘字节上限
connection_idYes连接 ID（由 open 返回）
match_encodingNomatch 的编码，默认 utf8
idle_timeout_msNo静默即停阈值（毫秒），默认 300

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations exist, so the description carries the whole burden. It discloses a lot — streaming write behavior, optional pre-flush, the returned value (path + tail preview), defaults for the archive directory, and stop-condition priority — but leaves key mutation semantics unstated: whether an existing file at `path` is overwritten or appended, and whether captured bytes are consumed from the buffer so a later read will not see them.

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?

Three dense sentences that are front-loaded with the core action and return value, followed by the stop-condition ladder and the default archive location; nothing is filler. The parenthetical '（可选先清缓冲）' mildly duplicates the flush parameter, and the priority sentence is punctuation-heavy, but overall it is efficient.

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

Completeness4/5

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

For a nine-parameter, no-annotation, no-output-schema tool, the description does the heavy lifting: it explains the return value, defaults, and termination logic. Residual gaps are overwrite/append behavior on `path` and whether the capture drains the RX buffer, both of which matter for an agent chaining this with read/receive.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all nine parameters, setting the baseline at 3. The description genuinely adds one piece of meaning the schema lacks — the relative priority among match, max_bytes, idle_timeout_ms and budget_ms — and clarifies the default archive location, but adds nothing about dir vs path precedence or match_encoding behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource: stream Rx (optionally after flushing the buffer) into a file and return the file path plus a tail preview. The clause '大流量/长日志不经过 MCP 搬运' implicitly separates it from the read/receive siblings, which return data through MCP, though those siblings are never named.

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?

Gives a clear selection context (high-volume traffic, long logs) and, unusually, explains the termination precedence: match hit > max_bytes > idle_timeout_ms silence > budget_ms exhaustion. It stops short of an explicit 'for small/one-shot reads use read or receive instead' exclusion, so the routing back to siblings is left to inference.

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