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

With no annotations, the description carries the full load and does disclose real behavioral traits: it writes multiple artifact types into a new directory, requires that directory not pre-exist, uses operation_id + result_dir for later lookup, and critically states it does not automatically rerun tasks in an uncertain state. That last point is valuable idempotency/failure-handling context. Missing are runtime/long-running expectations and failure modes.

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 optionality caveat is front-loaded and each sentence carries distinct information (scope, outputs, prerequisite, alternative, state semantics). It is dense but not padded; the only mild weakness is that the closure on operation_id/result_dir feels appended rather than integrated.

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 6-parameter tool with a nested object and no output schema, the description compensates well by enumerating what gets written (numerical values, plots, report, rerun script). The remaining gap is capture_dir's expected contents and whether the call is synchronous, but an agent has enough to invoke it correctly.

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 50%; roi, top_n, and the profile endpoints are already documented in the schema, so the description needn't repeat them. It does add meaning to operation_id and result_dir (their role in querying/state tracking), but capture_dir and the profile.width field are unexplained in both places, so the gap is only partially closed.

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 the concrete operations (combined statistics, profiles, full FFT on the captured package) and the artifacts produced (values, figures, report, rerun script), which is a specific verb+resource statement. It implicitly separates itself from the single-purpose siblings by noting simple measurements should use individual tools, though it never names dm_stats/dm_profile/dm_fft directly.

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?

It explicitly states this is optional and not a required DM step, gives the condition for preferring alternatives ('simple measurements → use individual tools'), and adds an environmental prerequisite (needs an independent report environment). What it lacks is naming which sibling tools to use instead, leaving the agent to infer the mapping.

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

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

With no annotations, the description carries the burden and does well: it discloses the concurrency hazard (no atomic snapshot of pixels and calibration in the DM API), the instruction not to edit the source during capture, and exactly what the package contains (2D ROI, calibration, hash). It does not state what the call returns to the caller, which is the remaining gap given there is no output schema.

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?

Three compact sentences with no filler: the action and output come first, followed by downstream usage, then the capture-time constraint. Each sentence contributes a distinct piece of information.

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 3-parameter capture tool with no annotations and no output schema, the description covers purpose, storage contents, downstream contract, and the non-atomicity race. Missing only the return payload and any failure/retry guidance, which keeps it short of a 5.

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%, including the default 'front' image_id, rect boundary semantics, and the new-directory rule, so the schema already does the heavy lifting. The description only reiterates the default image and the directory concept without adding syntax or edge-case meaning. A baseline 3 is appropriate.

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?

It states a specific verb and resource ('解析图像…保存有界二维像素副本与标定'), names the output location, and positions the tool within the workflow by noting that subsequent 2D preview and analysis read this package. An agent can distinguish it from dm_2d_preview/dm_2d_analyze, which consume, not create, the package.

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?

It clearly implies this is the prerequisite capture step ('后续二维预览和分析固定读取该包') and gives an exclusion ('捕获期间请勿编辑源图'). It does not name an alternative for partial needs (e.g. dm_crop for an in-memory ROI), so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return payload (MCP image block, local PNG path, capture-time calibration), the critical scientific caveat that display stretching must not be used for computation, and an explicit failure-mode instruction not to pretend to have seen an image. It does not state that a PNG file is written to disk as a side effect, which would be the remaining gap for a mutation-adjacent tool.

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?

Three tight sentences, front-loaded with the core action and output, followed by the compute caveat and the sibling routing. No sentence is filler, and each adds a distinct piece of information.

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?

There is no output schema, and the description compensates by enumerating the return contents (image block, PNG path, calibration). Combined with the display-vs-compute warning and the honest-failure instruction, an agent has enough to call it correctly; only file-write side effects and preview failure conditions are underspecified.

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 coverage is 75%, so most parameters are already documented, but the description adds real semantic value by explaining what roi and profile actually do (overlay regions and profile strips on the preview) rather than just their types. max_side is left entirely to the schema, so it is not fully compensatory.

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?

