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

With no annotations, the description carries the full behavioral burden and does well: it names an external dependency (Commander Spellbook), discloses the counting methodology, states the return semantics, and explicitly bounds the result as 'what the cards permit' rather than a power verdict. It stops short of noting cost, latency, or failure modes of the external lookup, which is the only remaining gap.

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

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

Front-loaded with the action, then methodology, then the caveat — a sensible order with no filler sentences. The closing 'Report it as…' line is arguably guidance for the agent's narration rather than tool behavior, but it earns its place given the misuse risk it prevents.

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 explanation is not owed, and the description compensates well for the absence of annotations by covering inputs counted, external calls, and the interpretive bound. The one substantive hole is the format of the 'deck' argument, which the schema leaves blank and the description never fills.

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% — the single required parameter 'deck' is typed only as a bare string with no title or description. The description gestures at the value ('a ManaPool deck', 'the card list') but never resolves whether the agent should pass a deck ID, a URL, or a raw pasted decklist, which is exactly the ambiguity that causes malformed invocation for a lone required field.

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 ('Check a ManaPool deck against the official Commander bracket criteria') and then enumerates exactly what it measures: Game Changers, mass land denial, extra turns, tutors, and Commander Spellbook combos. The output ('lowest bracket the card list mechanically permits') is concrete, and the function is clearly distinct from get_deck, search_decks, and price_deck.

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 rather than stated: an agent can infer this is the tool for bracket evaluation, but there is no explicit 'use this when…' clause, no mention of how to obtain the deck first (e.g., via get_deck), and no exclusion of alternatives. The second paragraph gives interpretive guidance about how to report results, which is useful but is not when-to-use routing.

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; it does disclose the payload contents (prices plus per-listing availability), which is genuine behavioral context. However it says nothing about authentication, rate limits, or what happens on ambiguous or unmatched card names.

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

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

One front-loaded sentence states purpose and scope, followed by a compact Args block that is warranted because the schema has no parameter descriptions. The example URL earns its space; there is minimal 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 single-parameter lookup with an output schema already covering return values, the description supplies everything needed to call it correctly: purpose, scope, and accepted input formats. Remaining unknowns (error behavior) are minor given the tool's simplicity.

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% for the single parameter, and the description compensates well by enumerating the three accepted identifier forms (card name, Scryfall id, ManaPool URL) and giving a concrete URL example. It does not state case sensitivity or name-matching tolerance, so it stops short of 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?

