Skip to main content
Glama

查询目标器件信息(芯片型号/Flash/RAM)

target_info
Read-onlyIdempotent

Reads the target chip's IDCODE register to identify the device model and return its Flash/RAM capacities and memory layout. Use this to verify chip selection or diagnose capacity mismatches during debugging.

Instructions

查询目标芯片信息:实时读 DBGMCU->IDCODE 寄存器得到 DEV_ID/REV_ID 并映射到型号,返回标称 Flash/RAM 容量与内存布局。排查“资源吃紧/选错型号/容量不符”时先调它。idcode 实时读取需已进入调试(内存读依赖调试会话);非调试态仅返回静态布局信息。注意:DEV_ID = IDCODE 低12位(&0x0FFF)、REV_ID = 高16位、IDCODE 为小端字节序(本工具已正确解析);实时读 IDCODE 需已进入调试,非调试态仅返回静态布局信息。未收录型号返回标称容量 None + 提示按丝印确认。 【参数】无(直接调用) 【调用示例】{}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.8

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/destructive annotations, the description discloses the debug-session dependency for live IDCODE reads, the static fallback in non-debug mode, endianness handling, bit-field mapping, and the behavior for unknown models. This is valuable context the annotations do not provide.

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 purpose and usage guidance are front-loaded, but the debug-session requirement is stated verbatim twice)Skip, adding unnecessary redundancy. The empty call example is also low-value given an empty schema.

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?

The description covers invocation mode requirements, fallback behavior, edge cases like unknown chips, and result semantics. Since an output schema exists, return structure is already handled; nothing needed to call this tool 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?

The tool has zero parameters and the schema coverage is 100%, so there is nothing extra to clarify. The description explicitly confirms no arguments are needed and gives an example empty call, which fits the 0-param baseline.

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 states a specific action: query target chip info by reading DBGMCU->IDCODE, mapping DEV_ID/REV_ID to a model, and returning nominal Flash/RAM capacity and memory layout. This is clearly distinct from siblings like read_mem or get_version.

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 explicitly says to call this tool first when troubleshooting resource pressure, wrong chip model, or capacity mismatch, and it clarifies debug vs non-debug behavior. However, it does not name alternative sibling tools or state when not to use it.

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