GO AI Tools

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

No annotations are present, but the description carries the burden well: it discloses the use of Apple's public iTunes Lookup API, the hard 30-storefront cap, sequential one-at-a-time lookups, and the roughly ten-second duration. It does not cover failure modes or rate-limit edge cases, but the most important behavioral constraints are clearly stated.

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?

Every sentence earns its place: purpose, inputs, output fields, API source, cap rationale, and pacing are all included without redundancy. The most important information is front-loaded, and the description is appropriately sized for the tool's complexity.

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, but the description names the output dimensions (availability, localized title, price, rating) and fully explains input, default behavior, cap, and timing. For a lookup tool, this is sufficient for an agent to select and invoke it correctly; missing error-case detail 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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description reinforces that appIdOrUrl can be an id or URL and that storefronts defaults to 30 major markets, but it adds little beyond the schema beyond context like the 173 total storefronts and deduplication behavior.

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: 'Looks up one app... in up to 30 App Store storefronts' and lists the reported fields. It clearly distinguishes this from the sibling appstore_search by framing it as a targeted lookup across markets rather than a search.

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 context is provided: use this when you have a numeric App Store id or apps.apple.com URL and want per-market availability, title, price, and rating. The description also gives practical guidance to call again with a different storefronts list to cover more markets, though it does not explicitly name appstore_search as an alternative or state when to prefer that 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?

With no annotations provided, the description carries the full behavioral burden and succeeds: it discloses the public API source, the 200-result maximum, the meaning of exactly 200 results (truncation likely), and the ordering caveat that relevance does not match App Store ranking. This is rich, non-obvious behavioral detail.

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 no filler: the first states the core action and output, the second covers result limits, and the third covers the ranking caveat. The structure is progressively more specific and each 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?

There is no output schema, so the description must explain return shape and caveats; it lists output fields, result cap, truncation signal, and relevance ordering. For a simple three-parameter search tool with full schema coverage, an agent has enough to select and invoke 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?

Schema description coverage is 100%, so the baseline applies. The description mentions the term and country concept, but the schema already documents all three parameters thoroughly, including verbatim query sending, entity enum values, and country defaults. The description adds no substantive parameter meaning beyond the structured 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 opens with a specific verb and resource: 'Searches one Apple App Store country storefront by term' and names the underlying iTunes Search API. It lists concrete return fields (title, seller, price, rating, direct link), and by stressing 'one ... storefront' it implicitly distinguishes itself from the market-comparison 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?

Clear operational context is present: this searches a single storefront via the public API and returns up to 200 results. It also gives a when-not signal ('cannot be used to track keyword rank'), but it does not name an alternative tool or explicitly say what to use for multi-storefront or ranking needs.

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 carries the full burden and does well: it discloses the median-filtered outlier rejection, 2-second session-reset logic, arithmetic-only nature, and the fact that it returns millisecond and Hz values. It could mention edge cases or exact output structure, but the main behavioral traits are transparent.

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 well-structured sentences that front-load the core purpose and then detail the returned outputs and use case. Every clause contributes useful information, and the length is justified by the tool's combined tempo-resolution and conversion behavior.

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

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

There is no output schema, so the description appropriately outlines the return values: straight/dotted/triplet delay and LFO-rate tables with ms and Hz units, plus bar-length and bars<->seconds conversions. Combined with the fully documented input schema, this is sufficiently actionable for an agent to call the tool 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 description coverage is 100%, and the schema already documents every parameter in detail, including exclusivity of bpm/tapTimesMs/tapIntervalsMs, defaults, limits, and custom time-signature handling. The description adds conceptual context about tap-tempo logic but no per-parameter semantics beyond the schema, so the baseline of 3 applies.

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

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

The description states a clear, specific verb and resource: it resolves a tempo and returns delay/LFO-rate tables plus bar-length conversions. It also distinguishes itself from GO AI's tap-tempo tool by noting it reuses the same tap-processing logic, so an agent can tell exactly what this tool 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?

The description gives concrete usage context: it is for setting delay/reverb/LFO times to a track's tempo and explicitly clarifies it is arithmetic-only, not a real audio engine. There are no direct sibling tools that compete with this calculator, so explicit exclusion criteria are not necessary.

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 present, the description carries full responsibility and does so thoroughly. It reveals the custom Reed-Solomon encoder, the 213-byte UTF-8 ceiling, clean failure that names byte counts, the fallback to includeQr:false, and the fact that storefront codes are not validated against real storefronts. These are exactly the non-obvious behaviors an agent needs to anticipate.

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 long but every sentence carries distinct information: core output, return values, QR implementation details, size limits and failure mode, and storefront validation caveat. It is front-loaded with the main purpose and then adds densely relevant edge-case context that would otherwise be invisible to the agent.

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 that there is no output schema, the description adequately defines the return contract: the assembled URL plus a params table, and image bytes when includeQr is true. It also covers the main failure mode and validation limitation, making the tool callable without dangerous assumptions.

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 baseline applies. The description adds useful contextual details such as shortening pt/ct to fit the QR byte limit and the unchecked storefront behavior, but individual parameter meanings are already thoroughly documented in the schema, so the description does not need to compensate.

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 opens with a concrete verb and resource: 'Builds a correct apps.apple.com URL for an app ID or a pasted App Store URL, in a chosen two-letter storefront.' It also clearly separates the optional QR rendering behavior and names the attribution parameters, making the tool's purpose unambiguous and distinct from siblings like appstore_search or appstore_compare_markets.

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 clear context for when this tool applies: whenever a correctly formed App Store campaign link (and optionally a QR code) is needed from an app ID or pasted URL. It does not explicitly name sibling alternatives or exclusion conditions, but the core scenario is unmistakable, and the QR/URL distinction is spelled out.

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 of behavioral disclosure. It does so thoroughly: it reveals the exact order of operations (tax removal before commission), explicitly states what is NOT done (commission is not applied to the sticker price), and enumerates the full return set including breakdown, effective share, comparisons, sanity check, and warnings. This is strong transparency for a stateless calculator.

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 two-sentence structure front-loads the core calculation and then lists the returns without filler; every clause earns its place. However, the second sentence is a dense enumeration of outputs, so while content is appropriate, the structure is somewhat heavy rather than crisp.

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 calculator with no output schema, the description covers the calculation method, all commission scenarios, output contents, and edge-case warnings for variable tax rates. Field-level defaults and enums are appropriately left to the schema, but nothing an agent needs to correctly understand and call this tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema. It explains that commission applies to the tax-exclusive remainder rather than the sticker price, clarifies the role of taxRatePercent and countryCode, and relates commissionScenario to the returned comparison. This materially improves an agent's ability to invoke the tool correctly.

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 ('Computes') and names the exact resource ('what a developer actually receives from an App Store sale'), with a precise calculation method. It doesn't explicitly distinguish itself from sibling tools by name, but the purpose is unmistakable and clearly unique among the listed 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?

