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

Annotations only declare write/openWorld/idempotency/destructive flags; the description adds real behavioral context: compressed input is decoded in bounded packets, output is PCM16/Float32 WAV, all encoded samples are verified, and clipping plus bounded decoder priming omissions are reported. It also clarifies no network access, consistent with openWorldHint=false. Not a full 5 since it omits what happens to an existing output file and whether partial output is left on failure.

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?

Four dense sentences, front-loaded with the operations and followed by format/verification detail, with no filler. The closing clause about 'the existing website effects and local browser' is slightly vague and adds less than the rest, but overall the text earns its 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?

For a 9-parameter local file mutation tool with no output schema, the description covers input formats, output format, verification and diagnostics, which is most of what an agent needs. The remaining gap is parameter interaction (volume_mode vs gain_db/normalize_db) and behavior when output_path already 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?

With only 22% schema description coverage, the description must compensate, and it does partially: it maps reverse, speed with optional pitch preservation (keep_pitch), gain vs peak-normalize (volume_mode), and PCM16/Float32 output (bits). But gain_db, normalize_db (and their mutual exclusivity with volume_mode), and the speed range limits are never explained, leaving nearly half the parameters undocumented in both places.

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 verbs and resource: reverse, speed change with optional pitch preservation, gain/peak-normalize on named audio formats, writing WAV output. An agent can immediately tell this is an audio-transformation tool rather than a trim/extract tool. However, it never names or contrasts with the closest siblings (abox_audio_trim, abox_audio_extract), so sibling differentiation is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists what operations exist but never states when to choose this tool over abox_audio_trim or abox_audio_extract, nor any prerequisites or exclusions (e.g. what happens if no transform parameter is set). Usage must be inferred entirely from the operation 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 only declare it is a non-read-only, non-idempotent, non-destructive write, which is minimal. The description adds substantial beyond-schema behavior: accepted containers (MP4/M4A/MOV audio tracks, AAC ADTS), that picture payloads are ignored and video is never decoded, that M4A copy requires no browser while WAV uses the local browser for bounded packet decoding, that there is no runtime encoder or dependency download, and that bits/channels controls are refused for M4A.

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-loads the core action and format split in the first two sentences before adding environment constraints. It is dense with jargon ('admitted', 'bounded ordinary') and slightly over-packed, but almost every clause carries operational information an 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?

No output schema and five parameters, so the description has to do real work; it covers accepted inputs, mode selection, and dependency/runtime behavior well. Remaining gaps are the semantics of the bits parameter and what happens if output_path already exists, which matter for a non-idempotent write tool.

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 only 40%, so the description carries extra burden. It explains the format choice and the channels/bits refusal rule for M4A, which helps, but never explains what 'bits' 16 vs 32 means or how it interacts with format, and says nothing about output_path overwrite semantics beyond the schema's path text.

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 precise verb and resource ('Extract admitted MP3 or AAC-LC audio into a new WAV ... or copy AAC-LC packets exactly into a new audio-only M4A') with the two output variants enumerated. It is clearly distinct from sibling audio tools like abox_audio_edit and abox_audio_trim, which imply editing rather than demux/extract.

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 a concrete decision rule between the two modes: WAV for transcoding/mono mixing, M4A copy for lossless packet copy that needs no browser and refuses bits/channels. It does not explicitly point to sibling alternatives (e.g. abox_audio_edit, abox_audio_trim) when the user actually wants modification rather than extraction, so it stops short of naming alternatives.

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

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

Goes well beyond annotations: it discloses that a new WAV is written (consistent with destructiveHint=false since input is untouched), that every encoded sample is verified, the default 5 ms fade and how to disable it, priming-sample trimming caveats, and the 1 ms gap rule in cut mode. It also flags the non-obvious requirement of a local browser, which an agent could not infer from schema or 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?

Front-loaded with the core operation and mode distinction, then progressively finer caveats. Every sentence carries content, though the priming-sample and 1 ms-gap details are dense and sit ahead of arguably more important facts (output WAV, local-browser requirement).

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 mutation tool with no output schema, the description covers what is produced (a new WAV), verification behavior, format support, and the browser dependency. It stops short on output bit-depth semantics, overwrite behavior if output_path exists, and time units, which an agent might still need.

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 33% schema description coverage, the description compensates well for mode, fade_ms, and ranges (ordering, repeats, cut-mode gap behavior). Gaps remain: the units for range start/end are never stated, and the bits parameter (16/32) is not explained anywhere. Strong but not fully compensatory.

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 (keep/cut ranges = trim) plus the resource (audio), and even enumerates supported formats (WAV, MP3 Layer III, AAC-LC). It is easy to separate from non-audio siblings, but it never explicitly contrasts with the near-neighbor abox_audio_edit, so sibling differentiation is only 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 keep-vs-cut semantics are conveyed, along with constraints (times must fit decoded audio, local browser required), but there is no explicit 'use this instead of X' routing to abox_audio_edit or abox_audio_extract. Usage is implied by the operation description rather than framed as 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 cover the safety profile (readOnly=false, destructive=false, openWorld=false), and the description adds context they can't: an environment precondition (local browser), a fidelity disclosure ('Source metadata is omitted; color, HDR and precision may change'), and a verification behavior ('compares every output pixel'). It does not say what happens if output_path already exists, which matters for a write 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?

Four dense sentences, front-loaded with the core action before constraints and caveats. Some phrasing is jargon-heavy ('admitted reduced-header AV1', 'unsupported derived layouts') and costs the reader without adding precision, but nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter conversion tool with no output schema, the description covers inputs, refusals, fidelity trade-offs, and the runtime prerequisite. Gaps are the undocumented 'quality' parameter and the lack of any statement about return values or output-file overwrite behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50% — input_path/output_path are documented, but 'format' and 'quality' have no descriptions. The description partially compensates by naming the three target formats, mapping loosely to the format enum, but it never mentions 'quality' or what it governs, so one of four parameters is unexplained in both schema and prose.

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 + resource + outputs: 'Convert one admitted reduced-header AV1 still AVIF to a new PNG, JPEG or WebP', which tells an agent exactly what goes in and comes out. It narrows scope with 'Refuses animation, movie tracks and unsupported derived layouts'. It never names the obvious sibling (abox_image_convert / abox_heic_convert), so differentiation from alternatives is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear eligibility conditions and explicit exclusions: still images only, animation and movie tracks refused, and a hard precondition 'Requires a local browser'. What's missing is routing guidance — it does not say to use abox_image_convert for other formats or abox_video_* for animations, so the agent must infer the alternative.

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?

Beyond the annotations (readOnly=false, openWorld=false, destructive=false), the description discloses substantive behavior: check digits are computed or validated and invalid supplied digits are refused, source-defined quiet zones apply, verification capacity can limit long inputs, and the payload is not returned. That is real context the annotations do not carry. Minor gap: nothing about overwrite behavior at output_path.

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 supported formats, followed by constraints in a tight sequence of sentences. Dense but nearly every clause carries a distinct fact; the only soft spot is the somewhat opaque 'verification capacity can limit long inputs' phrasing.

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 10 parameters, no output schema and 20% schema coverage, the description should do more. It correctly states that payload and completed digits are not returned (important since there is no output schema), but it never explains what the tool reports on success/failure or the meaning of the rendering parameters.

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 only 20%, and only input_path/output_path are documented in the schema. The description compensates partially by covering format, human-readable labels, quiet zones and digit validation, but leaves scale, height, background/foreground, code39_check and the text flag's exact meaning (human-readable captions) 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+resource ('create a verified SVG or PNG ... barcode') and enumerates the exact symbologies supported, plus the file-based payload source. An agent can distinguish this from abox_qr_generate and abox_svg_to_image 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?

