Valo.IA (ValoTCG)

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

Beyond the read-only, idempotent, and non-destructive annotations, the description usefully discloses credit consumption: a base charge plus per-card and include-related charges. The billing shorthand is somewhat ambiguous for mixed card and sealed-product requests, and other behavior such as price freshness or currency is not explained.

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

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

Two compact sentences front-load the capability, item limit, supported product types, and cost without filler. The phrase '+1 per card and include' is overly compressed and makes the otherwise efficient billing statement harder to 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?

Together with the fully described schema and safety annotations, the description provides enough information for a basic invocation, including item limits and billing. With no output schema and many price-related siblings, it remains incomplete about the summary contents and when this comparison tool is preferable to the single-product or other summary tools.

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 it already documents the ID limit, sealed prefix with an example, and include options. The description mostly repeats that information and adds little parameter meaning beyond associating include usage with additional cost.

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 the resource and operation: side-by-side price summaries for up to 10 cards and sealed products, including the sealed ID prefix. It does not explicitly distinguish the tool from overlapping siblings such as price_summary, get_card_prices, or get_sealed_prices.

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?

Side-by-side summaries and the 10-item limit imply that this is for comparing multiple cards or sealed products. There is no explicit when-to-use guidance, exclusion, or direction to a sibling for single-item, detailed, or historical prices.

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

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

The annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context by disclosing the 3-credit cost and the categories of data returned, but it does not describe response structure, pagination, or what 'price coverage' means.

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 compact sentence with no filler, and the cost is stated directly. However, the phrasing is fragmentary and 'Chase cards' could be clearer for an agent unfamiliar with the domain.

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 simple with one required parameter, full schema coverage, and rich annotations. Still, because there is no output schema, the description carries more burden for return-value clarity and only broadly lists returned categories without explaining their structure or coverage meaning.

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 single edition_id parameter is fully documented in the schema, including the reference to list_editions. The description only says 'of one edition' and adds no syntax or format detail 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 identifies a specific resource and scope: cards, sealed products, prices, and price coverage for one edition. It is distinguishable from siblings like list_editions or get_card because it is an edition-level overview, but it lacks an explicit verb and the phrase 'Chase cards' is somewhat ambiguous.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_card, get_sealed_prices, or list_editions. The only contextual signal is the cost statement, which does not help an agent choose between 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 establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description is free to add value elsewhere — and it does, disclosing that each call costs 1 credit and requires a Growth-or-higher access tier. These are operationally important facts absent from the structured fields. It omits behavior on an invalid or missing card_id, which keeps it from 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?

One dense sentence with the resource and return fields front-loaded and zero filler. The telegraphic style leaves "Growth and up" and "1 credit" slightly under-explained, which is the only structural cost.

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 read tool with full annotation coverage, the definition is nearly complete: it enumerates what comes back, which substitutes for the absent output schema, and states cost and access tier. Missing only failure behavior and an explicit pointer to the search/batch siblings for related needs.

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 single card_id parameter is documented in-schema as "Valo.Data card id" with bounds, so the description need not repeat it. The description adds no meaning beyond the schema for the parameter — 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?

"Full sheet of one card" gives a specific verb (retrieve the full record) and resource, and the field list (edition, number, rarity, images, marketplace ids) makes the payload concrete. It does not name the sibling it should be preferred over (e.g. get_card_prices for pricing, search_cards for discovery), so differentiation is left implicit.

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

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

Usage is only implied: an agent infers this is the tool to call once it already holds a card_id and wants the complete record rather than prices or search results. There is no explicit when-to-use/when-not statement and no routing to siblings like get_cards_batch or identify_card, though the "1 credit" and "Growth and up" notes do give a cost/entitlement signal that informs the decision.

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 closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the credit cost structure (1 credit plus 1 per include), which an agent needs for cost-aware planning. It stops short of saying how fresh the prices are or whether they are cached snapshots.

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, front-loaded with what is returned and from where, followed by the cost. Nothing is padded or redundant.

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

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