The description clearly implies use when a developer needs the net revenue from an App Store sale and corrects a common naive approach, but it never explicitly says when to prefer this tool over alternatives or names sibling tools. There are no exclusion criteria or routing hints.

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 delivers: it discloses internal metric-to-inch conversion, clamping to 2-75%, whole-number rounding, the waist-exceeds-neck/hip impossible-input warning, and the out-of-fitted-range caution. This goes well beyond a typical calculator description.

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 dense sentences with no filler: the first front-loads the purpose and inputs, the second packs all behavioral quirks. Every clause adds technical information an agent needs to call the tool correctly.

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, no-annotation, no-output-schema calculator, this description is unusually complete: it names inputs, outputs, formula variant, unit handling, rounding/clamping, and both warning conditions. The only conditional nuance (hip required for female) is already documented in the input schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by explaining that Navy equations are fitted in inches and metric values are converted internally, and by clarifying which measurements feed BMI vs body fat. This enriches the schema's per-parameter 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?

The description uses specific verbs and resources: it computes BMI with a category label, Navy-method body fat, and lean body mass, naming the exact input measurements. This clearly distinguishes it from sibling calculators like calculate_tdee without needing to open 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 clear statement of what it computes and the note that it matches GO AI's body-fat tool page exactly provide strong context for when to invoke it. It gives no explicit when-not-to-use guidance 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 full behavioral burden, and it does well: it warns that formulas are population averages, states that real expenditure can vary by 200–300 kcal, and mentions the safety warning flag for aggressive deficit targets. It also discloses conditional formula selection based on body_fat_percent.

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 dense but purposeful sentences with no filler. The first sentence front-loads the main operation and outputs, and the second sentence adds essential caveats and safety behavior.

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

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

Given no output schema and 11 parameters, the description covers core behavior, output categories, and caveats, so an agent can understand what the tool does. However, it omits details about how units and height/weight fields interact and does not describe the return shape beyond mentioning the warning flag, leaving meaningful gaps for a complex calculator.

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 must compensate, but it only paraphrases sex, age, height, weight, activity level, and body fat. It does not explain the units parameter, the metric/imperial height and weight field pairs, or map the goal enums (lose_20, lose_15, gain_10) onto the cut/bulk language beyond loose labeling.

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 ('Calculate') and resource: BMR via multiple formulas, TDEE, goal-adjusted calorie target, and macro split. It clearly distinguishes itself from the sibling BMI/body-fat calculator by enumerating outputs that go beyond body composition.

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 when this tool is appropriate: whenever an estimated TDEE, calorie goal, or macro split is needed. However, it does not explicitly state when to prefer calculate_bmi_and_body_fat or another sibling, and it offers no exclusion criteria or alternative routing.

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

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

With no annotations at all, the description carries the full burden of behavioral disclosure, and it handles this well. It explicitly reveals that APCA is reported for information only and not used for conformance, and that WCAG results are graded separately for normal text, large text, and UI components. The only minor gap is no mention of behavior on invalid or non-hex input, but the schema partially covers format expectations.

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 sentences with zero filler. The first sentence fronts the core computation and the output categories; the second clarifies the APCA/WCAG relationship and which metric governs conformance. Every clause earns its place, and the structure is immediately scannable.

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 simple two-parameter calculator with no output schema, the description adequately conveys what is computed, how results are categorized (AA/AAA statuses per text size/component type), and the informational role of APCA. It doesn't spell out the exact return JSON shape, but an agent can infer the result semantics well enough. A brief pointer to find_nearest_passing_color for correction workflows would improve routing, but this is a minor 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 description coverage is 100%, so the parameters are already fully documented with format and examples. The description adds minimal extra meaning beyond labeling foreground as 'text' and noting hex colors, which is a slight reinforcement but not substantial. It does not introduce any semantic detail absent from the schema, so the 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?

