Art Spotter - Eye of the Beholder

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the bar is low. The description adds meaningful context about the result: the calculation is tiered 'by band', includes 'the cap', and names 'who collects it' — output-shaping detail the annotations cannot convey.

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

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

A single tightly packed sentence with the essential scope front-loaded. Minor waste in the opening clause, which duplicates the title rather than advancing the agent's understanding.

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

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

For a one-parameter, no-output-schema calculator, the description covers the input domain, the tiered computation, the cap, and the beneficiary — everything needed to invoke it and anticipate the result. Nothing material is missing.

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

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

Only one parameter exists and schema coverage is 100% ('Resale price in pounds.'), so the schema fully documents it. The description adds only the implicit currency/context ('UK resale'), matching the baseline for high-coverage schemas.

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 computation ('royalty owed to an artist on a UK resale') with the domain named, which is enough to separate it from siblings like price_commission or get_fair_art_price. The first clause largely restates the title, so it isn't maximally efficient, but the verb+resource is unambiguous.

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

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

The phrase 'on a UK resale through a gallery, dealer or auction house' implies the applicable scenario and implicitly scopes to UK resales, but there is no explicit when-to-use, when-not, or named alternative to pick instead. Usage must be inferred from the domain framing.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral value by naming the concrete checks performed (reverse image search links, stolen-image and AI-work detection, payment-scam flags), which annotations alone would not convey.

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

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

The lead clause is well front-loaded, but the remainder is a comma-spliced run-on list ('Whether a link is..., reverse image search links..., and the checks that catch...') that is grammatically loose. Information density is good, but sentence structure does not earn full credit.

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

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

No output schema exists, so the description usefully previews what the tool returns (index status, buyer-protection status, reverse image links, scam indicators). It stops short of specifying output shape or how the two optional inputs combine, leaving a small gap.

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

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

Schema coverage is 100% with only two optional params (url, image) fully documented in the schema. The description alludes to 'a link' and the picture but adds no format, precedence, or fallback semantics beyond the schema. Baseline 3 is appropriate.

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

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

States a clear verb+resource ('Check an art listing') and enumerates what the check covers (index membership, buyer protection, reverse image search, scam detection). This distinguishes it well from price/commerce siblings, though it doesn't explicitly contrast with the closest sibling, verify_artwork_passport.

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?

'Before buying' gives a clear implied usage moment, but there is no explicit when-not-to-use guidance or routing to alternatives like verify_artwork_passport or search_art. The agent must infer the boundary between this and the passport-verification 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the result is a list of things to fix, which is useful framing, but it does not describe rate limits, fetch failures, or output shape beyond that single phrase.

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

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

Two sentences, but the second repeats the resource name from the first ('Check an artist's artworks.json. Reads an artist's artworks.json...'), which is redundant. The actionable content ('lists anything to fix') is buried at the end rather than front-loaded.

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

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

With no output schema, the description should carry return-value semantics; it only says it 'lists anything to fix' without indicating structure, severity, or what a clean result looks like. For a single-parameter read-only tool this is minimally adequate but leaves a real gap around output interpretation.

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?

Only one parameter exists and the schema documents it at 100% coverage ('The https address of the artworks.json file'). The description adds no format, hosting, or validation constraints beyond that, so the schema carries the load — baseline 3 applies.

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

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