With no output schema, the description carries the burden of describing returns, and it does so by naming the three sources and the native-currency convention. It is nearly complete for a simple two-parameter read, with only freshness/timing of the prices left unstated.

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

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

Schema coverage is 100% and the schema already documents card_id and the graded/population include values with their credit costs. The description's "1 credit, +1 per include" largely restates the schema's own cost notes, so it adds little beyond the baseline.

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

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

The description gives a specific verb and resource ("Current prices of one card") and names the three data sources (Cardmarket, US market, eBay sales) plus their native-currency treatment. This clearly separates it from get_price_history (historical) and compare_prices, though it never names those siblings explicitly.

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

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

Usage is only implied: an agent can infer this is the single-card current-price lookup, and the per-include credit note signals optional add-ons. There is no explicit when-to-use or when-not-to-use versus get_price_history, compare_prices, or price_summary, all of which sit near 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds the credit cost model — 1 credit per call plus 1 per card and per include block — which is real operational context an agent cannot get from annotations. It omits failure handling for invalid or missing ids and does not say whether results preserve input order or how stale prices are.

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 resource and scope before the cost detail, with essentially no filler. The cost clause '+1 per card and include' is compressed to the point of being slightly ambiguous in grammar, costing a point.

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 says 'current prices' without indicating how results are keyed back to the requested ids or what happens when some ids are invalid — an important gap for a batch tool where partial failure is likely. With only two well-documented parameters the tool is otherwise simple, so this is adequate but not 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 coverage is 100%, so the schema already documents the `sealed:{id}` prefix format with an example, and the description largely repeats it. The only added meaning is that `include` blocks are billed per card, which clarifies the cost tradeoff of the optional parameter. 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 and resource ('current prices of up to 100 cards and sealed products'), plus the batching scope ('in one call') and the sealed-product id convention, which is enough to separate it from single-card siblings like get_card_prices or get_card. It stops short of naming those siblings explicitly, which keeps it from 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?

The phrase 'in one call' implies the intended use case — bulk lookups instead of repeated single-card calls — but no alternative tool is named and there is no stated when-not (e.g. use price history for trends, or compare_prices for side-by-side). Usage must be inferred from the sibling list rather than read from the description.

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

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

Annotations already cover the read-only, idempotent, non-destructive safety profile, so the description adds genuinely new behavioral facts: daily granularity, single-source scope, a plan-dependent history window, and a fixed cost of 3 credits. It stops short of describing return shape or how sparse/partial series are handled.

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 with zero filler; the core scope is front-loaded and the cost note is appended compactly.

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

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

For an 8-parameter tool with no output schema, the description says nothing about the returned series structure, granularity of missing days, or the interplay between market_language, condition, and source. It is adequate to start a call but leaves meaningful gaps.

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

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

Schema description coverage is 88%, so the schema already documents source, card_id/sealed_id mutual exclusivity, variant, condition, and the date defaults. The description only reinforces 'one source' and 'card or sealed product', adding marginal meaning beyond the structured 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?

States a specific resource and scope: 'Daily price history of one source for a card or a sealed product'. The word 'history' implicitly separates it from sibling tools like get_card_prices and compare_prices, 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?

The phrase 'bounded by the plan's history' signals a real constraint on when results are available, and the credit price hints at cost sensitivity, but there is no explicit when-to-use / when-not guidance or named alternative such as get_card_prices for current values.

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 read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: results are per-source and unnormalized ("native currency"), and the call costs 1 credit. It does not describe freshness, caching, or what happens with an invalid id, so the added value is real but modest.

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, front-loaded with what is returned, followed by the currency caveat and cost. 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 single-parameter read tool with full annotation coverage, the description is adequate; the "each source in its native currency" note pre-empts a likely normalization misunderstanding even without an output schema. Minor gaps remain around number of sources and whether values are spot or delayed.

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 single sealed_id parameter is documented as a Valo.Data sealed product id. The description adds no syntax, range, or provenance detail beyond that, which is the expected baseline when the schema does the work.

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+resource combination ("Current prices of one sealed product") and scopes it to a single item, which separates it from batch/list siblings like search_sealed and get_cards_batch. It does not explicitly name which sibling to use for the card equivalent, but the sealed-vs-card distinction is implicit in the wording.

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 when-to-use guidance beyond the implicit 'one sealed product' scoping. The description never mentions how to obtain a sealed_id, nor does it point to compare_prices or search_sealed as the alternative for multi-product or comparison 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?

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value beyond them: result cap of 5, best-first ordering, disclosure of match signals, and a stated cost of 1 credit — the credit cost is exactly the kind of operational detail 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?

