Skip to main content
Glama

读取目标内存

read_mem
Read-onlyIdempotent

Read bytes from a target memory address, resolving symbols and relocation offsets. Automatically re-reads stale frames to return verified data, even while the CPU is running.

Instructions

从指定内存地址读取 n_bytes(别名 length,二者传其一)个字节。addr 支持十六进制(如 '0x20000000')、十进制,或符号名(如 'SystemCoreClock'、'svcrt_task_table'——自动查当前 .axf 符号表解析,命中时返回 addr_note 说明来源);读 App 侧符号可传 reloc_delta="0xF000"(或先用 set_reloc_delta 设全局),工具会把符号的链接地址偏到运行地址;显式数字地址不会被偏移;返回十六进制字节串及 ASCII 视图。脏读防护(verify,默认 "auto"):stop 之后紧跟的第一次读可能整帧返回全 0(真机实测 0x08022000 读出 16 个 00,重读即正确)——auto 会在「首帧整帧退化(全 0x00/全 0xFF)或距最近一次 stop 不足 1 秒」时自动复读,连续两次一致才采纳,并返回 read_confidence(high/low)、reread_count、reread_consistent、degenerate、since_stop_s;首帧是脏值时用 first_read_hex 留证、data_hex 换成可靠值并给 warning。verify=true 总是复读(强制确认),verify=false 关闭(大块搬运省时间);verify 可传字符串也可传 JSON 布尔(true/false 等价于 "true"/"false")。运行态读取(running,默认 "live"):目标全速运行时也能读(真机实测 SRAM 与外设寄存器都读得到,不必先 stop);运行态一律多复读一轮,两次不一致时给read_confidence=medium + read_unstable=true + while_running,并把「该地址本来就在被 CPU改写」与「这次读被运行中的目标打断了」两种可能都写明(不替你选一个)。要取某一瞬间的一致快照,用 running="halt"(停-读-走):会暂停目标再恢复,返回paused_ms / was_running / resumed / halt_note 如实交代代价,恢复失败会告警。**看到 read_confidence="low"/"medium" 或 degenerate 时不要据此下结论(例如「读到 0 就判定变量被清零」)。**勿越界读外设保留区,可先 query_memory_map 确认范围。 【输出控制】本工具返回体可能较大,额外接受三个可选参数:compact=true(精简)/ max_lines=N(限制列表条数)/ full=true(强制全量)。默认都不传=行为不变;被裁掉的内容一定会在返回体的 output 字段里如实上报(truncated/dropped/trimmed/hint),不会静默丢数据。也可用环境变量 MDKDEBUG_COMPACT=1 / MDKDEBUG_MAX_LINES=N 设全局默认。 【参数】必填: addr, n_bytes;可选: length, reloc_delta, verify, running, compact, max_lines, full(别名:n_bytes 也可写作 length) 【调用示例】{"addr": "0x20000000", "n_bytes": 16} 【参数别名】addr ← address/expression/location/name/pc/symbol/target;n_bytes ← bytes/count/nbytes/size。规范名以上方【参数】行为准;未列出的参数名会被拒绝,不会静默忽略

Input Schema

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

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.8/5.0
Behavior5/5

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

Annotations give readOnlyHint=true, idempotentHint=true, destructiveHint=false; the description adds substantial behavioral context beyond those: the dirty-read protection with read_confidence levels, reread_count, reread_consistent, degenerate status, and since_stop_s; the behavior for running='live' vs running='halt' with paused_ms/resumed flags; recovery-failure warnings; and explicit instructions that low/medium confidence should not drive conclusions. This transparently discloses surprising real-world behavior (first-frame zeros, instability during live reads) that the annotations do not capture. No contradiction.

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 dense and information-rich, front-loading the core purpose and then drilling into critical behaviors (dirty-read, running modes, output control). Every major sentence serves a functional purpose; the structure is logical (purpose → address formats → dirty-read → running modes → output control → parameters/examples). It is long but justified by the complexity of a memory-read tool with subtle consistency semantics.

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 9-parameter tool, the description is thorough across all dimensions: parameter meaning, behavioral caveats, output control, environment variables, and examples. The output schema further clarifies return fields. Even the edge case of a dirty first frame is documented with a warning. Nothing an agent needs to call this correctly is missing.

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

Parameters4/5

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

Schema description coverage is 33%, so the description carries significant burden for the 9 parameters. It clearly explains addr (with formats, hex/dec/symbol, and reloc_delta interaction), n_bytes/length alias, verify modes, running modes, and compact/max_lines/full with the environment-variable defaults. It also lists aliases. This adds meaning well beyond the schema, and while more detail could be given for reloc_delta's concrete semantics, the description answers the essential usage questions.

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 (read), resource (memory at an address), and quantity (n_bytes), with distinctive scoping: address formats, symbol resolution, relocation offsets for App-side symbols, and a dirty-read auto-reread mechanism. This clearly differentiates read_mem from its siblings such as read_variable (which targets debugger variables) and read_console_output (console text).

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 conditions across multiple scenarios: when to use reloc_delta, how to avoid dirty reads (verify auto mode with automatic retries, thresholds for degenerate frames), how to obtain a consistent snapshot (running='halt'), and when NOT to conclude from low-confidence reads. It also references query_memory_map for range validation and notes the App-side symbol offset flow via set_reloc_delta.

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