States a specific verb and resource: generate a display-linear PNG plus accurate source coordinate mapping from a dm_2d_capture directory, with optional ROI and profile overlays. It explicitly distinguishes itself from dm_2d_analyze, so an agent can route without opening either schema.

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?

Names the alternative explicitly ("只看图无需调用 dm_2d_analyze") and gives the condition that selects this tool: pure visual inspection. The inverse condition (quantitative measurement requires dm_2d_analyze) is only implied via "显示拉伸不用于计算", so exclusion guidance is not fully spelled out.

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

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

With no annotations at all, the description carries the full burden and does disclose real behavior: it is read-only, running state returns 'unknown' rather than a stopped verdict, and it will not auto-resend captures or analyses. That resolving of the 'running' ambiguity is valuable, though the response shape beyond status+hash is not described.

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?

Front-loaded with the scoping verb '只查询' and packed into a few semicolon-separated clauses with no filler. The density makes it slightly run-on, but every clause adds distinct information.

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?

No output schema exists, so the description should explain return values; it names 'status and output hash' and the running->unknown case, but does not describe the full response envelope. Adequate for a simple read tool, but not fully complete given the absence of an output schema.

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 coverage is 100%, so the two parameters are already documented as result_dir/capture_dir. The description adds a constraint the schema does not encode: exactly one of the two must be supplied (both are optional in the schema), which is genuine value beyond structured fields.

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 gives a specific verb and resource: query only (只查询) the status and output hash found in a capture or analysis directory. The agent can distinguish this from dm_2d_capture/dm_2d_analyze, which produce those directories, but no sibling is named to make the contrast explicit.

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?

Usage is implied rather than stated: the tool reads a capture or analyze directory, and '两种目录参数恰选其一' (choose exactly one of the two directory params) constrains invocation. It never explicitly says when to call this versus running dm_2d_capture or dm_2d_analyze again, and there are no exclusions beyond that clause.

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

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

No annotations, so the description carries the burden. It does valuable disclosure: read-only, only parses a bounded header rather than fully opening the image, and later reads happen in small chunks via a native binary stream. But it omits failure behavior, permission/auth needs, and what a successful open returns.

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?

Front-loaded with the core purpose, then constraints, then axis semantics. Dense but every sentence carries information; no obvious waste.

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?

With no output schema and 3 fully required parameters at 0% schema coverage, the description should do more. It covers the axis parameters well but leaves path semantics and any notion of the returned handle or object unspecified.

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 coverage is 0%, so the description must compensate. It adds real meaning for scan_axes and detector_axes by giving the expected NumPy assignments ([0,1] and [2,3]), which the schema only describes as 2-element integer arrays. But the path parameter is left entirely undocumented.

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?

States a specific verb and resource: read-only indexing of the unique 4D dataset in uncompressed uint8 DM4 files. The purpose is clear, but it does not explicitly differentiate itself from siblings like dm_open or dm_4dstem_read, leaving the agent to infer the open-vs-read relationship.

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 description implies this is the first step before chunked reads (后续...按小块读取), giving implied usage, and it states a hard precondition (uncompressed uint8 only). However, it never explicitly says when to use this over dm_open or dm_4dstem_read.

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

Does 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.

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

With no annotations, the description carries the full burden and discloses important behavior: chunked execution, a per-call scan-position limit, uint64 integer summation, and that native publishing requires exact dtype conversion. It also notes the side effect of publishing independent DM images, though overwrite and return-payload behavior remain unstated.

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 dense but front-loads the core computations and then lists important constraints. Most clauses earn their place, though the semicolon-separated style is somewhat compressed.

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 compute tool with no annotations and no output schema, the description adequately covers what is computed, what is published, chunk limits, numeric precision, and exclusions. It still leaves some gaps around the return structure and image naming/reference behavior.

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 75%, so the schema already documents most parameters including dataset_id, scan_bounds, and detectors. The description reinforces scan chunking and dtype/summation behavior but does not add much parameter-level meaning beyond what the schema provides.

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 specific computations (virtual circular BF/annular ADF, full-detector total intensity, average/total diffraction patterns) and states that standalone DM images are published. It is clearly a 4D-STEM virtual detector computation tool, distinguishable from sibling data-access and calibration tools.

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?

