ImageCompressor.si

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

With no annotations, the description carries the full burden and does well: it discloses that `keep` still strips metadata (a real side effect), that lossless is limited to four formats, the accepted input formats, and that the result is a download URL valid for one hour. It does not mention auth requirements, rate limits, or whether the source asset is left untouched, which are the remaining gaps for a mutation-shaped 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 purpose in one short sentence, then spends the body on the mode decision tree, which is the highest-value information. Dense but nearly every clause carries load; the format list and mode enumeration make it longer than ideal but not 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 10-parameter tool with no annotations and no output schema, the description covers the return value (hour-limited download URL), the accepted inputs, and the core behavioral branches. It leaves the rotation/crop/resize parameters and any permission model to the schema and outside knowledge, a minor but real gap.

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

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

Schema coverage is already 90%, yet the description adds genuine meaning: target_bytes overrides mode with a concrete example (100000 for 100 KB), the `smart` vs `quality` vs `lossless` vs `keep` semantics, and the format restriction on lossless. Undocumented parameters like `rotate`, `crop_ratio`, and `max_width`/`max_height` are left entirely to the schema, which is acceptable given its richness.

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

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

Opens with a specific verb and resource ("Make an image file smaller") and immediately qualifies scope by noting format is preserved unless `format` is given. It never names `convert_image` or `upscale_image`, so the agent must infer the boundary between compression, conversion, and upscaling from semantics alone.

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

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

Gives clear conditional routing between `target_bytes`, `mode=smart`, `mode=quality`, `mode=lossless`, and `mode=keep`, including the precedence of target_bytes over mode. It stops short of explicit sibling exclusions (e.g. "use convert_image when you only want a different format"), so the agent must reason about overlap with the conversion 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?

No annotations are provided, so the description carries the full burden, and it does disclose the return value ('a download URL valid for one hour') — valuable, since there is no output schema. It does not disclose whether image_url and image_base64 are mutually exclusive, whether quality/resizing affect output, rate limits, or failure behavior, leaving notable gaps for a no-annotation tool.

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

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

Three short sentences, front-loaded with the core action, then guidance, then return behavior — no filler. Minor redundancy: the format list restates part of the enum without adding information, and its incompleteness slightly undercuts its value.

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 return contract is covered despite no output schema, which is the biggest win. But with zero annotations and no output schema, the description should also cover the two mutually exclusive input paths, resize/quality behavior, and error conditions; as written an agent can invoke it but may misuse optional 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 coverage is only 50%: image_url and image_base64 are documented, but quality, max_width, and max_height are undefined in both schema and description. The description only touches the format parameter (and incompletely), so it fails to compensate for the undocumented resize and quality controls that materially change output.

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 an image') and enumerates target formats, so the agent immediately knows this is a format-transcoding tool distinct from compress_image or upscale_image. However, the listed formats omit six of the twelve enum values (bmp, ico, jxl, pdf, tga, psd), so the stated scope is narrower than the actual capability.

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

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

'Use webp or avif to modernise images for the web' gives a format-selection heuristic, which is genuine usage guidance. But there is no guidance on when to pick this over compress_image, upscale_image, or remove_background, and no prerequisites (input source constraints, size limits, auth) are mentioned.

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

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

With no annotations, the description carries the full burden and does a decent job: it says the return value is text plus engine confidence and gives a concrete interpretability threshold (~60 = needs checking). It does not cover the no-text-found case, error behavior for unreachable URLs, or whether mixed-language images are supported, so a gap remains for an unannotated tool.

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

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

Two sentences, no filler, and the core capability leads before languages and result interpretation. Every clause carries information an agent would otherwise have to guess.

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 three-parameter, zero-required read tool with no output schema, the description covers capability, language scope, and how to read the returned confidence. Only edge cases (no text detected, invalid source, unsupported language combinations) are unaddressed, which is a minor gap given the thorough schema.

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

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

