ChannelTerm

Overview Schema Source Related Servers Discussions Admin

Enter U-Boot

terminal_enter_uboot

Destructive

Interrupts a U-Boot countdown on an existing serial session and confirms entry via host-side raw-byte matching, enabling access to the U-Boot prompt during boot.

Instructions

Interrupt one U-Boot countdown on an existing serial Session and confirm entry using Host-side raw-byte matching. No skill installation is required.

Select: use terminal_list_sessions if the intended Session is unknown. If current evidence already establishes an idle U-Boot prompt, use terminal_write for authorized commands, not this entry tool or Bash-only terminal_exec. An old buffered prompt alone does not establish current state.

Prepare: inspect boot output with terminal_read (hex/base64 for non-UTF-8 bytes), supplied firmware configuration, or settings verified for this board and firmware. Select the literal markers and exact interrupt bytes from that evidence. An explicit any-key prompt permits a space; a generic countdown does not identify the required key or string. If a required setting is unknown, ask the user only for that missing detail before calling; reuse known answers. Do not guess or cycle through keys. The tool does not discover settings or ask questions during execution.

Run: stay within the user's authorized hardware action; an explicit request to enter U-Boot need not be reconfirmed. Choose wait_reset for manual reset, or reboot only from a verified idle Bash prompt with an explicit command. Before calling, save the terminal_session_events cursor; in another request observe the matching OPERATION_STATE ready event before manual reset. Prepare before resetting rather than relying on model round trips during the countdown. The Host manages its lease and sends the interrupt at most once.

Verify: only status entered confirms a fresh line-bound prompt after countdown; bytes_written alone does not. Check isError and structuredContent.result for partial evidence. boot_started means boot proceeded; timeout means entry was not confirmed, not that the key was wrong. On failure report evidence; do not automatically change keys or reboot again. Cancellation releases ownership without recovery keys or closing a healthy Session; a submitted reboot cannot be undone.

Limits: a silent countdown or firmware-disabled interruption is not handled by this flow; request firmware details instead of inventing a trigger. There is no dedicated password/credential-protection workflow; do not solicit secrets in chat or treat tool arguments as protected credential storage.

Input Schema

Name	Required	Description
`mode`	Yes	wait_reset only listens for a user-triggered reset; it does not reset hardware. reboot sends reboot_command through a verified idle Bash prompt, never through U-Boot or another shell.
`session_id`	Yes	Active Session ID or short reference.
`timeout_ms`	No	1..180000 milliseconds; default 60000.
`diagnostics`	No	Default metadata. capture explicitly opts into retaining sensitive raw terminal evidence for 15 minutes or earlier eviction. If diagnostic_id is returned, download via terminal_read_diagnostic or the diagnostics CLI before expiry or Host exit.
`prompt_pattern`	Yes	Exact 1..256 byte prompt line from this firmware, including trailing spaces (e.g. 'Zynq> ' or '=> '). Matched against raw bytes at an observed line boundary after countdown, not terminal colors or cursor position.
`reboot_command`	No	Explicit single-line Bash command; reboot mode only.
`countdown_pattern`	Yes	Literal 1..256 byte countdown marker from this firmware's output; no regex or wildcards. Use a distinctive fixed portion before changing digits, e.g. 'Autoboot in '. This text alone does not specify the interrupt key.
`interrupt_data_hex`	Yes	The verified interrupt key or complete non-secret string: 1..32 bytes as hexadecimal pairs without spaces, sent at most once. Encodings: space='20', Esc='1b', Ctrl+C='03', 'stop'='73746f70'. These are alternatives for firmware explicitly accepting that input, not a sequence of probes. No default key; no CR/LF is appended. Ask the user if the required input is unknown.
`boot_started_patterns`	Yes	1..8 literal markers showing boot has proceeded, each 1..256 bytes. Use verified firmware output, not generic U-Boot banners; a match takes precedence over prompt success.

Output Schema

Name	Required	Description	Default
`status`	Yes
`dropped`	Yes
`elapsed_ms`	Yes
`output_end`	Yes
`session_id`	Yes
`operation_id`	Yes
`output_start`	Yes
`bytes_written`	Yes
`diagnostic_id`	No
`prompt_cursor`	Yes
`prompt_matched`	Yes
`countdown_cursor`	Yes
`diagnostic_error`	No
`countdown_matched`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.2Oct 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations (destructive, openWorld, non-idempotent) are consistent with the text, which adds substantial context: the interrupt is sent at most once, the Host manages the lease, a submitted reboot cannot be undone, cancellation releases ownership without recovery keys, diagnostics capture retains raw evidence for 15 minutes, and no credential storage exists. It also explains failure semantics (timeout means unconfirmed, not wrong key) that no annotation conveys.

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?

It is front-loaded with a one-line purpose and organized under Select/Prepare/Run/Verify/Limits, which suits a timing-sensitive destructive operation. Some material duplicates the schema (hex encoding examples, literal-marker rules), so it is a bit longer than strictly needed.

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?

With an output schema present the description need not document return shapes, yet it still explains status semantics (entered, boot_started, timeout, isError, structuredContent.result), the cursor/OPERATION_STATE sequencing, and unsupported cases (silent countdown, firmware-disabled interruption). Nothing an agent needs to call this correctly and recover from failure is missing.

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?

Schema description coverage is 100%, so the schema already documents every parameter, including the interrupt hex encodings and countdown pattern rules that the description largely restates. The description adds framing ("no default key", "do not guess or cycle through keys") but not new per-parameter semantics beyond the schema, so baseline 3 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?

The opening sentence names a specific verb, resource, and mechanism: interrupting a single U-Boot countdown on an existing serial Session with Host-side raw-byte matching. It explicitly differentiates from siblings terminal_write, terminal_exec, and terminal_list_sessions, so an agent can route without opening another schema.

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?

It states when to select this tool, when not to (idle prompt already established → terminal_write; unknown Session → terminal_list_sessions), and the preconditions that must hold before calling. It also names the alternatives and the evidence required to pick them, leaving nothing to inference.

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

Deploy Server