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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the non-mutating, local-only nature is known. The description adds the diagnostic scope (missing/duplicate slices, mixed orientations, gantry tilt, multiple frames of reference), which is useful, but much of that overlaps with return-value content that the output schema likely covers, and no cost or failure behavior on unreadable/invalid paths is mentioned.

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 precondition ('before measuring or reconstructing'), the second lists exactly what is reported and flagged. No filler and no restatement of the tool name.

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?

A read-only single-parameter validation tool with an output schema, so purpose plus the enumeration of detected conditions is nearly sufficient. Minor gap: nothing about scale/cost on large directories or what happens when a path is unreadable, though the output schema and annotations cover most of the burden.

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?

There is a single parameter with 100% schema description coverage ('Local DICOM files or directories inside the allowed paths'), so the schema does the heavy lifting. The description adds nothing about accepted path forms, mixed file/directory lists, or constraints beyond the schema, which is the baseline for high coverage.

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 verb and resource ('Check series geometry') and immediately enumerates what the check reports (orientation, spacing, extent) plus the specific defects flagged. It positions itself relative to measuring/reconstructing workflows rather than naming sibling tools, so differentiation is implied 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?

'Check series geometry before measuring or reconstructing' gives a clear positional cue that this is a pre-flight validation step ahead of measure_distance/render_mpr. There is no explicit when-not-to or statement about which specific sibling supersedes it, but the context is unambiguous.

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?

Annotations already declare idempotent=true and destructive=false; the description adds real substance beyond them by clarifying that originals are untouched (copies are written), that UIDs are remapped consistently across the set, and that pixel data is left unchanged. It does not say how cache collisions or re-runs behave, which keeps it from a 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?

Two sentences, front-loaded with the action and destination, followed by the transformation semantics and one explicit non-goal. Nothing is redundant with the title or schema.

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 an output schema present and annotations covering safety, the description supplies the transformation model and the pixel-data caveat an agent needs to reason about results. The remaining gap — where in the cache output lands and how to chain into retrieve/search — is arguably covered by the return 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 description coverage is 100%, so paths, date_mode, keep_private and keep_descriptions are already documented. The description adds only the framing that this is a 'basic confidentiality profile subset', which implicitly bounds what the keep_* flags can preserve but gives no per-parameter detail.

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 ('Write de-identified copies of local DICOM files') plus the destination ('to the cache'), which cleanly separates it from store/move/transfer/retrieve siblings. An agent can select it without opening the 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?

Usage is implied — you de-identify when you need anonymised copies — but the description never says when to prefer this over store or transfer, nor any preconditions such as the allowed-paths constraint. No explicit when-not guidance is offered.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety bar is low. The description adds genuinely non-redundant context: the operation is protocol-dependent, issuing a C-ECHO in DIMSE but only a minimal QIDO-RS request in DICOMweb, which tells the agent the probe is lightweight and that behavior varies by node type.

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 front-loaded sentence with the verb and resource first and the protocol-specific mechanism in a parenthetical. Zero filler, and the scoping detail is optional to reading rather than buried in prose.

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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile; the one required parameter is fully documented. What remains unstated is how a failed echo surfaces (exception vs. result payload), a minor but real gap for a connectivity 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?

Schema description coverage is 100% and the single 'node' parameter is documented as 'Name of a configured DICOM node (see list_nodes)', which even points at the sibling that enumerates valid values. The description adds nothing beyond that, so the baseline of 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 ('Check connectivity to a node') and disambiguates the underlying operation per protocol (C-ECHO for DIMSE, minimal QIDO-RS for DICOMweb). It is clearly distinct from data-moving siblings like retrieve, move, store, and from list_nodes, though it does not name those alternatives.

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 word 'Check' implies this is a pre-flight/verification step rather than a data operation, but the description never says when to prefer it over alternatives such as list_nodes, nor does it state any failure-handling expectation. Usage is inferable rather than specified.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior — no pixel transfer and use of WADO-RS metadata/C-FIND against a remote node — but does not mention that results are capped by the limit default of 50 or how truncation is signalled.

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 front-loaded sentence with the core purpose first and the key constraint second. Every clause earns its place, with no redundancy against the schema.

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?

