POKEKA — Pokémon Card Prices

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

Annotations already indicate read-only, non-destructive behavior. The description adds value by detailing the exact output (PSA/CCIC populations, gem rate, scarcity tier), which goes beyond the annotations and helps the agent understand what to expect.

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 sentence that front-loads the core purpose ('Graded population for one card') and efficiently lists the specific data points. No redundant information.

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 tool with an output schema (mentioned in context), the description sufficiently covers the key output fields. It does not need to explain return values further, and the lack of error handling notes is acceptable.

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

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

Schema coverage is 100%, with the parameter description already specifying where to get the card_id. The tool description adds no further parameter context, so it meets the baseline but does not exceed it.

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

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

The description clearly states the tool provides graded population data for one card, including specific grade breakdowns for PSA and CCIC, gem rate, and scarcity tier. This distinguishes it from sibling tools like card_price and get_market_brief, which focus on different aspects.

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?

While not explicitly stating when to use or avoid this tool, the description implies it is for population data on a specific card. The sibling list and the tool name help differentiate, but explicit comparative guidance would boost clarity.

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 key behaviors: prices are derived from verified median sales, never listings or interpolations; there is no grade fallback; price_status values like 'reference_only' and 'card_not_found' are defined; market-specific pricing for Japanese and Simplified-Chinese cards is explained. This substantially exceeds what annotations alone provide.

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 long but every sentence carries operational weight: trigger conditions, return contents, grade-combination semantics, status codes, and market separation all in one dense block. It is front-loaded with the main use case and then builds logically into edge cases.

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 complexity — multiple grades, companies, markets, price_status values, and a policy of no fallback — the description is remarkably complete. It covers not-found behavior, low-confidence quoting, raw-card handling, and cross-market differences, leaving no obvious gap for an agent 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?

The schema already documents all four parameters with 100% coverage, so the baseline applies. The description adds useful combinatorial guidance — 'Pass company + grade to price a specific grade' — and clarifies that condition='raw' will not return a graded price, reinforcing the schema's semantics without contradicting it.

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

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

The description opens with a specific use-case trigger ('asks what a card is worth, its PSA 10 / PSA 9 / CCIC 10 price, current market value') and names the exact resource. It clearly distinguishes this from siblings like card_price_history by emphasizing a current-value snapshot with a per-grade ladder, not historical price movement.

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 states when to use the tool ('Use when the user asks...') and adds guidance for grade-specific requests and raw-card requests. It does not explicitly name alternatives or state when NOT to use it, but it gives enough contextual cues to route an agent correctly.

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?

Adds context beyond annotations: weekly median, representative grade, conditional change percentages. Annotations already indicate read-only and non-destructive, so description focuses on data specifics.

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?

Single sentence, front-loaded with key information, no redundancy.

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?

Adequately describes output and conditionality. Could clarify how representative grade is determined, but overall sufficient for a historical data retrieval tool with an 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 coverage is 100%, so baseline 3. Description does not elaborate on parameters beyond what schema provides, but adds context about data output.

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?

Description clearly states it provides weekly median price series for one card with up to 26 weeks and change percentages. It distinguishes from siblings like card_price and recent_sales.

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?

Implies usage for one card's historical prices, and notes change percentages are conditional on statistical confidence. Lacks explicit when-not-to-use or comparison to siblings.

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 readOnly/openWorld/destructive annotations, the description adds a crucial behavioral caveat: 'Absence of flags is not a clearance; coverage is curated and growing.' It also discloses exact-match nickname behavior and lists the informational components returned, giving the agent important expectations beyond the 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 compact: it front-loads the core content list, then explains the input options, and ends with an important safety caveat. Every sentence earns its place, with no redundant repetition of schema or annotations.

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 what the tool returns, how to address a card (card_id or exact nickname), and the key caveat about coverage. An output schema is present, so return-value detail is not required. For a read-only contextual lookup tool, nothing essential is missing 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 schema already covers both parameters with descriptions, so the baseline is 3. The description adds value by providing concrete example nicknames ('凡高皮', '金拱门') and explicitly emphasizing that the query must be an exact community nickname or alias, which is not fully stated in the schema descriptions.

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 ('get'), a clear resource ('one card'), and enumerates specific content: nicknames, counterfeit-risk flags with self-check steps, holder-turnover tier, and a context note. It distinguishes itself from price-only siblings by explicitly saying 'beyond the price' and by naming card-level rather than market-level 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 clearly implies when to use this tool: when you need non-price context around a specific card. However, it does not explicitly mention alternatives or when not to use it, such as comparing this with slang_lookup for nickname resolution or card_price for price-only queries. The usage signal is present but left 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?

