Render a local DICOM frame

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

The description adds substantial behavioral context beyond annotations: it discloses supported pixel formats, compression modes, independent sample and pixel checks, refusal of unsupported streams or decoder discrepancies, retention of burned-in identifiers, and the local-browser requirement. These details are consistent with readOnlyHint=false because the tool writes a PNG output.

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 front-loaded with the core action and then adds only material constraints. Despite technical density, each sentence contributes useful selection or invocation context without padding.

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 complex DICOM rendering tool with no output schema, the description covers supported inputs, output format, validation behavior, refusal cases, clinical limitations, and environment requirements. An agent has enough information to decide whether this tool is appropriate and how to invoke it safely.

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%, so the description must compensate. It usefully clarifies windowing and frame scope, but does not explain invert, exact window_width/window_center semantics, or the frame parameter's range and default, leaving meaningful parameter ambiguity.

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: rendering a single DICOM frame into PNG with defined pixel formats and windowing. It clearly distinguishes the operation from inspection siblings by emphasizing rendering, though it does not explicitly name abox_dicom_inspect as the non-rendering alternative.

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 through constraints such as 'No diagnosis or clinical preset' and 'Requires a local browser,' but there is no explicit guidance on when to choose this over abox_dicom_inspect or other related tools. The reader must infer the intended technical-rendering use case.

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