It gives a concrete usage constraint: at most 8192 scan positions per call and batching to cover the full scan. It also explicitly excludes hardware angle calibration and HAADF determination, though it does not name an alternative sibling for those tasks.

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

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

With no annotations, the description carries the full load and does well: it declares the operation is non-destructive ('原图保持不变'), that the bottom-right boundary is exclusive, that a new image id plus calibration are produced, and that 3D/4D input is unsupported. It does not say how it behaves on invalid or out-of-bounds rectangles (schema covers that) or whether a new dataset is registered in the tree.

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?

One dense but well-ordered sentence: the action and return first, then the boundary rule, then the non-destructive guarantee and the 3D/4D restriction. No filler, and the most decision-relevant facts are front-loaded.

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 tool with no output schema, the description does cover the return payload (new image id, calibration, shape) and the core constraints, which is what an agent needs to call it. Minor gaps remain around error/failure behavior and whether the new image appears in the dataset listing.

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 the baseline is 3. The description adds genuinely useful semantics beyond the schema by specifying the return shape as shape[y,x], which helps an agent keep the [x0,y0,x1,y1] rect ordering straight against NumPy axis ordering.

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 gives a specific verb and resource (natively crop a 2D independent sub-image inside DM) and immediately states what it returns (new image id, calibration, NumPy shape[y,x]). The explicit 'does not support direct 3D/4D cropping' clause separates it from the 4D-STEM siblings.

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?

It plainly states a when-not condition: 3D/4D arrays cannot be cropped directly. However, it never names the alternative tool (e.g. dm_4dstem_virtual or dm_2d_capture) an agent should switch to when that limitation applies, so routing is inferred rather than explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. It helpfully discloses the exact returned fields (id, name, shape, dimensions, dtype, type hint, per-dimension calibration), but it does not state read-only status, permissions, side effects, or error behavior.

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 compact sentence with a front-loaded verb and scope, followed by a tightly packed list of returned data fields. Every element describes what the tool yields, and the closing usage constraint is short and useful.

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?

Because no output schema exists, the description must convey the return shape, and it does so by enumerating the fields and type hints. For a zero-parameter read enumerator this is nearly complete, though it omits behavior for empty results or DM-not-open errors.

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?

The tool has zero parameters, so there is no parameter semantics to document in the description; the baseline for zero parameters is 4. The empty schema with additionalProperties false is consistent and needs no further parameter explanation.

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 uses a specific verb (枚举/enumerate) and resource (当前 DM 中所有图像数据集), and it lists the returned fields including type hints and calibration data. It does not explicitly contrast itself with siblings such as dm_metadata or dm_spectrum_info, so it falls short of the highest level.

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 phrase 分析前必查 explicitly tells the agent to call this tool before analysis, giving clear usage context. It does not provide when-not-to-use conditions or name alternative tools, so it is strong but not exhaustive.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses overwrite prohibition, writer selection per format, dtype-preserving uncompressed TIFF output with embedded calibration, and calibration side files for every format. It stops short of stating error behavior when the target file already exists or what is returned, but the key behavioral traits are covered.

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?

A single dense paragraph that front-loads the core constraint (new file, no overwrite) and then proceeds format by format. Every clause is substantive, though the compressed technical phrasing makes it slightly harder to scan.

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 three-parameter export tool with no output schema and no annotations, the description covers format-specific writing behavior and side-file generation but omits what the tool returns (path, list of side files?) and how it fails when the target exists. Adequate but with clear gaps.

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 the schema already documents path, format, and image_id in detail. The description's format list and PNG rejection merely restate what the schema's format parameter already says, adding no new parameter semantics beyond the baseline.

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?

