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

No annotations are supplied, so the description carries the full burden. It does disclose the analysis outputs, how commanders are inferred, and that budget_per_card 'flags cards above that USD price', which is useful contextual behavior, but it never states that the tool is read-only/non-mutating, requires no auth, or has any cost/latency characteristics for a tool that also computes prices.

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 opening sentence front-loads the verb, resource and accepted input formats, with the report scope and the two parameter notes following compactly. It is dense but list-like and every clause contributes; only the parenthetical format list and the role examples add bulk.

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 the return shape need not be described (the enumeration is a bonus, not a requirement). However, the tool takes four parameters with zero schema documentation and the description leaves `format` entirely unexplained, leaving an agent unable to know which format strings are valid or how legality is determined.

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 — and it partially does: commanders (only needed if the list doesn't mark them) and budget_per_card (USD threshold that flags cards) are explained. The `format` parameter, which drives the entire legality section and defaults to commander, is never described or given its allowed values.

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 (analyse) and resource (a pasted decklist) plus the accepted input dialects, and enumerates the report contents (legality, mana curve, pips vs land, roles, template gaps, Game Changers, price), which makes its scope concrete and distinct from sibling card-lookup tools. It never names a sibling explicitly, so it stops short of a 5; the implicit overlap with price_decklist is left unaddressed.

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 a conditional instruction for one parameter ('Pass `commanders` if the list doesn't mark them'), which is real usage guidance, but nothing tells the agent when to reach for analyze_deck over price_decklist or the EDHREC/search tools. Usage is only implied by the enumeration of report contents.

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?

With no annotations, the description carries the full behavioral burden, and it does disclose two useful traits: a result cap of 20 and fuzzy matching for misspelled input, plus an implicit guarantee of 'real' (non-hallucinated) names. It does not state that the operation is read-only or describe ordering, empty-result behavior, or rate limits.

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

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

A single, front-loaded sentence that conveys purpose, limit, and input type with zero wasted words. Ideal structure for a simple tool.

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 the low complexity, the presence of an output schema (so return values needn't be explained), and no annotations, the description covers the essentials for correct invocation. The main remaining gap is tying this tool to the sibling search_cards, which is a routing concern more than a completeness one.

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% and the single 'partial' parameter has no schema description, so the description must compensate. It does define the expected input as 'a partial or misspelled name', which adds real semantic value beyond the bare type, but omits constraints like minimum length or case sensitivity.

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 ('Suggest'), resource ('real card names'), scope ('up to 20'), and input trigger ('partial or misspelled name'). It clearly conveys the tool's function, though it never explicitly contrasts itself with the sibling search_cards, which is the most likely alternative for name lookups.

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 phrase 'for a partial or misspelled name', giving the agent a clear triggering condition. However, it provides no explicit when-to-use versus search_cards guidance and no exclusions, leaving the routing decision partly to inference.

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?

With no annotations, the description carries the full burden, but it only discloses the shape of the returned data (commanders, co-played cards) rather than behavioral traits such as caching, rate limits, or whether the lookup is a pure read. For a low-risk data lookup this is acceptable but thin.

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 colon-structured sentence that front-loads the resource and enumerates the return content with zero filler. Every clause 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 is simple (one param) and has an output schema, so return values need not be explained. The remaining gap is the absence of any routing guidance against the closely related edhrec_recommendations sibling, leaving selection ambiguous.

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

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

Only one parameter ('name') with 0% schema description coverage; the phrase 'for a card' implies the parameter is a card name, adding minimal meaning. It does not clarify accepted formats (exact name vs fuzzy, set/printing disambiguation) that an agent would need.

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 clear resource (EDHREC data for a card) and names the two concrete outputs (most-played commanders, commonly co-played cards), so an agent knows what it returns. It does not, however, differentiate itself from the sibling edhrec_recommendations, which reads as a near-overlapping EDHREC endpoint.

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

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

No when-to-use guidance is given, and no alternatives are named despite an obvious sibling (edhrec_recommendations) covering adjacent EDHREC data. The agent must guess which EDHREC tool to pick.

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?

With no annotations, the description carries the full burden, and it does disclose real behavior: cards already in a supplied decklist are removed so results are suggested adds, themes must come from the returned `themes` list, and each card reports inclusion % and synergy % with definitions. It omits auth, rate-limit, caching and pagination behavior, which are not obvious 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?

The one-line purpose is front-loaded and the four bullets each carry distinct information without repetition. The trailing sentence about inclusion % and synergy % is worthwhile, though the definition could be trimmed slightly without loss.

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 covers the return shape, so the description need not explain results, and the card-metric sentence is a bonus. Against 7 parameters at 0% schema coverage and a meaningful `partner`/`per_list` surface, the missing semantics for those arguments is the main gap.

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

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

Schema description coverage is 0%, so the description is the only source of parameter meaning, and it covers theme, budget, decklist and categories with useful detail (theme examples, 'budget'/'expensive' variants, tag names). It says nothing about partner, per_list (default 15), or the commander argument itself, leaving 3 of 7 parameters unexplained.

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 opening sentence states a specific resource (EDHREC recommendations for a commander) and enumerates what the result contains: high-synergy cards, top cards, and per-type lists. It is materially clearer than the bare tool name, but it never differentiates itself from the sibling edhrec_card, so an agent must guess which EDHREC tool to pick.

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 bullets explain what each option does (theme, budget variant, decklist subtraction, category restriction), which implies when to set each one. However there is no explicit when-to-use guidance relative to alternatives like edhrec_card, analyze_deck, or search_cards, and no note on required inputs beyond 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful scope behavior (results include off-deck combos requiring a different commander or added colors) and names the data source, Commander Spellbook, but says nothing about rate limits, auth, or result ordering. Given zero annotation coverage, more disclosure is expected.

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 primary function and followed by the supplementary result scope. No padding or repetition; the trailing enumeration 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?

An output schema exists, so return values need no explanation, and the description adequately frames what kinds of combos come back. However, for a 3-parameter tool with 0% schema coverage, the missing parameter guidance leaves the definition short of what an agent needs 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 0% across three parameters, so the description must compensate and does not. It never explains the decklist format, what the commanders parameter is for (nor why it is separate from decklist), or what include_steps changes about the response.

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

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

States a specific verb+resource (find combos in a deck) and enumerates three result categories: already-present combos, one-card-away combos, and combos enabled by a different commander or added colors. It does not explicitly differentiate itself from sibling search_combos, which is the obvious adjacent 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?

Usage is implied by the deck-centric framing, but there is no explicit when-to-use statement, no prerequisites, and no named alternative (search_combos, analyze_deck) with the condition that would select it. An agent can infer the intent but must guess at the boundary.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that matching is fuzzy by default and lists returned fields, but it says nothing about failure behavior (card not found), ambiguity when multiple cards match a partial name, or case sensitivity, which matters for a lookup tool.

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 core action and the key behavioral caveat (fuzzy default), then the return payload. 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?

An output schema exists so explaining return fields is not strictly required, and the description is broadly sufficient for the happy path. However, with zero schema coverage it should have covered `exact` and `set_code`, and offered at least a hint about ambiguous or missing matches.

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% and the description only addresses the `name` parameter via the fuzzy-matching note. The `exact` toggle and `set_code` filter are never mentioned, leaving two of three parameters undocumented in both schema and prose.

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 ('look up one card by name') and the scope 'one card' implicitly distinguishes it from the list-oriented search_cards sibling. It does not explicitly name any sibling to contrast with, so it falls 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 only implied: the fuzzy-by-default note hints at when this lookup is appropriate (misspellings, partial names), but there is no explicit when-to-use or when-not-to-use guidance and no mention of alternatives like search_cards or autocomplete_card_name.

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?

No annotations are provided, so the description carries the full burden. It does disclose useful traits: result ordering (cheapest first) and that each printing includes set and USD price, which is the key behavioral fact. However it says nothing about the default result cap, pagination, or what happens for a name with no printings.

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 resource and ordering, then the use case. Every clause earns its place with 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?

An output schema exists, so return values need not be detailed, and the description still summarizes them briefly. But with no annotations and zero parameter documentation, the omission of the limit/truncation behavior leaves a real gap for a tool that returns a variable-length list.

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 explain the two parameters, and it does not. `name` is only implied as the card identifier and the `limit` parameter (default 15) is never mentioned, leaving an agent to guess whether results are truncated.

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 (every printing of a card) and its ordering (cheapest first) plus the data returned (set and USD prices). That distinguishes it from get_card and search_cards, though it never names a sibling explicitly, so it stops short of a 5.

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

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

"Useful for budget builds" implies a usage context for price-comparison shopping, but there is no explicit when-to-use/when-not guidance nor any reference to the alternatives (get_card, search_cards) that an agent might otherwise pick. Usage is inferable but not 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?

With no annotations provided, the description carries the full behavioral-disclosure burden. It identifies the content returned, but does not state that this is a safe read-only retrieval, mention rate limits or permissions, or otherwise describe operational behavior.

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, front-loaded sentence with no wasted words. It states what the tool returns and the extra oracle-text context efficiently.

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 one-parameter retrieval tool with an output schema, the description is mostly sufficient about purpose and content. However, it omits usage routing and parameter format details, and with no annotations it leaves behavioral context unaddressed.

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 the single required parameter, so the description must compensate. It only implies a card is required via 'for a card'; it does not specify that the parameter is a card name, whether exact spelling is required, or any format expectations.

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

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

The description states a specific resource and scope: official rulings and Gatherer notes for a card, plus oracle text. This is clear enough for an agent to know what the tool returns, though it does not explicitly distinguish itself from siblings like get_card or search_cards.

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

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

No when-to-use guidance is given. The description implies it is for rulings, but it never says when to choose this over get_card or other sibling tools, nor does it state any prerequisites or 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses output ordering and USD pricing, but does not explicitly state read-only safety, authentication needs, rate limits, or error behavior. 'Price check' implies read-only, but that is inferential rather than stated.

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 front-loaded sentence with no filler. Every phrase adds useful scope or output context.

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 and an output schema exists, so return values do not need full explanation in the description. However, the required decklist format is left unspecified and no usage alternatives are given, leaving an agent to guess for the one required input.

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 required 'decklist' parameter has 0% schema description coverage. The description only says 'of a decklist' and does not define the expected format (e.g., plain text, Arena, MTGO), so it does not compensate for the missing schema documentation.

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

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

States a specific verb and resource ('price check of a decklist') and adds scope details: per-card USD price, total, and ordering. Clear what the tool does, but it does not distinguish itself from siblings such as analyze_deck or search_cards.

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 names no explicit when-to-use, when-not-to-use, or alternative tools. 'Quick price check' implies a use case, but it does not help an agent choose this over analyze_deck or get_card.

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?

With no annotations provided, the description carries the full behavioral burden. It discloses that the query is optional and gives a Scryfall query example, but omits key behavioral details such as authentication needs, rate limits, or handling of empty results, leaving the agent with incomplete operational context.

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 that states the core purpose and optional restriction without any wasted words. It is appropriately sized for the tool's simplicity.

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 the tool's simplicity, one optional parameter, and the presence of an output schema, the description is nearly complete. It covers the what and the parameter's role, though the absence of usage guidance leaves a minor gap.

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

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

Schema coverage is 0%, so the description must compensate. It does this effectively by explaining that the parameter is an optional Scryfall query and by providing an example ('is:commander id:ur'), which adds meaningful semantics beyond the bare schema. Some syntax coverage is still missing, preventing a 5.

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 identifies the resource ('A random card') and its optional scope ('restricted by a Scryfall query'), distinguishing it from siblings like search_cards or get_card by emphasizing randomness. However, it does not explicitly name or contrast with alternative tools, so it falls 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?

The description offers no guidance on when to use this tool versus alternatives such as search_cards or get_card. While the purpose implies usage, there is no explicit context, condition, or exclusion to help an agent select 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?

There are no annotations, so the description carries the behavioral burden. It discloses some behavior (order='edhrec' sorts by Commander popularity, detail='full' includes oracle text), but omits limit defaults, pagination, result scope, and rate-limit/auth considerations.

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 purpose is front-loaded, examples are compact, and supplemental notes are brief. The syntax URL is long but earns its place by providing the full query language reference.

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 an output schema present, return values need not be explained, and the description gives strong query-syntax guidance. However, because schema descriptions are 0% and annotations are absent, it is incomplete for limit/direction semantics and sibling selection.

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% across 5 parameters. The description meaningfully explains the query parameter's syntax and gives examples, and partially covers order and detail, but limit and direction are entirely undocumented, including their defaults and effects.

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

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

States a specific verb and resource ('Search cards') and identifies the supported syntax family ('full Scryfall syntax'). It does not explicitly differentiate from siblings like get_card or autocomplete_card_name, so it is clear but lacks sibling routing.

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?

Examples and notes imply how to search, and mentions of order='edhrec' and detail='full' give useful context. However, it never says when to use this tool versus get_card, autocomplete_card_name, or random_card, nor does it state exclusions or prerequisites.

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?

No annotations are provided, so the description carries the full burden, and it does disclose one real behavioral trait beyond the schema: results are sorted by popularity. It says nothing about result limits beyond the default, pagination, or whether the search is case/format sensitive, so the disclosure is partial.

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, purpose first, then concrete examples. No filler. Slightly terse given the untyped query format, but well front-loaded.

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

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

An output schema exists so return values need not be described, and the query examples cover the hardest part of invocation. Gaps remain around sibling differentiation (find_combos) and the undocumented limit parameter, so it 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 description coverage is 0%, so the description must compensate, and it does provide meaningful query-syntax examples (`card:"Thassa's Oracle"`, `result:"infinite mana" id<=bg`, `cards=2`). The limit parameter and the overall bounds/max of limit are left entirely undocumented.

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

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

States a clear verb+resource ('Search Commander Spellbook combos') plus ordering behavior ('most popular first'), so the agent knows exactly what the tool returns. However, it never distinguishes itself from the sibling find_combos, which appears to be a plausibly overlapping combo-retrieval 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?

The query-syntax examples imply how to use the tool but there is no explicit when-to-use guidance, no when-not-to-use, and no reference to find_combos or other siblings. Usage is inferred rather than stated.

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