The description adds significant behavioral context beyond annotations: it clarifies the index is 'fixed-basket same-card index (never vibes)', states it's 'not investment advice', and lists specific output components (phase read, peak/drawdown, sale counts, calendar). Annotations only declare readOnlyHint and non-destructive, so description bears full burden and does so well.

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, well-structured sentence that front-loads the core purpose and packs all key details without extraneous words. Each clause adds value.

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

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

Given the tool has only one optional parameter and an output schema exists, the description covers all necessary behavioral and output context. It lists the key outputs (phase read, index, peak/drawdown, sale counts, calendar) and notes 'not investment advice', which is complete for an agent to understand and invoke correctly.

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

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

Schema coverage is 100% for the single parameter (market enum with description). The description mentions 'per language track (all / en / ja)' but omits zh-cn from the schema. This adds no new meaning beyond the schema; baseline 3 applies.

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 provides a market cycle phase read, index values, peak/drawdown numbers, sale counts, and an event calendar. It specifies the scope (graded-Pokémon market per language track) and distinguishes from sibling tools like market_movers and market_volume_leaders.

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 use for obtaining a high-level market overview with specific metrics, but doesn't provide explicit guidance on when to use this tool versus alternatives like market_movers or market_volume_leaders. No when-not-to-use guidance.

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 establish the read-only, non-destructive nature. The description adds useful behavioral context beyond that: it is catalog-only, excludes per-card pricing, and details which statistics are included. This gives agents a good sense of what the tool will and will not return.

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 front-loaded with the core purpose and delivered in a compact format. The bilingual sentence is somewhat redundant for an AI agent, but it is short and does not meaningfully hurt clarity or scannability.

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 output schema, the annotations, and the schema-covered parameters, the description provides everything needed for correct tool selection and invocation. It covers scope, accepted identifiers, use cases, and the boundary against price tools.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The additional text mostly echoes the schema by mentioning accepted set_code formats, and does not substantially enrich parameter meaning beyond that baseline.

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: it returns whole-set statistics and a card checklist for one Pokémon TCG set. It differentiates itself from sibling tools by explicitly saying it is catalog data only and directing per-card price questions to card_price.

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 concrete use examples ('how many cards / SR cards are in 151c') and explicitly routes price-related questions to card_price. It also advises against card-by-card searching for set-level statistics, giving an agent clear when-to-use and when-not-to-use signals.

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 mark the tool as read-only and non-destructive, and the description adds substantial behavioral detail beyond that: liquidity gates, the ±40% cap, median consistency checks, real same-card/same-grade moves, and a 20-card limit. This meaningfully informs the agent about result trustworthiness and constraints.

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 dense but every sentence earns its place: use case, parameter semantics, data quality rules, and row meaning all appear without repetition. The critical usage guidance is 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?

Given the annotations, rich input schema, and output schema, the description fully covers when to invoke the tool, what each parameter means, what guarantees each row has, and the result limit. Nothing required for correct invocation is missing.

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

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

Schema coverage is 100% and all parameters have enums, so the schema already does the heavy lifting. The description still adds value by clarifying defaults, the meaning of direction/window, and the 'market tracks never mix' constraint.

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 use case: identifying Pokémon cards that are rising or falling, hot, or making the biggest moves. This clearly names the resource (card movers) and distinguishes the tool's function from generic price or market brief tools.

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 when to use the tool ('Use when the user asks which Pokémon cards are rising or falling...') and covers the main intent variants. It doesn't explicitly name alternatives or when not to use it, but the usage context is clear enough.

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 indicate readOnlyHint=true, and the description adds that windows anchor to latest sale date and that median_usd is a mixed-grade reference, preventing misinterpretation. 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?

Three sentences with clear structure, no fluff. First sentence covers purpose and filters, second window behavior, third clarifies data usage.

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 output schema exists, the description covers all needed: filters, window anchoring, max limit, and provides warning on median_usd use. No missing critical information.

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 covers all parameters with enums and descriptions. The description adds context: window anchoring, the meaning of PSA10, and the mixed-grade caveat for median_usd beyond 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 states 'Most-traded graded Pokémon cards by verified sales count over a 24h / 7d / 30d window', which clearly defines the verb (list leaders) and resource (traded cards). It distinguishes from siblings like card_price and market_movers by focusing on volume and verified sales count.

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 specifies filters (language, grade_company) and explains window anchoring behavior. It also advises using card_price for precise per-grade quotes, providing an alternative. However, it doesn't explicitly exclude other tools like market_movers or recent_sales.

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 readOnlyHint and destructiveHint annotations, the description adds valuable behavioral context: sales are 'real completed transactions, not listings', and they span US, Japan-domestic, and Chinese marketplaces. This authenticity and scope detail helps the agent understand the tool's limitations and reliability.

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: first sentence conveys core purpose and output fields, second adds geographic scope and data authenticity. Information is front-loaded and every word contributes.

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 output items (up to 10, date, grading, price, marketplace), geographic scope, and data authenticity. It does not explicitly state ordering (presumably most recent first), which is a minor gap. With an output schema present, the return structure is already 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?

