Skip to main content
Glama
smk-h

embedded-mcp-toolkit

by smk-h

serial_enter_uboot

Reboot the device and interrupt autoboot to enter the U-Boot prompt. Configurable detection handles autoboot stop, prompt matching, and fast fails for kernel boot or login states.

Instructions

Enter U-Boot by rebooting the device and stopping autoboot. Detection rules (autoboot prompts, command prompt, verify env keys) are configurable via device config serial.uboot; built-in defaults already cover Hit/Press x any-key/key/SPACE/Ctrl+C/Ctrl+u x stop/interrupt/abort wordings. Pre-check before rebooting (buffer tail, zero side effects): already at a U-Boot prompt returns success without rebooting; at a login/Password prompt fails fast ('reboot' would be consumed as input). restart=true forces a reboot cycle even when already at a U-Boot prompt: sends the U-Boot 'reset' command and re-intercepts autoboot to land back in U-Boot (Linux is never involved; the Linux-side path keeps using 'reboot'). Kernel-boot detection and prompt matching are not gated on an interrupt: devices that boot straight to the kernel fail fast, devices that disable autoboot (bootdelay=-2) succeed fast, instead of waiting out the full timeout. After the interrupt, two-layer strategy: prompt match first; if not matched within a short window, sends 'printenv' and verifies U-Boot env keys. Fails fast on kernel boot or verify timeout.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
restartNoForce a reboot cycle even when the device is already at a U-Boot prompt: sends 'reset' (U-Boot's reboot command) and re-intercepts autoboot to land back in U-Boot — Linux is never involved. Default false returns success without rebooting when already in U-Boot.
timeoutMsNoTotal timeout in ms to wait for the autoboot prompt after reboot (default: 60000 = 60s). Entering U-Boot requires a full device reboot, so the wait is genuinely long — scale generously and convert seconds to ms by multiplying by 1000 (e.g. 90s = 90000).
session_idYesThe session ID returned by serial_open

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.0.0
    • addedInput schema / properties / restart
      Added value: +{
      +  "description": "Force a reboot cycle even when the device is already at a U-Boot prompt: sends 'reset' (U-Boot's reboot command) and re-intercepts autoboot to land back in U-Boot — Linux is never involved. Default false returns success without rebooting when already in U-Boot.",
      +  "type": "boolean"
      +}
    • removedInput schema / properties / timeout
      Removed value: -{
      -  "description": "Total timeout in seconds to wait for autoboot prompt (default: 60)",
      -  "type": "number"
      -}
    • addedInput schema / properties / timeoutMs
      Added value: +{
      +  "description": "Total timeout in ms to wait for the autoboot prompt after reboot (default: 60000 = 60s). Entering U-Boot requires a full device reboot, so the wait is genuinely long — scale generously and convert seconds to ms by multiplying by 1000 (e.g. 90s = 90000).",
      +  "type": "number"
      +}
  2. Addedv1.0.3
  3. Removedv1.0.1
  4. First observedv0.2.2

TDQS

A4.7/5.0
Behavior5/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 it thoroughly. It discloses side effects ('rebooting the device'), no-side-effect fast paths, failure conditions, restart semantics, autoboot detection rules, the two-layer prompt/printenv strategy, and timeout expectations.

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?

The description is long but every sentence carries distinct behavioral information. It is front-loaded with the core purpose, then progressively covers pre-check, restart, detection, and failure modes without repetition or 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?

For a complex tool with no annotations and no output schema, this description is remarkably complete. It covers when it succeeds, when it fails fast, how restart differs, how detection is configured, and what happens after interrupt, leaving little ambiguity for an agent.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3. The description adds genuinely useful semantics beyond the schema, such as explaining that restart forces a reset cycle without involving Linux, and advising timeouts be scaled generously with seconds-to-ms conversion.

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?

The description opens with a specific verb and resource: 'Enter U-Boot by rebooting the device and stopping autoboot.' It clearly distinguishes this tool from sibling serial utilities by detailing the reboot-and-interrupt mechanism and the pre-check shortcut.

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?

The description gives rich situational guidance: when already at a U-Boot prompt it returns success without rebooting, when at a login prompt it fails fast, and restart=true forces a fresh reboot cycle. It does not explicitly name sibling tools as alternatives, but the behavioral conditions make the intended use clear.

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