Skip to main content
Glama

列出断点

list_breakpoints
Read-onlyIdempotent

Lists Keil debug session breakpoints, showing logical, hardware FPB, and persistent tables to identify and clean residues.

Instructions

列出断点。返回两部分:① 本服务内部记录(breakpoints/内部 id,用于按 bp_id 清除);② real 字段——本会话 Keil 的真实断点表(解析命令窗口 BL 输出获得,含 Keil 断点编号、类型 exec/access、地址、CNT、enabled)。注意:真机实测本版 Keil 的 CNT 是断点的计数条件设置值(.uvoptx 的 break_if_rcount),不随命中递增,不能当命中次数用。real 才是板上实际生效的断点:.uvoptx 持久化断点、数据观察点都会出现在这里。注意清除数据观察点必须按 Keil 编号(按地址会报 error 72)。另附 uvoptx 字段暴露工程里 BK 清不掉、下次进调试会自动恢复的持久化断点。③ hardware 字段:直接读 Cortex-M 的硬件断点单元 FPB(FP_CTRL@0xE0002000 / FP_COMP0@0xE0002008),给出 check(clean/residue/unavailable)、启用的比较器与地址。real 是 Keil 的逻辑表、hardware 是硬件里实际写着的项——两者是两回事:BK * 之后 real 可能为空、FPB 里却还留着,J-Link 会一直报 "two breakpoints at the same address"。hardware.orphans 给出「硬件里有、real 里查不到」的地址(这类就是清不掉的残留);读不到 FPB 时为 unavailable,不当作「干净」(没测 ≠ 没有)。 【输出控制】本工具返回体可能较大,额外接受三个可选参数:compact=true(精简)/ max_lines=N(限制列表条数)/ full=true(强制全量)。默认都不传=行为不变;被裁掉的内容一定会在返回体的 output 字段里如实上报(truncated/dropped/trimmed/hint),不会静默丢数据。也可用环境变量 MDKDEBUG_COMPACT=1 / MDKDEBUG_MAX_LINES=N 设全局默认。 【参数】必填: 无;可选: compact, max_lines, full 【调用示例】{}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo强制返回全量:忽略 compact/max_lines 与对应环境变量的默认值。当上面两项让你只看到部分数据、而你要据此下结论时,用它取回完整结果。
compactNo精简返回体:去掉空值字段,把列表元素中取值完全相同的字段提到 output.shared,并把 usage/note/hints 之类**说明性**长文本截断到 200 字符(数值与内容字段不动)。被裁掉的东西都会列在 output 里,绝不静默丢弃。不传则不改行为(受 MDKDEBUG_COMPACT 影响)。
max_linesNo限制返回的列表条数(只作用于元素为对象的列表,如 results/items/tools):最多 N 条,其余丢弃并在 output.truncated/dropped/hint 里如实上报。0 或省略=不限(受 MDKDEBUG_MAX_LINES 影响)。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already mark the operation read-only, idempotent, and non-destructive, and the description adds substantial behavioral context beyond that: it warns that CNT is not a hit counter, that unavailable FPB reads must not be treated as clean, that orphaned hardware breakpoints can persist after BK *, and that truncated output is always reported rather than silently dropped.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is well organized into numbered sections and front-loaded with the main return structure, but it is quite long and includes tangential notes (e.g., how clear_breakpoint must use Keil numbers) and an internal inconsistency ('返回两部分' followed by three parts). Every sentence is informative, yet the description would benefit from tightening.

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 complex read-only inspection tool, the description covers the internal, Keil, hardware, and persistence views, explains output-control behavior and truncation honesty, and supplies caveats needed to interpret results correctly. With an output schema present and annotations covering safety, no essential calling or interpretation information 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 coverage is 100%, and each optional parameter already has a rich description explaining its effect and interaction with environment variables. The description repeats some of this in the output-control section, but per the rubric the schema does the heavy lifting, so no more than the baseline 3 is warranted.

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 clear verb+resource statement ('列出断点') and enumerates the distinct result sections (internal records, Keil real table, and hardware FPB state), so an agent knows exactly what this tool returns. It separates this from set/clear breakpoint tools by focusing on inspection and even calls out Keil-vs-hardware domains.

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 intended use as the read-only inspection counterpart to set_breakpoint/clear_breakpoint is implied rather than stated; there is no explicit when-to-use or when-not-to-use guidance versus siblings. The rich interpretation guidance (real vs hardware vs uvoptx) helps an agent understand results, but not when to choose this tool over an alternative.

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