States a specific verb and resource ('导出到新文件' – export to a new file) and enumerates supported formats, so the agent knows this writes datasets to disk. It does not, however, distinguish itself from the sibling dm_spectrum_export, leaving ambiguity about which export path applies to spectra vs images.

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 description establishes key usage constraints ('禁止覆盖' – no overwrite, and PNG is rejected) and implies format selection, but gives no explicit when-to-use guidance against sibling tools such as dm_spectrum_export or dm_2d_capture. The agent must infer the intended scope from the format list.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the DC is mean-subtracted and that frequencies/spacings are calibrated, and it warns that d_pix is only a spectral grid radius, not 1/pixel or lattice spacing. However, it does not state whether the operation is read-only, whether it changes image state, or how errors are handled.

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 two tightly written sentences with no waste. It front-loads the purpose and return contents, then adds a single caveat that directly prevents a common misinterpretation.

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 tool with rich schema descriptions but no annotations and no output schema, the description does cover the core purpose and some output semantics. It remains incomplete because it does not explain output structure in detail, usage conditions versus siblings, or behavioral traits such as read-only status and error behavior.

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 the schema already documents rect, top_n, and image_id in detail. The description adds no additional parameter-level meaning beyond the caveat about d_pix, which is not one of the input parameters. A baseline 3 is appropriate when the schema carries the parameter documentation.

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 clearly states a specific operation, "二维 FFT", and summarizes what it returns: mean-subtracted DC, spectral grid coordinates, and calibrated spatial frequencies/spacings. It does not distinguish this tool from sibling analysis tools such as dm_2d_analyze or dm_spectrum, so it falls short of the sibling-differentiation bar for a 5.

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 description implies the tool is for 2D FFT analysis but gives no explicit guidance on when to use it instead of alternatives. The d_pix caveat is useful for interpreting output, but it is not a when-to-use rule or an alternative-selection guideline.

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

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

With no annotations provided, the description carries the full burden and does meaningful work: it discloses the path_status states (found/not_found/unavailable), the complete and issues signals, and warns not to treat truncation or read failure as missing labels. Missing are permissions/auth requirements and any rate or size limits.

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?

Three clauses with the purpose front-loaded and then the verification order. No filler, though the run-on second sentence packs several ideas together.

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?

There is no output schema, so the description usefully explains what the caller will see back (path_status, complete, issues) and how to interpret it. What remains uncovered is failure semantics like permissions or concurrency, which is a minor gap for a read tool.

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 prefix, image_id and max_depth are already fully documented in the schema. The description only adds the informal notion of a 'subtree budget' and the resolve-prefix-first step, adding little beyond the structured fields — baseline 3.

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 first sentence states a specific verb+resource: '读取指定元数据子树' (read the specified metadata subtree). It is clear what the tool does, though it never names which sibling (e.g. dm_datasets, dm_profile) it should be preferred over.

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?

It gives an explicit read order — check path_status first, then complete/issues, locate the prefix before reading against the subtree budget — which tells the agent how to sequence calls. It stops short of naming alternatives or stating when not to use this tool.

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

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

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that the tool returns a list of image ids and loads acquisition metadata/calibration for dm3/dm4 files, but it omits other relevant behavior: whether DigitalMicrograph must be running, what happens on invalid paths, and whether opening replaces or adds to existing documents.

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?

Two compact sentences with the main action and return value front-loaded. No sentence is redundant; the metadata-loading note adds useful context without bloat.

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 low-complexity file-opening tool without annotations or an output schema, the description covers the action, supported formats, return value, and metadata side effect. It is nearly complete but stops short of stating runtime prerequisites or error behavior.

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 the schema already explains both parameters fully. The description adds no parameter-level detail beyond what the schema provides, and the baseline score of 3 is appropriate.

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?