The description states a specific verb ('Computes') and resource ('WCAG 2.x contrast ratio'), names the exact inputs (foreground and background hex colours), and details the output categories (AA/AAA for normal text, large text, and UI components). This clearly distinguishes it from siblings like find_nearest_passing_color and oklch_convert, which serve different color-related purposes.

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 tool's purpose makes its use case self-evident: check WCAG contrast between two hex colors. However, it never explicitly names sibling alternatives or states when NOT to use this tool (e.g., when you need to adjust a color to pass, find_nearest_passing_color would be appropriate). The APCA comment explains metric choice but not tool selection, so usage guidance remains implied rather than explicit.

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 carries the full burden, and it is exceptionally transparent: it discloses BOM sniffing for UTF-16 decoding, case- and trailing-punctuation-insensitive duplicate detection, that extra keys are reported but not counted toward the issue total, that parse failures include line numbers, and that placeholder/plural consistency is out of scope. No behavioral trait is hidden.

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 one dense paragraph, but every clause earns its place; it front-loads the primary action, details the comparison checks, and ends with clear non-goals. It is longer than a minimal description, but the tool's behavior is genuinely complex. Some bullet-point structure would help skimming, but there is no fluff or redundancy.

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 input encoding, comparison semantics, edge cases (BOM, duplicates), and limitations, leaving the agent well-equipped to call the tool correctly. The only notable gap is that the return/report format is not described, and there is no output schema to fill that void. Still, the scope is clear enough that the agent can invoke the tool and interpret the findings.

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 both parameters well. The description adds critical semantics by specifying that content must be base64-encoded raw bytes (not decoded text) and that the file name appears in the report and participates in base-file selection. It does not add beyond the schema for baseFile, but the raw-bytes clarification is essential.

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 opens with a specific verb and resource ('Compares two or more iOS Localizable.strings files ... against a base file') and then enumerates a precise list of findings: missing keys, extra keys, byte-identical values, duplicate values, and parse failures. It also explicitly states non-goals (.xcstrings, plural rules, placeholders), making its purpose unmistakable and distinct from any conceivable 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?

The description clearly tells the agent how to invoke the tool ('sent as base64-encoded raw file bytes, not text') and when not to use it ('Does not support the newer .xcstrings JSON catalogue format'). It stops short of naming an explicit alternative tool or an explicit 'use this when...' condition, but the strong scope boundaries make that unnecessary.

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 excels: it discloses byte-sniffing (never trusting extensions), pass-through behavior for already-converted files, automatic orientation application, metadata stripping, per-file error handling, and zip bundling logic. It even explains the report fields. This is far more transparent than typical tool descriptions.

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 long but every sentence carries unique constraints or behavioral details; information density is high. It is logically organized: purpose first, then input rules, processing behavior, output format, and error semantics. However, it is one massive block of text with no paragraph breaks, making parsing harder than necessary.

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 there is no output schema, the description thoroughly explains return formats: individual inline/download-link results, optional converted.zip, failure statuses, and a JSON report with status/dimensions/sizes. It covers mixed inputs, orientation, and error handling. The only gap is the inconsistent size limit mention, which slightly undermines otherwise comprehensive coverage.

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 useful parameter semantics not in the schema: format is ignored for already-JPEG/PNG inputs, quality only applies to JPEG, and bundleAsZip requires more than one produced output. However, it introduces a potential contradiction by stating 'each up to ~30MB decoded' while the schema's dataBase64 description caps decoded input at 4,000,000 bytes. This ambiguity could mislead an agent about file size limits.

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 opens with a specific verb-resource pair: 'Converts iPhone HEIC/HEIF photos to JPEG or PNG'. This clearly distinguishes it from siblings like image_compress or resize_images, which handle different transformations. The technical pipeline mention (libheif + sharp) adds specificity without obscuring the purpose.

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 clear context for when to use the tool: when you have HEIC/HEIF photos needing conversion to JPEG/PNG, and it also accepts already-JPEG/PNG files to pass through. It does not explicitly name alternatives or say 'when not to use', but the highly specific input/output scope makes the usage context unambiguous.

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 carries the full burden, and it delivers: it discloses hard resource limits, up-front rejection behavior, the 12-megapixel pixel budget, actualFps rounding, palette sharing/banding, dithering side effects, bounce doubling frame count, audio dropping, and the frame-sampling approximation vs the original browser tool. This goes far beyond the schema and gives an agent accurate expectations for edge cases.

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 long, but the tool is genuinely complex with 11 parameters, no annotations, and no output schema. The hard limits are prominently front-loaded with a direct 'Read these before calling,' and later sections are organized by format and parameter concerns. Every major sentence adds operational or behavioral value rather than 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?

Given the tool's complexity and the absence of both annotations and an output schema, the description is exceptionally complete. It covers input size limits, trim constraints, output width rules, frame budget math, palette and audio behavior, return payload contents, and error semantics, leaving an agent with enough information to select parameters and interpret results 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?

Although schema coverage is 100%, the description adds substantial cross-parameter meaning that the schema alone cannot convey: the width x height x frames cap, how bounce doubles frame count, how speed below 1 costs more of the pixel budget, how dithering affects flat graphics, and how actualFps will differ from requested fps. It effectively teaches the agent how the parameters interact.

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 opens with a specific verb and resource: trims a SHORT video clip and converts it to an animated GIF, MP4, or WebM. It also clearly distinguishes itself from the browser-based Live Photo-to-GIF tool by noting the server-side addition of MP4/WebM output, so an agent can tell this from other conversion tools.

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 explicit usage preconditions: send a pre-trimmed clip, not a whole recording, keep the decoded video at most 4 MB, and keep the trim span between 0.25s and 10s. It also advises when not to retry after rejection and explains format-specific behavior such as audio always being dropped, making the when-to-use and when-not-to-use guidance unusually concrete.

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 carries the full burden and excels: it discloses the exact status return values ('sameViewports', 'flat', 'inverted', 'ok') and explains the meaning of each edge case, the 4-decimal rounding, the GO AI math equivalence, the rootFontSizePx=0 fallback, and both optional behaviors (preview evaluation and type-scale generation). Nothing about the tool's behavior is left hidden.

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 long but dense with no filler — every clause earns its place. It is front-loaded with the core purpose, then systematically covers return statuses, optional behaviors, and the website divergence. For a tool with 7 parameters, a nested object, and four status branches, this length is proportionate and well-organized.

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?

Even without an output schema, the description fully explains return semantics (the clamp() declaration in rem, the status strings and their meanings, computed pixel sizes for previews, and the type-scale output). Combined with 100% schema coverage on parameters, an agent has everything needed to select and correctly invoke 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 meaningful value beyond the schema: it explains that typeScale ratio is not limited to the website's presets (any positive value works), describes how preview viewports get 'returned as computed pixel sizes', and ties parameter combinations to distinct status outcomes (e.g., equal viewports produce no line). This is more than the schema alone provides.

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

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