The file-based input model and the 'PNG requires a local browser' constraint imply usage context, but there is no explicit when-to-use/when-not-to-use statement or named alternative (e.g. QR codes vs. Code 128, or when to prefer abox_svg_to_image). Usage is inferable 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?

Adds real value beyond annotations: it verifies a byte round trip and 'never returns file contents', so an agent knows the result is a file on disk, not data in the response. It also notes local-path-only scope. It does not say whether an existing output file is overwritten, which matters given 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-loads what the tool does, then the encoding variants, then behavioral guarantees. Dense but every clause carries information; the relaxed/canonical clause is compact but slightly jargon-heavy for an agent skimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A 5-parameter, no-output-schema mutation tool that mostly covers what's needed: writes a file, returns no contents, round-trip verified. The remaining gap is overwrite/error behavior on the output path, which the annotations alone don't settle.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, with url_safe and canonical undocumented in the schema, but the description compensates: url_safe is mapped to 'standard padded or URL-safe unpadded' and canonical to 'exact spelling and zero unused bits'. This is exactly the semantic gap-filling expected at low coverage; the path parameters rely on their schema descriptions.

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 specific verbs (encode/decode) and resources (local file bytes -> Base64 text, Base64 -> new binary file). No sibling tool shares this resource, and the bidirectional scope is clear enough that an agent can pick it over abox_file_hash or abox_image_data_uri.

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?

Explains the two operating modes and the condition selecting relaxed vs canonical decoding ('relaxed accepts whitespace, either alphabet and missing padding; canonical requires the requested exact spelling'). It gives clear context but never states exclusions or when to prefer a different tool (e.g., for hashing vs encoding).

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 useful behavior beyond the annotations: no Google contact/publishing, config text is preserved in the output file, optional photos are re-encoded, and a local browser is required. It does not cover overwrite behavior or permission expectations, but the annotations already establish the local, non-destructive write profile.

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-loads the core action and output format, then adds only meaningful constraints: local photo handling, no Google contact, config retention, and browser requirement. No sentence 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?

No output schema exists, but the description sufficiently explains that the result is an SVG/PNG written to output_path and emphasizes local-only behavior. Minor gaps remain around scale behavior and whether output_path is overwritten.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 60%, with descriptions for the three path parameters but not for scale or format. The description reinforces local JSON config input, optional photo re-encoding, and SVG/PNG output, but leaves scale semantics 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: "Render an illustrative business listing preview" from a local JSON configuration into SVG or PNG. The business-listing preview focus and local-config input distinguish it from the file/image/PDF utility 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?

Clearly frames the use case as an illustrative local preview and explicitly excludes contacting/publishing to Google or verifying a real listing. It also notes the local browser requirement, though it does not call out an alternative sibling tool.

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?

Beyond annotations, the description discloses the human-in-the-loop flow, permission granting, viewer approval, direct peer-to-peer media with no relay or recording, and that opening the window does not begin capture. It also clarifies what reaches the pairing service and what is not returned to the agent, which is unusually strong behavioral context for a session 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?

The purpose is front-loaded, and each subsequent sentence adds material behavioral or privacy context. There is no repetition or filler despite covering a complex session flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, open-world session tool with no output schema, the description covers the important behavior, privacy boundaries, and what the agent does or does not receive. It is only incomplete in that it does not address room_name or ttl_minutes semantics.

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 needs to carry parameter meaning. It explains the host/viewer distinction behaviorally, but does not explain room_name or ttl_minutes at all, leaving two of three parameters without semantic guidance beyond their names.

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: opening the local companion for abox.tools Remote Camera as host or viewer. It is clearly distinct from file-processing siblings, but it does not explicitly name or contrast with adjacent session tools like abox_share_session or abox_walkie_session.

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 context for use: remote camera sessions where a person opens a local companion, grants permission, and approves viewers. It does not state when to prefer this over other session tools or when not to use it, so it falls short of full alternative-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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds a genuine extra commitment — "Does not read user files" — which is useful privacy context beyond the annotations, but says nothing about cost, freshness, or whether results are cached/environment-dependent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no waste, with the positive capability statement front-loaded and the privacy caveat second. Every sentence 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?

For a zero-param, no-output-schema discovery tool the description covers the main question (what capability information is available) including browser availability, which is environment-dependent. It could say slightly more about what the caller gains before invoking it, but nothing essential 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?

Zero-parameter tool, so per the baseline there is nothing for the description to disambiguate. The schema is trivially complete for an empty object.

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 ("List") and a concrete resource set (supported local operations, limits, installed browser availability). This reads clearly as a discovery/meta tool, distinguishing it from the sibling operation tools (image_compress, pdf_split, exif_remove) without needing to name them.

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: mentioning "limits" and "installed browser availability" hints the agent should call this before attempting an operation, but there is no explicit "use when" or "do not use for" statement, and no routing to siblings.

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 safety (no destruction, no open world), and the description adds substantive context beyond them: pre-save verification, that HTML formatting alters whitespace and implicit closing, that this is not sanitization, and that nothing is executed or fetched. What's missing is behavior around writing to output_path, such as whether an existing file is overwritten.

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?

Four tightly packed sentences with no filler, and the core capability is stated first. The caveat sentences are dense but each carries distinct information; the prose is slightly crammed rather than bloated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers what the tool does and key caveats, but with no output schema it should say what is returned and what happens to an existing output_path for a write tool. Those operational details are absent, leaving a moderate gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, and the description adds just one parameter-relevant nuance: minification applies only to supported HTML/CSS, implying YAML cannot be minified. It says nothing about indent values or how minify interacts with indent, leaving real gaps relative to the low coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb pair (pretty-print/minify) and concrete resources (HTML/CSS/YAML), which cleanly separates it from siblings like abox_xml_format and abox_json_format. It doesn't name those siblings explicitly, so the differentiation is inferable 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 language list and the pretty-print/minify framing, but there is no explicit when-to-use/when-not guidance or routing to abox_xml_format or abox_json_format for XML/JSON inputs. The agent must infer the boundary itself.

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 substantial behavior beyond the annotations: payload text is never returned in tool results (only found/symbology/geometry), decoded data is written to a new local JSON report, links are never opened, and a local browser is required. This is exactly the kind of privacy and side-effect disclosure annotations can't convey, and it is consistent with readOnlyHint=false given the report write.

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?

Dense but front-loaded: the read action comes first, followed by result/output semantics and the browser prerequisite. The opening sentence is long with many clauses, but no sentence is 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 return-value burden by explaining found/symbology/geometry versus payload-in-JSON, plus the no-code case. An agent has everything needed to decide to call it and interpret results.

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 67%, and the description reinforces the input_path/output_path local-only constraint without adding syntax detail. The third parameter, 'thorough' (boolean, default true), is neither described in the schema nor referenced in the description, leaving a real behavioral knob undocumented.

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 ('Scan a still local JPEG, PNG or WebP for one QR code or supported linear barcode') and names the output artifact. It is clearly distinguishable from the generation siblings abox_qr_generate and abox_barcode_generate, which produce rather than read codes.

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 qualifying context: still images only (JPEG/PNG/WebP), one code per image, local browser required, and the outcome for a no-code image. It does not explicitly name an alternative tool or state exclusions beyond the local-file requirement, 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?