States a specific verb ('open') and resource ('local data file') and lists supported formats plus the return value, so the core action is clear. It does not distinguish this tool from the sibling dm_4dstem_open, which is also a file-opening tool and may overlap with 'other DM-supported formats'.

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 description gives no guidance about when to use this tool versus alternatives such as dm_4dstem_open, nor any prerequisites or exclusions. Usage must be inferred entirely from the purpose statement.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose that the result reports distance according to calibration and that the width algorithm/boundary strategy are returned with the result, which implies a non-destructive read. It does not state permissions, whether the image must be open, or the overall shape of the response.

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?

Two compact sentences with the core action front-loaded and no filler. The parenthetical mixes parameter guidance with sibling disambiguation, which is dense but still earns its place.

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 six-parameter tool with no annotations and no output schema, the description covers coordinates, width, and calibrated distance output. It omits whether the intensity profile itself is returned and what happens when image_id is absent (e.g., defaulting to the front window), leaving real gaps.

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 coverage is only 33%, and the four undocumented required parameters (x0/y0/x1/y1) are exactly what the description explains: raw pixel-center coordinates rather than start/end labels. It also mentions width's effect; only image_id semantics are left entirely to the schema.

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?

States a specific verb and resource: take an intensity profile along two points, using raw image pixel-center coordinates. It also explicitly separates itself from sibling dm_2d_preview's profile object, so an agent can distinguish the two calling conventions.

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 parenthetical about start/end applies to dm_2d_preview's profile object, which is a useful disambiguation against that alternative. However, it never states when to prefer this tool over siblings like dm_2d_analyze or dm_2d_preview, nor any prerequisites such as needing an open image.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: the tool is disabled by default behind an env var, it auto-diffs the image collection after execution, and reports newly created and deleted image ids. It implies destructive potential (deleted images) but does not warn that arbitrary script execution can mutate or destroy open documents, nor does it mention timeouts or failure modes.

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 purpose and equivalence to the script window are front-loaded, the algorithm examples justify the tool's niche, and the post-execution diff behavior and env-var gate follow in a logical order. No sentence is redundant.

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 output schema, the description covers the prerequisite gate and what the return reports (new/deleted image ids, warnings), which is what an agent needs to chain into other tools. Remaining gaps are error/timeout behavior and the risk profile of arbitrary code execution.

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% for both parameters, so the schema already documents 'script' (full DM-Script source) and 'expect_new_image' (warning if no new image appears). The description alludes to the image-diff behavior but adds no syntax, size limits, or usage detail beyond the schema, so baseline 3 applies.

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 states a specific verb and resource (execute DM-Script inside DM, equivalent to the script window) and scopes it to native algorithms the other dm_* wrappers don't expose (filtering, drift correction, EELS/EDS quantification, SI processing, batch macros). This clearly distinguishes it from the specialized siblings like dm_fft, dm_stats, or dm_spectrum.

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?

It gives a clear context for use: call native DM algorithms and batch macros not covered by other tools, then continue quantifying with other tools. It also states the prerequisite gate (DM_MCP_ALLOW_DMSCRIPT=1). It does not explicitly name which sibling to prefer over this one for a given task, so it falls short of full when/when-not routing.

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

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

No annotations, so the description bears the full burden: it discloses experimental status, synthetic-only coverage, float64 arithmetic, no unit assumption, no interpolation or background subtraction, and half-open window semantics. These are exactly the behavioral facts an agent needs before calling a real-data spectrum pipeline.

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?

One dense paragraph that front-loads the operation and then layers constraints, with zero filler. Slightly compressed (many clauses chained with semicolons), but every clause carries load-bearing information.

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?

With no output schema, the description still conveys the return content (channel centers plus float64 intensities), and the validation/limitation surface is well covered. It could be more explicit about the returned array shape, but for a 5-param tool with full schema coverage this is close to complete.

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 coverage is 100% and every parameter already carries a detailed description (energy axis NumPy ordering, non-clamping spatial bounds, [low,high) window). The description only restates the window and reduction semantics, adding little beyond the schema. Baseline 3 is appropriate.

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 states a specific verb and resource: it extracts raw channel centers and float64 intensities and reduces them by sum/mean over a spatial range. It also scops what spectrum data is accepted (eV/keV energy-axis calibration, no 4D diffraction). It doesn't name siblings such as dm_spectrum_integrate, so differentiation is implicit rather than explicit.

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?