States a specific verb and resource ('Get one card's ManaPool prices and per-listing availability') and makes clear via 'one card' that it is a single-entity lookup, implicitly contrasting with the sibling search_cards. It doesn't explicitly name the sibling, so differentiation is left slightly to inference.

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

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

Usage is only implied: an agent can infer this is for fetching details on a known card rather than searching, but there is no explicit 'use this when...' or reference to search_cards as the alternative. No prerequisites or failure conditions are stated.

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

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait: include_types triggers extra requests and thus cost. It says nothing about failure modes for malformed ids, permissions, or rate limits, which leaves meaningful gaps for a network-backed fetch 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?

Front-loaded single-sentence purpose followed by a compact Args block. Every sentence earns its place; the Args formatting is slightly stiff but not wasteful.

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?

Output schema exists, so return values need no explanation, and the tool is simple with only two parameters. Both parameters and the main cost tradeoff are covered; only error/edge-case behavior is absent.

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 do the work, and it does: 'deck' accepts a full https://manapool.com/lists/<uuid> URL or the bare uuid, and 'include_types' resolves Scryfall type lines at extra request cost. This adds genuine meaning beyond the bare schema types, though it could say what happens if the id format is wrong.

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 a specific verb and resource: 'Fetch one ManaPool deck'. The word 'one' implicitly separates it from the sibling search_decks, but it never names that sibling or states the distinction explicitly.

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

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

Usage context is only implied by the request shape ('by URL or list id') and by the include_types note that it is 'useful for multi-type payoffs' but 'costs extra requests'. There is no explicit statement of when to reach for this instead of search_decks or audit_deck.

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 supplied, the description carries the burden and does reasonably well: it discloses the pricing rule (cheapest in-stock printing), the input tolerance (three list formats, blank lines and // comments ignored), and the caveat that results differ from pre-built deck carts. It omits what happens to cards with no in-stock printing and any error behavior, which keeps it from a 5.

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

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

The core purpose is front-loaded in one sentence, followed by a scoping caveat and a compact Args block. The three inline format examples earn their place by removing parsing ambiguity, though the prose repeats the list-format idea slightly across sentences.

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 explanation is not required, and the description covers input format, pricing basis, and the comparison caveat. The main residual gap is how unpriced or out-of-stock lines are reported, which matters for a pricing tool but is arguably visible in the output schema.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines decklist as newline-separated with concrete examples and ignored-line rules, and explains that commander is optional and 'priced and reported separately.' That is meaningful semantics well beyond the bare string types in the schema.

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

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

The description opens with a specific verb and resource: 'Price a decklist against ManaPool's live singles inventory.' It also distinguishes the result from ManaPool's pre-built deck cart totals, which separates it from the deck-oriented siblings (get_deck, search_decks, audit_deck). It stops short of explicitly naming a sibling tool it should be preferred over, so it lands at 4 rather than 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?

'Use this to budget a custom build' gives a clear positive use case, and the note about pre-built decks using a single seller's stock tells the agent when this estimate differs from other totals. There is no explicit when-not-to-use guidance or named alternative (e.g. use get_card for a single card), so it is clear context without 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?

With no annotations, the description carries the full burden and does disclose the key non-obvious behavior: the search executes on Scryfall and each hit is then priced from ManaPool /products/singles, with the reason (no name search in ManaPool's public API). It does not cover failure modes such as cards with no ManaPool price, which is the remaining gap.

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 core action is front-loaded in one sentence, parameters are grouped in a compact Args block, and the final paragraph explains the two-stage pipeline in two lines. No sentence is redundant.

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

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

An output schema exists, so return shape need not be described; the description covers query format, limit bounds, and the data-source pipeline. Minor incompleteness remains around unpriced results and whether results are paginated.

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, and it largely does: four concrete Scryfall query examples for `query` and an explicit 1-50 range for `limit` that the schema does not encode. It still doesn't clarify the default of 15 or what happens when limit is out of range.

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 ('Search cards') plus a second behavior ('price them against ManaPool stock'), which distinguishes it from get_card (single card) and price_deck (whole deck). It does not explicitly name a sibling to route away from, keeping it just below 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 Scryfall syntax examples show how to phrase a query, which is real usage guidance for the main parameter. However, it never states when to prefer this over get_card or search_decks, nor any prerequisites or exclusions, so the when-to-use dimension is only implied.

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 discloses important traits: bracket is an unverified generated tag, price filtering is done locally by walking pages, and a price window forces price-asc sorting. It does not discuss rate limits or permissions, but it covers the key operational quirks.

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, then each parameter is documented in a compact Args block with no wasted sentences. The length is justified by nine undocumented schema parameters and the critical behavioral caveats.

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 enough for a nine-parameter search tool: it documents filters, pagination, sorting interactions, and the local price-scan behavior, while the output schema covers return values. The main remaining gap is sibling-level routing guidance, which overlaps with usage guidelines.

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 document all nine parameters, and it does: commander, bracket, min_price, max_price, theme, colors, sort, page, and limit are each explained with examples, constraints, and interactions. It adds substantial meaning beyond the bare schema, including the price-basis and page-offset behavior.

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

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

The description gives a specific verb and resource: search ManaPool's pre-built Commander deck listings. It is clear what the tool does, but it only partially differentiates from siblings by referencing audit_deck, not get_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?

It gives one useful routing hint: use audit_deck before recommending anything when relying on bracket. However, it does not explain when to choose search_decks over get_deck or search_cards, nor does it 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.