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

No annotations are supplied, so the description must carry behavior. It usefully discloses that output goes to a folder with manifest.jsonl, that replies contain no base64, and how avoid_repeat_cases affects case selection. It does not disclose overwrite behavior, directory creation, permissions, error handling, or return-path details for a file-writing batch 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, front-loaded with the core batch action and output location; no redundant restatement. It is appropriately sized for the description's role.

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 batch tool with nested request objects and no output schema, the description is too thin: manifest contents, output_dir behavior, file naming, and failure modes are unspecified. An agent can identify the tool but lacks enough context to invoke it safely and predictably.

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?

With only 0% top-level schema description coverage, the description must explain parameters. It explains avoid_repeat_cases and loosely maps output_dir to "one folder", and points requests to labeled_image, but does not clarify output_dir defaults or the structure and fields of each BatchRequest.

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 action and batch scope: run many labeled_image requests into one folder, which distinguishes it from the single labeled_image sibling. It also names manifest.jsonl and the no-base64 reply behavior, so the operation is immediately identifiable.

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?

Use is implied for many labeled_image requests rather than a single call, and avoid_repeat_cases is described. However, there is no explicit when/when-not guidance, no statement of alternatives such as labeled_image for single images, and no prerequisites.

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 supplied, so the description carries the full burden, and it discloses little: it names categories of data (pathology, study type, contrast phase, windows, presets, option names) but says nothing about read-only safety, return structure, or how that content is organized. For a lookup/metadata tool with no output schema, that leaves the response shape entirely undisclosed.

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?

It is a single short clause with no padding, so length is not a problem. However, it is a grammatically incomplete fragment that is not front-loaded with a purpose statement, so brevity comes at the cost of clarity.

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 annotations, no output schema, and no parameters, the description is the only source of information about this tool, and it does not say what calling it produces, in what form, or when it should be preferred over the list_*/find_* siblings. The gap is significant relative to how little structured metadata is available.

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 for the description to disambiguate; the baseline for a parameterless tool applies. The listed content categories describe what the call covers rather than argument meaning.

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 is a bare noun phrase ('Filter values..., windows, presets, and option names') with no verb and no statement of what the tool actually does or returns. It hints at dataset metadata enumeration, but an agent cannot tell whether this returns available filter values, a dataset summary, or configuration options, nor how it differs from siblings like list_structures or list_findings.

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 or when-not-to-use guidance and no mention of any alternative tool. At best the agent can infer 'call this to discover filter values before searching,' but that inference is never stated and no sibling is referenced.

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. It does disclose one real behavior beyond structured data -- min_value defaults to the finding's threshold -- and clarifies the return shape (cases plus a chosen slice). It says nothing about sorting (most_severe_first defaults true), the default limit, or what filters do to results, so meaningful behavioral gaps remain.

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, purpose front-loaded, no padding. Minor cost: the render_image call snippet consumes a third of the text for something that is arguably another tool's job.

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 a 15-field nested filter object, no output schema, and no annotations, the description is far too thin -- an agent cannot know which filters are safe to omit or what the returned slice field is named. The one useful note (min_value default) does not cover the filter surface.

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 0% across 6 parameters (plus a 15-field nested CaseFilters object), so the description must compensate. It explains only min_value; finding, max_value, limit, most_severe_first, and the entire filters object are left with bare titles like 'Max Value' and 'Filter'.

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 resource ('cases showing a measured finding') and what comes back ('the axial slice that best shows it'), which is concrete enough to distinguish it from list_findings, which it explicitly points to. It does not distinguish itself from find_slices, the closest-sounding sibling, so a 4 rather than 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 parenthetical '(see list_findings)' implies you must look up valid finding names first, and the last sentence chains results into render_image, which is useful workflow guidance. However, there is no statement of when to use this versus find_slices or slice_contents, and no exclusions.

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 supplied, so the description carries the full burden, yet it never says whether the tool is read-only, what the returned candidates look like (scores? IDs? pagination?), or that filtering defaults such as min_visibility=0.4 and allow_arms_in_fov=false silently exclude slices. For an 8-parameter search tool with zero annotation coverage this is a significant gap.

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?