Clear negative guidance: no background subtraction, no spectrum-type auto-identification, no element/chemical quantification, no unit assumption, rejects 4D diffraction and nm-calibrated axes. The 'experimental, real EDS/EELS/SI NOT_TESTED, synthetic only' note gives a strong when-not-to-trust signal. Missing explicit routing to an alternative tool for the excluded cases.

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

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

With no annotations present, the description carries the full burden and does so: it discloses the experimental/NOT_TESTED status with synthetic-only coverage, the non-destructive write policy, float64 arithmetic, and the deliberate refusal to assume intensity units. These are exactly the behavioral traits an agent needs before calling a file-writing tool.

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?

Front-loaded with the core action and output format, then limitations. Dense but every clause adds a constraint or exclusion; slightly long single-block sentences could break more cleanly, but there is little wasted text.

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 6-parameter tool with no annotations and no output schema, the description supplies the missing pieces: the produced file format and dtypes, the sidecar metadata output, the write-safety guarantee, and the scope of supported data. Nothing an agent needs to invoke it correctly is absent.

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 coverage is 100%, so the schema already documents every parameter including path, image_id, reduction, energy_axis, spatial_bounds and energy_window_eV. The description reinforces a few semantics (energy window selection, no interpolation/background subtraction, no unit assumption) but mostly repeats schema content, so baseline 3 applies.

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?

States a specific verb and resource: export a new CSV with named columns (energy_eV, intensity as float64) plus a metadata sidecar, derived from dm_spectrum's spatial reduction and energy selection. The 'new file, never overwrite or write back' framing distinguishes it from in-place analysis siblings like dm_spectrum and dm_spectrum_integrate.

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?

Explicitly enumerates when-not conditions: no spectrum-type auto-detection, no background subtraction, no elemental/chemical quantification, rejects 4D diffraction and nm-calibrated energy axes. It references dm_spectrum as the upstream source, though it does not name which sibling to use for the excluded tasks (e.g., quantification), so routing beyond 'don't use this' is incomplete.

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

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

No annotations exist, so the description carries the full behavioral burden. It does disclose critical maturity information (experimental, NOT_TESTED, synthetic-only) and enumerated refusals, but says nothing about permissions, error behavior, or return shape. It is strong on scope limitations but incomplete on other behavioral traits.

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 compact and front-loads its core purpose before moving to limitations. Each clause adds substance, though the run of negatives becomes dense and could be grouped more clearly.

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?

No output schema exists, so the description must, and does, indicate what the tool returns: axis, spatial selection, and calibration. Maturity and refusal conditions are covered. Minor gaps remain in return-structure detail, but it is sufficient for correct invocation.

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 coverage is 100%, so all three parameters are already documented in the schema, and the baseline is 3. The description restates a few constraints such as eV/keV calibration and the 4D rejection without adding syntax or semantics beyond what the schema already supplies.

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?

States a specific verb and resource: read spectral axis, spatial selection, and energy calibration for an explicitly named dataset. It is distinguishable from write/reduction tools like dm_spectrum_integrate through its stated exclusions, though it never names a sibling tool directly.

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?

Explicitly limits scope: no automatic spectrum-type identification, no background subtraction, no quantitative analysis, rejects 4D diffraction and nm-calibrated energy axes. It also flags genuinely useful context: experimental status with only synthetic-data coverage, so an agent knows not to trust it on real EDS/EELS/SI data. It does not point to an alternative tool for those rejected cases.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it does so: it marks the tool as experimental, says real EDS/EELS/SI data are NOT_TESTED with only synthetic coverage, states that it is a plain sum with no bin-width or trapezoidal weighting, and warns that output should not be read as a quantitative elemental map. It leaves open what the returned object is (new image id vs. in-place), which keeps it below 5.

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?

