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

Annotations already declare readOnly=false, destructive=false and idempotent=false; the description corroborates the additive/non-destructive nature with 'append...keeping the existing ones.' It does not disclose the non-idempotent consequence (repeated calls duplicate annotations) or any validation behavior, which is the main thing an agent needs to know beyond the annotation flags.

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; the key behavioral qualifier is in the same clause as the action.

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 much is already covered. However, the description omits type-dependent requirements (polygon needs points, circle needs radius, arrow needs arrowTarget) and the duplication risk of a non-idempotent append, leaving an agent to work those out from the schema alone.

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 nested AnnotationInput documents coordinates, per-type fields and defaults, so the schema carries the parameter burden. The description adds no parameter-level meaning beyond what the schema already 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+resource (append annotations to an image) and adds a scope qualifier ('keeping the existing ones') that implicitly separates it from replace_annotations. It could be stronger only by naming that sibling outright.

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 'keeping the existing ones' hints at when to prefer this over replace_annotations, but no alternative tool is named and no explicit when/when-not guidance is given. Usage must be inferred from the sibling 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?

Annotations declare readOnlyHint=false and idempotentHint=true, but the description goes well past that: it discloses asynchronous background execution, that a running analysis is reused rather than duplicated, restart semantics, wall-clock estimates (~40s/tile with cell types, ~15x longer, a minute of model warm-up), and a licensing/research-use caveat on the PanNuke weights.

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 action and the wait contract, then cost/tradeoff guidance — a sensible ordering for an agent. It loses a little to redundancy, since the tissue-finding and tile-sampling mechanics are explained twice in overlapping paragraphs.

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, long-running, expensive pipeline with an output schema present, the description covers timing, cost, defaults, resumption and licensing — everything needed to call it correctly and set agent expectations. Return-value detail is properly left to the 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 baseline is 3; the description earns above that by supplying concrete quantities the schema omits — 256x256 um tiles at 40x, the 3,000-tile / ~200 mm2 ceiling for full coverage, and the 12 vs 16 max_tiles defaults tied to cell_types. It does not add cost or format detail for wait_seconds beyond what the schema already 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?

Opens with a specific verb and resource ('Analyse a whole-slide image') and immediately scopes it as a background operation with a bounded wait. It is cleanly separable from siblings like detect_nuclei, classify_cells, check_image_quality and get_slide_analysis, which each cover a subset of what this composite pipeline does.

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 contrasts the two coverage modes by cost and output ('sample' in a few minutes vs 'full' with heatmap, longer for big resections), states the cell_types default flips between modes, and tells the agent exactly what to do if the wait expires ('call get_slide_analysis later') and how to force re-analysis (restart=true).

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 read-only, idempotent and non-destructive behavior. The description adds useful behavioral detail by listing the measured quality dimensions and explaining that results include a verdict, measurements and plain-language warnings.

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 concise sentences, front-loaded with the core action and followed by measurement details and return information. Every sentence contributes useful information without repetition.

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 single-parameter, read-only quality check with an output schema and complete annotations, the description provides enough context to invoke it correctly. It explains what is measured and what kind of result to expect.

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 one required parameter and schema coverage is 100%, so the schema fully documents image_id. The description does not add meaning 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?

States a specific verb and resource: checking a histology image's quality before analysis. It clearly describes the quality dimensions measured and the returned verdict, though it does not explicitly name a sibling tool such as analyze_slide for differentiation.

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?

Gives clear usage context: run this before analysing an image. It implies the pre-analysis workflow but does not specify when not to use it or explicitly compare it with analyze_slide or get_slide_analysis.

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 only declare the mutation/idempotency profile; the description adds the substance: background execution, 30–90s per image, relabelling of existing nucleus annotations, result contents (counts, percentages, immune-to-tumour ratio), and that a repeat call attaches to the same run. The licensing restriction (CC BY-NC-SA 4.0, research/education only) is a behavioral constraint an agent cannot infer from any structured field. This is consistent with readOnlyHint=false and idempotentHint=true.

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 action and target, then constraints, then retry behavior. Despite being four sentences, each carries distinct operational information (classes, runtime, prerequisite, resolution floor, retry semantics) with 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?