Schema coverage is 100%, so every parameter is already documented, including the image_url/image_base64 either-or and the default ['eng']. The description only restates the accepted language codes, adding minimal meaning beyond the schema, which is the baseline-3 case.

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?

It pairs a specific verb with a specific resource ('Read printed text from a scan, a screenshot or a photo of a page'), so an agent immediately knows this is OCR rather than image manipulation. It does not, however, say how it differs from a sibling such as inspect_image, so a sibling-differentiation claim cannot be made.

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?

'Printed text' implicitly excludes handwriting, and the language list narrows usage, but the description never states when to prefer this tool over inspect_image or the other image tools. Usage is implied by input types rather than explicitly routed.

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

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

With no annotations, the description carries the full burden and discloses meaningful behavior: it is read-only and remains available after scan files are deleted. It does not cover permissions or rate limits, but it adds substantial operational context beyond the schema.

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 and compact, with each sentence contributing a distinct fact: purpose, procedural constraints, persistence, and read-only behavior. There is no wasted text.

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

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

For a tool with no annotations and no output schema, the description does enough: it explains what the instructions contain, warns against misuse, and states key behavioral traits. It could be slightly more complete by clarifying the return format or how the agent parameter affects output, but overall it is adequate.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description does not add parameter-specific meaning beyond what the schema provides, making 3 the appropriate baseline.

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

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

The description clearly states that this tool returns step-by-step instructions for applying a scan's package, with concrete phases (inspect, match, change, validate, report). It is distinguishable from get_replacement_mapping by emphasizing instructions rather than the mapping itself, though it does not explicitly name the sibling.

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 establishes clear usage context: use these instructions when applying replacements, and explicitly warns against blind search-and-replace. It does not spell out when to prefer this over get_replacement_mapping, but the workflow guidance is strong.

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

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

With no annotations, the description carries the burden well: it declares 'Reads only', notes the result is paged, explains the status vocabulary (ready, proposed, keep_original, rejected), and warns that mutations happen elsewhere and ask the person first. It does not mention permissions, auth, or behavior on non-ready entries, which keeps it 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?

Front-loads the return shape, then the actionable constraint, then the alternative tools. Dense but every sentence carries information; the field list is long but substitutes for the absent output schema.

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

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

No output schema exists, and the description compensates by enumerating returned fields and status values, plus where the actual files live. Paging is mentioned but without total-count or termination guidance, a minor gap for a 3-param read 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 67% and the schema already documents scan_id's source and limit's default. The description only adds 'Paged', which implies the meaning of limit/offset but gives no bounds, default, or iteration guidance beyond what the schema states.

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

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

Opens with a precise framing ('What replaces what: one entry per original asset') and enumerates the exact fields returned, so the agent knows this is the per-asset replacement map for a scan. That is clearly distinguishable from siblings like list_website_assets (inventory) and get_website_scan (scan metadata).

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

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

Explicitly routes the agent: act only on `ready` entries, get the ZIP address via get_website_scan, and use the local server's load_replacement_package/preview_replacements/apply_replacements to actually change files. It names alternatives and the condition that selects them, which is exactly the when/when-not guidance needed.

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

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