One dense sentence with the resource and input flexibility front-loaded, followed by the result contract and cost. No filler or repetition of schema content.

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

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

For a 3-parameter read tool with no output schema, the description covers input domain, result cap, ordering, and cost. The one meaningful gap is the no-match / low-confidence case — an agent doesn't know whether to expect an empty list, a single forced best guess, or a confidence threshold.

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%, making 3 the baseline, but the description genuinely enriches the query parameter by stating that fields can appear in any order and that typos are tolerated — neither of which the schema says. It still doesn't clarify how the game/language filters interact with a query that embeds a language token.

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

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

Specific verb+resource ('Identify a card from free text') with a clear statement of input flexibility (name, number, edition, language, any order, typos tolerated) and output shape (up to 5 candidates, best first, with matched signals). It implicitly separates itself from structured siblings like search_cards, but never names an alternative explicitly.

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

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

The free-text, typo-tolerant framing implies this is the tool for messy human input rather than structured lookups, but there is no explicit 'use this instead of search_cards when...' guidance and no stated exclusions or prerequisites. An agent must infer the routing decision from the sibling names 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 declare readOnly, idempotent, and non-destructive behavior, so the description need not repeat safety. The description adds valuable context: results are ordered newest first, include ids, and cost 1 credit per page, which helps the agent understand output ordering and rate/cost implications.

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

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

The description is a single, front-loaded sentence with two tight clauses—no filler. It efficiently conveys purpose, ordering, identifier inclusion, search hint, and cost.

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 list tool with read-only annotations and a well-described schema, the description covers the key needs: what it returns, ordering, search via `q`, and credit cost. Minor gaps like pagination mechanics are already handled by the schema, so it is nearly 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 coverage is high at 80%, so the schema already documents most parameters thoroughly. The description repeats the `q` search behavior (name or set code) but does not add meaning for cursor, language, or page_size beyond what the schema provides; 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 clearly states it lists editions (sets) of a game, with identifiers, and that results are ordered newest first. It distinguishes the resource and scope well, but does not explicitly differentiate from sibling tools like edition_overview or list_games.

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 purpose—listing editions for a game—and the `q` parameter hint suggests searching by name or set code. However, there is no explicit guidance on when to use this tool versus alternatives such as edition_overview, nor any stated exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds useful behavioral context by stating what each returned record contains (slugs, languages, price coverage per source), but says nothing about result size, ordering, or whether the full catalogue is always returned. That is a modest addition beyond the annotations, not a rich one.

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

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

It is short and the payload information is front-loaded, so there is little waste. But '0 credit' is an unexplained fragment whose meaning (free call? no credit cost?) an agent cannot resolve, and the sentence is a bare noun phrase rather than a structured statement of what the tool does.

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 bears responsibility for describing the return value, and it does so only at a high level: games with slugs, languages, and per-source price coverage. It omits ordering, approximate result size, and how games relate to editions, which matters given the sibling list_editions. Adequate for a zero-parameter list call, but with clear gaps.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description does not mislead about inputs and correctly implies the call takes no arguments. No credit is lost here.

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 identifies the resource (games of the catalogue) and enumerates what each entry carries (slugs, card languages, price coverage per source), which is more than a restatement of the name. However it is a noun phrase with no verb and no differentiation from siblings such as list_editions, which an agent could easily confuse it with. The trailing fragment '0 credit' is cryptic and does not clarify 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?