Covers everything needed to invoke correctly: prerequisite tool, resolution requirement, expected latency, polling strategy, and a licensing constraint. Output schema exists, yet the brief return summary (counts, percentages, ratio) usefully sets expectations without duplicating the 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 baseline is 3; the description still adds real meaning by framing wait_seconds as an upper bound on blocking and explaining that a second call with the same image waits on the same run rather than starting new work. 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 ('Classify the nuclei detect_nuclei saved on an H&E image') plus the exact output classes, so the agent can distinguish it from detect_nuclei (which only finds nuclei) and segment_objects. The dependency on a prior detect_nuclei run is embedded in the first sentence, making the tool's role 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?

Explicit prerequisite ('Run detect_nuclei first') and an explicit when-not ('Needs a 20x or 40x image: coarser images are refused'), plus retry guidance when the wait expires. It does not name alternative siblings (e.g. segment_objects or analyze_slide) that an agent might consider, so it stops short of full alternative 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?

Annotations only flag a destructive, idempotent write; the description supplies the crucial scope of that destruction: only nuclei from an earlier detect_nuclei run are removed, other annotations are never touched, and replace_previous=false preserves them. It further discloses the up-to-one-minute cold start, the confidence-ordered capping at max_nuclei, and stain-related accuracy 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?

The core action and default behavior are front-loaded and no sentence is filler, but the prose is a dense paragraph with several clauses chained by semicolons; splitting the replace_previous and microns_per_pixel behaviors into distinct sentences would scan faster.

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, output-schema-backed analysis tool, the description covers input assumptions, default side effects, performance latency, measurement outputs, and the escape hatch for reruns. Nothing an agent needs in order to call it correctly and interpret the result is missing.

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, but the description adds genuine meaning beyond the schema: microns_per_pixel changes how the image is resized (model-optimal resolution vs. nucleus-size heuristic) and unlocks area/density units, and max_nuclei selection is described as most-confident-first. Practical resolution values (0.25 at 40x, 0.5 at 20x) help the agent reason about when to pass it.

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?

Opens with a specific verb and resource: find and outline every cell nucleus in an H&E-stained histology image using StarDist. It also states the input assumption (H&E, no bounding boxes required), so an agent knows exactly what it produces. It never names the closest sibling (segment_objects), so the differentiation is left 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?

Gives clear conditions: works on H&E, poor on other stains and non-histology images; use microns_per_pixel when scanner resolution is known, omit it otherwise; warm_up("nuclei") avoids the cold-start wait. It also explains that reruns replace rather than double annotations. It stops short of explicit 'use this instead of segment_objects/classify_cells when...' 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds genuine behavioral detail beyond that: YOLO exports polygons and circles as the web app does, and QuPath nuclei from StarDist arrive as detections. It doesn't discuss error conditions, but the output schema covers 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?

A single front-loaded sentence with no filler. Parentheticals are dense but each earns its place by clarifying a format's export 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?

With an output schema, full parameter documentation, and rich annotations, the description is nearly complete for a read-only export tool. It could add one line about when to choose this over export_dataset, but nothing required to invoke it correctly is missing.

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 meaning beyond the schema's enum: 'as the web app exports' clarifies YOLO semantics, and the QuPath parenthetical explains how nuclei appear as detections, which the schema does not state.

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 an image's annotations') and enumerates the exact output formats, which distinguishes it from export_dataset (a dataset-level export). An agent can identify the operation and scope 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?