An output schema exists and the input schema is fully described, so the description needn't explain return values. It is nearly complete for a read tool; the only meaningful gap is not warning that the limit parameter can truncate a large study's instance list.

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 all six parameters are already documented (including the series_uid dependency for sop_instance_uid). The description adds nothing about the study/series/instance narrowing hierarchy or the fields/limit semantics, so the 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+resource ('Read instance-level metadata') and scopes it with 'without downloading pixel data', which separates it from the pixel-fetching siblings. It stops short of naming 'retrieve' explicitly, so the differentiation is implicit rather than stated.

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 'without downloading pixel data' clause implies you should call this when you only need attributes rather than images, and the parenthetical 'WADO-RS metadata or C-FIND' hints at the two backends. There is no explicit when-not guidance or named alternative, so an agent must infer the routing decision.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description's contribution is the 'local cache' scoping, implying only previously downloaded data is returned and no network fetch happens, which is genuinely useful. However, it says nothing about truncation at the limit, ordering, or what happens when the cache is empty.

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 front-loaded sentence with zero waste. It is efficiently sized, though the brevity edges toward under-specification rather than optimal density.

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?

An output schema exists and annotations cover safety, so return-value detail is not required. Still, for a paginated list tool with a 200-item default cap, the agent gets no signal about whether results are truncated or how to page, leaving a real operational gap.

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 50%: study_uid is documented ('Only list files for this study') but limit has no description beyond a default of 200 and a minimum of 1. The description adds no meaning to either parameter, so it fails to compensate for the coverage gap on limit (truncation? pagination? 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?

Specific verb 'List' plus a precise resource, 'DICOM files in the local cache', which is meaningfully narrower than the sibling list_nodes or a generic search. It doesn't explicitly name a sibling to contrast with, so it stops short of 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?

There is no when-to-use guidance, no mention of when not to use it (e.g., versus retrieve or search), and no prerequisites such as having previously run retrieve to populate the cache. The 'local cache' phrasing hints at the context but nothing is stated outright.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered by structured data. The description adds that these are 'configured' nodes and that protocols are returned, but says nothing about whether credentials/connectivity are needed or whether unreachable nodes appear.

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 sentence with the resource and enumeration front-loaded and zero filler. Every element — nodes, node types, protocols — 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?

With an output schema present, return values need no explanation, and a zero-param read-only list needs little more. Only minor context (e.g., whether nodes are returned regardless of reachability) 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?

The tool takes zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description's scope phrase ('configured') is the only qualifier an agent needs.

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+resource — 'List the configured DICOM nodes' — and enumerates the node kinds (PACS, VNA, DICOMweb services) plus the returned attribute (protocols). It is clearly distinct from the data-operation siblings (retrieve/move/store/transfer), though it never names an alternative explicitly.

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 stated when-to-use, when-not-to-use, or alternative. The agent must infer that this is a discovery step preceding transfer/retrieve operations; nothing in the text says so.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioural detail that the measurement is expressed in millimetres derived from pixel spacing and that patient coordinates are returned, but says nothing about units edge cases, frame handling, 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?

A single front-loaded sentence with zero filler. It could be slightly sharper about the coordinate output, but nothing is wasted.

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 an output schema present and full parameter coverage, the description only needs to convey purpose and unit semantics, which it does. Minor gap: no mention of frame selection or what a returned patient coordinate represents, but those are largely carried by structured fields.

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 start/end, path and frame are already documented at the property level. The description only restates that positions are pixel coordinates, adding no syntax or format meaning beyond 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?

The description states a specific verb (measure) and resource (distance between two pixel positions) and names the outputs: millimetres and patient coordinates. It doesn't explicitly contrast with siblings like pixel_statistics or check_geometry, but the operation is unambiguous.

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 guidance on when to choose this tool over alternatives (e.g. pixel_statistics or check_geometry) and no stated prerequisites such as needing a valid DICOM path from retrieve. The agent must infer the usage context from the name alone.

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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds that this is a DIMSE push to a remote node, which explains the open-world nature, but it says nothing about transfer duration, whether the source archive queues the job, or failure modes when the destination is unreachable.

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 front-loaded sentence with zero filler that names the operation and its effect. Nothing could be removed without losing 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?

An output schema exists and the input schema is fully described, so the description needn't explain returns or parameters. What is missing is disambiguation from the other data-movement siblings and any note that the transfer is asynchronous or depends on the destination being configured.

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 all five parameters (including the constraint that sop_instance_uid requires series_uid) are already documented in the schema. The description adds no additional meaning such as UID format expectations or how 'destination' AE titles are resolved, so the baseline of 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 ('send data to another DICOM node') and names the protocol operation (C-MOVE), which is far more informative than the bare name 'move'. It does not, however, distinguish this from the closely related siblings 'retrieve', 'transfer', and 'store', which an agent could easily confuse it with.

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 guidance on when to pick this over 'retrieve', 'transfer', or 'store', which all involve moving DICOM data between nodes. The schema hints that 'node' comes from list_nodes, but the description itself offers no preconditions or alternatives.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine domain behavior beyond that by stating results are in modality units (HU for CT) and area in mm2, but it says nothing about failure modes such as a path outside the allowed roots or an out-of-range frame index.

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 sentence, front-loaded with the resource and with the output list following. Every clause (modality units, HU for CT, mm2 area) conveys information an agent would otherwise have to infer.

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?

An output schema exists, so enumerating return values was optional and it does so anyway; annotations cover the read-only profile. What remains missing is routing guidance versus the measurement and rendering siblings, but for a simple read-only statistics tool the definition is otherwise sufficient.

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%, with path, frame and the nested ROI fields all documented in the schema, so the schema carries the parameter burden. The description adds no parameter-level detail beyond the units mentioned (HU, mm2), 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?

Names a specific resource (pixel values within a frame/ROI) and enumerates the returned quantities (mean, std, min, max, percentiles, area), which clearly separates it from siblings such as measure_distance or render_image. It stops short of explicitly differentiating itself from those siblings by name.

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 when-to-use guidance: it never says when to prefer this over measure_distance or render_image, nor that a roi can be omitted to analyze the whole frame. The only procedural hint ('path ... e.g. from retrieve') lives in the schema, not the description.

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?

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral fact beyond them: that pixel data is deliberately excluded, which prevents an agent from expecting image content in 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 short sentences, no filler, and the core action plus the key exclusion are both front-loaded. Nothing could be removed without losing 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 an output schema present, return shape needn't be explained, and annotations cover the safety profile. The only real gap is guidance on when this local read should be chosen over the sibling get_metadata/list_local_files.

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 path (allowed-paths constraint) and max_depth (sequence expansion depth, 0-5) are fully documented in the schema. The description adds no meaning about either parameter, which is the expected baseline when the schema does the work.

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 the full header of a local DICOM file') and adds a scope constraint that separates it from pixel-level siblings like render_image or pixel_statistics. It never names an alternative such as get_metadata, so the local-vs-remote distinction is left implicit.

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 only implied through the words 'local DICOM file' and 'pixel data is not loaded'. There is no explicit statement of when to prefer this over get_metadata or list_local_files, and no prerequisite or exclusion guidance.

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 readOnlyHint=true already covering safety, the description still adds real behavioral context: modality rescale to HU, display windowing, non-square pixel correction, per-edge patient orientation reporting, and an input fingerprint. It stops short of describing failure behavior for non-DICOM or missing files, so not a 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?

Three short sentences with the core action front-loaded and no filler. Each sentence contributes a distinct piece of information: what it produces, what processing it applies, and what it returns.

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 carries the return-value burden and does name the PNG plus orientation and fingerprint outputs. It is nearly complete for a 6-parameter tool, though the exact shape of the orientation/fingerprint metadata is left vague.

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 every parameter including the window presets and max_size is already documented in the schema; baseline is 3. The description only loosely reinforces the windowing concept and adds nothing about frame indexing or the window_width/window_center override precedence beyond what the schema states.

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 ('Render one frame of a local DICOM image as a PNG') and names the output format, which is enough to tell it apart from metadata tools. It does not explicitly differentiate from the sibling render_mpr, leaving the single-frame vs multi-planar distinction implicit.

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 by 'local DICOM image' and the schema note that the path typically comes from retrieve, so an agent can infer the workflow. However, there is no explicit when-to-use statement, no mention of when to prefer render_mpr or pixel_statistics instead, and no note on preconditions such as the file needing to be DICOM.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context — it refuses failing series and its output is a PNG — but does not say whether the PNG is written to disk or returned inline, nor what the refusal response looks like.

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 core action and followed by the one non-obvious failure condition. Nothing extraneous.

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 8 parameters fully documented in schema, readOnly annotations, and no output schema, the description covers purpose, output type, and a key failure mode. Only the return/handling behavior of the PNG is left 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 description coverage is 100%, so every parameter including plane, window presets, and max_size is already documented. The description only echoes the plane concept and adds no format or default semantics beyond the schema; 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: reconstructs axial/coronal/sagittal views from a slice stack and renders a PNG. That distinguishes it from render_image (single-image rendering) implicitly, though the sibling is never named, so differentiation requires inference.

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?

Adds a real precondition by pointing at check_geometry (refuses series that fail it), which tells the agent when this tool will error. However there is no explicit routing guidance such as 'use render_image for a single slice' or requirements for calling check_geometry first.

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?

Annotations already declare it is non-read-only, idempotent, non-destructive, and open-world. The description adds the retrieval protocol and that results land in a local cache with file paths returned, which is genuinely useful, but it says nothing about overwrite behavior, node authentication, or disk footprint for a write-to-disk operation.

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, no waste, with the core action front-loaded and the return shape appended. Every clause carries 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 an output schema present, the description needn't explain return values, and full schema coverage handles parameters. It covers action, mechanism, and destination adequately; only the relationship to move/transfer siblings is left implicit.

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 node, study_uid, series_uid, and sop_instance_uid are all documented in the schema itself, including the series_uid dependency for sop_instance_uid. The description only echoes the study/series/instance narrowing, adding no new semantics, 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 (download) and resource (study/series/instance) plus the destination (local cache) and protocols (C-GET/WADO-RS). An agent can tell it fetches data locally, though why it differs from siblings like `move` and `transfer` is not spelled out.

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 'into the local cache' phrase implies when this is appropriate versus server-side moves, but there is no explicit when-to-use, when-not, or named alternative among `move`, `transfer`, or `list_local_files`. Usage must be inferred.

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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description reinforces this by naming C-FIND/QIDO-RS, which tells the agent the query goes out to a remote DICOM node. It says nothing about failure behavior, empty results, cost of broad queries, or how paging interacts with large result sets.

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 front-loaded sentence with the resource scope first and the protocol qualifier second; every word earns its place and nothing is padded.

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?

An output schema exists and the input schema is fully described, so the description does not need to cover return values or parameters. However, for a six-parameter, open-world query tool sitting among sixteen siblings, the absence of selection guidance against retrieve/get_metadata leaves a real gap.

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 node, level, limit, offset, filters, and return_fields are all documented in the schema including a filter example. The description adds no parameter meaning beyond repeating the level names, so the 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 (search) and enumerates the resource levels it queries (patients, studies, series, instances), plus names the underlying protocols (C-FIND/QIDO-RS). It is clearly distinct from siblings like retrieve or move, though it does not explicitly contrast with get_metadata, which also reads DICOM attributes.

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 guidance on when to choose search over retrieve, move, or get_metadata, and no mention of prerequisites such as a node already being configured via list_nodes. The only routing hint ('see list_nodes') lives in the schema, not the description.

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?

Annotations already disclose readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is clear. The description adds protocol-level context by naming C-STORE and STOW-RS, but does not explain failure behavior, overwrite semantics, or authentication needs beyond what annotations imply.

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 definition is a single sentence with no filler, and the core purpose is front-loaded. Every word 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?

With a full input schema, an output schema, and annotations covering the safety profile, much of the context is already structured. However, for a network mutation tool the description could better explain its relation to sibling tools and any operational constraints, leaving a moderate gap in contextual completeness.

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 parameters are fully documented in the input schema. The description adds no parameter-level meaning such as path restrictions or node configuration details, so the baseline of 3 applies when schema carries the full burden.

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 ('Send') and resource ('local DICOM files to a node'), and names the two supported protocols (C-STORE / STOW-RS). It clearly indicates an upload-from-local operation, distinguishing it from retrieval or metadata tools, though it doesn't explicitly contrast with siblings like transfer or move.

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 explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives such as transfer or move for remote-to-remote operations. The schema notes that the node must be configured, but the description itself leaves selection entirely to inference.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds useful behavioral context beyond annotations by stating that copying goes through the local cache and supports protocol bridging from DIMSE to DICOMweb, though it omits overwrite and authorization details.

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, front-loaded sentence with no filler. Every phrase contributes either the action, the node scope, the protocol support, or the local-cache mechanism.

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?

The tool has five parameters, three required, with full schema coverage, annotations, and an output schema. The description covers the core action, supported node transfer, and cache mechanism, but it could better address sibling differentiation and whether destination data is overwritten.

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 all five parameters are already documented in the schema. The description adds only the general notion of source and destination nodes and does not provide additional syntax or constraints beyond the schema, making the baseline score 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: 'Copy data between any two nodes', and adds protocol scope with 'including DIMSE to DICOMweb'. It is clear what the tool does, though it does not explicitly differentiate itself from the sibling tools move, store, or retrieve.

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 explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as move or store. The only implied usage is copying data between nodes, which is not enough to guide tool selection among close siblings.

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