States a specific verb+resource: 'Generates a CSS clamp() declaration (in rem) that linearly interpolates a size between a value at a small viewport width and a value at a large one.' This is unambiguous and clearly differentiates the tool from the sibling calculators (BMI, TDEE, contrast, oklch, etc.), which all occupy distinct domains.

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 provides clear context about when the tool applies — generating fluid CSS clamp() values with optional type-scale generation — and even contrasts itself with GO AI's website ('unlike the website's five-option dropdown, any positive ratio is accepted here'). It doesn't explicitly name sibling tools to use instead, but the sibling set is homogeneous (all different calculators), making cross-tool confusion unlikely.

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 disclosure burden and does so thoroughly: it explains the estimation algorithm (chars/4 and words/0.75), accuracy bands (±10–15% English prose, ±15–25% non-Latin), known biases (code and heavy punctuation tokenize denser), and cost behavior (only when prices are supplied, no stale default assumed).

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 most important caveat ('Heuristic estimate... NOT a real per-model BPE tokenizer') followed by accuracy detail, additional features, and a final billing caveat. Every sentence earns its place 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?

despite no output schema and no annotations, the description names what the tool reports (token count, context fit, optional USD cost), specifies defaults, and explains accuracy and cost behavior. Combined with a fully described input schema, this is enough for an agent to select and invoke the tool 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 100% and each parameter already has a detailed description, so the baseline is 3. The description mostly restates what the schema already says, such as default context windows and per-million-token pricing, though it does add useful high-level context fit and algorithm behavior.

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 clear, specific purpose: a heuristic token-count estimate plus context-window fit and optional cost estimation. It is unambiguous about the resource and action, but it does not explicitly differentiate itself from sibling tools such as recommend_ai_model, so it misses the 'distinguishes from siblings' bar for a 5.

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

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

Explicitly frames the tool as a heuristic and warns 'NOT a real per-model BPE tokenizer,' then closes with 'Use a provider's own tokenizer for exact billing figures.' This gives a clear when-to-use / when-not-to-use boundary and names an alternative for exactness.

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 present, the description carries the full burden of behavioral disclosure, and it delivers: it states what kind of estimate is produced, that hemisphere is handled correctly, that direct-west-sun scorch risk is flagged, and that reasoning plus a suitable-plant shortlist are returned. It also explicitly warns about the tool's limitations, which is valuable transparency.

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

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

The description is dense but well-structured: it front-loads the purpose and output vocabulary, then adds exclusions and behavior in the second sentence. There is no filler, no repetition of schema content, and every sentence contributes 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?

Despite having no output schema and no annotations, the description tells an agent what inputs affect the result, what category vocabulary will be produced, how the estimate behaves across hemispheres, and what the return includes (reasoning plus plant recommendations). This is enough context to call the tool correctly and interpret its result.

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

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