With no annotations, the description carries the full burden. It usefully discloses the returned quantities (requests used this month, plus the account's limits), which implies a read-only operation, but it never states that it is read-only, whether the figures are live or cached, when the monthly window resets, or whose account is queried.

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

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

A single short sentence with zero filler, leading with the primary quantity (request count) and then the limits. Nothing is buried or repeated.

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 parameterless read tool with no output schema, the description needs to convey what comes back, and it does name both the consumed count and the applicable limits. Minor gaps remain around account scoping and the freshness/reset semantics of the numbers, but an agent has enough to call it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Per the baseline for parameter-free tools, this scores 4; no parameter meaning is missing because none exists.

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

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

States a specific resource (request count for this account) and a specific scope (this month) plus the limits, which is more than a restatement of the name. It is clearly distinguishable from every sibling, which are all image/website utilities rather than account-quota tools. It stops short of a clean verb+resource phrasing, reading as a question, but the intent is unambiguous.

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

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

Usage is only implied: an agent can infer this is the tool for checking quota consumption or limit headroom before making calls. There is no explicit statement of when to call it, when not to, or what to do instead, and no prerequisites such as auth context are mentioned.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses that the call blocks for up to a minute — a critical trait — but omits what happens on timeout (error vs. partial result), whether polling again is expected, and any permission requirements. Solid on the main behavior, incomplete on the edges.

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, zero filler, with the identity of the tool and the blocking-wait caveat both front-loaded. Nothing is redundant.

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

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

For a one-parameter polling tool with no output schema, the description covers what it returns, where the id comes from, and the wait window. The remaining gap is post-timeout behavior and return shape, which an agent would want to know before retrying.

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?

Single parameter with 100% schema description coverage, so the schema already explains that job_id comes from optimize_website. The description's 'Pass its job_id' restates the schema without adding format, lifetime, or reuse semantics; 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 resource — the pending result of an optimize_website call — and explains the trigger condition (the call was still working when it returned). This clearly separates it from list_website_scans and get_website_scan, though it never names those siblings explicitly, so an agent must infer the distinction.

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 clear condition for use: it applies to an optimize_website call that returned while still working, and the agent is told to pass that job_id. It does not state when NOT to use it (e.g. for a completed scan, use get_website_scan) or what to do after the wait expires.

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

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

With no annotations provided, the description proactively states 'Reads only,' which is a meaningful behavioral disclosure for a read operation. It also explains field semantics, specifically that estimated_savings is a prediction while optimized_from and optimized_to are measured. It does not cover authentication, rate limits, or error behavior, but it adds useful transparency beyond the bare schema.

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 two tight sentences with no wasted text. It front-loads the core purpose and uses the second sentence for high-value field interpretation. Every phrase 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?

Given the absence of an output schema, the description does a good job explaining what the return contains: scan status, findings, saved outputs, and download addresses. It also clarifies the meaning of key measurement fields. It does not cover possible status values, pagination, or error cases, but it is substantially complete for a single-parameter read 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?

There is only one parameter, scan_id, and the schema already documents it at 100% coverage, including where to obtain the id. The description adds no further meaning about the parameter beyond what the schema provides. A baseline of 3 is appropriate because the schema does the heavy lifting.

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

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

The description clearly states that this tool returns a scan's status, findings, saved outputs, and download addresses for ZIPs, replacement maps, and reports. This is a specific verb-and-resource definition. However, it does not explicitly distinguish itself from siblings like get_website_report, get_replacement_mapping, or list_website_scans, which could cause selection ambiguity.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as get_website_report or list_website_scans. 'Reads only' describes safety, not usage. The only contextual clue is the required scan_id, which the schema says comes from list_website_scans, but the description itself does not route the agent.

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

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

With no annotations, the description carries the full burden and does solid work: it discloses the Chromium renderer, a script-disabled sandbox, blocked network fetches, and a one-hour download URL as the return. It does not cover failure behavior for invalid HTML, size-limit errors beyond the schema's 2 MB note, or any rate limits.

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

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

Front-loaded with purpose and use cases, then constraints, then the parameters that matter, then the return value. Every sentence carries distinct information with no restatement of the name or 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?

Despite eight parameters and no annotations or output schema, the description covers the render environment, the key sizing knobs, and the return contract (a one-hour download URL). An agent has everything needed to call it correctly and anticipate the sandbox limits.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds practical interpretation by clarifying that width/height are CSS pixel page dimensions, that 'scale 2 makes a sharper picture', and that full_page extends a long page to its end. It does not touch format, quality, or transparent, but the schema already documents those fully.

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 ('Draw a page of HTML and CSS as a PNG, JPEG or WebP picture') and enumerates concrete artifacts (social cards, badges, receipts, mockups, SVG diagrams). The clause 'anything fetched from an address does not' work implicitly separates it from the sibling screenshot_url, so an agent can pick correctly without opening a 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 context is clear through the example use cases and the rendering constraints (no script, no network access) that tell the agent when this tool will and will not succeed. It stops short of naming screenshot_url as the alternative for live URLs, leaving that routing step to inference.

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

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

With no annotations, the description carries the behavioral burden and does well: it explicitly says the image is not changed and lists the metadata categories returned, including hidden EXIF/GPS/colour-profile data and duplicate fingerprints. It does not cover error behavior, permissions, or whether remote URLs are fetched server-side, but the core non-mutating behavior is clear.

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

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

It is a single front-loaded sentence with no filler. The enumerated facts are dense but each contributes useful scope, and the non-mutating constraint is stated 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 two-parameter read-only inspection tool with no output schema, the description does a good job of explaining what information is returned and that the source image is untouched. It lacks explicit alternative-routing guidance and some operational details, but the essential selection and invocation context is present.

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 the two input parameters are already well documented by the schema. The description does not add parameter-specific guidance, so the baseline score of 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?

The description states a specific resource (an image) and clearly scopes the operation to extracting facts without modifying it. It enumerates the kinds of facts returned and implicitly distinguishes itself from mutating siblings such as compress_image, convert_image, and remove_background.

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

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

The phrase 'without changing it' implies this is the read-only inspection tool, which gives useful implied usage. However, it does not explicitly say when to choose this over siblings like extract_text or screenshot_url, nor does it state exclusions or prerequisites.

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

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

With no annotations, the description carries the safety burden and does state 'Reads only', which is the key behavioral trait. It also discloses paging behavior and a genuinely non-obvious semantic: `estimated_bytes` is predicted while `optimized_bytes` is measured. It omits auth/prerequisites and whether pagination returns totals.

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 resource definition, then value semantics, then filtering, then the read-only guarantee. No filler, and the most decision-relevant facts 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?

No output schema exists, so the description must characterize returns, and it does: asset kinds, sizes, findings, state, plus the two byte fields. For an 8-parameter list tool it is nearly sufficient; only the response envelope (items array, pagination totals) and the `search` parameter are unaccounted for.

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?

At 50% schema coverage the description must compensate, and it does by naming the four filter dimensions (kind, status, finding, page) and stating the result set is paged, which covers limit/offset implicitly. It leaves `search` and the scan_id linkage unmentioned beyond the phrase 'of a scan', so compensation is good but not complete.

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 first sentence names a specific resource and scope: an asset inventory for a single scan, enumerating images, CSS, JS and fonts along with sizes, findings and state. That clearly separates it from get_website_scan (scan metadata) and get_website_report (aggregate report), though it never names those siblings explicitly.

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

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

Usage is implied rather than stated: paging and 'filter by kind, status, finding or page' suggest per-asset drill-down after a scan, but there is no explicit when-to-use, when-not-to-use, or named alternative. The agent must infer that this is the detail view beneath a scan summary.

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

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

With no annotations, the description carries the full burden and does disclose two important traits: 'Reads only' (safe, non-mutating) and 'Paged' (pagination semantics). It still omits the page-size ceiling, behavior on an invalid or expired scan_id, and whether results are eventually consistent.

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 compact sentences, front-loaded with what the tool returns, followed by paging/filtering and the read-only guarantee. Nothing is wasted or repeated.

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 5-parameter read-only list tool with no output schema and no annotations, the description covers return fields, pagination, filtering, and safety. Minor gaps remain around result ordering, total counts, and the meaning of the four status enum values.

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 offset undocumented anywhere and scan_id only explained in the schema. The description reinforces the search and status filters and the paging model but adds no syntax, matching rules, or defaults beyond what the schema already states.

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

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

States a specific resource and scope: a page inventory for a given scan, with the fields it returns. It is distinguishable from list_website_scans and list_website_assets by the 'pages of a scan' framing, 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?

'Paged; filter by status or search' implies how to narrow results, but there is no explicit when-to-use guidance, no statement of when to prefer get_website_scan or list_website_assets instead, and no prerequisites beyond the scan_id note living in 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?

With no annotations, the description carries the full burden, and it does disclose two useful traits: read-only ('Reads only') and result ordering ('newest first'). It says nothing about pagination, result limits, or account/permission scoping, which are the remaining behavioral questions for a list endpoint.

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

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

A single dense sentence that front-loads the resource, then ordering, then fields, then the read-only note. Nothing is redundant, though the trailing field list makes it slightly list-like rather than prose.

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

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

Because there is no output schema, the description's field enumeration does real work and covers return values adequately. However, it leaves out pagination behavior, result caps, and how the nested project/scan relationship is shaped, which matter for an unpaginated-looking list endpoint.

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

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

The tool takes zero parameters, so the schema baseline does not apply and 4 is the default. The description compensates usefully by enumerating the output fields in lieu of an output 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 names the resource precisely — 'the website projects of this account with their scans' — and enumerates the returned fields (id, site, status, pages analysed, bytes saved), so an agent knows exactly what it will get back. It is distinguishable from the singular get_website_scan and from list_website_pages/list_website_assets by the project+scans framing, though the distinction is implicit rather than stated.

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

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

There is no explicit guidance on when to choose this over get_website_scan (single scan detail) or list_website_pages/list_website_assets. The 'newest first' overview framing hints at a listing use case, but no condition or exclusion is 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?

With no annotations, the description carries the full behavioral burden and does so: it discloses plan-based rate/scale limits (5 pages/100 images free, 50/500 Pro), the fact that large sites return a job_id instead of a result, and that the tool returns files rather than mutating the site. Return payload fields (zip_url, replacements, per-image sizes/download URLs) are spelled out.

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 primary action and scope, then progressively adds output format, application workflow, and limits. Dense and generally earning its length, though the opening sentence is a long run-on and the deployment recipe could be trimmed.

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

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

No output schema exists, so the description must describe return values — and it does, naming the report contents, zip_url, and replacements mapping. Combined with the async job_id path and plan limits, an agent has everything needed to call and handle this 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 100%, so the baseline is 3; the description adds real context by quantifying the plan caps that determine the default max_pages value. It says nothing about the quality parameter beyond what the schema documents, so it 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?

States a specific verb chain (crawl → discover images → convert to WebP) and the exact resource (all images on a public site), with the output artifact named. It is clearly distinguishable from siblings such as convert_image (single file) and list_website_assets (listing only).

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 use case concretely (start at one page, follow same-host links) and gives the downstream workflow for applying results to a codebase, plus the async escape hatch via get_website_report. It lacks explicit 'when not to use' or named alternatives, so it stops 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?

With no annotations, the description carries the behavioral burden and does well: it explains what the background becomes in each case (transparent PNG/WebP, solid hex colour, blurred original scene) and discloses the return contract, a download URL valid for one hour. It omits permissions, cost/rate limits, and what happens if neither image input is supplied.

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 doing distinct work: what it does, what the output is, how to pick the edge modes, and what comes back. The primary purpose is front-loaded before any option detail.

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 tool with no annotations and no output schema, the description covers purpose, key modes, and the return value, and the schema fills the remaining parameter detail. The one gap is that it never states the image input requirement (exactly one of `image_url` or `image_base64`), which the agent must read from the schema.

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

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

Schema coverage is 100%, so baseline is 3, but the description earns above it by explaining the semantics of `background` values as behaviors (transparency, solid fill, scene blur) rather than just restating the pattern, and by characterizing `refine` and `graphic` by use case. `format`, `shadow`, and the two input fields add nothing beyond the schema.

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

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

"Cut the subject out of a photo" gives a specific verb and resource that no sibling (compress_image, convert_image, upscale_image) shares. An agent can immediately tell this is the background-removal tool rather than a generic image transform.

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 states clear conditions for the mode options – `refine` for hair/fur edges, `graphic` for logos or text on a surface ("not for photos") – which is real selection guidance. It does not name alternative tools or say when not to use this tool (e.g. when a plain conversion suffices), so it stops short of full when/when-not coverage.

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

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

With no annotations, the description carries the full burden and does well: it discloses the Pro-plan requirement, that dry_run computes sizes without processing, and that results come back as a one-hour download URL plus a per-step report. It does not cover failure/partial-failure behavior or any cost/rate-limit implications.

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, leading with the core purpose before schema detail. The pipeline/ops enumeration is necessarily long, though the parenthetical nesting makes it slightly harder to scan than a bulleted form would.

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 7-param tool with a nested object and no output schema, the description covers the return value and the two alternative input modes (pipeline vs preset). Minor gaps remain on how version/name interact and on step-failure handling.

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?

Far exceeds the 71% schema coverage by documenting the nested pipeline shape (steps with op/params/when), enumerating all ops, listing the allowed 'when' conditions, and naming the available presets and templates. It also clarifies that dry_run previews rather than processes.

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 ('run a multi-step workflow on an image in one call') and immediately supplies concrete op examples. It is clearly differentiated from single-op siblings like compress_image, convert_image, and remove_background, which this tool composes.

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 clear context for use ('one call' doing background removal, resize, convert, compress), a Pro-plan prerequisite, and a dry_run mode for previewing. It never explicitly says to prefer this over chaining the individual sibling tools, so the alternative routing is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does real work: Chromium rendering, no script execution, public-address-only reachability, and a download URL valid for one hour. Missing are failure behaviors (timeouts, unreachable hosts) and any rate-limit or cost note, keeping it at 4 rather than 5.

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

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

Three dense sentences, front-loaded with the core action, then behavior, then the return contract. Every sentence adds information an 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 7-parameter tool with no annotations and no output schema, the description covers the render mode, address restriction, and the return value's lifetime and form, which is what an agent needs to call it correctly. Error handling and rate limits remain unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds interpretation: `scale` 2 yields a sharper picture and the choice is between first screen and whole page. That maps the knobs to intent rather than merely restating field names, lifting it above baseline.

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

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

States a specific verb and resource — 'Take a picture of the web page at a public http(s) address' — with formats and viewport scope, which distinguishes it from siblings like html_to_image (renders supplied HTML) and get_website_report (produces a report). It stops short of naming the sibling it should not be confused with, so a 4 rather than 5.

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

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

Usage constraints are clear: only public http(s) addresses are reachable, and the page is drawn without running its scripts, which tells the agent when this tool will not give the expected result. No explicit alternative tool is named for cases like authenticated pages or JS-rendered content.

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

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

With no annotations, the description should carry the behavioral load, and it does disclose input-size limits, that scale 4 runs the model twice and is slower, and that the returned download URL expires after one hour. It omits error behavior and any cost/quota implications, keeping it 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?

It is front-loaded with the core action and mechanism, then limits and return behavior; the parenthetical '(2.25 on Pro)' and 'runs the model twice' are slightly compressed but every sentence carries information.

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

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

There is no output schema, so the description correctly explains the return value (one-hour download URL), and it covers size limits and scale trade-offs; the main gap is what happens on oversized inputs or failures.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning by tying `scale` to Pro-only status, a 1MP input cap, and extra latency, beyond the schema's terse '2 (default) or 4 (Pro)'.

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?

It states a specific verb and resource ('Double an image's width and height') plus the mechanism (super-resolution model reconstructing edges/texture), which clearly separates it from compress_image or convert_image even 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?

It gives useful preconditions (input up to ~1MP, 2.25 on Pro; scale 4 requires Pro and is slower) but never says when to prefer this over alternatives like convert_image or run_pipeline, so the usage decision is only implied.

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