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?

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 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?

Goes well past what the annotations declare: it names the write target (a new directory), discloses a hidden cost (reopening every output PDF to count pages), and enumerates losses (tags, labels, attachments, metadata, unsupported actions) plus signature invalidation. 'Writes a new directory' is consistent with destructiveHint=false since no existing data is claimed to be removed, so no contradiction arises.

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 with the operation, the output shape, and the side effects ordered by importance; no filler and no restatement of the title. The dense phrasing still resolves into distinct facts.

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 and only partial schema documentation, the description covers preconditions, side effects, and data loss adequately. It stops short of describing the created directory's structure/naming or error behavior, and leaves two optional parameters 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 description coverage is only 33%, and the description compensates partially by explaining the mode enum semantics (each page / batches / explicit ranges) and that ranges are 1-based, which the schema does not say. But keep_bookmarks and pages_per_file are left entirely unexplained, and the blanket 'omits metadata' sits awkwardly against a keep_bookmarks default of true, leaving the agent to guess their interaction.

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 (split) against a specific resource (an unencrypted local PDF) and enumerates the three output shapes (per page, batches, range groups). The scope 'local, unencrypted' plus 'writes a new directory' cleanly separates it from the sibling image/EXIF utilities and from any in-place PDF 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?

The constraints 'unencrypted' and 'local' function as implicit preconditions, telling the agent when this tool will refuse work. However, there is no explicit when-to-use guidance, no statement about when to prefer batches over ranges, and no mention of alternatives; the agent must infer invocation conditions from the description.

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