Skip to main content
Glama
serial-hub-mcp

serial-hub-mcp

by yhuan416

统一接收窗口(持续收流量直到结束)

receive

Continuously captures serial traffic until a byte match, size limit, idle timeout, or budget expires, returning every captured byte with match status and stop reason.

Instructions

持续消费全部到达流量,直到命中 match(字节)、达到 max_bytes、静默 idle_timeout_ms、或 budget_ms 耗尽。结束时不丢弃流量——期间所有字节如实带回,由 matched/stopped_reason 说明命中情况;内容判读交给 agent。start=cursor 从当前游标起;start=flush 先清缓冲(干净窗口)再开始;可选 reset 复位(配合 start=flush 抓启动日志)。抓 boot 示例:receive({start:'flush', reset:'dtr', budget_ms:15000})。

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": "receive"
  }
}

Input Schema

NameRequiredDescriptionDefault
matchNo出现即停的匹配串(字节级),如 "login:"
resetNo(start=flush 配合)复位方式,默认 none
startNocursor=从当前游标(默认);flush=先清缓冲再开始
budget_msNo整次观察预算(毫秒),默认 10000
max_bytesNo返回字节上限
connection_idYes连接 ID(由 open 返回)
match_encodingNomatch 的编码,默认 utf8
reset_pulse_msNo复位脉冲保持毫秒数,默认 100
idle_timeout_msNo静默即停阈值(毫秒),默认 300

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses that no traffic is dropped at the end, that all bytes are returned, and that matched/stopped_reason explain the outcome. It implies cursor consumption ('消费', 'start=cursor 从当前游标起') but never spells out that a subsequent read will not re-see those bytes, nor does it address concurrency, disconnect behavior, or that the call blocks until a stop condition fires.

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

Conciseness5/5

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

Front-loaded with the core behavior (continuous consumption and its stop conditions), then the non-discard guarantee, then mode semantics, then a single compact example. No sentence is redundant and the example directly reinforces the start=flush + reset combination.

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 9-parameter streaming tool with no output schema, the description usefully names the return fields (matched/stopped_reason) and explains the buffer-consumption model. It leaves out failure behavior (connection loss, invalid reset state) and the cursor-advance consequence, which an agent would need before calling it repeatedly.

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 real interaction semantics: the precedence of the four stop conditions, the start/reset coupling for boot capture, and a worked example with concrete budget_ms. It does not clarify edge cases such as match_encoding versus the returned byte representation or reset_pulse_ms tuning.

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?

The description states a specific verb and resource ('持续消费全部到达流量') plus the exact termination conditions (match hit, max_bytes, idle_timeout_ms, budget_ms). This clearly delineates it from a one-shot 'read' sibling by describing a bounded observation window, though no sibling is named explicitly.

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 concrete guidance on which mode to pick: start=cursor starts from the current cursor, start=flush clears the buffer for a clean window, and reset goes with start=flush for boot-log capture. What's missing is any statement of when to prefer this tool over read/transact, or any when-not-to-use condition.

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