[moellere]

Follow-up to #18, which I closed as superseded — your /api/serial/write is the better implementation, and this is the one piece of it that is missing.

serial_write is the only serial endpoint the MCP server does not expose:

serial_reset  serial_monitor  serial_output  serial_recover  serial_release

So an MCP-driven client can reboot a board and read what it says, and has no way to reply — which rules out every prompt-driven flow the endpoint was added for: answering a console prompt, driving a firmware CLI, pushing provisioning keys.

Not a safety exclusion — flash, ota, gpio_set and serial_reset are all exposed already.

The description points elsewhere for the reply

Worded so a model does not expect the reply in the return value:

Returns {ok, written}; the device's reply is NOT returned here — the slot's recorder captures it, so read it back with serial_output (or serial_monitor to wait for a pattern).

That is the part an agent gets wrong unprompted. It is the same assumption that led me to couple write and read in #18, before _start_recorder existed — so it seemed worth spending a sentence on.

Verified against a real bench

Driven over stdio against a Pi running current main (I upgraded it for this), with an ESP32-S3 on SLOT29:

serial tools: serial_monitor, serial_output, serial_recover, serial_release, serial_reset, serial_write
params: ['hex', 'newline', 'slot', 'text']   required: ['slot']

  text write         -> {"ok": true, "written": 2}
  hex write          -> {"ok": true, "written": 2}
  missing text/hex   -> {"ok": false, "error": "need 'text' or 'hex'"}
  unknown slot       -> {"ok": false, "error": "slot 'SLOT99' not found"}

One SPECS row, no other changes. Nothing in pytest/ asserts the tool list and manifest.json does not enumerate tools, so there is nothing else to keep in step.