There is no when-to-use guidance, no statement of prerequisites, and no mention of any alternative. With list_editions in the sibling set, an agent is left to infer on its own whether 'games' and 'editions' are the same concept or different levels of the catalogue. The '0 credit' note implies a cost consideration but is too terse to act on.

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

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

The annotations already establish a safe, read-only, idempotent operation. The description adds useful behavioral context beyond them: pricing is in EUR, includes source and reliability, reports 7/30/90-day changes, and costs 1 credit with +1 per include.

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 tightly written sentences front-load the core purpose and then add cost and contents. 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?

With only three fully documented parameters and no output schema, the description supplies the essential return-value context and credit cost. It could be stronger by clarifying sibling alternatives, but it is otherwise complete for this tool's complexity.

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 explains card_id, sealed_id, and include. The description adds the credit implication of including extras, but otherwise does not add much parameter meaning 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 (price summary) and scope (a card or sealed product in EUR), including the returned fields: source, reliability, and 7/30/90-day changes. It does not explicitly differentiate itself from close siblings such as get_card_prices or get_price_history, which keeps it from 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?

Usage is implied by the card-or-sealed scope and the returned summary fields, but there is no explicit guidance on when to choose this over compare_prices, get_card_prices, or get_price_history. The agent must infer the appropriate situation from the description 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavior: result count and ordering, per-photo scan billing, no charge on refused photos or errors, and in-memory processing with no retention. The privacy and cost disclosures are high-value context an agent cannot derive from the annotations.

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

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

Three compact sentences, front-loaded with purpose and result shape, followed by the chaining hint and then the cost/privacy clauses. Every clause carries information an agent would otherwise not have; there is no filler.

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

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

With no output schema, the description compensates by describing the return ('up to 5 Valo.Data cards, best first'), which is enough to parse results. It could say slightly more about what a candidate entry contains or what happens when no card is recognised, but the essentials for correct invocation are present.

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

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

Schema coverage is 100%, so game, image and language are already fully documented with constraints (base64/data URL, formats, 8 MB, 480 px minimum, language filter). The description adds no parameter-level meaning 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 a specific verb and resource ('Recognise the card in a photo') and names the underlying engine (Valo.Vision), plus the result shape: up to 5 Valo.Data cards, best first. It does not distinguish itself from the sibling identify_card, which appears to cover similar ground, so an agent still has to guess between them.

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

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

It gives clear next-step workflow guidance ('chain with price_summary for its price') and an explicit cost/retry rule ('1 scan per analysed photo; a refused photo or an error costs nothing'), which is exactly what an agent needs before attempting a call. It lacks an explicit when-to-use-this-instead-of-identify_card statement, so the guidance is contextual rather than exclusionary.

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

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

Annotations already cover read-only, idempotent, non-destructive, and closed-world, so the description is not obligated to restate safety. It does add one genuinely useful non-annotation fact: a cost model of 1 credit per page, which affects how an agent sizes page_size and pages through results.

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, front-loaded with the action and scope, followed by the cost note. Nothing is redundant or padded.

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

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

For a 7-parameter paginated search with 86% schema coverage and full read-only annotations, the description covers what it searches and what it costs. The remaining gap is that there is no output schema, so the description does not indicate what a result page contains beyond the implicit cursor in the schema.

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

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

Schema description coverage is 86%, so the schema already explains q (name FR/EN or number), game slug, cursor, rarity format, language, and edition_id. The description's filter list largely mirrors those fields and adds no format rules, examples, or combination semantics 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 concrete verb and resource ("Search the cards of a game") and enumerates the filterable dimensions, which lets an agent distinguish it from get_card and get_cards_batch. It falls short of a 5 because it never names or contrasts those siblings explicitly.

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

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

The description implies search usage through its filter list, but gives no explicit when-to-use or when-not-to-use guidance, and does not point to get_card (single lookup), identify_card, or search_sealed as alternatives. The agent must infer the boundary from the names 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?