All four parameters are already well documented in the input schema with enums and explanatory descriptions, so the schema carries the semantic weight. The description only recaps the inputs at a high level ('window's hemisphere, compass aspect, what obstructs it, and how far back') without adding per-parameter detail beyond what the schema already provides.

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

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

The description opens with a specific verb ('Estimates') and a concrete resource ('indoor light level a window gives a plant'), then names the exact output vocabulary an agent should expect: Direct sun / Bright indirect / Medium light / Low light / Too dark. It also disambiguates itself from a physical light meter or sun-position model, making its purpose unmistakable.

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 clear boundary conditions: it is a heuristic scoring table, not a physical light-meter reading or a per-location sun-position model, which tells an agent when not to rely on it. It does not explicitly compare against a sibling tool, but the context makes the intended use case—quick houseplant light-level categorization—clear.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it handles it well. It discloses that only lightness is moved, hue and saturation stay fixed, it takes the smallest step that clears the target, it defaults to 4.5:1, and it reports found:false when no lightness change can succeed. This is far beyond what the schema alone provides.

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 no filler. The core behavior is front-loaded, then thresholds, then failure behavior. Every clause earns its place, including the practical consequence of an impossible pair.

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 relatively simple tool with no annotations and no output schema, the description covers algorithm, thresholds, adjustable side, and the impossible-case result. The only gap is that it never explicitly states the success return shape (e.g., whether found:true comes with the adjusted hex), which would be useful given the absence of an output schema.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds genuine value on top by explaining adjust as 'move one side while the other stays fixed' and by expanding the target enum into concrete ratios and custom numeric support. It does not redundantly restate hex format details, which the schema already covers.

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 ('moves'), a clear resource ('foreground/background hex pair'), and a precise constraint (hue and saturation held fixed). It immediately differentiates itself from contrast-checking tools like check_contrast by presenting itself as a hue-preserving fixer rather than a checker.

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 clearly frames when to use it: to fix a failing contrast pair while preserving brand hue, and it explicitly notes the default threshold and available named thresholds. It also tells the agent when the tool is not the answer ('that pair needs a different hue, not a different lightness'). It stops short of naming sibling alternatives explicitly, hence not 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?

No annotations are provided, so the description carries the full burden, and it delivers thoroughly. It discloses that transparency is flattened because Apple rejects alpha, non-square images are letterboxed rather than stretched, scaling is done by repeated halving, the dark variant is a mechanical 82% black overlay that needs review, the tinted variant is a Rec.709 luminance map, and the result is always returned as a resource_link.

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 dense and front-loaded with the core function, and every sentence carries useful signal with no obvious filler. However, it is one long unbroken paragraph with many nested clauses; bullet points or short segmented paragraphs would make it easier for an agent to scan and parse.

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 tool is complex, with multi-platform outputs, appearance variants, color handling, and resampling details, and there is no output schema. The description compensates by reporting the JSON result fields, non-fatal warnings for non-square/undersized sources, and the guaranteed resource_link return, so an agent has enough to invoke and consume the result 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 100%, so the baseline is 3, and the description adds meaningful behavioral context beyond the schema. It connects variants to which AppIcon files appear in Contents.json, backgroundColor to flattening and padding, and imageBase64 to the ideal 1024px source and non-square handling.

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 resource: it turns one source image into a ZIP containing an iOS AppIcon set, Android mipmap set, and a flat sizes folder. The title scopes it to iOS + Android, and the output details clearly distinguish it from sibling tools like generate_favicon_set.

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 makes its context explicit by listing the exact artifacts produced for iOS and Android, so an agent knows when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, such as directing favicon-only work to generate_favicon_set, 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 provided, the description carries the full burden of behavioral disclosure, and it delivers extensively: it discloses that the ICO is a real multi-resolution container not a renamed PNG, that apple-touch-icon is flattened because 'iOS paints transparency black', that the maskable padding approximates the source tool's square padding rather than the true inscribed-circle safe area, that non-square sources are centred on transparent canvas, that the JSON result includes manifest text, HTML snippet, per-file table, and an upscaling warning, and that it 'Fails with a clear message rather than throwing'. This is exceptional transparency. It doesn't explicitly state the operation is non-destructive, but no destructive hint could reasonably apply to a generation 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 information-dense but long (approximately 180 words) and runs as a single paragraph. Every sentence adds real information — no filler — but the wall of text makes it harder for an agent to quickly extract key facts. The output format explanation (files returned individually, JSON result structure) could be tightened or moved later given the description's length.

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 having no output schema, the description explicitly enumerates the JSON result contents (manifest text, HTML snippet, per-file table, warning), making the return contract clear. With 6 parameters all fully documented in the schema plus deep behavioral notes (iOS flattening, maskable safe-zone semantics, ICO container detail, decode failure behaviour), nothing an agent needs to call this correctly or set expectations is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial meaning beyond the schema: it explains that `backgroundColor` is also the flatten colour for apple-touch-icon and the padding colour for maskable icons, that `maskablePadding` sets 'purpose' to 'maskable' vs 'any', that `themeColor` is 'purely metadata -- never painted onto any icon', and that `shortName` falls back to `siteName`. This transforms parameter semantics from names into actionable decisions.

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 a clear verb ('Turns') and resource ('one source image into a complete favicon set') and enumerates concrete outputs (favicon.ico with a real multi-resolution ICO container, PNG files, site.webmanifest, HTML snippet). It distinguishes itself from sibling `generate_app_icon_set` by referencing 'Ported from GO AI's browser-based favicon tool' and being specific to web favicon assets rather than app icons.

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 when to use by naming the exact output artifacts (web-app manifest, apple-touch-icon, favicon.ico) and states a specific constraint: files are returned individually rather than zipped because 'each name matters (favicon.ico and site.webmanifest belong at the site root)'. It also explains the alternative behavior via `maskablePadding` and the fallback semantics. It doesn't explicitly say 'use generate_app_icon_set for app store icons' though — that exclusion is implied at best.

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 handles it well: it discloses that the tool is a fixed, deterministic lookup table, identifies the vendor-documentation date as the mapping reference, and explicitly states limitations around SDK changes and app configuration. This is far beyond a minimal description and accurately sets expectations.

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 information-dense but every sentence earns its place: it front-loads the output structure, then adds necessary caveats about determinism, non-legal status, and documentation drift. No filler or repetition of schema details is present.

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

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

For a single-parameter deterministic lookup tool with full schema coverage and no output schema, the description completely explains what the agent can expect: grouped privacy data types, reasons, tracking applicability, and the vendor-documentation date. The caveats about verification against SDK documentation make the tool's practical usage and limitations fully clear.

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 schema already fully documents the single `items` parameter and its enum values. The description adds context about treating those items as 'SDKs/features present' and mentions chosen items causing reasons, but it does not need to add parameter-level detail beyond what the schema already provides.

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

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

The description states a specific verb and resource: given SDKs/features, it returns App Store Connect privacy data types grouped by Apple's categories, with reasons and tracking applicability. This clearly distinguishes it from the unrelated sibling tools and makes the tool's function immediately obvious.

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 explicitly frames when to use the tool (when you have a list of SDKs/features and need a starting privacy checklist) and when not to rely on it: it is not a code scanner and not compliance advice. It also warns that results must be verified against current SDK documentation, giving clear usage boundaries.

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 carries the full burden of behavioral disclosure. It transparently explains that images are never enlarged, that EXIF/ICC metadata is always stripped, the meaning of positive/negative percent size change, the input size cap, and the output stats object. This is exemplary for a tool without annotations.

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

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

The description is three dense sentences, front-loaded with the core operation. Every sentence carries distinct value: downscale/re-encode behavior, input format and constraints, and output/metadata details. There is no filler or redundancy.

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 four parameters, no annotations, and no output schema, the description is remarkably complete. It covers input format, input size limits, output shape, edge cases (re-encode may be larger), metadata stripping, and format selection tradeoffs. An agent has everything needed to call this tool 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 description coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: it explains the input is 'base64-encoded image bytes' in any decoder-supported format, clarifies the output includes a stats object with size-change semantics, and gives practical format guidance (e.g., 'jpeg is the safest choice for old viewers or print'). It does not merely repeat schema fields.

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 specific verbs and resources: 'Downscales an image to fit within a maximum dimension' and 're-encodes it as JPEG, WebP or AVIF at a given quality'. It clearly states the operation and scope, making it easy to distinguish from sibling tools like resize_images or strip_image_metadata even without explicit naming.

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 indirectly implies when to use the tool through details like 'matching GO AI's browser compressor tool' and format tradeoffs, but it does not explicitly state when to use this tool over alternatives such as resize_images or image_compression_curve. There are no exclusions or direct sibling comparisons.

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 so thoroughly: it discloses analysis-only behavior, no byte return, repeated 14x encoding, downscaling without enlargement, the 2000px cap rationale, accepted formats, and the per-level reported fields. Minor ambiguity between '14 quality levels' and the '(5, 10, ..., through 100)' example prevents a perfect score.

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 critical 'analysis-only (no image bytes returned)' caveat and is dense with useful detail. It is long, but most sentences justify their place; the slightly confusing parenthetical about quality levels and the comparison with image_compress add minor noise.

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?

Even without an output schema, the description explains the input encoding, accepted formats, resizing behavior, output fields per level, and the alternative tool for actual bytes. An agent has enough information to invoke the tool correctly and interpret its 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 100%, so the baseline is 3. The description adds meaningful context beyond the schema, such as why maxDimension is capped at 2000 vs image_compress's 4000, that defaults match the source, and that input must be base64 image bytes. It does not merely repeat schema 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?

The description names a specific operation—re-encoding an image across fixed quality levels and reporting byte size and percent change—and immediately clarifies that it is analysis-only with no image bytes returned. It clearly distinguishes itself from sibling tool image_compress.

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 explicitly states when to use this tool: 'Use this to find that knee... or image_compress to actually get the compressed bytes at one chosen quality.' It also explains the maxDimension tradeoff relative to image_compress, leaving no ambiguity about selection.

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 carries the full burden of behavioral disclosure. It explains that the tool byte-searches the CMS/PKCS7 container, never validates or decodes the signature, does not report on certificates beyond count, classifies profiles using specific fields, and returns a structured { ok: false, error, message } result instead of throwing. This is exemplary transparency.

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

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

The description is dense and front-loaded with the core action, followed by methodology, limitations, and output details. While long, every clause earns its place because there is no output schema or annotations to supplement it. Slight redundancy with the schema's base64 wording keeps it from a 5.

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 tool's complexity and the absence of annotations and output schema, the description covers all essential aspects: input encoding, file types, parsing approach, limitations, reported fields, and error behavior. An agent has enough context to invoke the tool correctly and interpret its 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?

The schema description already fully documents the single parameter 'base64', including the accepted file types. The tool description adds little beyond what the schema provides, which meets the baseline for high schema coverage but does not elevate it further.

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 a specific verb ('Reads'), the resource (iOS/macOS provisioning profile), and the accepted input formats. It also describes the internal mechanism and differentiates this from broader cryptographic validation tasks. No sibling tool overlaps with this functionality.

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 makes the intended use obvious by explaining exactly what inputs are accepted and what information is extracted. It does not explicitly name when not to use the tool, but there are no closely related sibling tools, so the context is clear enough for an agent to select it appropriately.

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 carries the full behavioral burden and handles it well. It discloses the return value shape (canonical oklch() text plus sRGB-gamut-mapped hex/rgb()/hsl() equivalents), explains the CSS Color 4 gamut-mapping algorithm rather than channel-clipping, and explicitly states the sRGB-only limitation with no P3 or Rec2020 support.

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 dense, front-loaded sentences. The first establishes the core function and input modes, and the second covers output format and algorithm behavior. Every clause adds information; there is no filler or repetition of the title.

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

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

The description is unusually complete for a tool with no output schema and no annotations: it explains input modes, output structure, gamut mapping, and limitations. The main gaps are unspecified behavior when neither input mode is supplied (no required parameters), and no mention of how alpha values are handled for rgba()/hsla() inputs.

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 meaningful interaction semantics beyond the schema: callers must supply either `color` or l/c/h, and `color` takes precedence when both are present. It also summarizes what each parameter group represents, reinforcing the schema without contradicting it.

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

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

The description leads with a specific verb and resource: 'Converts a color to and from OKLCH.' It enumerates the accepted input formats (hex, rgb()/rgba(), hsl()/hsla(), oklch()) and the explicit l/c/h alternative, which clearly distinguishes this conversion tool from siblings like oklch_ramp or check_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?

The description clearly frames when to use the tool: any time a color needs converting to or from OKLCH. It also gives concrete guidance on input selection, noting that callers should supply either `color` or l/c/h, and that `color` takes precedence when both are supplied. It does not explicitly name alternatives or exclusions, 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 provided, the description carries the full behavioral burden. It discloses the exact transformation approach (sweep one channel, hold two fixed), gamut-mapping to sRGB using the CSS Color 4 chroma-reduction algorithm, and the output format including hex previews and a ready-to-paste CSS block. It could add caveats about out-of-gamut or extreme inputs, but the core behavior is well covered.

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 information-dense but well organized: it front-loads the main purpose, explains the method and rationale, then describes the output. Every clause earns its place, and there is no redundant repetition of schema details.

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 tool has 7 parameters and no output schema, the description is remarkably complete. It explains inputs, the sweep behavior, the color-mapping algorithm, and the exact deliverable (hex previews plus a CSS custom-property block). An agent has enough context to invoke it correctly and interpret the result.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds useful context by tying the color/l/c/h inputs to oklch_convert and clarifying what 'mode' does when sweeping, but it does not substantially expand on parameter meanings beyond the schema.

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

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

States a specific verb ('Builds'), a precise resource ('OKLCH swatch ramp / CSS custom-property block'), and the core operation (sweeping one channel while holding others fixed). It clearly differentiates from the sibling oklch_convert by focusing on multi-step ramp generation rather than single-color conversion.

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 makes the use case clear: build a perceptually even ramp by sweeping hue, lightness, or chroma. It references oklch_convert for the shared input format and explains why OKLCH is preferred over HSL for this purpose, though it does not explicitly state when to choose this tool over a sibling.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, and it succeeds. It reveals the algorithm's origin (fixed drought-tolerance table, exact multiplier compatibility), the output format details (RFC 5545, 75-octet line folding, recurring all-day events), and an important caveat that the intervals are heuristic rather than measurements. This is exemplary transparency for a tool with no structured annotation support.

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 purpose and outputs, then moves to compatibility and caveats. It is dense but each sentence earns its place; the middle sentence overlaps somewhat with schema parameter descriptions, so it is not maximally concise, but the structure is logical and scannable.

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 six parameters and no output schema, the description adequately outlines both deliverables (schedule breakdown + full .ics text), the event format (recurring all-day reminders), and the RFC 5545 standard. It leaves the internal structure of the 'schedule breakdown' unspecified, but an agent has enough information to call the tool and know what to expect.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some flavor by mentioning terracotta/glazed/low-light/winter multipliers and the northern-hemisphere default, but these details already appear in the parameter descriptions. It doesn't introduce new parameter-level semantics beyond what the schema already provides.

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

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

The description opens with a specific verb ('Builds') and names the exact resource ('soil-check interval per houseplant'), then lists the two concrete outputs: a schedule breakdown and a downloadable RFC 5545 .ics calendar file. It also draws a clear behavioral distinction by noting reminders are deliberately 'check the soil' rather than 'water', making the tool's purpose unmistakable even among unrelated 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?

The description provides strong contextual guidance: it establishes fidelity to GO AI's browser tool, explains the northern-hemisphere season default, and implies the tool is the right choice for generating houseplant watering-check calendars. It doesn't explicitly list alternatives or exclusions, but since no sibling tool overlaps in this domain, the context is sufficient for an agent to select it correctly.

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 carries the full burden of behavioral disclosure and does so thoroughly. It reveals the day-by-day Mifflin-St Jeor recalculation, the widening gap versus the naive projection, the 1500/1200 kcal refusal floor, the plateau asymptote behavior, and the adult-only/weight-loss-only constraints. This is far more than a typical tool description.

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 dense but every sentence earns its place: purpose, algorithmic contrast, refusal/plateau conditions, and input constraints. It is front-loaded with the core purpose and does not include filler or redundant 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?

For a tool with no output schema, the description does a strong job of explaining key outputs: a projected date, the naive straight-line comparison, and a plateau outcome. It also references the weekly weight series via the includeChartSeries parameter. The main gap is that it never explicitly states the return shape, field names, or date format, so an agent must infer some output details.

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 baseline of 3 applies. The description adds useful algorithmic context about how the intake interacts with changing maintenance calories, but it does not meaningfully explain individual parameters beyond the schema. There is also a mild ambiguity between 'fixed daily calorie intake' and the dailyDeficitKcal parameter's schema wording, which is left unresolved.

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 opens with a specific verb and resource: 'Projects the calendar date a goal body weight is reached under a fixed daily calorie intake.' It then distinguishes itself from a naive straight-line calculator and states the dynamic-model behavior, making the tool's purpose unmistakable and differentiated from sibling health calculators.

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 makes usage context clear: a weight-loss goal-date projection under a calorie plan, with explicit constraints (adult-only, goalWeight must be less than currentWeight) and clear failure modes (calorie floor, plateau). It does not explicitly name sibling alternatives like calculate_tdee or calculate_bmi_and_body_fat, but the purpose is specific enough that an agent can infer when to select 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?

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses that baking powder, baking soda, and yeast use USDA teaspoon weights rather than proportional cup weights; that variants are supported; and that a comparison with a generic water-density converter is reported except when the requested unit is already grams or ounces. It even explains the cupSizeMl/density derivation caveat.

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 long but information-dense, front-loaded with the core purpose and followed by necessary caveats and special cases. It could be lightly restructured with sentence breaks for readability, but every clause adds useful behavior not available in the 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?

The description thoroughly covers ingredient semantics, variants, unit behavior, and the comparison output. There is no output schema, and while the description explains the comparison report, it does not explicitly state the shape of the returned conversion result. This is a minor gap for an otherwise very complete definition.

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 baseline is 3. The description adds meaningful context beyond the schema: why variants matter, the special teaspoon-weight behavior for certain ingredients, and the caveat that cupSizeMl does not affect the reported density. This goes beyond simple parameter labels.

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 opens with a specific verb and resource: 'Converts an amount of one ingredient between cup, tablespoon, teaspoon, millilitre, gram and ounce using that specific ingredient's own USDA FoodData Central portion weight.' It clearly distinguishes this from generic water-based converters, and the title reinforces the per-ingredient density focus.

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 provides clear context for when to use the tool: any per-ingredient conversion where density matters, including variant handling and special spoon-weight cases. It contrasts with a generic water-density converter, but it does not explicitly name sibling alternatives or state when not to use this 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?

With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses the algorithm (multiply by ratio), the formatting (whole number or simple/mixed fraction), conditional gram appendage, and explicit fallback rules for unrecognized or unparseable lines. It also notes that unchanged lines are returned exactly as-is, including typos, which is important behavioral detail.

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 a single dense sentence with no filler, and the core action is front-loaded. It packs a lot of behavioral detail efficiently, though the length and subordinate clauses make it slightly harder to parse quickly. It earns its words overall, but a short structured break into main behavior and edge cases would improve 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?

The description covers the input format, transformation logic, conditional gram conversion, and edge-case fallbacks thoroughly, which is impressive given there is no output schema or annotations. However, it never explicitly states the return value shape (e.g., that the tool returns an array of strings mirroring the input lines). This is a minor gap since the behavior implies the return type, but a clear statement would make it fully complete.

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 baseline is 3; the schema already documents each parameter's meaning, defaults, and constraints. The description adds useful high-level context about how the parameters interact (e.g., density table and gram conversion), but it does not add meaning per-parameter beyond what the schema provides. It neither harms nor significantly improves on the already-excellent 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?

The description states a specific verb ('Scales'), a specific resource ('a pasted recipe ... from one servings count to another'), and the exact transformation behavior. It clearly differentiates from sibling tools like recipe_convert_ingredient by focusing on bulk scaling with gram-weight enrichment. The title reinforces the purpose, and the description's detail leaves no ambiguity about what the tool 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?

The description clearly implies when to use the tool: when you have a multi-line recipe to scale and want servings-adjusted amounts with optional gram weights. It also describes edge cases where lines are passed through unchanged, which helps an agent understand the tool's behavior. However, it does not explicitly name alternatives or state when not to use this tool in favor of recipe_convert_ingredient or another sibling.

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 delivers: it discloses that the recommendation is static, subjective opinion, current as of August 2026, not measured accuracy or pricing data, and that priority only changes the result when the tradeoff is offered. This is unusually transparent about the tool's limitations and conditional 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?

Every sentence earns its place: the first sentence scopes the tool and disclaims it, the second describes the returned value, and the third explains priority semantics and its limits. Front-loaded with the most important caveat (static editorial, not a benchmark), it remains dense without being wordy.

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 states what the caller gets: recommended model, reasoning, and a second-opinion backup. It also explains the priority parameter's no-op behavior and the input vocabulary via the schema, leaving no major gap for an agent to call this tool 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 description coverage is 100%, so the baseline is 3. The description adds modest context—e.g., that cost routes to DeepSeek and freshness routes to Grok, and that the default is 'quality'—but this largely echoes the schema's own parameter descriptions. It doesn't add significant new meaning for the task parameter beyond what the enum already documents.

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

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

The description is specific: it names the exact verb ('recommend'), the resource ('which of six AI models to use for a given kind of task'), and the concrete output (recommended model plus reasoning and backup). It also distinguishes itself from siblings by explicitly saying it is NOT a live benchmark or leaderboard, so an agent can tell it apart without opening schemas.

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 clearly frames when this tool is appropriate: for editorial opinion-based model selection, and explicitly excludes live benchmark/leaderboard use. It doesn't name an alternative tool because no sibling offers the same functionality, but it does explain the optional priority behavior and when it has no effect.

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?

There are no annotations, so the description carries the full burden. It thoroughly discloses limits and refusal behavior, rendering constraints, the 'all' size ZIP expansion, blank-page behavior, edge spill, and input format guidance such as using JPEG for multi-page sets. This is far beyond typical disclosure.

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 dense and front-loaded: core purpose first, then rendering behavior, then limits. Nearly every clause adds information, though the long LIMITS passage is somewhat harder to scan than a structured breakdown would be.

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 how pages, device frames, blank pages, text limits, gradient options, and size expansion behave, and it gives concrete call-level constraints. There is no output schema, so the only slight gap is not describing the exact returned artifact or response shape, though PNG export and ZIP-for-all are at least mentioned in the description/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%, so the baseline is 3. The description adds some cross-parameter context like total byte limits and the edge-spill behavior, but most per-parameter meaning is already fully documented in the schema. It does not meaningfully expand individual parameter semantics beyond what the schema provides.

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

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

The description states a specific verb and resource: composite screenshots into a device frame, add background/text, and export PNG at App Store Connect sizes. It also gives distinctive behaviors (blank pages, device edge spill) that separate it from sibling image tools such as generate_app_icon_set or resize_images.

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

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

The description gives a clear context for the tool: producing App Store screenshot sets, title cards, outros, and multi-page continuations. It does not explicitly name alternatives or state when-not-to-use, but the domain is distinct enough that an agent can infer when this tool applies.

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 delivers: PNG re-encoding, EXIF/ICC stripping, auto-rotation, uncompressed ZIP rationale, preset folder naming, always-resource_link return behavior, per-file output metrics, and input byte caps. This goes well beyond typical descriptions.

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 long but every sentence earns its place: core operation, encoding behavior, ZIP packaging rationale, link return, and limits. It is front-loaded with the primary action and uses the length to clarify genuinely complex behavior.

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

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

There is no output schema, yet the description fully covers return behavior (resource_link to a ZIP, JSON with per-file dimensions/bytes) plus all operational constraints. For a 6-parameter tool with complex preset logic, nothing needed to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value by explaining folder naming conventions ('social/photo-1200x630.png', 'android/mipmap-hdpi/icon.png') and exposing the server-level per-input byte cap not present 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 verb and resource: 'Resizes a batch of 1+ images to a named real-world preset ... or a custom width/height', and names the fitting modes and output packaging. This clearly differentiates from sibling tools like image_compress or strip_image_metadata by focusing on preset-driven batch resizing.

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 context about when to invoke: batch resizing to presets, custom dimensions, and the fact that output is a ZIP via resource_link. It doesn't explicitly name alternative tools or state when NOT to use it, but the preset and ZIP framing makes the use case evident.

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 so exceptionally. It discloses byte-level stripping with no re-encoding or pixel decode, a byte-for-byte self-check, the failure behavior when the check fails, and the EXIF Orientation side-effect. This is rich, non-obvious behavioral context that an agent could not infer from 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 long but every clause is information-dense and earns its place. The core action and optional mode are front-loaded, followed by process guarantees, failure behavior, and limitations. There is no redundancy 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?

There is no output schema, yet the description adequately explains the report contents, cleaned image behavior, self-check failure handling, supported formats, and the orientation caveat. An agent has enough information to select and invoke this tool 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 100%, so the baseline is 3. The description adds meaningful parameter semantics, particularly for include_cleaned_image: it explains the default true, byte-level stripping, and that no cleaned file is returned if the self-check fails. It also reinforces that format detection is by content signature, not filename.

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 specific, action-oriented language: 'Reads a JPEG or PNG's hidden metadata' and 'returns a structured report', plus clearly states the optional stripping behavior. It clearly differentiates this tool from image compression, conversion, and resizing siblings by focusing on metadata inspection and byte-level removal.

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 clearly defines the tool's job—inspect and strip metadata—and gives an explicit eligibility limitation: 'Only JPEG and PNG signatures are recognized (not TIFF or other formats)'. It doesn't explicitly name alternative tools, but none of the siblings share this metadata-specific purpose, so the usage context is clear.

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