Schema description coverage is 100% for the single required parameter card_id. The tool description repeats the same guidance ('from search_card / slang_lookup') as the schema, adding no new meaning. At baseline, with full schema coverage, a score of 3 is appropriate.

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 specifies the verb (get/recent sales) and resource (sales for one card), includes details about output fields (date, grading, price, marketplace), and implies it retrieves recent vs historical data. It distinguishes from siblings by focusing on recent sales rather than price history or population, which are covered by card_price_history and card_pop.

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 states it provides 'most recent verified sales for one card (up to 10)', giving clear context for when to use. However, it does not explicitly mention when not to use or list alternative tools like card_price or card_price_history for other use cases.

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 mark this as read-only and non-destructive; the description adds meaningful behavior beyond that: a 10-result cap, the set-level fallback with guidance, the requirement to use card_id with other tools, and the guarantee that language tracks are never mixed. 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 front-loaded with query types and examples and remains organized across output limits, set behavior, and language filtering. The Chinese sentence partly restates the English content, but it is short and serves the bilingual user base.

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 output schema and annotations, the description covers everything needed: accepted query formats, result count, key returned fields, how to chain card_id into other tools, the set-only edge case, and language track behavior. No critical calling context is missing.

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

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

Schema coverage is 100% for both parameters, and the description still adds substantial value: concrete syntax examples ('sv8a 喷火龙', 'CEL 4'), bare set-code handling, and the semantics of the lang filter. This is well beyond what the schema alone provides.

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 pair ('Search graded Pokémon cards') and enumerates the three accepted query forms: name, nickname, and set code + number. It also distinguishes this tool from siblings by explaining that bare set queries produce a set-level summary rather than a card list.

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 routes bare set queries to get_set_overview / set_species_summary and instructs users to pass returned card_id to other tools. It does not explicitly contrast search_card with sibling slang_lookup, but the guidance is otherwise clear and actionable.

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 declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context by clarifying that counts are catalog facts, NOT pull-rate probabilities, which helps prevent misinterpretation of the output. It also specifies that counts refer to card faces and variant splits, adding meaning beyond the 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 main English description is concise and front-loaded with the core purpose, followed by a practical answer-oriented sentence and a useful caveat. However, the Chinese sentence nearly duplicates the English content, adding redundancy and token cost without introducing new information.

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 simple two-parameter schema, an output schema, and annotations covering safety, the description is complete enough for correct invocation. It covers what the tool returns conceptually, the intended use case, and an important interpretative caveat, leaving no critical gap for the 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 100%, so set_code and lang are already documented in the input schema. The description does not add parameter-specific details, but it does not need to; the baseline of 3 applies because the schema carries the semantic weight.

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 per-Pokémon breakdown for one set, covering card-face counts and variant splits. It also states the question the tool answers, 'which Pokémon has the most versions in this set'. It does not explicitly name or differentiate sibling tools, 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?

The description gives a clear use case: when you need variant counts per Pokémon in a set, or want to answer 'which Pokémon has the most versions in this set'. It does not explicitly describe when not to use it or point to alternatives, but the context is strong enough for an agent to select it appropriately.

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 only cover read-only and non-destructive behavior. The description adds behavioral detail beyond annotations by stating the result limit ('Up to 10 cards') and the multilingual scope. There is no contradiction with the 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 short, front-loaded, and to the point. It conveys purpose, supported languages, output fields, and cardinality in a compact form without repeating 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?

For a single-parameter, read-only lookup with an output schema, the description covers input style, output contents, language coverage, and the 10-card limit. There is no meaningful gap for an agent trying to decide when to use this tool.

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

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

Schema coverage is 100% for the single term parameter, so the baseline is 3. The description adds concrete examples of valid inputs (鬼皮, 老喷, Zard) and clarifies the term may be a Chinese/Japanese/English community nickname, which is meaningful additional semantic guidance.

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: resolving a Chinese/Japanese/English community nickname to actual cards, and lists the resulting fields (official names, set, number, card_id). This clearly distinguishes it from sibling tools like search_card.

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: use this tool when you have a community nickname or slang term that needs mapping to a real card. It does not explicitly state when not to use it or name alternatives like search_card for official-name queries, so it stops 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.