It is short and front-loaded, with the core ranking behavior first and the enum gloss second, so no sentence is wasted. However, the second sentence covers only a fraction of the enum surface and the backtick-marked tokens read as fragments rather than structured guidance.

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?

Given eight parameters, a nested-but-undescribed filters object with many behavioral toggles, no annotations, and no output schema, the description is far too thin to let an agent call the tool correctly. An agent would have to guess at strategy semantics, filter defaults, and the shape of the ranked result.

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 0% at the top level: seed, view, level, limit, strategy, structures, and slice_index have no inline documentation. The description clarifies only two of six strategy enum values and says nothing about 'max_visibility', 'max_area', 'random', or 'index', nor how 'level' interacts with the strategy or with the 'auto' view.

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: 'Rank (case, view, slice) candidates where every structure is clearly visible', which tells an agent this is a ranked slice search rather than a listing or rendering call. It does not explicitly differentiate itself from siblings such as find_findings or slice_contents, 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 versus alternatives and no indication of when a caller should prefer this tool over find_findings, slice_contents, or render_image. The only usage hint is the gloss on two strategy values ('classical', 'level'), leaving four other strategies, the 'view' and 'limit' choices, and the required 'structures' argument unaddressed.

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 of behavioral disclosure. It usefully discloses that the tool selects randomly among the top_k best cases, that seed controls reproducibility, and that shuffle_labels randomizes label-to-group assignment. It does not describe side effects such as writing to output_dir, what is returned, how failures are handled, or how visibility is evaluated.

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 three tightly written sentences with the core action front-loaded. Each sentence adds distinct information: the find-and-render behavior, the top_k randomness and seed reproducibility, and the shuffle_labels effect. The phrase "answer's number varies" is slightly ambiguous but does not undermine the overall efficiency.

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?

This is a complex tool with 14 parameters, extensive nested objects, no annotations, and no output schema. The description covers only the core selection and randomization semantics. It leaves the agent without enough context about filters, rendering settings, output behavior, include_base64, output_dir, hotspot_zones, strategy, and how labeled structures are 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 description coverage is reported as 0%, so the description should compensate heavily for 14 top-level parameters. It adds meaning only for top_k, seed, shuffle_labels, and context_structures. Critical parameters such as labels, filters, render, strategy, view, hotspot_zones, include_base64, and output_dir receive no explanation in the description.

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 composite action: find a slice where all labeled structures are visible and then render it. This clearly identifies the tool as a labeled-image generator rather than a pure slice finder or renderer. It stops short of naming or distinguishing sibling tools such as find_slices, render_image, or batch_labeled_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 explains how to make repeated calls vary or be reproducible via top_k and seed, and how shuffle_labels changes the answer's number. However, it gives no explicit guidance on when to use this tool versus find_slices, render_image, slice_contents, or batch_labeled_images. The usage context is implied by the find-then-render behavior, but alternatives are not addressed.

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 supplied, so the description carries the full burden. It does add genuinely useful provenance — findings are measured from segmentations rather than asserted in metadata, and counts are returned — but says nothing about whether the listing is exhaustive, how counts are scoped (per case vs per scan), or what the response shape 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 sentences, front-loaded with the core purpose and followed by the secondary metadata source. The parenthetical pathology examples are informative rather than filler, and nothing 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 zero-parameter, read-only listing with no output schema, the description is largely sufficient: it names the two data sources and the presence of case counts. A brief note on return shape (e.g. how findings are keyed) would close the remaining 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?

The tool takes zero parameters, so the baseline is 4; there is no argument semantics to explain and the description correctly implies no filtering options exist.

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 resource and what it returns: pathology present in the dataset, derived by measuring segmentations, with case counts, plus coarse per-scan metadata categories. That distinguishes it from list_structures (structures) and find_findings (search), though it never names those siblings 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?

Usage is implied by 'pathology this dataset actually contains' versus metadata categories, but there is no explicit when-to-use guidance, no statement of when to prefer find_findings or dataset_info, and no prerequisites or exclusions.

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 usefully discloses that `query` has dual behavior (exact name/synonym resolution versus substring search), which is non-obvious, but says nothing about result volume, pagination, or what fields a returned structure carries — significant gaps for a zero-annotation 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?

