Real sold prices, history & PSA population for graded Pokémon cards (EN/JP/CN). Knows nicknames.
Scored across 14 tools
Most tools target distinct resources and questions (per-card price, population, history, set stats, market movers, volume leaders). The one real overlap is search_card vs slang_lookup, since both resolve a name/nickname to a card_id; descriptions hint at the split (search also handles set code + number) but an agent could plausibly reach for either.
All names are consistently snake_case, which is good, but the verb convention is mixed: some use a get_ prefix (get_account_access, get_card_context, get_set_overview) while others are bare verb_noun or noun_noun (search_card, card_price, market_movers, set_top_priced_cards). Still readable and predictable enough to be low-risk.
14 tools sit at the top of the well-scoped 3-15 range and each maps to a distinct facet of the card-price domain (search, price, history, population, context, set stats, market aggregates). No tool feels redundant padding given the breadth of the domain.
The surface covers search, per-card pricing/history/population, set-level stats, market aggregates, recent sales, slang resolution, and account access, which is strong lifecycle coverage. Minor gaps: no explicit set-listing/browse tool and no direct card-to-card comparison, though search and the set tools largely route around these.
Graded population for one card: PSA population by grade (total / 10 / 9 / 8), CCIC population (total / 10 / 9.5 / 9), PSA gem rate and scarcity tier when available. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | Card id from search_card / slang_lookup. |
| Name | Required | Description |
|---|---|---|
| psa | No | |
| ccic | No | |
| note | No | |
| card_id | No | |
| gem_rate | No | |
| gem_rate_band | No | |
| scarcity_tier | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral note: 'Calls record usage and query metadata within POKEKA,' which discloses a side effect (usage recording) not present in annotations (readOnlyHint: false). This is useful, but it does not address other behaviors like rate limits, authentication, or optionality of 'when available.'
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 fluff. The first sentence front-loads the core purpose and data breakdown; the second adds a relevant side-effect note. Efficient and well-ordered.
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 query tool with an output schema, the description covers the essential payload (grades, gem rate, scarcity) and notes the 'when available' caveat. It does not explain pagination or error cases, but the output schema handles structure and the annotations handle safety.
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 the card_id parameter already carries a clear description ('from search_card / slang_lookup'). The tool description adds nothing beyond saying 'one card,' so it does not improve on the schema's parameter explanation.
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 names a specific resource ('one card') and a specific data type ('graded population'), enumerating exact metrics (PSA population by grade, CCIC population, gem rate, scarcity tier). This clearly differentiates it from siblings like card_price or recent_sales, which are about prices/sales rather than population counts.
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 when to use it ('Graded population for one card') but does not explicitly state when not to use it or name alternative tools. It could guide the agent by saying 'for population data, not prices/history,' but it leaves that to the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks what a card is worth, its PSA 10 / PSA 9 / CCIC 10 price, current market value, or what it last sold for. Returns a headline price (USD/CNY/JPY) from verified real sales (robust median — never listings, never interpolated) with grading company, grade, sample size, window and confidence, plus a per-grade ladder (PSA 10/9/8, CCIC, BGS, CGC …). Pass company + grade to price a specific grade (e.g. company "PSA", grade "9"); if that grade has no data the response says price_status "grade_not_available" and does NOT fall back to PSA 10. price_status "reference_only" = low confidence or thin sample — quote it with that caveat (safe_to_quote=false). "card_not_found" = wrong id, search again. Markets are kept separate: Japanese cards with Japan-domestic activity are priced from JPY marketplace sales (not converted US prices), Simplified-Chinese cards from Chinese market sales including CCIC slabs. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | No | Optional grade to price, e.g. "10", "9.5", "9". Use with company. No fallback to another grade. | |
| card_id | Yes | Card id from search_card / slang_lookup. An exact community nickname (e.g. "moonbreon", "鬼皮") also resolves when it maps to exactly one card. | |
| company | No | Optional grading company to price, e.g. "PSA". Use with grade. | |
| condition | No | "raw" = the user asked for an ungraded card. Raw prices are not offered yet; the response says so instead of returning a graded price. |
| Name | Required | Description |
|---|---|---|
| card | No | |
| note | No | |
| fx_as_of | No | |
| headline | No | omitted when there is no verified headline price — read price_status |
| reference | No | |
| grade_ladder | No | |
| price_status | No | |
| last_sold_date | No | |
| headline_confidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are sparse (readOnlyHint=false, destructiveHint=false) but the description carries the burden and does so richly. It discloses that prices are based on verified real sales (robust median, never listings/interpolated), explains the meaning of price_status values (grade_not_available, reference_only, card_not_found) and their implications (e.g., no fallback, safe_to_quote=false). It also notes market separation (JPY/CNY) and usage tracking within POKEKA, adding behavioral context well 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?
Though the description is lengthy, every sentence contributes essential information. The opening sentence states the trigger and scope immediately. Subsequent sentences cover edge cases, status codes, market separation, and tracking without redundancy. It is dense but structured with clear clauses and semicolons, appropriately sized for the tool's complexity.
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 when to use it, parameter semantics, expected output (headline price, ladder), error/status handling, market nuances, and side effects (usage tracking). With an output schema present, return values are already documented, so the description completes all other aspects an agent needs to select and invoke the tool correctly. No gaps are evident.
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 is 3, but the description adds substantial meaning. It explains that company and grade work together, that grade has no fallback, that condition='raw' means ungraded and returns a message instead of a graded price, and that card_id can be a nickname resolving to exactly one card. These details significantly enhance the schema's descriptions and help the agent use parameters correctly.
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 ('use when the user asks what a card is worth...') and enumerates the exact kinds of queries (PSA 10/9/CCIC 10 price, market value, last sold). It also distinguishes the output (headline price with confidence, per-grade ladder) and implies differentiation from siblings like card_price_history and recent_sales by focusing on current value and specific grades.
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 when the user asks...' which provides clear context for invocation. It also specifies parameter combinations ('Pass company + grade to price a specific grade') and explains fallback behavior and status conditions. However, it does not name alternative tools (e.g., card_price_history) or explicitly say when NOT to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Weekly median price series for one card (representative grade, up to 26 weeks) plus 30d/90d change percentages (only shown when statistically confident). Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | How many recent weeks (default 26, max 26). | |
| card_id | Yes | Card id from search_card / slang_lookup. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| series | No | |
| card_id | No | |
| point_count | No | |
| change_pct_30d | No | |
| change_pct_90d | No | |
| weeks_requested | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses two meaningful behaviors: change percentages are only shown when statistically confident, and calls record usage and query metadata within POKEKA. This is particularly valuable because readOnlyHint is false, so the side-effect disclosure adds important context the annotations do not 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 two sentences with no filler: the core result is front-loaded, followed by a statistical-confidence caveat and a side-effect note. Every sentence contributes meaningful 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?
The description covers the core scope, time window, confidence condition, and side effects, and an output schema exists so return values need not be enumerated. It lacks an explicit pointer to when a sibling tool would be more appropriate, but that gap is already addressed under 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 100%, so the input schema already fully documents card_id and weeks, including defaults and ranges. The description reinforces the 26-week cap and mentions 'representative grade', but it does not need to add parameter-level detail beyond what the schema already 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 clearly states the tool's resource and behavior: a weekly median price series for one card with up to 26 weeks of history plus change percentages. It differentiates itself from siblings by explicitly scoping to 'one card' and emphasizing price-history and confidence-gated percentages, which is distinct from market-wide sibling tools like get_market_brief or 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?
The description implies the tool is for single-card historical price analysis, but it does not explicitly state when to prefer it over siblings such as card_price or get_market_brief, nor does it provide exclusions or alternative conditions. Usage context is present only by inference from the data scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connect the user's existing POKEKA account or check its current access permissions. Use when the user explicitly asks to connect, sign in, or check their POKEKA account access (连接账号、登录、查看账号权限). Requires POKEKA OAuth; if not connected, return the account-linking challenge and retry after authorization. Public card and market queries do not require this tool. Returns the existing access tier and connection-management link, never credentials or personal identifiers. Does not purchase or change a plan. Calls update token activity and may record internal usage statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| connected | No | |
| access_tier | No | |
| detailed_market_data | No | Whether the linked account currently has access to detailed market data; individual tool limits still apply. |
| manage_connection_url | No | POKEKA account page where the user can manage or revoke this connection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals important behavior beyond annotations: OAuth is required, unauthenticated calls should trigger an account-linking challenge and retry, it returns access tier and a connection-management link but never credentials, it does not purchase or change a plan, and it may record usage statistics. This fully discloses side effects 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?
Every sentence earns its place: purpose, usage trigger, auth behavior, return characteristics, exclusions, and side effects. The core action is front-loaded and the description remains compact despite covering multiple essential aspects.
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 zero-parameter tool with an output schema, the description covers all decision-relevant context: when to use, what to expect on auth failure, what is returned, what is never returned, what side effects occur, and what it does not do. Nothing needed 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?
The input schema is empty, so parameter semantics are trivially satisfied. The description adds contextual requirements like OAuth but no parameters need explanation. A score of 4 is the baseline for a zero-parameter tool.
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 names a specific verb ('Connect', 'check') and resource ('POKEKA account'), and clearly differentiates from all sibling card/market tools by stating that public card and market queries do not require this tool. The purpose is immediately identifiable and unambiguous.
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 use conditions: when the user asks to connect, sign in, or check account access. It also provides a clear exclusion: public card and market queries do not require this tool. This tells an agent both when to invoke it and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything around one card beyond the price: community nicknames (圈内叫法), counterfeit-risk flags with self-check steps, holder-turnover tier (locked vs high-churn), and a curated context note — plus the headline price. Accepts card_id or an exact nickname via query (e.g. "凡高皮", "金拱门"). Absence of flags is not a clearance; coverage is curated and growing. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Alternative to card_id: an exact community nickname or alias. | |
| card_id | No | Card id from search_card / slang_lookup. |
| Name | Required | Description |
|---|---|---|
| card | No | |
| note | No | |
| headline | No | |
| last_sale | No | |
| nicknames | No | |
| reference | No | |
| price_note | No | |
| risk_flags | No | |
| context_note | No | |
| price_status | No | |
| release_date | No | |
| hoarding_tier | No | |
| has_risk_flags | No | |
| context_coverage_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, implying possible side effects; the description transparently states that calls record usage and query metadata within POKEKA. It also discloses that absence of flags is not clearance and coverage is curated and growing, which adds important caveats beyond annotations. 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 the core output, then usage, then caveats. It is reasonably concise for the amount of information conveyed, though slightly lengthy. Every sentence serves a purpose, but it could be tightened slightly without losing 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?
Given the tool's complexity, the description covers the main purpose, input methods, and important caveats. An output schema exists, so return values are documented elsewhere. The description provides enough context for an agent to correctly select and invoke the 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 already covers both parameters with descriptions (100% coverage). The description adds value by clarifying that either card_id or an exact nickname can be used, and gives concrete examples (凡高皮, 金拱门). This helps agents understand the input format better than schema alone.
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?
Clearly states what the tool returns: community nicknames, counterfeit-risk flags with self-check steps, holder-turnover tier, curated context note, and headline price. This distinguishes it from sibling tools like card_price and card_price_history, which focus on price alone. The verb 'get' plus the resource 'card context' is explicit.
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 explains how to use it: accepts card_id or exact nickname via query, with examples. It implies the use case (need context beyond price) but does not explicitly mention when not to use it or name alternative tools. However, the instruction is clear enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where the graded-Pokémon market stands in its cycle, per language track (all / en / ja): a one-line phase read backed by a fixed-basket same-card index (never vibes), peak/drawdown numbers, weekly verified-sale counts, and an upcoming release/event calendar. Not investment advice. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Track, default all. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| as_of | No | |
| phase | No | |
| market | No | |
| basket_size | No | |
| index_level | No | |
| tx_7d_count | No | |
| upcoming_events | No | |
| change_from_base | No | |
| drawdown_from_peak | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a non-obvious side effect—'Calls record usage and query metadata within POKEKA'—which goes beyond the bare readOnlyHint: false annotation. It also adds methodology transparency ('fixed-basket same-card index (never vibes)') and a disclaimer. No contradiction with the annotations 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?
The first sentence is dense but packs a precise list of data elements, and the remaining sentences add necessary behavioral and disclaimer information. It could be more scannable as a bulleted list, but there is no filler or unnecessary 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?
With an output schema present and only one optional parameter, the description sufficiently covers the data scope, methodology, side effects, and disclaimers. The gaps are the omitted zh-cn track and lack of explicit sibling routing, which prevent it from being fully 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 coverage is 100%, so the baseline is 3, but the description's parenthetical 'all / en / ja' omits the valid 'zh-cn' value present in the enum. This makes the parameter documentation actively misleading rather than merely redundant, despite the schema being authoritative.
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 names the specific resource (a market brief) and enumerates its concrete contents: a one-line phase read, a fixed-basket same-card index, peak/drawdown numbers, weekly verified-sale counts, and a release/event calendar. This clearly separates it from siblings such as card_price, market_movers, or 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?
The description implies the tool is for a market-cycle/phase overview, but it gives no explicit guidance on when to use it versus market_movers, market_volume_leaders, or recent_sales. It also lacks any when-not-to-use or alternative routing, leaving the agent to infer suitability from the listed contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whole-set statistics for one Pokémon TCG set: total cards, per-language-track counts, breakdown by rarity (with EN star-system + JP-style display names) and by variant (Master Ball / Poké Ball mirror slots etc.), top featured Pokémon, plus a paginated card checklist. 中文用户: 一次拿到整个系列的卡表统计(总卡数/每稀有度几张/每变体几张/出场宝可梦), 不用逐张搜。Use for questions like "how many cards / SR cards are in 151c". Accepts internal set_code, official abbreviation (CEL) or set name. Catalog data only — for the most valuable cards in a set use set_top_priced_cards; per-card prices via card_price. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Optional language track filter — same code can be different products per track. | |
| page | No | Checklist page (0-based). Anonymous/free tier: 20 cards/page, first 2 pages; Pro: 50/page (whole-set sweeps are rate-guarded). | |
| set_code | Yes | Set code, official abbreviation, or set name (e.g. "151c", "sv2a", "CEL", "Celebrations"). |
| Name | Required | Description |
|---|---|---|
| lang | No | |
| note | No | |
| by_lang | No | |
| guidance | No | |
| set_code | No | |
| by_rarity | No | |
| checklist | No | |
| by_variant | No | |
| top_species | No | |
| total_cards | No | |
| species_note | No | |
| checklist_page | No | |
| checklist_capped | No | |
| checklist_page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry readOnlyHint=false, and the description explains why: 'Calls record usage and query metadata within POKEKA.' It also discloses pagination tiers (20 cards/page for anonymous, 50 for Pro) and rate-guarding. No contradiction between description and annotations; side effects are explicitly 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?
The description is well-structured and front-loads the core purpose, but the included Chinese translation is redundant in English context and adds length without new information. Still, it's efficient given the breadth of content covered.
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 relatively complex tool (multiple statistics, variants, pagination), the description covers all key aspects and explicitly lists alternatives. An output schema exists, so return-format details are not required. The description gives an agent everything needed to decide and call appropriately.
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 cover 100% of parameters, so the baseline is 3. The description reinforces the semantics (e.g., set_code accepts multiple forms) but adds minimal new information beyond what the schema already provides. The examples are helpful but not essential.
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 ('get') and a clear resource ('set overview'), and lists the exact contents (total cards, per-language counts, rarity and variant breakdowns, featured Pokémon, checklist). It distinguishes itself from siblings by noting 'Catalog data only' and explicitly contrasting with set_top_priced_cards and 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?
Provides explicit use-case examples ('how many cards / SR cards are in 151c'), explains accepted input formats (set_code, abbreviation, name), and lists alternatives with clear conditions ('for the most valuable cards use set_top_priced_cards; per-card prices via card_price'). No ambiguity about when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks which Pokémon cards are rising or falling, what is hot, or the biggest moves this week/month. lang = "en" / "ja" / "zh-cn" (market tracks never mix). direction = "up" (cards rising) or "down" (cards falling), default "up". window = "7d" / "30d" / "90d"; omit to use the default window published for that track. Every row passes a liquidity gate — at least 5 verified sales in both the current and the base window, change capped at ±40%, both medians consistent with the card's reference price — and carries price_now / price_base / n_cur / n_prev, so a listed move is a real same-card, same-grade move. Up to 20 cards. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | Yes | Market track: "en", "ja" or "zh-cn". | |
| window | No | Change window: "7d", "30d" or "90d". Omit to use the default window published for that track. | |
| direction | No | "up" = cards rising, "down" = cards falling. Default "up". |
| Name | Required | Description |
|---|---|---|
| note | No | |
| market | No | |
| movers | No | |
| window | No | |
| direction | No | |
| anchor_date | No | The window anchors to this latest-sale date; present it. |
| mover_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (all false) by disclosing that calls record usage metadata, explaining the liquidity gate (minimum 5 sales, ±40% cap, median consistency), and describing the output fields (price_now, price_base, n_cur, n_prev). It also clarifies that market tracks never mix. This is rich, honest behavioral disclosure.
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 well-organized: it leads with the usage trigger, then parameter explanations, then data quality and output details, and finally the side effect. Every sentence carries useful information; no filler. It earns its length.
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 and the presence of an output schema, the description covers everything an agent needs: usage trigger, parameter semantics, data filtering rules, output field names, row limit, and side effects. Nothing essential 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?
Although schema coverage is 100%, the description adds significant meaning: it explains what 'lang' implies (tracks never mix), the default for 'direction' and 'window', and the data-quality implications of the gate. It enriches the parameters beyond the schema's enum lists and 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 clearly states the tool's purpose: to show which Pokémon cards are rising or falling, what is hot, or the biggest moves. It specifies a concrete resource (market movers) and differentiates from volume or pricing tools by focusing on change. While it doesn't name a sibling, the context is 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?
The description provides explicit when-to-use guidance: 'Use when the user asks which Pokémon cards are rising or falling, what is hot, or the biggest moves this week/month.' It also explains parameter selection (lang, direction, window) in detail. However, it doesn't mention when not to use it or point to alternatives, so it stops short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most-traded graded Pokémon cards by verified sales count over a 24h / 7d / 30d window, filterable by language track (all / en / ja / zh-cn) and grading company (all / PSA / CCIC / PSA10). Windows anchor to the latest sale date on record (anchor_date in the response) — always present results with that date. median_usd is a mixed-grade reference; use card_price for a precise per-grade quote. Up to 50 leaders. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language track filter, default all. | |
| limit | No | How many leaders (default 10, max 50). | |
| window | No | Volume window, default 7d. Anchored to the latest sale on record, not wall-clock now. | |
| grade_company | No | Grading filter, default all. PSA10 = PSA grade-10 slabs only. |
| Name | Required | Description |
|---|---|---|
| lang | No | |
| note | No | |
| window | No | |
| leaders | No | |
| anchor_date | No | Latest sale date on record — always cite this with results |
| leader_count | No | |
| grade_company | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (no readOnlyHint true), and the description adds valuable behavioral context: it records usage/query metadata, anchors windows to the latest sale date, and clarifies that median_usd is a mixed-grade reference. These go beyond the schema and annotations, though it doesn't mention pagination or error 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?
The description is a compact paragraph that front-loads the core purpose, then adds anchoring details and a usage caveat. It is efficient and well-ordered, though a few clauses could be tightened without loss of meaning.
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 4 optional parameters with enums and an output schema, the description covers the main purpose, filters, anchoring, and the median_usd vs card_price distinction. It also notes usage recording and the 50-leader limit. The only minor gap is not elaborating on the definition of 'verified sales count' or the exact sort order, but these are inferable from the title and context.
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 clear per-parameter descriptions, so the baseline is 3. The description repeats some schema info (e.g., window anchoring, PSA10 meaning) and adds context about median_usd vs card_price, but that pertains to response fields, not parameter semantics. It doesn't meaningfully enhance the parameters beyond 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 clearly states the tool lists most-traded graded Pokémon cards by verified sales count over configurable windows, with filters for language and grading company. This is a specific verb+resource+scope and distinguishes it from siblings like market_movers (price movers) and recent_sales (individual transactions).
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 an explicit alternative for precise pricing ('use card_price for a precise per-grade quote') and clarifies the window anchoring behavior, which guides when to use this tool. However, it does not explicitly name other siblings like market_movers or state when not to use this tool, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most recent verified sales for one card (up to 10): date, grading company + grade, price in USD, marketplace name. Sales span US, Japan-domestic and Chinese marketplaces — each sale is a real completed transaction, not a listing. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| card_id | Yes | Card id from search_card / slang_lookup. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| sales | No | |
| card_id | No | |
| fx_as_of | No | |
| sale_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint: false, openWorldHint: false, destructiveHint: false), so the description carries most of the behavioral burden. It adds valuable transparency by clarifying that results are verified completed transactions, spanning specific marketplaces (US, Japan-domestic, Chinese), and that calls record usage and query metadata. 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 two sentences, front-loaded with the core purpose and cardinality, then supporting details about market coverage and data authenticity. The final clause about usage metadata is relevant to behavioral transparency and does not feel like padding. Every sentence 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?
For a tool with a single required parameter and an existing output schema, the description is complete: it gives the result count cap, the fields returned, the market provenance, and the key distinction from listings. There are no complex prerequisites or exclusions that are left unexplained, and the output schema covers the return structure.
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% and the only parameter, card_id, is documented in the schema as 'Card id from search_card / slang_lookup.' The description adds no additional parameter-level semantics beyond reinforcing that it targets one card. With full schema coverage, the baseline 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 states a specific verb-resource pairing ('Most recent verified sales for one card'), with precise scope (up to 10), and enumerates the returned fields. It also clearly distinguishes this from listings and from broader market tools by saying 'each sale is a real completed transaction, not a listing,' which differentiates it from sibling tools like card_price or market_movers.
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 useful context: it is for a single card and returns verified completed sales, not listings. However, it does not explicitly name alternative sibling tools nor state when to prefer this over card_price_history or get_market_brief. The usage guidance is implied rather than explicit, so it earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search graded Pokémon cards by name (Chinese / English / Japanese), community nickname (e.g. "鬼皮"), or set code + card number (e.g. "sv8a 喷火龙", "CEL 4"). 中文用户: 按官方卡名/圈内简称/系列码+卡号查任意宝可梦评级卡, 返回 card_id 供查价/走势/存世量工具使用。Returns up to 10 matching cards with card_id (incl. rarity/variant/species fields) — use card_id with the other tools. A bare set code or set name (e.g. "151c", "Celebrations") returns a set-level summary with guidance instead of a truncated card list — follow it to get_set_overview / set_species_summary for whole-set stats. Optional lang filters to one language track (en / ja / zh-cn); tracks are never mixed. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Optional language track filter. | |
| query | Yes | Card name, nickname/slang, or set code + number. zh/en/ja all accepted. |
| Name | Required | Description |
|---|---|---|
| hint | No | |
| lang | No | |
| query | No | |
| sample | No | |
| by_lang | No | |
| results | No | |
| guidance | No | |
| mismatch | No | |
| set_code | No | |
| by_rarity | No | |
| condition | No | "raw" when the user asked for an ungraded card |
| guess_note | No | |
| match_kind | No | species | card_name | guess — guess means nothing matched and the results are prefix guesses, never price from them |
| query_type | No | "set" = the query was a bare set code/name; read guidance and use the set-level tools |
| set_tracks | No | when the query is a set-level name or a bare set code: every (set_code, lang) it exists on, with card counts. The same release usually has a different set code per language track. |
| exact_match | No | true only when set, number AND every other entity in the query (character, nickname, language) agree with the results |
| total_cards | No | |
| query_intent | No | |
| related_sets | No | only when unambiguous: the set that carries the same collector name on the requested language track (the same release usually has a different set code per language). Absent when the name covers a whole era or product family rather than one release. |
| result_count | No | |
| entity_anchor | No | |
| rarity_filter | No | |
| safe_to_price | No | true = results[0] can be priced without asking the user to confirm; false = candidates only |
| grading_filter | No | |
| qualifier_note | No | |
| unresolved_note | No | |
| also_matched_sets | No | |
| unresolved_tokens | No | words from the question that were NOT used to choose the card |
| qualifiers_dropped | No | |
| query_constraint_note | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations present, the description still adds meaningful behavior: results are capped at 10 with a truncation-avoiding fallback for set-level queries, and 'Calls record usage and query metadata within POKEKA' explains why readOnlyHint is false for what looks like a read. It stops short of describing result ordering or emptiness 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?
It is dense but front-loaded: the primary search surface comes first, then the return/handoff contract, then the set-code fallback. The bilingual sentence is redundant for an English-reading agent but not wasteful, and no filler sentences are present.
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, yet the description still supplies the fields the agent needs to act (card_id, rarity/variant/species). Combined with the fallback routing and language-track rules, an agent can invoke this correctly without further context.
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 a 3 is the baseline, but the description goes further by giving concrete query syntax examples ('sv8a 喷火龙', 'CEL 4'), explaining that zh/en/ja are all accepted, and clarifying that lang restricts to one track with no mixing.
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 names a specific verb (search) and resource (graded Pokémon cards) plus the three accepted query modes: name in three languages, community nickname, or set code + card number. It also distinguishes its role from siblings by stating it returns card_id for use with pricing/history/population 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 gives explicit usage conditions and even an edge-case routing rule: a bare set code or set name returns a set-level summary and the agent should follow it to get_set_overview / set_species_summary. It also documents the optional lang filter behavior and that language tracks are never mixed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Per-Pokémon breakdown for one set: how many card faces each species has and how they split across variants (base / Master Ball / Poké Ball / …). 中文用户: 这个系列里每只宝可梦有几张卡、各是什么版本(普卡/大师球闪/精灵球闪)一表拿全。Answers "which Pokémon has the most versions in this set". Counts are catalog facts, NOT pull-rate probabilities. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Optional language track filter. | |
| set_code | Yes | Set code, official abbreviation, or set name. |
| Name | Required | Description |
|---|---|---|
| lang | No | |
| note | No | |
| species | No | |
| guidance | No | |
| set_code | No | |
| total_cards | No | |
| coverage_note | No | |
| species_count | No | |
| species_covered_cards | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false hints and carry almost no signal, so the description shoulders the burden — and it delivers: it discloses that calls record usage and query metadata (consistent with readOnlyHint=false), and it corrects a likely misconception by stating counts are catalog facts, NOT pull-rate probabilities. 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 primary purpose is front-loaded in the first sentence, which is good. However, the full Chinese translation duplicates the English content nearly verbatim, roughly doubling length without adding agent-useful information; the not-probabilities caveat and metadata note are valuable, but the bilingual block is bloat for an AI consumer.
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 is present, so return-value documentation is covered elsewhere. The description supplies purpose, the question it answers, variant semantics, a misuse warning, and side-effect disclosure — adequate for a two-parameter set-scoped query tool. Only explicit sibling differentiation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (set_code, lang) are already documented, meeting the baseline. The description adds domain context about what variants (base/Master Ball/Poké Ball) mean and that lang is a language-track filter, but it does not add parameter-level syntax or format details beyond the schema — marginal added value.
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 deliverable — a per-Pokémon breakdown of card faces and variant splits for one set — with a concrete question it answers ('which Pokémon has the most versions in this set'). The verb 'breakdown' plus the set-scoped resource make the purpose clear, though it never names a sibling it is not, leaving slight overlap ambiguity with get_set_overview.
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 case is implied through the 'Answers X' line and the set-scoped framing, which distinguishes it from market tools like card_price and recent_sales. However, there is no explicit when-to-use vs when-not-to-use guidance, nor any named alternative for overlapping set-level queries, so routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank the highest-priced cards inside one Pokémon TCG set, on one language track (top N, max 20). 中文用户: 某个系列里最贵的前几张卡(如「M2A 前5最高价的卡」「151c 最贵的卡」)一次拿到, 不用逐张查价。Answers "most expensive / top 5 priciest cards in m2a". Each row carries exactly the price card_price returns for that card_id (its headline grade, usually PSA 10 or CCIC 10) with price_basis = verified_sales or reference. Cards with no usable price are not ranked, and the response says how many cards in the set have one. Returns only the top of the ranking — it is not a price-sorted checklist and has no paging. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language the CARDS are printed in (e.g. ja for Japanese sets such as m2a / sv2a), not the language the user is writing in. Prices are never mixed across tracks. Omit it unless the set code exists on more than one track — the response then lists the tracks. | |
| limit | No | How many top cards to return (1-20, default 10). | |
| set_code | Yes | Set code, official abbreviation, or set name (e.g. "m2a", "151c", "CEL"). |
| Name | Required | Description |
|---|---|---|
| lang | No | |
| note | No | |
| ranked | No | |
| tracks | No | |
| guidance | No | |
| set_code | No | |
| needs_lang | No | |
| total_cards | No | |
| priced_cards | No | cards on this track with a usable price (the ranking pool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With all annotations set to false, the description carries the full burden and delivers: it reveals that each row uses 'the price card_price returns for that card_id (its headline grade, usually PSA 10 or CCIC 10) with price_basis = verified_sales or reference,' that 'Cards with no usable price are not ranked,' that the response reports how many cards have a usable price, that it has no paging, and that calls 'record usage and query metadata.' This is extensive behavioral disclosure beyond what any annotation or schema provides.
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 opens with a clear one-sentence purpose statement and front-loads the core ranking behavior. It includes a bilingual note and example queries that occupy space, and some redundancy exists between the first sentence and the quoted examples. Still, every sentence adds a distinct behavioral fact or clarification, so the length is justified rather than padded.
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 tool with an output schema and fully documented parameters. It covers language-track nuances, top-N limit behavior, handling of cards with no usable price, absence of paging, and metadata recording. Edge cases such as multiple language tracks and the reported count of ranked cards are addressed. Nothing an agent needs to call or interpret the result is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantics for the lang parameter: it clarifies that lang refers to the card's print language, not the user's language, warns that 'Prices are never mixed across tracks,' and explains the omission behavior when a set exists on only one track. The set_code parameter also gets examples (m2a, 151c, CEL). This is value beyond the schema's own parameter 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 first sentence states a specific verb and resource: 'Rank the highest-priced cards inside one Pokémon TCG set, on one language track (top N, max 20).' It further distinguishes itself by explicitly saying it is 'not a price-sorted checklist and has no paging,' which separates it from any list-returning sibling. The description also provides concrete example queries ('Answers "most expensive / top 5 priciest cards in m2a"'), leaving no ambiguity about what the 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 implies when to use this tool versus manually checking individual cards ('不用逐张查价' — no need to check prices one by one) and references card_price as the pricing source. It defines boundary conditions like 'on one language track' and 'no paging,' but it does not explicitly name alternative sibling tools or state when NOT to use this tool. This is clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a Chinese/Japanese/English community nickname (e.g. "鬼皮", "老喷", "Zard") to the actual card(s): official names, set, number, card_id. 中文用户: 把圈内简称(鬼皮/老喷/大月…)解析成具体是哪张卡。Up to 10 cards. Calls record usage and query metadata within POKEKA.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | The nickname / slang term. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| term | No | |
| cards | No | |
| card_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, which the description complements by disclosing that the tool 'Calls record usage and query metadata within POKEKA' – indicating a side effect (usage logging) and a scope (within POKEKA). It also states 'Up to 10 cards' as a result limit. This adds meaningful behavioral context beyond the annotations, though it does not specify behavior on no matches or errors.
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 concise and front-loaded, stating the main purpose first, then providing examples and a bilingual note. It contains no filler and every sentence adds useful information. The inclusion of the Chinese translation is efficient for the target audience without bloating the text.
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 tool with one parameter and an output schema, the description is complete. It explains what the tool returns (official names, set, number, card_id), the maximum number of results (up to 10), and the side effect (usage recording). Since an output schema exists, it doesn't need to detail the return structure. The agent has enough information 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?
The single parameter 'term' is fully described in the schema (100% coverage), so the baseline is 3. The description adds value by providing examples of valid nicknames (鬼皮, 老喷, Zard) and specifying supported languages (Chinese/Japanese/English). This enriches the semantic understanding of what constitutes a valid term, going beyond the schema's simple 'The nickname / slang term.'
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: resolving community nicknames to actual cards, listing the output fields (official names, set, number, card_id). It uses a specific verb 'Resolve' and gives concrete examples. This distinguishes it from sibling tools like search_card, which search by official names, and other market tools. The purpose is unambiguous and unique.
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 when the user has a nickname or slang term, and the Chinese note reinforces this. However, it does not explicitly state when NOT to use this tool or mention alternatives (e.g., use search_card for official names). The guidance is implied but not explicit, leaving some ambiguity for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
search_card2 fields changedOutput schema / properties / related_setsAdded value: +{
+ "description": "only when unambiguous: the set that carries the same collector name on the requested language track (the same release usually has a different set code per language). Absent when the name covers a whole era or product family rather than one release.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "lang": {
+ "type": "string"
+ },
+ "set_code": {
+ "type": "string"
+ },
+ "total_cards": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / set_tracksAdded value: +{
+ "description": "when the query is a set-level name or a bare set code: every (set_code, lang) it exists on, with card counts. The same release usually has a different set code per language track.",
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "lang": {
+ "type": "string"
+ },
+ "set_code": {
+ "type": "string"
+ },
+ "total_cards": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+}Neutral prices + PSA population for PSA-graded vintage Pokémon (WotC 1999–2003). Read-only.
Trading card prices and grading ROI for 1.5M+ Pokémon, Magic, Yu-Gi-Oh! and sports cards. Read-only.
Connect to your CollectHolo Pokémon card collection. Check your portfolio value, look up card, sealed and graded (PSA/BGS/CGC) prices from Cardmarket, TCGplayer, eBay, Goldin and Fanatics, search the catalog in six languages, import a whole collection from a spreadsheet, and add or update holdings in plain language. Every change asks for confirmation.
Trading card prices: daily TCGplayer market, history since 2024, sold comps, PSA 10 floors. 6 games.
Add one secure layer between your agents and this server.
