flashgate

Overview Schema Source Related Servers Discussions Admin

console_send

Send one UART console command to firmware and capture its reply within a set wait time, verifying board behavior and diagnosing wiring or command errors.

Instructions

Talk to the firmware directly: send ONE command line on the console UART and collect its answer.

Example: line "led0?" — the firmware replies with its LED state and
the live PWM register value (a hardware readback, not a cached
variable). The command set is board-specific — board_info and the
board's probe definitions show the known commands; unknown commands
typically answer "ERR unknown-cmd". The reply lands in
data.response within wait_s seconds; silence is reported as
"(no response)" in the summary + a warning — check wiring before
concluding the firmware is dead.

Input Schema

TableJSON Schema

Name	Required	Description
`line`	Yes	One console command line to send, e.g. "led0?". Written verbatim — embedded newlines dispatch multiple commands, and over-long lines are dropped by the firmware console buffer. The command set is board-specific; board_info and the board's probe definitions list the known commands.
`board`	No	Path to the board profile YAML (e.g. boards/apollo-h743.yaml). Omit to use the server's --board argument, else the default search path.
`wait_s`	No	Seconds to wait for the firmware's answer after sending; below 0.1 it is clamped up (typical 1.0). Large values block for that long.

Output Schema

TableJSON Schema

Name	Required	Default
`code`	Yes
`data`	No
`policy`	No
`status`	Yes
`summary`	Yes
`evidence`	No
`warnings`	No
`exit_code`	No
`schema_version`	No	1.0

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 13, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations (readOnlyHint=false, openWorldHint=true) only signal that this mutates device state; the description goes much further by disclosing the response channel (data.response), the wait_s timing window, the '(no response)' plus warning behavior on silence, the 'ERR unknown-cmd' fallback, and that replies are live hardware readbacks rather than cached values. That is exactly the extra behavioral context annotations cannot carry.

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 core action and example, and every sentence carries at least some operational value. The board-specific command guidance is however repeated in the description and again in the line parameter, which is mild redundancy rather than wasted content.

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

Completeness5/5

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

An output schema exists, yet the description still usefully names the response field, the timing window, and the failure signals, leaving nothing an agent needs in order to invoke and interpret this tool correctly.

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 description coverage is 100%, so line, board, and wait_s are already fully documented including the verbatim-writing and buffer-overflow behavior. The description reinforces the 'led0?' example and board-specific command set but adds no parameter syntax or constraints beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource ('send ONE command line on the console UART and collect its answer') with an explicit cardinality constraint that separates it from passive read siblings like console_read. An agent can tell this is the active command-dispatch tool without opening the 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?

Gives clear context for use — direct firmware interrogation, board-specific command set discoverable via board_info and probe definitions — and tells the agent how to interpret 'ERR unknown-cmd'. It does not explicitly say when to prefer console_read or another sibling over this tool, so it falls short of a full when/when-not/alternatives statement.

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

Deploy Server