Annotations already cover readOnly, idempotent, non-destructive and openWorld=false, so the bar is lower; the description still adds material behavior: sequences and unsupported transforms are refused, output excludes patient names/dates/private values/identifiers, and no browser is required. It stops short of describing failure modes or error reporting.

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?

Five short sentences, front-loaded with the accepted-input scope. Dense with domain jargon (PS3.10, RLE, transfer syntax) but every sentence carries information; 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 usefully characterizes the return as 'technical shape and counts' minus identifiers, which is enough for an agent to know what to expect. A note on what a refusal looks like 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?

Schema description coverage is 100% and there is a single parameter, so the schema already documents input_path fully (absolute local path, URLs/network shares refused). The description adds only the "requires no browser" framing, which is marginal for this dimension; 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 (inspect) and resource (DICOM PS3.10 files) with explicit scope limits: bounded, flat, known native transfer syntaxes, strict one-frame RLE/JPEG-lossless subsets. This clearly separates it from abox_dicom_render, though it never names the sibling 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?

"Checks compressed geometry and complete stream structure before source decoding" implies its role as a pre-flight validation step before rendering, which is real usage context. It does not explicitly say when to prefer abox_dicom_render instead or what to do when the inspection is refused.

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then adds only material constraints. Despite technical density, each sentence contributes useful selection or invocation context without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, so the description must compensate. It usefully clarifies windowing and frame scope, but does not explain invert, exact window_width/window_center semantics, or the frame parameter's range and default, leaving meaningful parameter ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: rendering a single DICOM frame into PNG with defined pixel formats and windowing. It clearly distinguishes the operation from inspection siblings by emphasizing rendering, though it does not explicitly name abox_dicom_inspect as the non-rendering alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered; the description adds genuinely new context such as the 3–6 pixel edge inset caused by source warping and that output pixels/PDF payloads and page layout are verified. The local-browser requirement is a real operational constraint not expressed in structured fields. It doesn't say whether an existing output file at output_path is overwritten, which is a notable omission for a writer 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?

Roughly four tight sentences, front-loaded with the core action and followed by constraints and the non-goals. The telegraphic style ('Perspective-correct explicit document corners...') is dense but every clause carries information; 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 11 parameters, 18% schema coverage, no output schema, and a required JSON config whose structure is never described, the definition leaves too much undocumented for an agent to invoke it confidently. It should at minimum sketch the config file's contents and explain the tuning knobs (strength, quality, dpi, max_side).

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 only 18% (just the three path params), yet the description does not explain dpi, quality, max_side, strength, margin_mm, page_size or format. The one useful addition is that config_path supplies 'explicit document corners', hinting at the JSON payload's purpose, but the format of that JSON and the meaning of strength/quality remain unspecified in both places.

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 names a specific verb and pipeline: perspective-correct explicit document corners from a local JSON file, then clean up pages into a PDF or PNG. It also distinguishes itself from neighbors by ruling out OCR / corner detection and from generic converters by requiring a browser renderer. An agent can tell this apart from siblings like abox_image_convert or abox_receipt_extract.

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 exclusions ('Does not detect corners or perform OCR') and an environmental prerequisite ('Requires a local browser'), which effectively tells the agent when this tool is the wrong choice. It stops short of naming explicit alternatives (e.g. use abox_receipt_extract for OCR), so it lands at 4 rather than 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?

Goes well beyond the annotations by disclosing the post-write verification pass, that thumbnails and compressed picture payloads are retained, that non-targeted metadata survives, and the real risk that rebuilt EXIF can invalidate undocumented maker-note offsets. It also states the privacy property that values never enter arguments or results, which the annotations cannot express.

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 formats, then layers the verification and risk caveats. Sentences are dense and telegraphic ('Requires no browser', 'Values never enter tool arguments or results') but each carries distinct information, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and a non-trivial binary rewrite, the description covers verification, retained blocks, residual metadata and known risk. It stops short of saying whether output_path may overwrite an existing file or whether the input is left untouched, which an agent would want before calling.

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 each path parameter is already documented as an absolute local path with network shares refused. The description reinforces that edits_path is a bounded JSON file holding values rather than inline arguments, but adds little beyond what the schema already says.

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 pair (set/remove) and resource (EXIF tags) with supported formats (JPEG, PNG, WebP) and the edit mechanism (local JSON edits file). It implicitly separates itself from bulk-removal tools via 'Other metadata remains; this is not anonymization', but never names the exif_remove sibling that would be the actual alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied rather than stated: inputs must be local absolute paths, values must live in a companion edits file, and the operation is scoped to selected tags. The 'not anonymization' clause hints at a different tool but no sibling is named and no explicit when-to-use/when-not conditions are given.

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 readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real value by disclosing the output scope: presence and counts of supported blocks, with private tag values and image bytes withheld — information an agent cannot get from 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?

Two tight sentences with the non-modifying guarantee and supported formats front-loaded, followed by the report scope. 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 carries the burden of describing returns, and it does so at a high level (presence and counts, values withheld). It does not enumerate which metadata blocks are 'supported', leaving some ambiguity, but nothing critical for 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% and the single input_path parameter is fully documented in the schema, including the refusal of URLs and network shares. The description adds nothing parameter-specific, 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 ('Read the metadata inventory') and narrows the scope to local JPEG, PNG or WebP files. The 'without modifying it' clause and 'presence and counts' framing clearly separate inspection from siblings like abox_exif_edit or abox_exif_remove, though no sibling is named 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 'inspect' and the read-only framing, but it never says when to choose this over abox_exif_edit, abox_exif_remove, abox_gif_inspect or abox_file_hash. No exclusions or prerequisites are stated beyond the format 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?

Goes well beyond the annotations: it discloses that the operation is lossless (no re-encoding), that it writes a new file rather than mutating the input (consistent with destructiveHint=false), that the output is re-inspected, and which metadata survives by default. What it omits is the reason for idempotentHint=false — e.g. whether an existing output_path is overwritten or rejected.

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?

Four short sentences, each carrying a distinct payload: what it does, verification behavior, defaults, and output/non-goal. No filler and the core operation leads.

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 write tool with no output schema, the description covers operation, formats, lossless guarantee, preservation defaults, output location, and the explicit non-goal of anonymizing visible content. The only residual gap is overwrite behavior on an existing output file, which is minor.

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 50% — the two boolean flags carry no schema descriptions — but the description compensates by stating that defaults preserve an orientation-only EXIF block and the ICC profile, which explains exactly what keep_orientation and keep_icc control. Path semantics are covered by the schema's own 'absolute local path, no URLs' text.

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?