Format-specific context is provided ('as the web app exports', QuPath import steps), which implies when each format is appropriate. However, it never explicitly names alternatives (e.g., export_dataset) or states when not to use this tool, leaving routing 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 declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, so the safety profile is already carried; the description adds genuinely new context: files are written to a folder on the server machine, that option is unavailable when hosted, and only a summary is returned in that case. It does not cover the returned-payload-vs-files tradeoff beyond that or any size/perf limits besides the 100-image cap.

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 format/selection/output details in a compact block. Some phrasing duplicates schema descriptions (classes ordering, output_dir folder semantics), but each clause still carries operational information rather than 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?

An output schema exists, so return values needn't be spelled out, and the description still notes that only a summary comes back when writing to disk. The one gap is that with zero required parameters, the behavior when neither category nor image_ids is given (error? export all?) is never stated.

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 baseline is 3, but the description adds meaning beyond the schema: how classes fixes numbering and that other labels follow first-seen order, what each format produces ('one COCO file for all images', 'a label file per image, named after it'), and the hosted-server restriction on output_dir. Only the all-optional default case is left unexplained.

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 with its defining scope: 'Export several images as ONE training dataset, with one class list so ids mean the same everywhere.' The three output formats are named, and the distinction from export_annotations is implicit in the resource (multi-image dataset vs annotations) and made concrete by the format list.

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?

Gives clear selection guidance ('by category (case-insensitive) or image_ids (up to 100)') and a situational recommendation ('output_dir ... suits large datasets such as nuclei'). It does not name a sibling alternative or state what happens when neither category nor image_ids is supplied, so it stops short of full when/when-not coverage.

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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real value beyond them by disclosing that the returned viewing URL is signed and expires after 24h and that the full annotation set is included — a detail an agent must know before caching or reusing the URL.

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 that front-loads the return payload and ends with the operationally important 24h URL caveat. No filler, no redundancy with the title.

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 one-parameter read tool with a full output schema and strong annotations, the description covers purpose, payload contents, and the URL expiry caveat. The only shortfall is the unaddressed overlap with view_image, which an agent choosing between the two would still have to guess at.

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 image_id parameter is fully documented in the schema, including its UUID format and provenance. The description adds nothing beyond 'one image', 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?

Specific verb and resource ('Get one image') plus an explicit enumeration of the payload: metadata, all annotations, and a signed viewing URL. That is far more informative than the title. It does not, however, distinguish itself from the nearby sibling view_image, leaving the boundary between the two 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?

