flashgate

Overview Schema Source Related Servers Discussions Admin

verify

Destructive

Prove firmware runs on a board: rebuild, flash via ST-Link, require boot evidence matching the build, and run hardware probes to return pass/fail.

Instructions

The hardware gate — the authoritative answer to "does this firmware actually work on the board?".

status=succeeded means the BOARD ITSELF booted the exact tree you are
on (its reported git sha matches the working tree) and every
functional probe passed. Trust no other signal; a clean build is not
a pass.

What it does: rebuild the tree, flash over ST-Link, start the app,
then require boot evidence proving WHICH build is running (UART
banner; or, without a serial cable, an SWD RAM signature — a stale
signature is wiped and read-back verified before start; a wipe that
fails, or whose readback answers wrong or cannot run at all, fails
closed), then run every defined probe, asserting on the board's
answers, including live register readbacks. DESTRUCTIVE: rewrites the
board's flash.

The failure code names the broken stage: BUILD_FAILED, FLASH_FAILED,
BOOT_EVIDENCE_TIMEOUT, BOOT_ERROR, IDENTITY_MISMATCH (the board runs
a different tree, or the signature wipe failed or its readback
answered wrongly — check the debug probe, not the build),
CAPABILITY_UNAVAILABLE (a required check could not run — most often
the console UART, or a readback that cannot run at all: environment
failure, check named, start withheld), PROBE_FAILED. Full transcript
in data.log; data.record is this run's persisted evidence record,
data.record_dir where the audit trail accumulates.

Report the status and code verbatim; never claim success from the
build step alone.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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.

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?

Goes far beyond the single destructiveHint annotation: discloses that it rebuilds, flashes over ST-Link, starts the app, requires boot evidence (UART banner or SWD RAM signature with fail-closed wipe/readback), and enumerates all failure codes with their meanings. Explicitly flags DESTRUCTIVE flash rewrite and the persisted output files.

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 identity before the operational detail, and uses 'What it does:' style structure. Dense and long, but almost every clause carries behavioral meaning for a complex destructive operation, with minimal filler.

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?

Covers the full lifecycle, the success/failure semantics, the destructive impact, and where transcript/record artifacts land (data.log, data.record, data.record_dir). With the output schema present, no return-value detail is missing for an agent to call and interpret this tool.

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?

Only one optional parameter (board) with full schema description coverage and a clear default/fallback stated in the schema. The description adds no board-path syntax or precedence detail beyond the schema, so the baseline 3 for high coverage 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 precise verb+resource ('the hardware gate', 'does this firmware actually work on the board') and defines success concretely (board booted the exact tree, probes passed). Explicitly distinguishes itself from siblings: 'a clean build is not a pass' separates it from build/flash/probe.

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?

Strongly routes the agent away from weaker signals ('Trust no other signal; a clean build is not a pass') and frames itself as the authoritative final gate. It stops short of an explicit when-not-to-use statement or naming a specific alternative tool to run first.

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

Deploy Server