A specific verb ("Remove") plus a precisely bounded resource ("metadata from JPEG, PNG, or WebP containers") plus a key qualifier ("without re-encoding image data"). The format restriction and the lossless framing make it unmistakable against siblings like abox_image_compress or abox_pdf_split.

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 context is implied rather than stated: 'Writes a new local file' and 'does not anonymize visible content' clarify scope but never name an alternative tool or a when-not condition. There is no guidance about prerequisites (does the output file need to not exist?) or what to do when metadata is unsupported.

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/closed-world, so the description earns credit for adding real behavioral facts: streaming (memory-safe for large files), support for empty files and up to 8 GiB, and the guarantee that no file contents are returned or modified. It does not mention failure modes for >8 GiB files or hashing errors.

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, front-loaded with the action, then constraints, then the default. Every sentence carries information the agent needs; nothing is redundant 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 two-parameter read-only tool with annotations covering safety, the description covers input scope, size limits, output form (hex digests) and the default algorithm — enough to call it correctly without an output schema. Ordering of returned digests relative to the requested algorithms list is the only notable omission.

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 50% — only input_path is documented in the schema, while `algorithms` has no description. The description adds the size/empty-file constraint and notes SHA-256 is the default, but never names the available algorithms (md5/sha1/sha384/sha512) or says multiple digests can be requested together, leaving the enum array under-explained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb and resource — streaming a local file through checksum engines to produce hexadecimal digests — which no sibling tool does, so it is naturally distinct from the format/convert family. An agent can immediately tell this is a hashing utility, not a media transformer.

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 'Stream a local file' and the 8 GiB/empty-file support, and the local-only scope is reinforced in the path parameter. However there is no explicit statement of when to prefer this tool (e.g. integrity verification, deduplication) or what to do when a URL must be hashed instead.

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 generic mutation profile (readOnly=false, destructive=false, non-idempotent, closed-world). The description adds real value: post-write verification of LZW streams, timing, palette pixels and composited frames, plus an explicit warning that quantization, resizing and centisecond timing are lossy, and an environment requirement. It omits overwrite behavior for output_path, which is the main remaining gap for a write 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?

Three sentences, front-loaded with the core operation and then constraints and caveats. No filler, and each clause adds a distinct fact (formats, controls, verification, lossiness, environment).

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 15-parameter write tool with no output schema and near-zero schema descriptions, the definition covers purpose, limits, validation and lossy behavior well. It is still missing overwrite semantics, default values and the precedence between mutually exclusive sizing/timing/loop parameters, which an agent needs to call it correctly on the first try.

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 only 7% across 15 parameters, so the description carries most of the burden. It enumerates the control families (timing, size, fit, palette, dithering, transparency, looping) and the 32-frame cap, which is genuinely helpful, but it does not disambiguate the competing pairs (delay_ms vs delays_ms, width/height vs max_side, loop vs loop_count) or state defaults, leaving several parameters still opaque.

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 ('Turn ... ordered still images into a new GIF') plus the accepted input formats and the control surface. This clearly separates it from siblings like abox_gif_inspect, abox_gif_split and abox_gif_to_mp4, which consume rather than produce GIFs.

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 input-count bound (1 to 32), format restriction (JPEG/PNG/WebP) and 'Requires a local browser' hint at when the tool applies, but no alternative is named and there is no explicit when-not guidance. An agent could reasonably wonder whether to use abox_images_to_video or abox_gif_inspect first; the description does not route it.

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 and non-destructive, and the description usefully corroborates and extends that: 'Reports structural damage without modifying the input' plus explicit disclosure of what is withheld (comments, application text, palette values) and that frame summaries are paginated. It does not describe error behavior for malformed/non-GIF input or output shape, keeping it below 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, each carrying distinct information: scope, exclusion, side-effect/privacy profile, pagination. Front-loaded with the verb and resource, 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 does the work of saying what is reported (headers, frame rects, timing, disposal, palette counts, structural damage) and how results are paged. Missing only edge-case behavior (invalid path handling, whether damage reporting aborts the inspection).

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 only 33% — frame_limit and frame_offset have no schema descriptions. The description partially compensates by explaining that frame summaries are paginated with a zero-based offset, but frame_limit gets no explicit meaning (default 20, max 100) in the prose. Partial compensation for a documented 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 ('Inspect') and enumerates the exact resource facets covered: headers, frame rectangles, timing, disposal, palette counts. That is clearly distinguishable from siblings like abox_gif_split, abox_gif_create, or abox_video_inspect.

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 negative scope ('Does not decode or verify LZW pixels') and a privacy scope ('Private comments, application text and palette values are excluded'), which tells an agent when this tool is sufficient rather than a decoder. It stops short of naming an alternative sibling (e.g. abox_gif_split) for pixel-level work, so it is not a full when/when-not routing statement.

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 say readOnly=false and destructive=false but nothing about safety, verification or environment. The description adds real context: output is verified pixel-by-pixel, decoding is strict and aborts on damaged frames, a local browser is required for encoding (implying cost/latency), and frames are not scaled. It does not say what happens if output_dir already exists, which matters given idempotentHint=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?

Five dense sentences, each adding a distinct fact (output, mode semantics, error policy, verification, environment constraint) with the primary outcome front-loaded. No filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does describe the artifacts produced (PNG directory + timing manifest). Missing details are modest: file naming convention, manifest format, and behavior on a pre-existing output directory for a non-idempotent writing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, and the description compensates meaningfully by defining what 'composited' and 'stored' modes actually do rather than just listing the enum values. 'Selected or all frames' implies the purpose of the frames array but gives no indexing convention or bounds, which remains a 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, resource and output artifact: extract GIF frames into a new local directory of lossless PNGs plus a timing manifest. That output shape cleanly separates it from sibling GIF tools (abox_gif_inspect, abox_gif_create, abox_gif_to_mp4) without needing to name them.

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?

Explains the two modes and their defaults, which tells an agent how to configure a call, and 'strict decoding refuses damaged or partial frames' implies a failure mode. But it never says when to reach for this tool instead of abox_gif_inspect or abox_gif_to_mp4, so the alternative-routing guidance is left implicit.

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?

Beyond the annotations, the description discloses important behavior: output is silent H.264, timing is preserved, transparency is flattened over a chosen background, odd dimensions are padded, and output frames/timing are verified. It also surfaces a significant environmental constraint: a local browser with a supported native H.264 encoder is required and no external encoder is downloaded. These details materially help an agent anticipate behavior and constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and then layers in constraints and behavior in four compact, information-dense sentences. There is no filler, and the most important details come first.

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 conversion tool with no output schema, the description covers core behavior, verification, and environmental requirements well. The remaining gap is that it does not describe the return value or whether the output path is returned, and bitrate semantics remain unexplained. These are meaningful but not fatal omissions given the otherwise rich behavioral detail.

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 only 50%, so the description needs to compensate. It adds meaning for the background parameter by explaining that transparency is flattened over a chosen background, but it never explains the bitrate parameter, its units, or effects. The input_path and output_path semantics are already covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action and resource: encoding a GIF playback cycle into a silent H.264 MP4. It is clearly distinguishable from sibling tools like abox_gif_inspect, abox_gif_split, and abox_images_to_video because it names the exact source and output formats. An agent can identify the tool's job 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?

The conversion purpose is clear from the name and first sentence, so usage is strongly implied. However, the description does not explicitly say when to use this tool versus alternatives such as abox_images_to_video or abox_gif_create, nor does it state when not to use it. It provides runtime requirements but no 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?