Two tight sentences with no filler, and the query behavior is front-loaded before the filters. The trailing 'or system' is slightly elliptical — it reads as an afterthought and leaves the parameter under-described rather than saving space.

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 no annotations, the description should at minimum sketch what a structure record looks like (identifier, canonical name, region, system) so an agent can chain into labeling tools. It covers inputs adequately but leaves the output side entirely 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 description coverage is 0%, so the description must compensate and largely does: it explains `query`'s two resolution modes and enumerates all eight valid `region` values that the schema does not constrain via enum. The `system` parameter is only named, with no values or semantics given, which is the one real gap.

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: list labelable structures. The word 'labelable' scopes the result set and implicitly separates it from siblings like list_findings, but no sibling is named, so the differentiation is inferred 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?

Usage is only implied — an agent can guess this is the lookup step before labeling (labeled_image, batch_labeled_images), but the description never says when to call this versus find_findings or list_findings, nor whether filters are combinable or exclusive.

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. It does add genuinely useful behavior: it discloses the return payload (image path plus base64, answer key with arrow/label geometry, optional pixel-aligned hotspot mask PNGs) and explains that shuffle_labels randomly reassigns label text with seed for reproducibility. It does not mention whether files are written to disk via output_dir, what permissions are needed, cost or performance, or what happens on an invalid slice 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?

Three tight sentences, front-loaded with the core action and the return contract, followed by the one non-obvious parameter behavior. Nothing is padded or redundant, though the parenthetical detail about transparent PNGs could be trimmed.

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 an 11-parameter, no-annotation, no-output-schema tool, the description covers the return shape well, which is the most important missing piece. It still leaves the labels and hotspot_zones structures, view and slice selection, and output_dir side effects to the schema, so an agent could invoke it but not confidently.

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 0% at the top level across 11 parameters, so the description must compensate, but it only explains shuffle_labels and seed. Core parameters like case_id, view, slice_index, labels, hotspot_zones, include_base64, and output_dir get no elaboration. Nested $defs do carry some descriptions, such as Label.label and RenderSettings.size and window, which softens the gap slightly, but most top-level semantics are left implicit.

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 a slice with labels, returning an annotated image. It is clear what the tool does, but it never distinguishes itself from the sibling tools labeled_image and batch_labeled_images, which sound like near-identical operations, so an agent cannot tell which to pick from the description alone.

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 and no exclusions. Given that labeled_image and batch_labeled_images exist as siblings, the description should say when this single-slice renderer is the right choice instead of those, but it says nothing.

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 does disclose ordering ("largest first") and the returned attributes (area, visibility), which is useful, but it never says the tool is read-only, does not mention the area filtering behavior implied by min_area_mm2, and does not address empty results or what happens when a slice has no structures.

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 with the resource description and the ordering fact front-loaded, and no filler. The only inefficiency is the jargon-laden second sentence, which spends words on an unexplained term rather than on information the agent needs.

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 4-parameter tool with no annotations and no output schema, the description is thin: it omits the default filter behavior, index conventions, and the form of the returned structure entries beyond naming two fields. An agent could call it, but not predict what it receives or how the threshold affects the result.

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 0% across 4 parameters, so the description must supply meaning. It only gestures at "slice" and "area"; it never explains what slice_index indexes (base, range), what view values are valid (only in the enum), or that min_area_mm2 is a threshold defaulting to 50 mm² that suppresses small structures.

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?

"Structures visible on a slice (area, visibility), largest first" states a specific verb-and-resource plus the returned fields and ordering, so an agent knows it retrieves per-slice structure listings. It does not distinguish itself from the sibling list_structures, which plausibly returns structures at the dataset level, leaving some ambiguity about scope.

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?

"Use to choose distractors" gives one concrete use case, which is more than a bare purpose statement. However, no alternative is named (list_structures, find_slices), no when-not-to-use is stated, and the domain term "distractors" is undefined, so the agent must infer the selection conditions.

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