Skip to main content
Glama

设置断点

set_breakpoint
DestructiveIdempotent

Sets a software breakpoint at a function, variable, or address during Keil debug sessions. Automatically normalizes Thumb-bit addresses and returns failure diagnosis with next-step guidance.

Instructions

在指定符号或地址处设置软件断点。expr 可为函数名/变量名(如 'main')或地址(如 '0x08001034')。返回是否成功。地址路径与符号路径做同一套归一:入参地址若带 Thumb 位(bit0=1,常见于函数指针)会自动按偶地址下断并返回 thumb_bit_stripped/address_normalized——真机实测 Keil 的 BS 对奇数地址一律报 error 57: illegal address,而符号名路径经 calc_expression 拿到的是偶地址,所以只有裸地址会踩这个坑。设断点失败时返回 diagnosis(错误码含义 + 地址落在哪个区 + 是否在 .axf 覆盖范围 + 下一步建议)。另外:设断点走命令窗口 BS,会触发 Keil 异步推送断点消息,紧随其后的命令响应可能被污染(本工具已改为先 calc_expression 取地址再 BS 0xaddr);设断点后立即 run/step 前需稍等异步消息落地。需已进入调试且配置 .axf。 【参数】必填: expr;可选: 无 【调用示例】{"expr": "main"} 【风险】高——不可逆:会改写目标 Flash/内存,或关闭/重启用户的 Keil 实例。执行前确认目标与工程正确。 【参数别名】expr ← addr/address/expression/func/function/keyword/location/name/pattern/pc/query/symbol/target/var/variable。规范名以上方【参数】行为准;未列出的参数名会被拒绝,不会静默忽略

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
exprYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, it discloses the Thumb-bit normalization behavior, Keil error 57 on odd addresses, asynchronous message pollution after BS, the need to wait before run/step, and the diagnosis payload on failure. These are exactly the non-obvious behavioral traits an agent needs.

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?

The description is long but structured with bolded key points, parameter/example/risk/alias sections, and no filler. It earns its length because the tool is high-risk and has several platform-specific edge cases, though it remains denser than strictly necessary.

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?

Given the high-risk mutation context, the description covers prerequisites, operand semantics, return behavior, failure diagnosis, operational ordering caveats, and risk. With an output schema present, nothing essential is missing for correct invocation.

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?

With 0% schema coverage, the description carries the full burden and succeeds: it explains expr accepts symbol names or addresses with formatting examples, documents normalized outputs, lists parameter aliases, and warns that unknown parameter names are rejected rather than ignored.

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-resource pair: '在指定符号或地址处设置软件断点' and immediately gives examples of expr (function/variable name or address). This clearly distinguishes it from sibling tools like clear_breakpoint and list_breakpoints.

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?

It states clear prerequisites ('需已进入调试且配置 .axf') and gives a concrete call example. It does not explicitly name alternatives or when not to use it, but the operational context is unambiguous.

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