Skip to main content
Glama
Sign In
agentic-hil

agentic-hil

by agentic-hil
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

reset_target

Restart connected firmware on an embedded board through the debugger, keeping flash intact. Requires allow_reset; stop any open debug session first.

Instructions

Reset the board through the in-circuit debugger or programmer: the firmware restarts, flash is kept. Replaces st-util. Needs allow_reset (else permission_denied). Refused with resource_busy while a debug session is open: debug_stop_session first. To check the board without a reset use probe_target. Failures: reset_failed (reset not confirmed), timeout (one command over debugger.timeout_s).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "reset_target"
  }
}

Input Schema

NameRequiredDescriptionDefault
modeNoDefault 'run' (core executes); 'halt' stops the core at reset; 'init' also runs the reset-init script (clocks, wait states, watchdog), OpenOCD-only, else not_supported.run

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.22.1
    • changedInput schema / properties / mode / description
      Previous value: -"How the target is left: 'run' executes, 'halt' stops the core, 'init' also runs the reset-init script (clock tree, wait states, watchdog) and is OpenOCD-only: other backends answer not_supported."New value: +"Default 'run' (core executes); 'halt' stops the core at reset; 'init' also runs the reset-init script (clocks, wait states, watchdog), OpenOCD-only, else not_supported."
  2. First observedv0.22.1-dev.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description goes well beyond, disclosing the non-destructive reset semantics (flash kept), the allow_reset permission gate with the permission_denied result, the resource_busy conflict and its resolution, and the specific failure modes reset_failed and timeout with debugger.timeout_s.

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 core action and its non-destructive semantics, then preconditions, alternative, and failure codes in dense, zero-waste sentences. Every clause is actionable; nothing is 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 single-parameter reset tool with no output schema, the description covers outcome semantics, prerequisites, session conflict handling, alternatives, and error codes — everything an agent needs to invoke it correctly.

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% and the single 'mode' enum is fully documented in the schema (run/halt/init with the not_supported caveat), so the description adds no parameter meaning. Baseline 3 is appropriate when the schema does all 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 (reset) and resource (the board) via the in-circuit debugger/programmer, and immediately clarifies the key semantic: firmware restarts but flash is kept. It explicitly distinguishes itself from the sibling probe_target ('to check the board without a reset').

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?

Gives explicit when-not guidance: it is refused with resource_busy while a debug session is open, and directs the agent to call debug_stop_session first. It also names the alternative (probe_target) and the condition that selects it, plus the allow_reset prerequisite.

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

Deploy Server

Other Tools