Get a Riftbound decklist

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.