Adds substantial context beyond the annotations: metadata is stripped, output is 8-bit SDR, JPEG/WebP are lossy, a local browser is required, and the tool pre-validates extents/dimensions and compares every output pixel post-decode. The destructiveHint=false annotation is consistent with writing only to a new directory, and the description explains the data-loss behaviors (metadata omission) that annotations cannot express.

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 output, then layered with validation and caveat details. Dense and jargon-heavy ("admitted", "reference budgets") but each sentence carries distinct information; only the validation-procedure sentence borders on over-detail for a tool description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description never states what the result looks like (counts, paths, per-file verification report) despite describing a verification step. Otherwise it covers format, quality implications, environment requirements, and data-loss caveats adequately for a 4-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%: input_path and output_dir are documented in the schema, but format and quality are not. The description mentions JPEG/PNG/WebP formats (mapping loosely to format) but says nothing about quality semantics or defaults above the schema's own default 0.92, so it does not compensate for the 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 (convert) and resource (HEIC images, including tiled grids) with the destination artifact (a new directory of JPEG/PNG/WebP). It is clearly not abox_image_convert or abox_avif_convert by virtue of the HEIC/HEVC scope, 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?

"Requires a local browser" and "offline" imply the execution context, but the description never says when to prefer this over abox_image_convert or abox_avif_convert, nor when not to use it. Usage is inferable, not 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?

Beyond the general non-destructive annotations, the description adds critical operational behavior: it requires a 'local browser' to function, and clarifies that 'Input names and heights remain in the output file,' which is specific data retention behavior.

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 efficient, front-loading the primary action ('Render locally configured figures...') and immediately listing the key capabilities. The language is dense but highly descriptive, avoiding padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the complexity of a rendering tool that requires local resources and specific visual configurations, the description is complete. It covers the engine, the supported elements, the file types, and the environmental requirements.

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?

Since schema coverage is only 50%, the description compensates by explaining what the tool processes (names and heights) and what options are available (silhouettes, technical ruler options, explicit units), adding meaning to the data inputs.

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 title and description are highly specific: 'Render locally configured figures, names and heights' into SVG or PNG. This clearly defines the function (creating a visual comparison chart) and the resource (data visualization).

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 the intended use case (rendering figures, names, and heights) and lists the specific features (silhouettes, technical rulers). While it doesn't explicitly list sibling alternatives, the highly specific nature of the function serves as a clear boundary.

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?

Goes well beyond annotations: discloses that it writes a JPEG photo, print sheet and measurement report into a new directory; performs geometry, DPI, output dimension and lossy JPEG pixel error checks; and requires a local browser. These details clarify side effects and constraints consistent with readOnlyHint=false and 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?

Four sentences, front-loaded with the core action, then outputs, exclusions, checks and the local-browser requirement. Every sentence carries useful information with no repetition or 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?

For a mutation tool with no output schema, the description adequately covers written artifacts, validation checks and runtime requirements. It does not describe the expected JSON settings format or failure behavior, but those are reasonable external details for a three-path-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three path parameters are already documented in the schema, including the rejection of URLs and network shares. The description mentions the roles of input, settings and output artifacts but adds no syntax or parameter-level detail beyond the schema, so baseline 3 is 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 ('Apply custom numeric photo rules') and resource ('ID photo', 'print sheet'), distinguishes the tool from generic image siblings by clarifying 'No face detection, country rules or official approval', and names the exact artifacts written. An agent can tell what this tool uniquely 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?

Usage context is implied by 'custom numeric photo rules and explicit crown, chin and eye landmarks from a local JSON settings file', but no sibling alternatives are named and there is no explicit when-to-use vs when-not-to-use guidance beyond the 'no face detection' exclusion. An agent must infer that other image tools are not appropriate.

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

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

Annotations already declare it is a non-read-only, non-idempotent write; the description adds substantive behavior beyond that: it writes a new local file, the target can be missed so 'fitted' should be checked, small files pass through with metadata retained, and 'auto' may change the output extension. It omits overwrite semantics for an existing output_path, which matters for a non-idempotent writer.

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?

Four short sentences, front-loaded with purpose before caveats, with no filler. Some phrasing is overly telegraphic ('Check fitted'), which costs a little clarity for its brevity.

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 file-writing tool with no output schema, the definition covers the main failure mode (missed target) but leaves return-value shape, overwrite behavior on output_path, and the effect of allow_resize unstated. Adequate but with visible gaps given the 5-parameter, mutation nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, so the description carries extra burden. It clarifies target_bytes ('target byte count'), the 'auto' value of format, and implicitly resizing, but says nothing about allow_resize or the 'keep'/'jpeg'/'png'/'webp' format choices, leaving half the parameters to the schema alone.

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 (compress) plus the accepted resource types (JPEG, PNG, WebP) and the governing constraint (target byte count). It is clearly distinct from siblings like abox_pdf_split and abox_exif_remove, though it does not explicitly contrast with them.

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 implies the use case (hit a byte budget) and adds caveats about misses and pass-through, but never states when to prefer this over e.g. abox_exif_remove or when it is inappropriate. Usage must be inferred from the target_bytes requirement.

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 establish it is a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds genuinely non-obvious traits: JPEG transparency is filled with the requested background, the output format and dimensions are verified after writing, and metadata may be stripped by re-encoding — a real data-loss caveat that the destructiveHint=false annotation does not convey.

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, zero filler. The capability and format matrix come first, then the notable behaviors, then the caveat — appropriately front-loaded and each sentence carries distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully states what the tool does with the output ('writes a new local image and verifies its format and dimensions'). Remaining gaps are modest: no mention of overwrite behavior on an existing output_path, and no return-value shape, but the critical call requirements are covered.

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 40%, so two of the non-path parameters (format, quality) lack schema descriptions. The description recovers the format enum implicitly and explains the background parameter's role in JPEG transparency, but quality (default 0.92) and its interaction with lossless PNG/WebP are never addressed. Partial compensation only.

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 ('Convert a still JPEG, PNG, or WebP into JPEG, PNG, or WebP') plus the output artifact ('Writes a new local image'). This is clearly distinct from sibling operations like abox_image_compress, abox_image_resize, or abox_svg_to_image, though it never explicitly names them for contrast.

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 format-pair framing, so an agent can infer this is for format change rather than size or dimension change. However, there is no explicit 'use X when Y' routing against the large family of image siblings, and no stated preconditions beyond the local-path requirement carried by the schema.

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 real context beyond the annotations: signature-based type detection, byte-preservation verification, metadata/SVG markup retention, and an explicit negative scope ('does not verify rendering or sanitize SVG'). It stops short of saying whether output_path may overwrite an existing file, which matters given readOnlyHint=false and idempotentHint=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?

Four tight sentences, each carrying a distinct fact (what it makes, how encoding is chosen, what is preserved, what is not done, what is returned). No filler, though the SVG-encoding sentence is dense enough to require a second 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 no output schema, the closing 'Returns paths, sizes and metadata counts' usefully covers return values, and the non-sanitization/no-render-verification caveats close the main safety gap. Remaining gap is the undocumented `identifier` parameter, which leaves one of five inputs unexplained across both schema and description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, so the description has to carry weight; it partially does by mapping output shapes onto the `shape` enum in prose and hinting at the auto/base64 svg_encoding split. The `identifier` parameter (presumably the CSS custom-property/HTML name) is never mentioned, and the shape descriptions are not tied to the literal enum values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb (encode image bytes) plus the exact resource produced (a local .txt data URI, .css rule/custom property, .html tag, or .md image), enumerating all output shapes. This separates it from abox_base64 and abox_image_convert 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?

