Reads a bounded small 4D-STEM block via a read-only Gatan stream, creating a separate calibrated DM image without changing the source file.
用Gatan原生只读流读取最多256个扫描位置且不超过16MiB的小4D块，创建独立DM图像并复制四轴物理标定；不修改原文件。
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | dm_4dstem_open返回的有界文件索引id | |
| scan_bounds | Yes | [[scan_y0,scan_y1],[scan_x0,scan_x1]]，原始NumPy坐标，右端排除 |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden well: it states the operation is read-only, creates an independent DM image, copies physical calibration, and does not modify the original file. It is still somewhat silent on the returned result or error behavior, but the key side effects and safety profile 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence with no wasted clauses. It front-loads the core operation and then adds the important constraints and non-destructive behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no annotations and no output schema, the description provides enough operational context: source access mode, size limits, image creation, calibration copying, and non-modification. It could be more complete by explaining what the returned independent DM image reference looks like, but the essential calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both dataset_id and scan_bounds are already well documented in the schema. The description adds context about the size limits of the scan bounds but does not add meaning beyond the schema for the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action and resource: read a small 4D block using Gatan native read-only streaming, create an independent DM image, and copy four-axis calibration. It clearly distinguishes this as a bounded block-read operation, but it does not explicitly name sibling alternatives such as dm_4dstem_open or dm_4dstem_virtual.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The limits 'at most 256 scan positions' and 'not exceeding 16 MiB' imply when this tool is appropriate, namely for small 4D blocks. However, the description does not explicitly say which sibling to use for larger blocks or other 4D-STEM workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.