The annotations already establish that the operation is read-only, idempotent, and non-destructive, while the description adds the important billing behavior of 1 credit per page. It offers little further operational context, such as result-page behavior, but the cost disclosure is valuable beyond the annotations.

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

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

Two compact sentences front-load the action, resource, examples, and available filters, then disclose the per-page cost. There is no filler or unnecessary repetition.

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

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

Combined with the rich schema and safety annotations, the description supplies enough context for most correct selections and invocations, including game scope and usage cost. With no output schema, brief result and pagination context would help, and explicit routing to search_cards or get_sealed_prices would improve disambiguation.

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 86%, so the baseline score of 3 applies. The description's filters and product examples largely repeat what q, edition_id, product_type, and language already document, without adding new syntax, constraints, or parameter interactions.

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 pairs a specific verb and resource—searching a game's sealed products—with concrete examples and filter dimensions. The sealed-product scope hints at the distinction from search_cards and get_sealed_prices, but it does not explicitly differentiate those siblings.

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

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

It provides clear usage context: find sealed products for a game by name, edition, type, or language. It does not explain when not to use it or direct agents to search_cards for cards or get_sealed_prices for pricing, so the guidance is not fully 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds genuinely useful non-schema context: the 3-credit cost and the implicit 10 EUR minimum card value, which affect whether an agent should call it. It does not describe the response shape or ordering, but with annotations carrying safety this lands at a 3.

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

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

Two compact sentences, front-loaded with what the tool returns and immediately followed by the credit cost. No filler and nothing an agent must read twice.

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-output-schema tool the description is nearly sufficient: scope, time windows, price floor and cost are all stated. It omits what a result entry looks like (card identity, price change, percentage) and how the `reliable` flag and `direction` combine in practice, but the rich schema descriptions compensate for most of that.

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 86%, so the schema already explains game, period, language, reliable, direction and edition_id in detail. The description restates the period options and adds the 10 EUR threshold, which is a real filter not expressed in the schema, but it offers no additional meaning for limit, language or edition_id. 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 gives a specific verb and resource: 'largest price rises or falls of a game or an edition' with the time windows and a price floor. An agent can distinguish it conceptually from siblings like top_priced (most expensive) and get_price_history (per-card history), though neither 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 framing (movers over 7/30/90 days for cards >= 10 EUR), which tells the agent the shape of question this answers. However, there is no explicit when-to-use guidance, no mention of when to prefer top_priced or get_price_history instead, and no stated prerequisites such as needing a game slug from list_games (that hint lives only in the schema).

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts: prices are EUR as shown in the ValoTCG app, omissions mean 'every edition and language', and the call costs 3 credits — a real operational constraint an agent cannot get from structured fields.

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-loads the resource and ranking criterion, then the optional narrowing dimensions, then the cost. Nothing is wasted and no sentence merely restates the title.

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

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

For a read-only ranked-list tool with 6 params and no output schema, the description supplies the currency, the filter defaults, and the credit cost — enough to call correctly. It stops short of describing what each returned item contains or how ties/ordering are handled, which would matter for result 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?

Schema coverage is 83% so the baseline is 3, and the description earns the extra point by clarifying the default semantics of the optional filters — an omitted edition_id means all editions, an omitted language means all languages, and product_type only applies when kind=sealed. The limit parameter is left unexplained but the schema covers 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 names a specific resource and ranking criterion — 'Most valuable cards or sealed products of a game, by the price the ValoTCG app shows (EUR)' — which clearly separates it from retrieval tools like get_card or filtering tools like search_cards. It does not explicitly name a sibling alternative, which keeps it 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?

Usage is implied by the framing: use this when you want a ranked top-N by value, optionally narrowed to one edition, language, or sealed product type. There is no explicit exclusion or routing against near-neighbours such as top_movers (movement-based) or price_summary (aggregate statistics), so the agent must infer the boundary.

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