Offers conditional guidance for the svg_encoding choice ('Standalone UTF-8 SVG URIs can use percent encoding; SVG embedding shapes use Base64'), which is genuinely useful. However it never states when to pick this tool over the nearby abox_base64 or abox_svg_to_image siblings, so routing remains inferential.

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?

Goes meaningfully beyond the annotations: it states a new file is written, that re-encoding can change pixels, that source metadata is stripped, and gives hard size caps (8192 px/side, 32 MP). That is real context not present in readOnlyHint/destructiveHint. The one notable omission is whether an existing file at output_path is overwritten or refused.

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?

Four dense sentences, front-loaded with the core verb+resource and followed by constraints and caveats; almost every clause carries information. The phrase 'using the existing abox.tools engine' is the one bit of near-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?

For a 12-parameter mutation tool with no output schema and 8% schema coverage, the description supplies the essential behavioral envelope (limits, format outcomes, metadata loss, layout defaults). Overwrite semantics for output_path and the quality/background parameters are the remaining gaps an agent would want.

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 only 8%, so the description must compensate, and it largely does: it explains gap, padding, contain/cover, cell ratios, format choices, columns default for grid, and the 8192 px/32 MP resolution ceiling. It leaves quality and the width default (1600) and background color semantics unaddressed, which is why this is not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (Arrange) and resource (still JPEG/PNG/WebP images) plus the exact output modes (grid, horizontal/vertical strip), which cleanly separates it from siblings like abox_images_to_video or abox_image_stack. It never names a sibling to contrast against, so it stops just short of the top band.

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 input constraints (2-32 still images, absolute local paths) and by the stated defaults (grid = two square columns, strips preserve ratios), which helps an agent pick options. There is no explicit statement of when to prefer this over abox_image_stack or abox_images_to_pdf, and no exclusion guidance beyond the implicit 'still images only'.

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 annotations declaring a non-readonly, non-destructive write, the description adds real context beyond them: the operation is permanent, output is a flattened PNG, source metadata is not copied, every decoded output pixel is verified, and a local browser is required. It does not state that transparency/color profile may be lost or how out-of-bounds regions are reported, keeping it just short of 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?

The effect and permanence are front-loaded in the first sentence, followed by inputs, outputs, verification and limits in a tight sequence with no filler. It reads as a dense list of clauses, which is efficient but slightly terse to scan.

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 3-parameter write tool with no output schema, the description covers effect, accepted formats, output format, metadata handling, verification and the browser prerequisite. Remaining gaps (error behavior for mismatched dimensions or non-fitting rectangles) are partially covered by 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 description coverage is 100% and the schema already documents all three paths and the JSON region format in detail. The description only restates that dimensions and rectangles come from a local JSON file, so it adds little beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Permanently replace explicitly selected image rectangles with opaque black pixels" gives a precise verb, resource and effect, and no sibling tool performs redaction, so it is unambiguous against the surrounding compress/resize/convert family. The follow-on sentence naming the accepted input formats and PNG output further pins down the operation.

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 makes clear the regions must be chosen in advance and supplied via a JSON file, and explicitly says it "Does not detect sensitive content or prove the chosen regions cover it," which steers an agent away from expecting auto-detection. No sibling is named as an alternative, but none exists, so guidance is effectively complete for the context.

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 generic write profile (readOnly=false, destructive=false, idempotent=false, openWorld=false); the description adds real value by disclosing that a new local file is written and verified, that re-encoding may strip metadata, and that upscaling is disabled by default. It does not say whether an existing output_path is overwritten.

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?

Four short sentences, front-loaded with the operation and formats, then the sizing rules, then behavioral notes. The phrase 'existing abox.tools geometry and codecs' is mild filler but arguably signals consistency with sibling tools.

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, low schema coverage, and a mutation tool, the description should carry more: overwrite behavior on output_path, what 'verifies' means, and the role of quality/background when re-encoding are all unstated. The core geometry semantics are covered, so it is adequate but incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 22% of 9 parameters, and the description compensates for some: the meaning of fit values ('contain' fits the whole image, 'cover' crops centrally) and the default of allow_upscale. It says nothing about format, quality, or background, leaving a third of the parameters undocumented in both places.

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 ('Resize a still JPEG, PNG, or WebP') plus the scope of supported formats, which cleanly separates it from siblings such as abox_image_convert and abox_image_compress. An agent can identify the operation 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 concrete invocation conditions: specify width, height, or both; contain fits the whole image, cover crops centrally; upscaling is off by default. It stops short of naming alternatives (e.g. use abox_image_convert to change format only) or stating when not to use it.

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 (not read-only, not destructive), and the description adds real operational context beyond them: it writes and verifies an output file, needs a local browser, and refuses non-local paths. It does not say what happens if output_path already exists (overwrite vs. fail), which is the main remaining behavioral 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?

Three tightly packed sentences with the capability front-loaded and limitations trailing. The clipped enumeration style ('No alignment, rescaling, RAW decoding or focus stacking') is efficient rather than wasteful.

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 7-parameter write tool with no output schema, the description covers inputs, methods, constraints and the fact an output file is written and verified. It falls short on the semantics of gain/kappa/quality and on overwrite/conflict behavior, which an agent needs before committing a write.

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 only 14%, so the description must carry weight. It does map the method names (average, median, sigma-clipped, brightest, darkest, additive) onto the enum values, but gain, kappa and quality are never explained, leaving three of seven parameters undocumented anywhere.

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 (combine) and resource (2-8 equal-size opaque still images) with the full method list enumerated. It also carves out scope boundaries explicitly ('No alignment, rescaling, RAW decoding or focus stacking'), which no sibling tool covers.

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?

Clear preconditions are given: images must already line up, must be equal-size, opaque and still, and a local browser is required. The negation list implicitly routes alignment/rescaling/RAW/focus-stacking work elsewhere, though no sibling is named directly.

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 establish the safety profile: not read-only, not open-world, not idempotent, not destructive. The description adds useful behavioral context beyond that, including verification by reopening the PDF and checking page counts/dimensions, local codec use, and metadata retention in keep mode.

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 four efficiently written sentences, front-loads the core action and output, then layers on supported formats and verification behavior. There is no filler or 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?

Given 11 parameters, low schema coverage, and no output schema, the description is only partially complete. It covers the core workflow and verification but omits important operational details like overwrite behavior, limits on input volumes, and semantics for several non-enum parameters.

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 only 9%, so the description needs to compensate, and it does for some parameters: input order, paper sizes, margins, lossless/JPEG encoding, and keep-mode metadata. However, many parameters such as dpi, fit, quality, max_side, background, and orientation remain unexplained, leaving clear gaps.

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: placing JPEG, PNG, or WebP images into a new PDF, one per page, in requested order. That clearly distinguishes it from PDF merge/split and image conversion siblings, though it does not explicitly name an alternative for related tasks.

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 what the tool does but gives no explicit guidance on when to use it versus siblings like abox_images_to_video, abox_pdf_merge, or abox_image_convert. Any usage context is implied by the purpose 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 already establish that this is a non-read-only, non-destructive, non-idempotent closed-world operation. The description adds useful behavior beyond that: silent H.264 output, output verification, frame/dimension/timing limits, and no external encoder download. It stops short of stating overwrite behavior for output_path or error recovery details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core operation, then adds constraints and environment requirements in compact sentences. Every sentence contributes useful selection or invocation context with no 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?

