MTG Bench

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

Beyond the readOnlyHint annotation, the description discloses important behavioral nuances: that bans changed multiple times in 2026, that the commander parameter counts toward the deck count, and that omitting commander results in a response saying color identity went unchecked. These details help the agent understand the tool's behavior and limitations.

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, focused paragraph that opens with the core purpose, then adds a persuasive justification for using the tool, and finishes with parameter specifics. Every sentence earns its place; it is concise without being sparse.

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 validation tool with an output schema, the description covers the essential context: what rules are checked, why it's needed, and how to handle Commander. It also explains a common failure mode (unchecked color identity). The presence of an output schema reduces the need to describe return values, making this description 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?

The description provides detailed semantics for the commander parameter, explaining its role and impact. However, it does not elaborate on the format parameter (e.g., allowed values) or the cards array structure beyond what the schema already shows. With 0% schema description coverage, the description only partially compensates, leaving these parameters under-specified.

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 tool validates a decklist against constructed format rules, specifying exactly what it checks (banned cards, deck size, copy limits, and color identity in Commander). It uses a specific verb and resource, and the purpose is distinct from sibling tools like rate_deck or deck_stats.

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

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

The description explicitly instructs to use this tool rather than recalling ban lists from memory, citing a concrete reason (frequent ban changes and stale training data). It also provides conditional guidance for the commander parameter, explaining when to pass it and why it's necessary for color-identity checking.

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, but the description adds significant behavioral nuance: it explains how to interpret synergy scores, warns that high deck count with low synergy is often a generic staple like Sol Ring, and distinguishes between popularity and commander-specific synergy. This exceeds what annotations 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 description is well-structured and front-loaded with the tool's purpose. It uses three packed sentences covering data source, output fields, interpretive guidance, and a usage recommendation. No word is wasted, and the Sol Ring example makes it concrete.

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

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

The description covers the data source, output semantics, and how to interpret results, making it sufficient for most users. It is slightly incomplete because it omits the behavior of the optional parameters 'limit' and 'minSynergy', which could be gleaned from the schema names but are not explicitly defined.

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?

With 0% schema coverage, the description must explain all parameters. It clarifies that 'commander' is the target commander via 'with a given commander', but it does not mention the 'limit' parameter (likely a cap on returned cards) or 'minSynergy' (a filter threshold). These gaps are not compensated elsewhere.

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 that the tool returns the most commonly played cards with a given commander, along with deck count, share, and synergy score. It differentiates itself from siblings by emphasizing both popularity and synergy, and explicitly contrasts with 'everyone plays anyway' cards like Sol Ring.

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

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

The description gives a clear use case: 'Use this to ground deckbuilding in what people actually play instead of guessing.' It also advises to lead with high-synergy cards when recommending. However, it does not explicitly name alternative sibling tools or state when not to use 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 readOnlyHint=true and openWorldHint=false, and the description adds substantial behavioral context: deterministic, no judgment calls, specific statistical methods (hypergeometric), scope (any format), and Commander-specific band signals. This goes well beyond 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 description is a single, dense sentence that front-loads the main purpose and then systematically lists the analysis dimensions. Every phrase carries informative weight, and there is no filler or 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?

Given an output schema exists and annotations are present, the description covers the tool's scope and capabilities thoroughly. It lists a comprehensive set of outputs and clarifies the deterministic/non-judgmental nature, making it complete for an analyst agent.

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 0%, so the description must compensate. It does so by explaining 'decklist' (cards), 'any format' (format), and 'Commander bands' (commander), adding meaning beyond the raw schema fields. However, it does not explicitly map each parameter to its exact usage constraints.

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 tool performs deterministic statistical analysis of a decklist and enumerates specific outputs (mana curve, card types, probabilities, suggested land count, etc.). It distinguishes itself from siblings like rate_deck or upgrade_deck by emphasizing 'Pure data — no judgment calls.'

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

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

The description provides clear context for use: any format, statistical focus, and deterministic outputs. It implies when to use (when objective deck stats are needed) but does not explicitly name alternatives or exclusion criteria, so it falls just short of a 5.

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

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

Annotations provide readOnlyHint=true, and the description adds meaningful behavioral context: it returns both full combos and near-misses, includes card prices for near-misses, and filters suggestions based on format/commander legality. It does not contradict annotations and goes beyond them by explaining the curated database source and integration with rate_deck.

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

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

