flashgate

Overview Schema Source Related Servers Discussions Admin

flash

Destructive

Write firmware to an MCU via ST-Link, verify the write, then start the application. Replaces existing code; build first if sources changed.

Instructions

Write the built firmware to the board's flash over ST-Link, verify the write, then start the application. DESTRUCTIVE: whatever runs on the MCU is replaced.

Flashes the artifact from the last build — call build first if
sources changed since. Tries up to 3 times on transient probe
errors. Any failure — including a missing ST-Link or CubeProgrammer —
surfaces as failed + FLASH_FAILED, exit_code 2; data.log carries the
programmer output. Run doctor to tell an environment problem (no
probe / no tools) apart from a write failure.

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.7/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true, and the description reinforces with concrete consequences ('whatever runs on the MCU is replaced'). Beyond that it discloses retry policy (up to 3 attempts on transient errors), failure semantics (FLASH_FAILED, exit_code 2), and where output lands (data.log), all of which go beyond the annotation.

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 destructive warning and primary action, followed by dependency, retry, and failure-handling detail. Every sentence carries distinct, actionable information with no 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?

An output schema exists so return values need not be explained, yet the description still covers dependencies, retries, and failure routing. Combined with the destructive annotation, an agent has everything needed to call it safely and interpret failures.

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 and schema description coverage is 100%, so the schema fully documents the board profile path including fallback behavior. The description adds no additional parameter meaning, which matches the baseline 3 when the schema does the work.

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+resource ('write the built firmware to the board's flash over ST-Link'), plus the follow-on actions (verify, start application). It is clearly distinguishable from siblings like build, verify, and probe.

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

Usage Guidelines5/5

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

Explicitly routes the agent: 'call build first if sources changed since' and 'Run doctor to tell an environment problem apart from a write failure.' It names both the dependency and the diagnostic alternative with the condition that selects each.

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

Deploy Server