Skip to main content
Glama
microhenrio

io.github.microhenrio/openocd-mcp

by microhenrio

configure

Configure the debug session by setting interface, target, transport, SVD, and ELF files. Only non-empty arguments are applied.

Instructions

Set the chip/project settings for this session. Only non-empty arguments are applied; the rest keep their current values.

interface_cfg : debug-probe OpenOCD config, e.g. 'interface/stlink.cfg' or 'interface/jlink.cfg' target_cfg : chip OpenOCD config, e.g. 'target/stm32g0x.cfg' transport : 'swd' or 'jtag' — set 'swd' for J-Link on Cortex-M (else it picks JTAG) svd_file : path to the chip's CMSIS-SVD file (peripheral registers) elf_file : path to the firmware .elf (variables by name)

Alternatively, put these in an 'openocd-mcp.json' file in your project so they load automatically. Loading a new SVD/ELF takes effect on next use.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
elf_fileNo
svd_fileNo
transportNo
target_cfgNo
interface_cfgNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Discloses that only non-empty arguments are applied and that loading new SVD/ELF takes effect on next use. No annotations to contradict. Could mention persistence across sessions.

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?

Concise, well-organized with clear parameter explanations. No fluff; every sentence adds value.

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?

Covers all parameters and behavior for a configuration tool. Output schema exists so return value explanation is unnecessary; could mention if settings persist.

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%, but description compensates with detailed, example-filled explanations for each parameter, including specific usage guidance for 'transport'.

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?

Clearly states verb 'set' and resource 'chip/project settings for this session'. Distinguishes from sibling tools like 'connect', 'flash_write' by focusing on configuration.

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?

Provides explicit behavior (only non-empty arguments applied) and alternative (openocd-mcp.json file). Lacks explicit when-not-to-use but context is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/microhenrio/openocd-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server