The description states a concrete verb ('check'/'reads') and resource (an artist's artworks.json), and explains the artifact's purpose (an open format for finding work sold direct). 'Check ... lists anything to fix' tells the agent this is a validation/lint operation, which separates it from siblings like check_art_listing, though the word 'check' itself remains somewhat generic.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of when this is preferable to siblings such as check_art_listing or verify_artwork_passport. The agent must infer the use case from the resource alone.

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

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

Annotations already establish read-only, idempotent, open-world and non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it uses US and UK fee tables and offers print-on-demand options for prints, plus a sort order (by money kept). It omits caveats such as fee-table freshness or accuracy limits.

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

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

Front-loaded with the purpose and then packed with platform names and output ordering. It is dense but every clause carries information; the platform enumeration is a bit list-heavy but justifies the sort-by-proceeds promise.

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

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

With no output schema, the description carries the burden of describing the result and does so: per-platform kept amounts, sorted by money kept, with print-on-demand variants. Fee-table geography is noted. It stops short of clarifying output shape or currency handling in results, but is otherwise sufficient.

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 all four parameters, making 3 the baseline. The description reinforces the price input and the print option (kind), but adds no format, range, or default detail beyond what the schema states.

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

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

States a specific verb and resource — what the artist keeps after fees on a named list of platforms — which distinguishes it cleanly from siblings like get_fair_art_price (buyer-facing price) and calculate_resale_royalty (royalty math). The agent knows immediately this is a net-proceeds comparison.

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: it takes a sale price and returns per-platform net proceeds, which tells the agent when to reach for it. It does not name an alternative or state exclusions versus the pricing/royalty siblings, so it stops short of the explicit when/when-not routing.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds useful scope detail (UK arts council grants, Own Art, ARR; US $85 group registration) but does not describe return format, default country behavior, or any operational constraints.

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

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

Three sentences, front-loaded with the topic list, then country specifics. The first sentence duplicates the title, but the rest is dense and waste-free.

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

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

For a low-complexity, one-optional-param lookup tool with rich annotations and full schema coverage, the description supplies enough content scope to call it correctly. It omits what happens when country is omitted and does not describe the return structure, but those gaps are minor given the tool's simplicity.

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

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

Schema coverage is 100% and the single country parameter is already documented as 'GB or US.' The description goes further by mapping 'UK' to GB and explaining what content each country yields, adding real semantic value 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?

The description enumerates the exact subject areas (grants, buyer finance, royalties, copyright) and differentiates UK vs US content, so an agent knows this is a reference tool for artist funding. However it states topics rather than an action verb and does not distinguish itself from the royalties-calculation sibling calculate_resale_royalty, so it stops short of a 5.

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

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

No when-to-use guidance, no prerequisites, and no alternative tools are named. The description only lists content domains, leaving the agent to infer that this is the right tool for funding questions.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuine context beyond that: the data source ('independent artists' own shops') and the shape of the result (typical price, middle half of prices, price per square inch). It does not mention rate limits or latency, keeping it short of a 5.

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

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

Two sentences, front-loaded with the purpose, and the second sentence is dense but all content (source, three statistics, comparables) earns its place. Slightly heavy for the second sentence but 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?

There is no output schema, and the description compensates by naming the returned statistics (typical price, middle half, price per square inch) and the data source. Combined with full schema coverage and rich annotations, an agent has what it needs to call and interpret this tool; only explicit alternative-tool routing 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 description coverage is 100% with enums for kind and unit, so the schema already carries parameter meaning. The description restates the size/medium dimensions but adds no format, default, or edge-case detail beyond the schema (e.g. no note on unit defaults when omitted). Baseline 3 is appropriate.

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

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

States a specific verb+resource ('fair price for a new artwork') and scopes it by 'size and medium', which cleanly separates it from siblings like price_commission, calculate_resale_royalty, and compare_where_to_sell. An agent can identify the tool's output without opening the schema.

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

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

The word 'new' plus 'comparable works for sale' implies the pricing-a-fresh-work use case, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative (e.g. price_commission for commissions, calculate_resale_royalty for resales). Usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description goes further by disclosing what each entry contains (entry fees, usual closing month, media, official links), which is genuinely useful for a tool with no output 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?

Two compact sentences with the resource named first and the scope/return details second. No filler, though the second sentence is a dense comma list that could be tightened.

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

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

For a read-only list tool with fully documented optional filters and no output schema, the description covers the domain, geography and result contents. It leaves out only result volume/pagination behavior, a minor gap against rich annotations.

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%, with kind, media and country all documented in the schema itself. The description adds no format, syntax or combination guidance beyond that, so the baseline 3 applies.

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

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

The description states the resource precisely — open calls, prizes and residencies for artists — and adds the geographic scope (UK, US, Canada), so an agent knows what it retrieves. It does not name or contrast any sibling tool (e.g. get_artist_funding), so differentiation is left to inference.

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

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

Usage is implied: an agent listing opportunities for artists would pick this. The UK/US/CA constraint implicitly bounds where it applies, but there is no explicit when-to-use or when-not-to-use guidance versus the many sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered. The description adds real value beyond them: it discloses the fingerprinting of the picture, the dual output form (printable text plus schema.org data), and the intended downstream verification use. It stops short of describing failure behavior when the image URL cannot be fetched (relevant given openWorldHint=true) or the fingerprint algorithm's stability.

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

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

Two sentences, front-loaded, with the outcome and mechanics packed efficiently into the second. The opening sentence largely restates the title ('A free artwork passport for an artist's work'), which is minor redundancy but the only wasted words in an otherwise tight definition.

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

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

With no output schema, the description usefully sketches the return ('printable text and schema.org data'), and all inputs are covered by the schema. What is missing for full completeness is edge-case behavior: what happens with an unreachable image address or an omitted optional field, and confirmation that the fingerprint is deterministic so the later check is meaningful.

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 defines all seven parameters with examples, and the baseline is 3. The description enumerates the same field set, adding no syntax or format detail beyond what the schema provides, so it neither compensates for nor exceeds the schema.

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

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

The description names a concrete verb and artifact ('Makes a certificate for a work'), enumerates the fields carried (title, artist, year, medium, size, edition), and states the outputs ('printable text and schema.org data'). It also implicitly separates this from the sibling verify_artwork_passport by explaining the purpose is so 'anyone can later check the picture is unchanged', so an agent can see the create/verify pairing.

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

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

Usage is only implied: an agent can infer you call this when you want to mint a passport for a work. There is no explicit when-to-use statement, no prerequisites (e.g. image must be publicly reachable), and no sibling named as an alternative or follow-up, even though verify_artwork_passport is the natural counterpart.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful scope by enumerating the kinds of outputs returned (deposit, revision rounds, cancellation fees, copyright, contract checklist). It stops short of stating that figures are estimates, whether results depend on external data, or any caveats, so it only modestly exceeds the annotation baseline.

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 first sentence is a verbatim restatement of the title and is pure waste. The second sentence is a long but informative enumerations of outputs, and the key scope ('by size and the artist's level') is not front-loaded. Readable, but not tight.

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

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

With no output schema, the description compensates well by listing the returned content (price guide, comparable sales, deposit, revision rounds, cancellation fees, copyright, contract checklist). Parameters are fully covered by the schema. The remaining gap is the lack of disambiguation from pricing siblings, which matters in this crowded sibling set.

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 width, height, unit, level and medium are fully documented in the schema, giving a baseline of 3. The description only loosely mirrors two of them ('by size and the artist's level') without adding format, default, or range detail, so it adds little 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?

The description states a specific resource and function: a price guide plus terms (deposit, revision rounds, cancellation fees, copyright, contract checklist) for a commissioned piece, scoped by size and artist level. It is far more informative than the title alone. It does not, however, differentiate itself from siblings like get_fair_art_price or calculate_resale_royalty, so an agent must infer the boundary.

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

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

There is no explicit when-to-use guidance and no mention of alternatives, despite the sibling set containing several pricing-related tools. The commissioning context is implied only by the word 'commissioning,' which is not enough to route reliably between get_fair_art_price and 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?

Annotations already declare it read-only, idempotent, non-destructive and open-world, so the safety burden is lifted. The description adds genuinely useful behavior not in the annotations: the two underlying sources (independent shops and eBay) and the fields each result carries, which substitutes for the missing output 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?

Two dense sentences, purpose front-loaded, no filler. The second sentence is long but earns its place by describing the result shape where no output schema exists.

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

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

For a 13-parameter, no-required-params discovery tool with no output schema, the description covers both the source scope and the returned fields. Only the lack of guidance on result limits/pagination semantics (the limit param) keeps it from 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 schema already documents all 13 parameters with examples and enum values. The description restates facets (kind, original/print, price, size, colour) at a high level without adding syntax, defaults, or interaction rules beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb and resource ('Find art for sale') and adds real scope: it searches independent artists' own shops plus eBay art. That clearly separates it from pricing/passport/royalty siblings, though no sibling is named explicitly.

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

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

Usage is implied by the enumeration of search facets (subject, style, place, artist, kind, price, size, colour), so an agent can infer it is the discovery tool. However, there is no explicit when-to-use or when-not-to-use guidance, and no routing against check_art_listing, check_artworks_feed, or compare_where_to_sell.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description does add one behavioral fact beyond the annotations — that a size-range search is bundled into the response — but says nothing about what the returned numbers look like or the mutual dependence of wall_width and furniture_width.

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

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

A single dense sentence, front-loaded with the primary question ('what size art fits a wall and how high to hang it') followed by the derived outputs and the ancillary search. Every clause maps to a real capability, though the output list is slightly packed.

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

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

No output schema exists, so the description must name the returns — and it does (width, hanging height, gap, gallery spacing, matching works). For a 3-param, zero-required calculator with full schema documentation, that is nearly complete; it only omits guidance on supplying one of the two width 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% with per-parameter descriptions for unit, wall_width and furniture_width, so the schema carries the burden. The description only echoes the wall-vs-furniture distinction without adding format or selection rules, matching the baseline 3 for full schema coverage.

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

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

The description names the concrete outputs (art width for furniture or wall, hanging height, gap above furniture, gallery wall spacing) and adds a ready size-range search, which clearly separates it from siblings like search_art or get_fair_art_price. It stops short of a crisp verb-first statement, but the resource and computed results are unambiguous.

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

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

Usage is implied: the wall/furniture context tells an agent this is a sizing calculation, and no alternatives are named for exclusion. There is no guidance on when to prefer this over search_art or which of wall_width vs furniture_width to supply, so it remains minimum viable.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and openWorld. The description adds genuine behavioral context beyond that: it recomputes the fingerprint rather than trusting input, and returns a match/no-match verdict. It stops short of describing failure modes (bad URL, unreadable image) or the response shape.

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

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

Two short sentences, zero filler, with the core purpose front-loaded and the mechanism as supporting detail. Nothing repeats the title verbatim without adding information.

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

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

For a two-parameter, read-only, no-output-schema tool this is nearly complete: purpose, mechanism, and the nature of the result are all stated. The only gap is not clarifying what happens on mismatch or invalid input, which an agent calling it blind might want.

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

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

Schema description coverage is 100%, so both parameters (image URL, sha256 fingerprint) are already documented in the schema. The description restates the same mapping ('picture's fingerprint' vs 'the one in the passport') without adding format, encoding, or error semantics beyond 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?

States a specific verb (check/verify) and resource (picture against an artwork passport), and the second sentence explains the mechanism (recompute fingerprint, compare to passport value). It is clear what it does, though it never names or contrasts with the obvious sibling make_artwork_passport.

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

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

Usage is implied: you run this when you have an image URL and a passport fingerprint and want to confirm authenticity. There is no explicit when-to-use/when-not-to-use statement and no alternative tool named, so an agent must infer the context.

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