The description never says when to call this instead of list_images or view_image, nor does it state prerequisites (an existing image_id from a listing or upload). The only usage signal is the singular 'one image', which an agent could infer from the required image_id anyway.

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 readOnly/idempotent/non-destructive, and the description adds real value on top: the four lifecycle states, that tile-level metrics and densest-tile images are included, and that nucleus output is QuPath GeoJSON. It stops short of the one behavior an agent most needs — whether a call with status 'queued' or 'running' returns immediately or blocks until completion.

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 sentence, front-loaded with the resource ('A whole slide's analysis') and then the contents. The parenthetical tile-field list is dense but each item is informative; only the trailing GeoJSON detail could be trimmed given an output schema exists.

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 read tool with full annotations, full schema coverage and an output schema, the description is nearly complete: it covers the state machine and the payload shape. The remaining gap is polling/blocking semantics for queued and running states, which the output schema cannot convey.

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 a single parameter at 100% schema coverage, the schema already explains that image_id is the UUID returned by upload_slide or upload_slide_from_url. The description adds nothing about the parameter, which is acceptable given the schema does the work, 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?

The description makes clear this retrieves the analysis record for a whole slide and enumerates exactly what that record contains (status, tile metrics, densest-tile images, nucleus GeoJSON). It is specific about the resource and payload, but it never names the sibling it is distinct from — notably analyze_slide, which presumably triggers the work this tool reads.

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: the enumeration of statuses (queued, running with current step, done, failed) hints that this is the tool to poll after kicking off an analysis, but the description never says so explicitly and names no alternative. There is no statement of when not to use it or what to call instead to start an analysis.

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 readOnly/idempotent/non-destructive, so the bar is lower. The description still adds value beyond them by disclosing that results are summaries only and that full annotations and viewing URLs live elsewhere, which prevents an agent from assuming a rich return payload.

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, zero waste: the operation and filter come first, the pointer to get_image second. Every clause 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?

An output schema exists, so return-shape detail is not required, and the description correctly signals that returns are summaries. Combined with annotations covering safety and a single fully-documented parameter, an agent has what it needs; only pagination/ordering behavior is left unstated.

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 the schema already documents the category parameter, its null default, and case-insensitivity. The description restates the case-insensitivity but adds no new syntax or 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 and resource ('List images saved in Image Label') plus the scope of the optional filter. It is clearly distinguishable from get_image, view_image, and the upload/mutation 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?

Explicitly routes to get_image when annotations or the viewing URL are needed, which is the key sibling decision for this tool family. It doesn't state exclusions (e.g., use export_dataset for bulk export), so it falls short of a 5.

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?

Adds meaningful context beyond annotations: names the algorithm (Macenko), states the original is unchanged and a new image is created, which is consistent with readOnlyHint=false and destructiveHint=false. It does not address idempotency (annotations say non-idempotent) or failure modes, so it stops short of full transparency.

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 the key fact (saved as a NEW image) in the first line; the method and rationale follow. Slightly wordy with a redundant closing 'Returns the new image,' but no sentence 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?

Output schema exists, so return values need not be described, and the non-destructive behaviour plus algorithm name are supplied. For a single-parameter mutation tool with annotations covering safety profile, the only missing piece is idempotency/failure behaviour.

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 the single image_id parameter is fully documented there, including that it comes from list_images or an upload. The description adds no parameter-level detail, 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+resource (normalize an H&E image's colours via Macenko) and immediately clarifies the output is a NEW image, distinguishing it from transformation-in-place siblings like update_image_metadata. An agent can tell exactly what this does 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?

Gives clear context for when it is useful: slides from different labs/scanners differ in pink and purple tones, and normalizing makes them comparable and helps models such as detect_nuclei. This implicitly routes the agent (run before detection/classification), though it does not state explicit exclusions or prerequisites (e.g. requires an H&E slide).

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 destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that: unknown ids are silently ignored rather than erroring, and all removals happen in a single atomic save. It does not explicitly restate irreversibility, but the destructive hint covers that ground.

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 action and scope, then the alternative, then edge-case behavior. The final sentence on return values is somewhat redundant given an output schema exists, but the rest of the text is dense and waste-free.

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 destructive mutation with full schema coverage, annotations, and an output schema, the description covers scope, alternative routing, id sourcing, and unknown-id handling. Nothing an agent needs to call it correctly is missing.

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 both parameters are already documented in detail, including the UUID format and the 'ids not on the image are ignored' note. The description's mention of get_image's id field largely duplicates the schema, so it adds little 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 (remove) plus resource (annotations) and the scoping qualifier 'by their ids, keeping all the others,' which makes the partial-deletion semantics unambiguous. It is clearly distinguishable from add_annotations and replace_annotations without opening any 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?

Explicitly says when to use it ('delete a few annotations') and names the alternative plus its selecting condition ('to change many at once ... use replace_annotations instead'). It also routes the agent to get_image for id acquisition, closing the prerequisite loop.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful behavioral detail by emphasizing that ALL annotations are replaced and that an empty list clears them, though it does not discuss reversibility or permissions.

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-load the key action and then provide the important empty-list edge case. There is no redundant or filler 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?

Given rich annotations, a fully described schema, and an output schema, the description provides everything needed to understand the tool's effect. Return values need not be explained because an output schema exists.

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 already well documented. The description reinforces that the annotations list is the complete replacement set and that an empty list clears, but adds little syntax or format detail 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?

States a specific verb (replace), resource (annotations), and scope (ALL on an image). The all-caps scope and empty-list clearing behavior distinguish it from add_annotations and remove_annotations without needing sibling names.

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?

Clearly establishes when to use it: replacing the entire annotation set, with an explicit note that an empty list clears annotations. It does not explicitly name add_annotations or remove_annotations as alternatives for append or partial deletion, but the usage context is clear.

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 only declare the write/safety profile; the description adds the operational context an agent would otherwise learn by failing: a 20-object batch cap, that a loose box suffices, that medsam accepts boxes only, that save=false is a dry run returning outlines unsaved, and that each result carries a 0-1 quality score. No contradiction with readOnlyHint=false / destructiveHint=false.

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 action and the key insight about rough boxes, and the operational limits come next. It loses a little by restating the model enum description almost verbatim from the schema, which is duplicated text rather than new 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 4-parameter mutation tool with an output schema and full annotation coverage, this is complete: batch limit, dry-run mode, model semantics, input units and quality-score presence are all covered. Return-value detail is correctly left to the 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 baseline is 3; the description earns above that by explaining that the box 'only has to contain the object' (removing the most common calling error) and by tying model choice to image domain. It does not add much about color/notes, but those are self-evident from 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 ('Trace precise outlines with Segment Anything and add them as polygon annotations') and explicitly distinguishes itself from the manual alternative in the sibling set ('Prefer this to drawing polygons yourself'). An agent can tell it apart from add_annotations 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?

Gives selection criteria for the model parameter ('sam' for photos, 'medsam' for CT/MRI/X-ray/ultrasound/endoscopy/pathology), states the box-only restriction for medsam, and defines the save=false path. It also names the alternative workflow (hand-drawing polygons) and says to prefer this tool, which is real routing 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?

The description adds substantial behavior beyond the annotations: the link opens in a browser without an account, copies the image into the recipient's workspace for editing and export, exposes the image publicly for 7 days, and carries an explicit confidentiality warning. These details align with openWorldHint=true and do not contradict the annotations.

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 short and front-loaded: it first explains what the link does and then gives the important 7-day public-access warning. Every sentence contributes useful information without repetition.

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 public-sharing operation, the description covers the essential behavioral and security context: no recipient account, workspace copying, 7-day expiration, and who should receive the link. With an output schema present and the parameter fully documented, no critical invocation detail is missing.

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 schema fully documents the single image_id parameter, so the baseline is 3 under high schema coverage. The description reinforces that it operates on one specific image but adds no syntax or format detail beyond what the schema already 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 clearly conveys that this tool produces a shareable link to one image and its annotations, and it distinguishes that link from internal viewing by noting it opens in anyone's browser with no account needed. It stops short of an explicit action verb such as 'creates' or 'generates,' and it does not name sibling tools, so it is clear but not maximally differentiated.

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 clear usage context and a security-sensitive constraint: share only with people who may see the image, because anyone with the link can view it for 7 days. It does not explicitly compare this against alternatives like get_image, view_image, or export_annotations, so it lacks named alternatives but provides strong when/when-not 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the patch-style 'omitted fields unchanged' contract, which is useful, but it is silent on what happens when a field is explicitly set to null (the schema permits null) and on any permission requirements — an ambiguity that matters for a mutation 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 short sentences with zero filler; the mutable field list comes first and the partial-update rule is front-loaded immediately after. 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, so return values need not be explained, and annotations cover the safety profile for a low-complexity 5-parameter flat tool. The only real omissions are the null-versus-omit distinction and any authorization expectations, which are minor but not negligible for a write operation.

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 property already carries an 'omit to keep it' description plus a UUID explanation for image_id, so the schema does the heavy lifting. The description merely enumerates the same four editable fields and adds the aggregate patch rule, which is a baseline-level contribution rather than new semantics.

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 ('Update') and resource ('an image's name, category, sub-category or description'), so the agent knows exactly what changes. It is the only metadata-mutation tool among the siblings, but the description never says so explicitly, leaving differentiation to 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?

The sentence 'Omitted fields are left unchanged' establishes partial-update semantics, which is real usage guidance for calling it correctly. However, there is no explicit when-to-use framing versus siblings such as add_annotations or replace_annotations, and no stated prerequisites (e.g., whether the image must exist or be owned by the caller).

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=false and destructiveHint=false, so the write semantics are covered. The description's only added behavioral detail is that the path resolves on the server host, not the client; it says nothing about the 20 MB cap, storage location, or whether a repeated upload duplicates the image.

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 sentence, front-loaded with the action, with the parenthetical caveat placed exactly where it is needed. No padding, though it is arguably too terse for a mutating upload tool.

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 all four parameters are documented in the schema, so return values and argument details are not the description's burden. The remaining gap is routing guidance against upload_image_from_url, which an agent would have to infer.

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% – path, name, category and description each carry their own schema-level explanation including the 20 MB limit. The description restates the path constraint but adds no syntax or format meaning beyond the schema, so the baseline 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 ('Upload a local image file ... to Image Label') and the parenthetical clarifies the source is a filesystem path, which implicitly separates it from upload_image_from_url. Sibling differentiation is only implied by 'local' rather than stated explicitly, 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?

The 'path on the machine running this server' note tells the agent where the file must live, which rules out remote files, but it never names upload_image_from_url as the alternative for URL-based uploads or states any other when-to-use condition.

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 non-read-only, open-world, non-idempotent, non-destructive. The description adds genuinely new facts the annotations cannot convey: the server performs the fetch, accepted formats, and the 20 MB ceiling — the failure modes an agent would otherwise hit blind. It doesn't mention auth/SSRF restrictions or that repeated calls duplicate the image.

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 followed by the content constraints, then the usage cue. No filler and nothing an agent would have to re-read.

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 param coverage, the description need only carry constraints and selection guidance, and it does both. The remaining gap is that it treats this as the only URL-based image ingest path without pointing at upload_image for 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 coverage is 100%, so name, category and description are already documented, giving a baseline of 3. The description only restates the format and size constraints already attached to the url property, adding nothing new; note it says 'https URL' where the schema says 'public http(s) URL'.

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 two-step verb chain (download from URL, upload to Image Label) plus the resource, which an agent can distinguish from upload_image and upload_slide_from_url by the 'from an https URL' qualifier. It never names those siblings explicitly, 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?

'Use this for images that are online, e.g. ones attached in a chat' gives a clear positive selection condition. It stops short of the inverse rule (e.g. 'for local files use upload_image') or any note that each call creates a new image rather than replacing one.

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 flag a non-read-only, non-idempotent write; the description adds real value by disclosing the background analysis kickoff and the size ceiling. It does not say what happens on a name collision or whether a re-upload duplicates or overwrites the slide.

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 sentence, format-and-limit constraint front-loaded, and the pointer to analyze_slide at the end. No 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?

An output schema exists, so return values needn't be explained, and annotations carry the safety profile. The only meaningful gap is failure/overwrite behavior on an existing slide name.

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 formats, path semantics, analyze, max_tiles, cell_types and category are all already documented in the schema. The description adds no syntax or default detail beyond what the schema fields provide, 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?

Specific verb and resource (upload a whole-slide file), with accepted formats and the 5 GB cap stated inline. The phrase 'from the machine running this server' separates it from the sibling upload_slide_from_url without naming it.

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 local-file constraint plus the note that analysis starts in the background (see analyze_slide) gives clear usage context. It never explicitly says to prefer upload_slide_from_url for remote files, so an exclusion is implied rather than stated.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description's added value is the async behavior: analysis is kicked off 'in the background' rather than returned inline, which an agent must know. It also bounds the operation with accepted formats and a 5 GB ceiling. It does not mention that repeat uploads are non-idempotent (duplicates), which annotations flag but the description never reinforces.

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 action first and the side effect second; every clause carries information an agent needs. No padding or restatement of the title.

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 all six parameters are fully described in the schema. The async nature of the analysis is disclosed. Gaps are minor but real: failure/partial-upload behavior and the duplicate-creation risk of a non-idempotent upload go unmentioned.

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 is documented inline, so the schema carries the semantics. The description's format and size details largely restate the 'url' parameter's own description and add no syntax or behavioral nuance beyond it. Baseline 3 applies when the schema does the heavy lifting.

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 ('Copy ... from an https URL into Image Label') and a specific resource ('whole-slide file'), plus the side effect of starting analysis. The 'whole-slide' qualifier implicitly separates it from upload_image_from_url, but the sibling tools upload_slide and upload_image_from_url are never named, so the distinction 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 implied by the file-type and size constraints (use this for large pyramidal slide formats from a remote URL), and it points to analyze_slide for the follow-on behavior. There is no explicit when-to-use vs. when-not guidance, and no mention of when to prefer the local-file sibling upload_slide.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely non-obvious behavior: the image is downscaled to at most max_size, the grid labels use the original image's pixel coordinates rather than the scaled ones, and region performs a zoom. That coordinate-frame disclosure is exactly the kind of detail an agent cannot infer from structured fields and would otherwise misread when consuming boxes or points.

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: what it returns and in what coordinate frame first, then when to call it, then the zoom case. Every clause carries information an agent needs to place the call in a workflow; 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 description correctly carries the burden of describing the return value (the rendered picture plus grid) and the coordinate convention. It leaves minor gaps — e.g., the image_id source is only in the schema, and behavior when annotations exist but with_annotations is false is unstated — but nothing essential to correct invocation is missing.

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 would be 3, but the description goes further by explaining the purpose of region ("zooms into part of a large image ... to see individual nuclei") and tying grid and max_size to their rendered effect. It adds intent-level meaning beyond the per-field schema text without restating it.

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 concrete verb and resource ("Look at an image: returns the picture itself") and specifies the exact artifact returned — a scaled picture with a yellow grid labelled in the ORIGINAL image's pixel coordinates. This implicitly separates it from get_image, which by name suggests metadata/id retrieval rather than a rendered view, and the coordinate-frame detail tells an agent precisely what it will see.

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?

Explicit workflow routing: "Use it before segment_objects or add_annotations" and "with with_annotations=true afterwards to check the outlines," plus the condition for region ("e.g. to see individual nuclei"). It lacks an explicit when-not statement or a named alternative such as get_image for metadata-only needs, which keeps it from a 5.

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 readOnly=true, idempotent=true, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral context that annotations cannot express: the call is fire-and-forget, it exists to mask a one-to-two minute cold-start latency, and it should be overlapped with other work. It stops short of stating what happens if the model is already warm or what the response confirms, which keeps it below 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, both front-loaded with the action and the model-value mapping before the rationale. No filler, though the second sentence's clause buries the strongest usage instruction ("call this as soon as you know") after the latency explanation.

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 single-parameter, zero-required, idempotent pre-load tool with a full output schema and rich annotations, the description supplies exactly the missing piece: when to fire it and how to overlap it with other work. Nothing an agent needs in order 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 description coverage is 100% and the enum is self-documenting, so the baseline is 3. The description earns above baseline by tying each value to the downstream tool that benefits from the warm-up (sam/medsam → segment_objects, nuclei → detect_nuclei), which tells the agent how to pick a value from intent rather than from the string alone. It is marginally less complete than the schema, which also mentions classify_cells for 'nuclei'.

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 — "Start loading a model ahead of use, without waiting for it" — and immediately maps each model value to the sibling operation that will consume it (segment_objects, detect_nuclei). An agent can distinguish this pre-loading tool from the actual segmentation/detection tools 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?

Gives an explicit trigger ("call this as soon as you know you will need it (for example right after uploading)") and an explicit behavioral instruction for the interim ("do other work meanwhile"). It also justifies the advice with the condition that motivates it — a quiet spell causing a one-to-two minute cold start.

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