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

serial-hub-mcp

by yhuan416
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

保存连接 profile

profile_save

Save connection parameters as a named profile so later open({profile}) calls reuse transport, port, baud rate, and framing settings in one step.

Instructions

把常见连接参数存为命名 profile，供 open({profile}) 一条复用。字段与 open 一致：transport/endpoint/port/baud_rate/data_bits/stop_bits/parity/flow_control/rx_buffer_size/newline/prompt/regex/note。

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": {
      "name": "<name>"
    },
    "name": "profile_save"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesprofile 名，如 quarkpi、uart0
noteNo备注
portNo串口路径（可省略，open 时另行指定）
regexNo默认结束正则
parityNo
promptNoshell 提示符正则，receive(prompt:true) 用它作结束条件
newlineNo发送默认追加的换行，默认 none
endpointNo远端地址（transport=remote 时用）
baud_rateNo波特率，默认 115200
data_bitsNo
stop_bitsNo
transportNo链路类型，默认 serial
flow_controlNo
rx_buffer_sizeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations at all, the description carries the full behavioral burden. It does not state whether saving a name that already exists overwrites it or errors, where and for how long the profile persists, or whether the profile is immediately usable. For a tool that writes data, these omissions are significant.

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?

It consists of two sentences and is front-loaded with the action and the reuse rationale. The long slash-separated field list is somewhat redundant with the schema, but it is the only thing that establishes parity with open.

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?

The description is minimal but viable for a 14-parameter write tool with no annotations and no output schema. It covers what the tool does and how the result is consumed, but it omits overwrite semantics, persistence scope, and what happens to fields that are not supplied.

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 sits at 64% and there are 14 parameters. The description's main addition is the claim that the fields are identical to open's parameters, which lets an agent copy fields from a working open call; that is genuine value. However, the field list mostly repeats the schema property names without adding defaults, constraints, or collision behavior for name.

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 gives a specific verb-plus-resource: it saves connection parameters as a named profile, and explains the payoff as reuse through open({profile}). That tie to a specific sibling is useful. It does not name profile_list or profile_delete, so it does not fully establish which sibling to choose in every case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that you should use this tool when you want to reuse settings in later open calls, but it never states the exclusions or prerequisites. This matters: it does not say whether you must already have a working open call, or whether an omitted field is inherited or left unset. The connection to open() is the only guidance offered.

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