The description is two sentences, front-loaded with the core function, and each clause earns its place by adding critical information about features, inputs, and usage. It is compact yet information-dense without fluff.

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 output schema exists, so return values need not be described. The description covers purpose, key behavior (full combos + near-misses), input requirements (format/commander), and integration with rate_deck. Given the tool's moderate complexity, this is fully complete for an agent to invoke it correctly.

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

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

Schema coverage is 0%, so description must compensate. It explains the purpose of `format` and `commander` for near-miss filtering, but does not describe the required `cards` parameter or the optional `limit`. This partial coverage is useful but leaves significant gaps for the two unnamed parameters.

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 tool detects known combos in a decklist using Commander Spellbook's curated database. It distinguishes itself from siblings like find_synergies by specifying 'known combos' and 'near-misses one card away', giving a precise verb+resource+scope.

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

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

Explicitly instructs to pass `format` and `commander` for filtering near-misses, and tells when to use this tool: 'instead of recalling combos from memory' and 'also feeds rate_deck's compact-combo check'. This clearly sets context and differentiates from alternatives.

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, so the agent knows this is safe. The description adds behavioral details beyond that: 'Seeded by example rather than by description' and the `limit` default/cap. No contradictions with annotations. However, it does not mention any potential quirks or response structure, but output schema exists.

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, each serving a distinct purpose: the core function, alternatives/usage, and limit behavior. No redundancy or filler. Front-loaded with the primary purpose, making it easy 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?

Given that the tool has 7 parameters and zero schema descriptions, the description is not fully complete. It covers the core input (`cardNames`) and `limit`, but leaves multiple filter parameters undocumented. It also does not contrast with the similar sibling `find_combos`, though it does distinguish from `semantic_card_search` and `search_cards`. The presence of an output schema mitigates some completeness 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 0%, so the description must compensate. It only explains `limit` (defaults to 10, caps at 100) and implies `cardNames` means card names. The other parameters (`types`, `colors`, `format`, `manaValueMax`, `manaValueMin`) are left entirely unexplained, leaving the agent guessing about their allowed values and semantics.

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 tool's purpose: 'Given one or more cards the user ALREADY has, find cards that work with them.' It uses a specific verb (find) and resource (cards), and explicitly distinguishes from siblings by contrasting 'semantic_card_search instead' and 'search_cards for structured filters.'

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 explicit when-to-use guidance: 'Given one or more cards the user ALREADY has' and explicitly names alternatives with instructions ('Use semantic_card_search instead to describe a desired effect in words, and search_cards for structured filters'). Also includes the `limit` default and cap, adding practical usage context.

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, and the description adds meaningful behavioral context by enumerating the exact output fields (oracle text, mana cost, type line, format legalities, printings summary) and noting the 'exact name or id' constraint. This goes beyond the basic read-only hint.

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 with no filler. The first sentence front-loads the tool's purpose and result fields, and the second gives a conditional alternative. Every word earns its place.

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

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

The description is adequate for a card-detail fetch: it states what data is returned and when to choose a different tool. The presence of an output schema means return structure doesn't need to be explained. It doesn't cover error behavior (e.g., not found), but given the tool's simplicity and annotations, it is sufficiently 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?

With 0% schema description coverage, the description must compensate for the parameters. It clarifies that 'name' and 'id' are acceptable for exact-match lookup, but it completely omits the 'slug' parameter present in the schema. This leaves a gap for the agent's understanding of all available inputs.

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 tool's action ('Fetch full detail for ONE card') and specifies the exact resources returned (oracle text, mana cost, type line, format legalities, and a brief summary of printings). It also distinguishes itself from the sibling tool get_card_printings by explicitly deferring printing-list use cases.

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

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

The description provides explicit guidance to use get_card_printings instead when a complete printing list matters, giving a clear exclusion and alternative. It implies usage for exact-name/id lookups but does not mention other sibling tools like search_cards for fuzzy lookups, so it is not fully exhaustive.

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?

Beyond the readOnlyHint annotation, the description reveals important behavioral context: the returned image content block is the display itself, the client renders it directly, and sandboxed widget environments block external hosts. This explains why custom HTML should be avoided and adds value beyond the safety hint. It also discloses supported sizes/formats, which is useful for caller expectations.

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

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

