stm32-stlink-mcp

by phryniszak

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Single-step

debug_step

Step through STM32 code execution with modes for stepping over, into, or out of function calls during a debug session.

Instructions

Steps the target: 'over' (next line, step over calls), 'into' (step into calls), or 'out' (finish the current function).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "sessionId": "<sessionId>"
    },
    "name": "debug_step"
  }
}

Input Schema

Name	Required	Description
`mode`	No	default: over
`sessionId`	Yes
`waitForStopMs`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 21, 2026

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Steps the target' implies a mutation of execution state, but it does not mention side effects such as halting or resuming execution, the need for an active session, or the impact of waitForStopMs. The tool acts on a target but no consequences or prerequisites are disclosed.

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 a single, well-structured sentence that front-loads the core action and immediately explains the options. Every word adds value, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a debug tool with three parameters, no output schema, and no annotations, this description is incomplete. It fails to mention the requirement for a valid sessionId, the purpose of waitForStopMs, or any behavioral expectations (e.g., whether the tool returns after the step completes). Users are left guessing about essential operational details.

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

Parameters2/5

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

The description explains the 'mode' parameter well, including the meaning of each enum value and its default. However, schema description coverage is only 33%, and the required 'sessionId' and optional 'waitForStopMs' are left entirely undocumented. The description does not compensate for this low coverage, leaving critical parameters unexplained.

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 clearly states the verb 'Steps' and the target, and enumerates the three modes ('over', 'into', 'out') with brief explanations. This distinguishes it from sibling tools like debug_run (complete execution) and debug_halt (stop execution), making its specific function unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for stepping through code by listing modes, but it does not explicitly state when to use this tool versus alternatives (e.g., debug_run for full execution, or when a breakpoint should be set first). No exclusions or prerequisites are provided, leaving the 'when to use' somewhat implicit.

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