Core operation leads, followed by caveats and exclusions, with no filler. Several clauses are packed into long semicolon-joined sentences, which makes it denser than ideal, but every segment carries operational information.

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 tool with no output schema, the description adequately covers the output (per-position sums with remaining spatial axes preserved, not a quantitative map) and the major input restrictions. The maturity and units caveats are stated, though the exact return type is not specified.

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 coverage is 100%, so the baseline is 3. The description adds interpretive meaning beyond the schema: no bin-width weighting, no assumed intensity units, and rejection of nm-calibrated energy axes. This clarifies how energy_window_eV is interpreted and what the result means, though it adds little about spatial_bounds.

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 first clause states a specific verb and resource: sum raw channels over the given energy window per spatial position, preserving the remaining spatial axes. The caveats that follow (no bin-width weighting, no background subtraction, no quantification, rejects 4D diffraction and nm-calibrated axes) make clear how it differs from the other dm_spectrum* siblings.

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?

Strong exclusion guidance lists cases where the tool must not be used: 4D diffraction, nm-calibrated energy axes, and calls expecting elemental or chemical maps, background subtraction, or quantification. It doesn't name the alternative tool to use for those needs, so the agent knows what to avoid but not where to route.

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

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

With no annotations supplied, the description carries the full burden; it does disclose the computed quantities (min/max/mean/stddev/quantiles), which is real behavioral information beyond the name. However, it says nothing about the return structure (single map? per-channel/per-frame?), data-source handling, or side effects, and "可限定矩形区域" merely restates the schema.

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?

Two short sentences, front-loaded with the metrics, no filler. Slight redundancy with the schema on the rect restriction, which does not earn its place.

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?

Two optional parameters and no output schema, so the description should at least sketch the return shape; listing metric names partially covers this but leaves the structure (keys, dtype, per-channel behavior) unspecified. Adequate minimum-viable, not complete.

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 rect (half-open [x0,y0,x1,y1], must lie fully inside, no clamping) and image_id (id from dm_datasets or "front") are fully documented in the schema. The description adds nothing beyond that, so baseline 3 applies.

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?

"区域统计" states a concrete operation (statistics) plus the exact metrics computed (min/max/mean/stddev/分位数), so an agent knows precisely what it gets. It does not differentiate itself from siblings such as dm_2d_analyze or dm_profile, which could plausibly also summarize pixel data.

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?

There is no statement of when to use this versus dm_2d_analyze, dm_profile or dm_2d_result, and no exclusions or prerequisites. The only usage hint is the optional rect, which is already implied by the schema.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the diagnostic content and implies it is a safe probe, but never states that it is read-only or side-effect free, nor what the response shape looks like. The guidance 'do not restart DM because of this' adds useful operational context.

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?

Two sentences: the first front-loads the enumerated self-check contents, the second front-loads the usage trigger and the misdiagnosis warning. No filler.

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?

With no output schema, the enumeration of what gets reported (backend, versions, manual path) is the right compensation and is present. Only the read-only/no-side-effect guarantee is missing, a minor gap for a diagnostic probe.

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?

The tool takes zero parameters, so there is nothing to disambiguate; the baseline for a parameterless tool applies. The description correctly does not invent parameter guidance.

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 the tool as a link self-check and enumerates exactly what it probes: bridge backend (digitalmicrograph/mock), DM version, host Python and numpy versions, and the offline manual path. It does not explicitly contrast with the dm_* data siblings, but the diagnostic intent is unmistakable against tools like dm_metadata or dm_stats.

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?

It gives a clear trigger ('when DM connection or native operation errors') and an explicit exclusion routing to a different check ('local preview/report dependency errors should check DM_ANALYSIS_PYTHON, don't restart DM'). This is the when/when-not/alternative pattern in full.

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