The description is two sentences and front-loaded with the core purpose. The second sentence is long but packs critical rendering guidance and optional parameter details without redundancy. Every phrase earns its place, though the size list is somewhat lengthy and could be trimmed or rephrased for clarity.

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

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

The description covers the main behavior, display instructions, and optional parameters, and an output schema exists so return format need not be explained. However, it does not clarify how a caller specifies which card (e.g., id vs. name) when both are optional, nor does it describe default behavior when no setCode/version is provided. This is a notable gap for a tool with four optional parameters.

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?

With schema description coverage at 0%, the description carries the burden. It explicitly explains setCode (specific printing) and lists size/version options (small, normal, large, png, art_crop, border_crop, etc.), which appear to map to the 'version' parameter. However, it does not explain 'id' or 'name' parameters, nor does it clearly connect the 'size' list to the schema's 'version' field, leaving some ambiguity about which parameter controls which aspect.

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

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

The description opens with 'Fetch a card's image,' a specific verb+resource pair that clearly states the primary action. It distinguishes itself from siblings like get_card (card data) and get_card_printings (printing list) by focusing on the image retrieval and display. The optional setCode and size details reinforce the scope.

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 usage ('Fetch a card's image') but does not explicitly contrast with alternatives or state when not to use it. It provides guidance on how to display the result (as a content block) and warns against custom HTML, but these are post-fetch behaviors rather than tool-selection criteria. No direct comparison to sibling tools is offered.

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 readOnlyHint already signals safety, and the description adds behavioral context by emphasizing 'EVERY' printing and enumerating output fields (set, rarity, artist, finish, collector number). This goes beyond the annotation, though it does not mention potential response volume or ordering.

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 primary action and followed by a brief alternative reference. Every clause earns its place, with no redundant or filler 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?

The tool is simple, has an output schema, and safe read-only annotations. The description explains what the tool does, when to use it, and what to expect, making it complete for this complexity level.

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 0% for three optional parameters, and the description provides no guidance on how to select or prioritize id, name, or slug. The phrase 'of a card' is the only hint, which is insufficient for understanding parameter semantics.

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: 'List EVERY printing of a card' with concrete fields in parentheses. It explicitly distinguishes itself from get_card, which returns a short summary, making the tool's unique purpose unmistakable.

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

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

It provides explicit when-to-use guidance: 'get_card already returns a short printings summary, so reach for this only when the full list is the point.' This names the alternative and sets a clear exclusion condition, which is exactly what this dimension asks for.

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 declare readOnlyHint=true, and the description adds context about the rulings being official Wizards content with dates, and emphasizes the risk of hallucination. This goes beyond the annotation by describing the nature of the data and the recommended quoting behavior, though it doesn't detail the exact response structure (covered by 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?

The description is two sentences, front-loaded with the purpose, and every sentence earns its place: the second provides guidance and sibling differentiation. No waste.

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 read-only tool with one parameter and an output schema, the description covers purpose, usage, alternatives, and a critical caution about hallucination. It is complete for the agent to select and invoke the tool correctly.

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

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

The schema has one parameter 'name' with no description (0% coverage). The description implies 'name' is the card name by saying 'for one card', but it doesn't specify exact naming requirements or format. It adds some meaning beyond the bare schema, but could be more explicit.

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 tool fetches official Wizards rulings for a single card with dates, using a specific verb and resource. It also distinguishes this tool from search_rules for general mechanics, making it unique among 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?

Explicitly tells when to use this tool (any 'how does this card actually work' question) and when not to (general mechanics, use search_rules instead). It also provides a usage caution to quote rulings rather than paraphrase from memory.

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 readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral detail: exact matching, inclusion of lettered subrules (e.g., 601.2a-i), and that it returns the full context. This goes beyond the annotation without contradicting it.

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

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

The description is two sentences, front-loaded with the verb and resource, and includes an illustrative example. No redundant or repetitive wording.

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 single-parameter read tool with an output schema and strong annotations, the description covers purpose, usage context, parameter semantics, and behavior fully. It is clear enough for an agent to select and invoke it correctly.

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

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

The input schema has no description for the 'ref' property, so the description carries the burden. It does so well by specifying the exact rule number format and giving an example. However, it could have been slightly more explicit about accepted formats (e.g., whether subrule references are also accepted).

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 tool fetches a Comprehensive Rules entry and its lettered subrules by exact number, with a concrete example. This distinguishes it from search_rules and other siblings by emphasizing exact-number lookup and full-context retrieval.

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

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

It explicitly says 'Use after search_rules to read a rule's full context,' providing a clear workflow context and an alternative tool. It does not enumerate exclusive when-not cases, but the sequential guidance is enough for typical use.

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 set readOnlyHint=true, and the description adds valuable context beyond that: the authentication method (X-API-Key or Authorization Bearer), the expected output content (counts, copies, source), and the fact that this is only a summary, not detailed card data. No contradiction with annotations.

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

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

The description is extremely concise—two sentences that front-load the primary purpose, then clarify when not to use the tool, and finally provide authentication details. Every sentence earns its place with no superfluous 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?

Given that the tool has no parameters and an output schema exists, the description is fully complete. It covers the exact summary metrics, directs users to appropriate sibling tools, and explains authentication requirements—nothing critical 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?

The tool has zero parameters and the schema coverage is complete, so the baseline score of 4 applies. The description does not add parameter-specific details, but none are needed since there are no parameters.

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 tool's function: summarizing the user's imported collection with specific metrics (distinct cards, total copies, import source). It also explicitly distinguishes itself from sibling tools by saying 'This is the SUMMARY only' and pointing to search_my_collection and what_can_i_build for other operations.

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

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

The description provides explicit when-to-use and when-not-to-use guidance. It states to use search_my_collection for individual card lookup and what_can_i_build for commander rankings, and it gives the API key requirement for invoking the 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?

Beyond the readOnlyHint annotation, the description discloses the exact deterministic signals returned, the bracket floor, the rubric, and the fact that the tool is intentionally incomplete—requiring the agent to complete the assessment. This goes well beyond annotations, revealing the tool's role and limitations.

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, then dense with high-value behavioral details. No filler or redundancy. The structure flows logically: what it does, what it returns, what the agent must do.

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

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

The description fully captures the tool's scope: its inputs are implicit but the behavior and output are thoroughly described. It even tells the agent the next steps (checking combos, weighing soft signals). With an output schema present, return format is covered. Only parameter semantics are weak, but that is captured in a separate dimension.

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

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

The description makes no mention of the 'cards' or 'commander' parameters, leaving all meaning to the schema. With 0% schema description coverage, the agent receives no guidance on how to format the deck input or whether commander is optional. The description fails to compensate for the schema's lack of examples.

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 begins with a specific verb-resource pair: 'Assess a Commander deck's official WotC bracket (1-5).' It clearly distinguishes this from siblings like deck_stats or find_combos by focusing on deterministic signals and the official decision tree. The purpose is unambiguous and specific.

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

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

The description clearly implies the tool is used to start a bracket assessment, and it provides explicit context on how to proceed: the tool returns a floor and rubric, and the agent must finish the assessment by checking combos and soft signals. It does not explicitly state alternatives or exclusions, but the workflow is well-defined.

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?

Beyond the readOnlyHint annotation, the description discloses the return format ('Returns exact / not_found per name, with the canonical spelling and id for the ones that exist'), performance characteristics ('Cheap, batched'), and safety ('safe'). It also explains the input modes (names array or text decklist). No contradictions with annotations.

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

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

The description is a bit longer than minimal but every sentence adds value: core action, return info, usage guidance, rationale, efficiency, and input modes. It is front-loaded with the main action and remains structured. Could be tightened slightly, but there is no fluff.

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 a simple schema (2 optional params), an output schema present, and read-only annotations, the description provides sufficient context for an agent to know when and why to use the tool, what to expect in return, and how to invoke it. It covers both parameters and the tool's place in the broader workflow of validating Magic card names.

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 input schema provides no descriptions for the two parameters, so the description must compensate. It clarifies that 'names' is an array of card names and 'text' is a pasted decklist, and that either can be accepted. While it doesn't detail text decklist format or edge cases, it gives meaningful semantics beyond the bare schema types.

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

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

The description clearly states a specific verb ('Check') and resource ('card names') with a clear scope ('in bulk'). It distinguishes itself from siblings by focusing on validation of real card names, returning canonical spelling and id, while siblings like get_card or search_cards serve different purposes. The phrase 'the most common failure in Magic assistance is confidently naming cards that do not exist' underscores its unique role.

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

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

The description explicitly tells agents to 'Call this reflexively before presenting any decklist or card recommendation you generated' and notes it is 'safe to call on every card you are about to mention.' It provides strong when-to-use context but does not mention alternative tools or any when-not-to-use scenarios, so it falls just short of a 5.

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

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

The annotations already provide readOnlyHint=true, so the read-only nature is known. The description adds valuable behavioral context by stating that it searches every Magic card and that limit defaults to 25 and caps at 100. This goes beyond the annotations without contradicting them.

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 four sentences long, front-loaded with the core purpose, and every sentence contributes meaningful information. There is no fluff or repetition of schema details.

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

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

An output schema exists, so return value details are handled elsewhere. The description covers the tool's scope, filter types, limit behavior, and provides clear alternatives. It is sufficiently complete for an agent to use the tool effectively, with only minor omissions like supertypes.

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?

With 0% schema description coverage, the description compensates by naming the primary filter categories: colors, color identity, types, mana value, format legality, and sets. It also explains limit behavior. However, supertypes is not explicitly mentioned, and the types/supertypes distinction is left implicit, which is a minor gap.

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 tool finds cards by name or structured filters, enumerating filter categories such as colors, types, mana value, and format legality. It distinguishes itself from sibling tools like semantic_card_search and find_synergies, so the agent knows exactly what this tool does.

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

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

The description gives explicit usage guidance, stating to use this tool when queries can be expressed as filters, and directs to semantic_card_search for effect-based queries, find_synergies for pairing with existing cards, and search_my_collection to limit to owned cards. This is exemplary decision support.

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?

Beyond the annotations (readOnlyHint=true, openWorldHint=false), the description adds key behavioral details: 'Returns at most 100 owned cards per call, with the full match count in `total`' and 'Requires a free API key (send it as "X-API-Key: <key>" or "Authorization: Bearer <key>")'. This is valuable context that annotations alone do not provide. No contradiction is present.

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

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

The description is three sentences long, front-loaded with the core purpose, and every sentence earns its place—scope, alternative, result limits, and authentication. There is no fluff or 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?

The description covers ownership scope, search criteria, the primary use case, return limits, count behavior, and authentication. Since an output schema exists, the return structure is already documented. The tool is a straightforward search; all necessary context is present in a concise and complete manner.

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 input schema has no descriptions (0% coverage), so the description must compensate. It explains the meanings of colors, types, and notInDecks explicitly, but leaves `query` and `limit` to inference. The 'at most 100' limit is mentioned but not tied to the `limit` parameter. Overall, it adds significant meaning to the key parameters despite not covering all five.

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 tool's specific function: 'Search only the cards the user OWNS' and lists search criteria (name, colors, type). It also distinguishes from sibling search_cards ('Use search_cards instead to search every Magic card regardless of ownership'), so there is no ambiguity about its unique 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?

Explicit guidance is provided: 'Use search_cards instead' for global searches, and the notInDecks parameter is explained with a concrete use case ('what is sitting idle in my binder'). This tells the agent exactly when to use this tool and when to choose an alternative.

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?

Beyond the readOnlyHint annotation, it reveals the semantic nature of the search and instructs the agent to 'answer FROM the returned chunks and cite rule numbers', which is important behavioral context. No contradictions.

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, no fluff; the first sentence states purpose, the second provides usage and parameter guidance.

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

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

The description is complete for a search tool: purpose, usage, param guidance, and output expectation are covered. The limit parameter is not addressed, but output schema likely covers it.

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 descriptions are absent, but the description explains the kinds parameter with specific values and their intended use cases, providing meaningful guidance. Query and limit are left to schema/defaults, which is acceptable for obvious params.

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 action ('Semantic search') over a specific resource ('Magic Comprehensive Rules, glossary, and 84k card-specific rulings'), which clearly distinguishes it from siblings like get_rule or get_card_rulings.

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

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

The description explicitly says 'Use for any rules/interaction question' and provides filter guidance for kinds ('ruling' vs 'rule'/'glossary'). However, it does not explicitly state when not to use it or mention alternative 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?

The description adds meaningful behavioral context beyond the readOnlyHint annotation: it discloses that this is a vector search (not exact), that it handles natural language effect descriptions, and that limit defaults to 10 and caps at 100. This extra detail helps the agent set expectations and call the tool correctly.

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 compact and front-loaded with the purpose, followed by examples and alternatives. Every sentence adds value, including the limit behavior note. There is no wasted wording.

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 core purpose is well covered, but the presence of filter parameters (colors, types, mana value) contradicts the advice to use search_cards for structured filters, leaving an unresolved gap. Since an output schema exists, return values are not needed, but the param interaction should be clarified for full contextual completeness.

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 0%, so the description must compensate. It explains the `limit` parameter (default, cap) but says nothing about the other six parameters (types, colors, format, manaValueMin/Max). The claim 'Use search_cards instead for structured filters' even implies these parameters aren't meant for this tool, deepening the confusion about what they do.

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 tool does vector search over card text for semantic effect descriptions, with concrete examples. It explicitly distinguishes itself from search_cards and find_synergies, making its unique purpose unmistakable.

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

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

It gives explicit when-to-use guidance ('when an effect cannot be written as a filter') and names alternatives directly: 'Use search_cards instead for structured filters' and 'Use find_synergies instead when the user names specific cards.' This is exactly the kind of decision support an agent 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?

Beyond the readOnlyHint annotation, the description discloses critical behavioral nuances: the two-phase dependency on `strategy`, the fact that cuts are theme-alignment based rather than card-quality based, and the pricing source (Card Kingdom/TCGplayer). This helps the agent set expectations about output semantics and usage sequence.

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 compact (four sentences) and front-loaded with the main purpose. Each sentence adds critical information: what it does, the two-phase requirement, the semantics of cuts, and the price source. No redundancy or filler.

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

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

The description covers the core workflow (two-phase) and clarifies important behavioral aspects, but with 9 parameters and several sibling tools, it could helpfully explain more about how parameters like `ownedOnly` or `maxAdds` affect results. The presence of an output schema reduces the need to explain return values, so this is not a major 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?

The description explicitly references the `strategy` parameter and the optional `budget`, and implicitly covers `cards`. However, it does not explain `maxAdds`, `maxCuts`, `commander`, `ownedOnly`, or `maxCardPrice`. With 0% schema coverage, these missing parameter explanations create gaps, though the parameter names provide some self-evident meaning.

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

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

The description opens with 'Suggest priced deck upgrades: cards to add and cards to cut,' which is a specific verb-action statement. It clearly distinguishes from siblings like rate_deck (ratings) and find_synergies (synergy detection) by focusing on actionable upgrade recommendations with pricing.

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 two-phase instruction ('first call WITHOUT `strategy`... then call again WITH your derived `strategy`') provides explicit workflow guidance. It explains the purpose of each phase and the relationship between them, though it does not name alternative tools or explicitly state when not to use this tool.

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

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

Annotations already declare readOnlyHint=true, but the description adds important behavioral context beyond annotations: it requires an API key for authentication, specifies how to send it, and explains that the tool reads the user's imported collection. It does not mention rate limits or error behavior but adds meaningful transparency about data source and auth.

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

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

The description is two sentences, front-loaded with the primary purpose, followed by a concise API key requirement with a URL. It is efficient, but the second sentence could be slightly more concise, and the informal 'what should I sleeve up tonight' adds color without critical information. Overall, it earns its place.

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

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

The tool has an output schema and is read-only, so the description need not detail return values. However, it leaves unexplained key input parameters (limit, missing) and does not specify what 'most nearly build' means precisely. The auth requirement and purpose are clear, but without parameter semantics, completeness is only average.

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 input schema has 2 parameters (limit, missing) with zero description coverage. The description does not mention or explain these parameters at all. Given the low schema coverage, the description should compensate but fails to clarify what 'limit' or 'missing' control, leaving their semantics entirely ambiguous.

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 tool's purpose: 'rank the Commander decks they can most nearly build right now' with 'the most-played cards they are still missing.' It distinguishes itself from siblings by focusing on deck suggestions from the user's collection, answering 'what should I sleeve up tonight'—a specific question different from card lookups, legality checks, or staples.

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

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

The description provides clear context for when to use the tool: 'Given the user's imported card collection' and 'from cards they physically have.' It implies use when a user wants deck recommendations based on their collection, but it does not explicitly contrast with sibling tools like 'upgrade_deck' or 'commander_staples,' so it lacks explicit exclusions.

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