dm_spectrum_integrate

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.