STM32 Debug MCP

Overview Schema Source Related Servers Discussions Admin

serial_sequence

Run multi-step hardware sequences mixing serial I/O, delays, captures, and SWD memory reads or writes in one call, preserving real timing between steps for hardware-in-the-loop tests.

Instructions

Run a multi-step hardware sequence (serial + SWD memory) in one tool call.

Executes a list of send, delay, capture, mem_write, and mem_read steps sequentially with real timing (no tool-call overhead between steps). Useful for hardware test sequences that are timing-sensitive — blinking GPIOs over SWD, bit-banging registers with deterministic delays, mixed serial/memory flows.

Timing note: each mem_write/mem_read currently launches a fresh OpenOCD process (~tens of ms overhead per op), so sub-10ms delays between memory ops won't be honored precisely. Delay steps themselves are accurate.

Args: steps: JSON array of step objects. Step types: Send: {"send": "CMD", "to": "/dev/ttyACM0 (Linux) or /dev/cu.usbmodemXXXX (macOS)", "expect": "OK", "read_timeout": 2.0, "line_ending": "lf"} Delay: {"delay_ms": 500} Capture: {"capture": true, "label": "my_label", "device_index": 0} MemWrite: {"mem_write": true, "address": "0x48000418", "value": "0x40", "probe": "yellow", "width": 32} or {"mem_write": true, "symbol": "blink", "elf_path": "/path/to.elf", "value": "1", "probe": "yellow"} MemRead: {"mem_read": true, "address": "0x48000400", "count": 2, "probe": "yellow", "width": 32, "label": "gpio_pre"} or {"mem_read": true, "symbol": "blink", "elf_path": "/path/to.elf", "probe": "yellow"}

    Serial: "to" is the connection_id from serial_connect. "expect",
        "read_timeout", "line_ending" optional on send steps.
    Capture: "label" and "device_index" optional. PNGs saved to /tmp/stm32-captures/.
    Memory: "probe" accepts board nickname, probe nickname, or ST-Link SN.
        "address" is hex ("0x48000418"); or use "symbol" + "elf_path".
        "width" is 8/16/32 bits, defaults to 32 (auto-detected from symbol size).
        "count" (read only) defaults to 1. "label" (read only) prefixes the result line.
on_failure: "continue" (default) to run all steps, or "stop" to abort on first failure.
filter_responses: If true, expect patterns match only >-prefixed VCP response lines.

Returns: Formatted report with per-step results and a summary line.

Input Schema

Name	Required	Default
`steps`	Yes
`on_failure`	No	continue
`filter_responses`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 28, 2026

TDQS

A4.4/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 mem_write/mem_read spawn a fresh OpenOCD process with tens-of-ms overhead so sub-10ms memory delays are inaccurate, that delay steps are accurate, the on_failure default, the filter_responses semantics, and where capture PNGs land. It lacks any statement about concurrency, permissions, or partial-failure result shape beyond the return summary.

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 primary capability and the important timing caveat, then organized as Args/Returns. Length is justified by the empty schema, though the per-step type reference duplicates some of the prose that follows it.

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?

A complex multi-mode tool with a rich output schema, and the description covers step construction, failure policy, and timing limits. Minor gap: it says 'steps: JSON array' while the schema types it as a string, leaving the encoding requirement implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (steps is a bare string), so the description must do all the work — and it does, enumerating every step type with example JSON, field meanings, defaults, hex address format, symbol+elf_path alternative, width rules, and label semantics. An agent can construct a valid call from this text alone.

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: 'Run a multi-step hardware sequence (serial + SWD memory) in one tool call.' The scope ('sequential, real timing, no tool-call overhead') clearly separates it from one-shot siblings like serial_send and stm32_write_memory.

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 concrete usage contexts: timing-sensitive test sequences, blinking GPIOs over SWD, bit-banging registers, mixed serial/memory flows. It stops short of explicitly naming when to prefer serial_send or stm32_read_memory instead, so the exclusion side is inferred rather than stated.

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