Given 10 parameters, low schema coverage, and no output schema, the description covers the high-level capability, environment, and hard limits well. However, it leaves significant invocation details undocumented, especially individual parameter meanings and output overwrite behavior.

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 only 10%, so the description must compensate, but it only broadly mentions size, timing, fit, and quality controls. It does not explain key parameters such as input_paths limits, durations_ms versus duration_ms precedence, background, fit enum semantics, or quality levels.

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: encode ordered still JPEG/PNG/WebP images into a silent H.264 MP4. This is precise enough to distinguish it from sibling media tools such as gif_create, gif_to_mp4, video_join, and image_layout.

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?

Provides clear usage context through hard limits (60 seconds, 1800 frames, 1080p) and an environment requirement (local browser with native H.264 encoder). It does not explicitly compare with alternatives, but the use case is strongly implied.

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 a non-readOnly, non-destructive, closed-world mutation, and the description usefully adds that it writes a new ICO and then verifies its directory and image entries, plus that it reuses abox.tools' renderer/encoder. It does not say what happens if output_path already exists (overwrite?), what the return payload contains, or any limits, which is the main behavioral gap for a file-writing 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?

Three dense sentences with the conversion target stated first, followed by mechanics and the write/verify step. No filler, though the middle sentence packs three distinct behaviors into one long clause and could be split for scannability.

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 file-writing tool with no output schema, the description covers source formats, fit modes, background and the write-and-verify outcome. It leaves the storage encoding parameter and the overwrite behavior of an existing output_path unexplained, which an agent needs before calling it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 33%, so the description has to compensate and it partly does: it maps 'pad, crop or stretch' to fit, 'requested icon sizes' to sizes, and 'transparent or solid background' to background. It never mentions the storage option (auto/png/bmp), and it paraphrases enum values without explaining what pad versus crop actually does visually.

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 opening sentence gives a specific verb (Convert), a precise input class (still JPEG, PNG or WebP) and a precise output (one ICO with requested icon sizes). No sibling produces ICO output, and the format restrictions implicitly separate it from abox_image_convert and abox_svg_to_image.

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: an agent can infer this is the tool for turning a raster image into a multi-size icon. There is no explicit when-to-use/when-not guidance, no mention of the alternative siblings (image_convert, svg_to_image), and no prerequisites such as the source needing to be a local still image rather than animated GIF.

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?

Beyond the annotations, the description discloses that the trace is a lossy shape interpretation, that complex traces are refused, that it writes and verifies a static path-only SVG, and that it requires a local browser. It does not discuss overwrite behavior for an existing output_path or expected runtime, so it stops short of full behavioral coverage.

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 four compact sentences, front-loads the core action and output, then adds suitability and constraints. There is no repetition or 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?

For an eight-parameter local file conversion tool with no output schema, the description gives a clear output artifact and key behavioral constraints. It is not fully complete because it omits semantics for min_area and corner_angle and does not state what happens if output_path already 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?

The description adds meaning for several parameters by mentioning automatic or explicit threshold, inversion, detail, and single-color output. However, schema description coverage is only 25% and the description does not explain fill format, min_area, or corner_angle, leaving several parameters underspecified.

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 precise verb and resource: trace a still JPEG, PNG or WebP into a single-color SVG path. It names the three raster formats and the output artifact, which clearly separates it from siblings such as abox_svg_to_image and abox_image_convert.

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 says the tool is 'best suited to logos and line art' and refuses overly complex traces, giving real suitability guidance. It does not explicitly name an alternative tool for photographic or non-line-art inputs, so a sibling-level routing rule is missing.

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 substantial context beyond the annotations: it writes a new file, appends a final newline, verifies tokens and structure post-write, and states hard limits (8 MiB input, 256 nesting levels, 32 MiB output). It also discloses preservation guarantees (numeric spellings, large integers, duplicate keys, key order) and that file contents are not returned — none of which the annotations convey.

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?

Dense but front-loaded, with the core action in the first clause and limits/behavior following. Minor filler in the implementation reference ('using the existing abox.tools parser'), but nearly every sentence carries useful information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description supplies exactly what an agent needs: that output goes to a new file rather than the response, the size/nesting limits, and post-write verification. Nothing material is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 40%, so the description must compensate. It clarifies sort_keys as 'natural key sorting' and explains that minify is an alternative mode, but indent's allowed values (2/4/tab) are left entirely to the enum and the interaction between minify and indent is ambiguous. Partial compensation.

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 pair (pretty-print/minify) and resource (UTF-8 JSON file), and the format-only nature distinguishes it from conversion siblings like abox_yaml_json and abox_xml_json. An agent can tell what it 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?

Usage is implied by the operation (format an existing JSON file), but there is no explicit when-to-use/when-not guidance and no mention of alternatives such as the conversion tools. The input_path/output_path constraints in the schema implicitly scope it to local files only.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is clear. The description adds valuable behavioral context beyond annotations by explicitly listing what is NOT returned (pairing codes, invitations, received contents, device labels, media) and clarifying the scope is this adapter process. It does not describe error behavior or whether one or all sessions are returned.

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 compact sentences with no filler. It front-loads the return-content summary and uses the remaining sentences for exclusions and process scope. It could be slightly more front-loaded around the action rather than the return payload.

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 appropriately explains returned fields and exclusions, which is essential. Annotations cover the safety profile well. However, the lone parameter's behavior is left entirely undocumented, leaving a clear completeness gap for an agent deciding whether/how to pass session_id.

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 optional parameter (session_id) with UUID format, but schema description coverage is 0%. The description never mentions session_id or explains whether it filters to a single session or is ignored. With low schema coverage, the description should compensate, and it does not.

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 specifies the exact return payload of a status check (session types, safe state, peer counts, capture kind, expiry, saved-file counts). Combined with the title, an agent can identify this as a read-only status tool. It is clear but does not explicitly name a sibling alternative or give a direct action verb like 'check'.

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 offers no when-to-use guidance, no prerequisites, and no explicit alternatives among siblings like abox_live_stop or the various session tools. The statement 'Sessions belong to this adapter process' is scoping context, not usage guidance. Purpose is implied only by the tool name and title.

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 give generic flags; the description adds real substance by disclosing exactly what is torn down, that completed local saves survive, and that repeat-close is harmless. The 'harmless when already closed' claim sits in mild tension with idempotentHint=false, but it is a nuance rather than a reversal; permission requirements remain unstated.

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, each carrying distinct information, with the destructive-effects disclosure front-loaded. No filler or repetition; only the missing parameter sentence keeps it from being ideal.

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?

Effects and cleanup semantics are well covered, but for a mutation tool with no output schema the agent gets no success/failure signal and no documentation of the one required argument. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is a single required parameter at 0% schema description coverage, and the description never mentions it at all. 'The selected companion browser' hints at a session reference but gives no format, no source for obtaining the id, and no indication of what an invalid id does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a concrete verb ('Close') and enumerates the specific resources torn down: companion browser, capture, peer connections, incomplete receive files. An agent can tell this is a teardown of a live session, though it never explicitly maps the action to the 'session' concept in the tool name or to sibling session tools like abox_live_status.

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: you call it to end a live session. There is no explicit when-to-use/when-not, no mention of checking abox_live_status first, and no guidance on obtaining the session id or whether this should follow a failure.

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?

