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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds real behavioral value by stating the cross-parameter constraint ('provide at least one of') that the schema's zero required fields does not enforce, plus the batch-vs-single-search intent and the response_format choice.

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 core purpose, then the constraint, then args and mini-examples; every section is useful. The Args block partially restates the schema descriptions, which is mild redundancy but it is paired with mapping examples that add value.

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

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

For an identity-lookup tool with no output schema, the description covers purpose, inputs, combination rules, alternatives and response_format. It does not describe the shape of returned card data, a minor gap, but the response_format hint and 'turn ids into real card names' framing give the agent enough to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it with concrete example values (["OGN-007"], ["Vi, Destructive"]) and semantic framing such as 'card or variant UUIDs, as returned in deck contents', clarifying where the ids come from.

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 (resolve/look up) plus resource (Riftbound cards) with three explicit lookup keys (collector number, exact name, UUID), and it names the sibling it is not (search_cards). An agent can distinguish it from piltover_search_cards without opening either 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?

States the selection condition ('Provide at least one of variantNumbers, names or ids'), the concrete use cases (resolving cardId/variantId from a decklist, batch lookup to avoid one search per card), and an explicit negative case routing to piltover_search_cards for criteria-based search.

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 genuinely useful behavior the annotations cannot express: card UUIDs are resolved by default at the cost of extra requests, and the exact sections returned (champions, battlefields, runes, main deck, sideboard, bench). It stops short of describing output format details, but that is minor here.

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

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

Front-loaded with purpose and behavior, then a scannable example and exclusion. The 'Args' block largely duplicates the schema descriptions, which is redundant given 100% coverage, but the overall length is proportionate to a 3-parameter tool with a non-obvious default.

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, yet the description enumerates the returned sections and the markdown/json format choice, so an agent knows what comes back. Combined with the worked example and the explicit routing rule, nothing needed to call this 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, but the description adds real meaning: resolve_cards is explained as the tool's purpose with a stated cost tradeoff and a false-escape hatch, response_format is framed as reading vs. further processing, and deck_id's origin is tied to piltover_search_decks. This goes beyond the schema text rather than restating 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?

Starts with a specific verb+resource+scope: fetch one deck by ID and return its full contents. It also names the sibling piltover_search_decks as the source of the deck_id and clarifies the resolution behavior that is 'the point of the tool', so an agent can distinguish it from the search tool without opening a schema.

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

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

Contains an explicit exclusion — 'Don't use when: you only need deck metadata for many decks — piltover_search_decks already returns that' — and states the condition under which the costly default (resolve_cards=true) should be switched off. Both when-to-use and when-not-to-use are covered with the alternative named.

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 destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the shape of the returned data (prefix + release date) and the response_format tradeoff for downstream processing. It does not mention pagination or ordering, so it isn't fully exhaustive.

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

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

Front-loads the core purpose, then adds the cross-tool rationale, args, and short examples. Every block earns its place and 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?

For a single-optional-param, no-output-schema tool, the description supplies what the return contains (prefix, release date), the routing rationale, and the format options. Nothing an agent needs 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 description coverage is 100% and there is only one enum-constrained parameter, so the schema already documents response_format. The description restates the 'markdown (default) or json' options without adding format-specific meaning beyond the existing enum description — baseline 3.

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 precise verb+resource ('List every Riftbound card set') and specifies the returned fields (prefix and release date). It also differentiates itself from the sibling piltover_search_cards by explaining that its prefixes feed that tool's `sets` filter.

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

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

Gives an explicit trigger condition: call this first when a question names a set in words rather than by prefix. The worked examples ('What's the prefix for Origins?' -> {} then read the table) reinforce exactly when and how to invoke 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds genuinely new behavior: filters combine with AND, every filter is optional so an empty call lists all cards, and results are printings rather than game cards, with the underlying card nested under `card`. It does not mention pagination metadata or rate/latency behavior, so it stops short of a 5.

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

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

Front-loads purpose, then filters, then Args, then Examples, then the don't-use case. The Args block largely restates the schema, which is some duplication, but the example section is high-value and the whole thing stays 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 25-parameter tool with no output schema, the description covers result shape (printing + nested card), pagination limits, default response format, and failure mode routing to the sibling. Minor gap: no detail on what pagination/total metadata the response carries, but the essential call-correctness information is present.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond it by grouping parameters into semantic families (free-text vs single-field, multi-value filters, numeric ranges, sort/dir, page/limit, response_format) and by tying natural-language questions to concrete parameter combinations in the examples, which the schema alone does not convey.

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 Piltover Archive database of Riftbound trading card game cards') and immediately differentiates itself from the sibling piltover_get_cards, which handles exact IDs/collector numbers. The scope note that Riftbound data is absent from training data makes the tool's role 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?

Explicit when-to-use ('use this tool rather than answering from memory whenever a specific card, cost, rules text or price is involved') and explicit when-not-to-use with the named alternative ('you already have exact collector numbers or IDs — use piltover_get_cards, which is one request instead of many'). Both the trigger and the exclusion are stated.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds value beyond that: it states the return shape (deck summaries with a deck ID), the pagination limit (max 100), and the default response format.

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 purpose sentence, then tight Args list and two concrete examples. Every line earns its place and the format is 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?

With no output schema, the description compensates by stating what comes back (deck summaries, deck ID) and where to go next. Pagination, defaults, and sort semantics are all covered, so an agent has enough to invoke 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 baseline is 3, but the description adds genuine meaning: q is explained to span deck name, description AND legend name, so a champion query finds decks even when the title omits it. It also clarifies sort/dir pairing and what response_format is for.

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 (Search) and resource (public decklists on Piltover Archive), and adds the intent behind it (seeing how a champion/archetype is built). It also differentiates from the sibling piltover_get_deck by explaining it returns summaries whose deck ID feeds that tool.

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

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

Gives clear context for when to use it ('see how a champion or archetype is actually built, what the community is playing right now') and explicit example query->arg mappings. It routes to piltover_get_deck for the full card list, though it doesn't explicitly distinguish itself from piltover_search_cards.

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