Beyond the annotations, the description discloses important behavior: it writes a new standalone HTML file, applies a restrictive CSP, verifies tag nesting and source text, keeps links clickable but never opens them, and makes no network requests. This is unusually rich behavioral context for a write-oriented local 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?

The description is front-loaded with the core render operation and then adds security, supported syntax, and link behavior without filler. Every sentence contributes useful scope or behavior 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 two-path local file conversion tool with full schema coverage and annotations, the description covers supported syntax, security posture, link handling, and browser requirements well. It does not mention overwrite behavior for an existing output_path or error/return behavior, which leaves a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both required path parameters are fully documented by the schema. The description adds only the implication that output_path receives a new standalone HTML file and does not explain path handling 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?

The description states a specific verb and resource: render a Markdown dialect into a new standalone HTML file. It also scopes the output with a restrictive CSP and distinguishes the tool from browser-based rendering and raw HTML handling.

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 by listing supported Markdown features and explicit exclusions such as raw HTML, image rendering, automatic requests, and browser use. It does not name a specific alternative sibling tool, so it falls short of full when-to-use/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?

Adds substantial context beyond the annotations: secrets are never returned, never hashed or sampled, and the output file is plaintext rather than a vault. This resolves the natural question of what happens to the generated secret. It stops short of stating what happens if output_path already exists (overwrite vs. refusal), which matters given idempotentHint=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?

Four tight sentences, purpose front-loaded, with the non-obvious constraint (secrets never returned) placed early. Every sentence adds information an 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?

No output schema exists, and the description explicitly explains the return behavior (writes to file, never returns secrets), which is the key gap such a tool would otherwise have. For a two-parameter tool with full schema coverage, nothing material 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 baseline is 3, and the description adds real value on top: the 24-character single-password default is not in the schema, and 'Optional bounded local JSON configuration' characterizes config_path's scope better than the schema's field list. It also enforces a usage constraint (never place secrets in arguments).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Generate cryptographically random passwords or EFF-wordlist passphrases') and states the delivery mechanism ('Writes secrets only to a new local .txt file'). No sibling tool does anything similar, and the definition makes the distinction obvious 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 concrete operating context: defaults to one 24-character password, optional bounded local JSON config selects settings, and directs the agent to call capabilities for the full list of configuration fields. It lacks explicit when-not guidance, but the tool has no true alternative among the file-processing siblings.

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?

Discloses behavior beyond the annotations: it keeps content streams, verifies page order/geometry, pixels may change, output can be larger, and critically that signatures become invalid and the output is an unencrypted new file. That last point matters because destructiveHint=false could otherwise suggest no meaningful side effects.

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?

Six short statements, each carrying a distinct fact, with the core operation and the most consequential warning (signature invalidation) appropriately placed. No restatement of the name or schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does mention that it reports actual savings, so return behavior is partially covered. For a 6-parameter local-file mutation tool the description is nearly complete, though the strip_metadata and preset/dpi interaction remain unaddressed.

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 50%; the description adds meaning for presets and quality ('quality for size') and implicitly dpi ('image resolution'). It says nothing about strip_metadata or how preset and dpi interact, so the undocumented half remains 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+resource ('Recompress supported PDF images and rewrite structure') and scopes it to local files via the title. It implicitly separates itself from abox_image_compress by operating on PDF structure, but never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives useful framing ('Presets trade image resolution and quality for size', 'No byte-target search'), which tells the agent what the tool will not do, but there is no explicit when-to-use versus abox_image_compress or abox_pdf_split 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 indicate this is a local, non-read-only, non-idempotent operation. The description adds useful behavior beyond that: input-order preservation, input limits, output verification, and caveats that metadata/attachments may be omitted and signatures invalidated. It still omits overwrite/error behavior for output_path.

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 sentences, front-loaded with the core action and constraints, then behavioral caveats. Every sentence adds useful information 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?

The description is strong on limits and caveats, and annotations cover safety, but it does not explain keep_bookmarks, overwrite behavior for output_path, or what is returned after verification. For a 3-parameter mutation tool with no output schema, that leaves notable gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 33%, and keep_bookmarks has no schema description and is never mentioned in the description. The description clarifies input ordering and aggregate limits, but it fails to explain a full third of the parameters, leaving a material 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?

The description uses a specific verb and resource: 'Combine ... PDFs ... into a new PDF.' It also scopes the operation to 'unencrypted local PDFs in input order,' which clearly distinguishes it from split, select, and images-to-PDF 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?

It provides clear applicability constraints: 2 to 32 unencrypted local PDFs, with size and page limits. It does not explicitly name alternative siblings or when-not conditions beyond rejecting encrypted/non-local inputs, so it falls short of full 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?

Adds substantial behavior beyond annotations: passwords are read from files and never appear in arguments/results, permission flags are advisory and viewer-dependent, and the output is reopened/decrypted for verification. This is exactly the operational context an agent needs for a non-readonly, non-idempotent 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?

Front-loads the core operation, then adds only high-value constraints about passwords, permissions, and verification. Dense but every sentence 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?

Covers the critical encryption, password handling, permission, and verification behavior for a complex tool with no output schema. It could still state what a successful call returns or how existing output files are handled, but the gaps are minor.

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 50% schema description coverage, the description compensates by explaining revision 6 AES-256 vs revision 4 AES-128, the password-file indirection, and the advisory nature of the print/copy/change flags. The path parameters are already well described in 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 operation (encrypt) on a specific resource (PDF), with supported revisions and explicit scope (unencrypted or blank-open-password PDFs). This clearly distinguishes it from encryption-adjacent siblings such as abox_pdf_unlock even though no sibling is named.

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 by limiting input to unencrypted or blank-open-password PDFs and ruling out password guessing. It does not explicitly name alternatives such as abox_pdf_unlock or say when not to use it, so it falls short of full 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?

Discloses behavior well beyond the annotations: no source text, attachments, links, annotations or metadata objects are copied; all pages are flattened; signatures are lost; output size can increase; RGB samples and object graph are verified. These are exactly the consequences an agent needs before invoking an irreversible-content 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?

Front-loaded with the core action, followed by consequences and constraints; nearly every clause carries information. It is dense to the point of being a single run-on, but no sentence is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description covers what is produced (fresh image-only PDF, verified samples) and what is lost, which is the critical return-value context. Given only four parameters and a non-idempotent mutation, an agent has what it needs to call this correctly.

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 75% and the paths are already documented as absolute-local-only, but the description adds real meaning for regions_path ('Local JSON supplies exact displayed page geometry and top-left point coordinates') that the schema does not convey. The dpi parameter is left unaddressed in both places, so it is not a complete 5.

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 ('replace explicitly selected rectangles with opaque black pixels, and write a fresh lossless image-only PDF'), which is far more precise than the title alone. It is distinguishable from siblings like abox_pdf_compress or abox_image_redact by being PDF-region-specific, but it never names those alternatives for contrast.

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 useful preconditions ('Requires a local browser', 'admitted unencrypted PDF page', local JSON geometry) and boundaries ('Does not identify sensitive areas or prove selected coverage'), which implies when it is appropriate. However, it never states when to pick this over abox_image_redact or abox_pdf_select, nor what to do if the PDF is encrypted (presumably abox_pdf_unlock).

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