Trading card prices: daily TCGplayer market, history since 2024, sold comps, PSA 10 floors. 6 games.
Scored across 11 tools
Most tools target distinct questions, but `search` and `search_cards` overlap heavily as name-based lookup tools, and `card_price` and `fetch` both return today's price per printing for one product. Descriptions do clarify downstream tool dependencies, but an agent can still misselect between them.
All names use snake_case, which is consistent, but the semantic pattern is mixed: some are action verbs (`fetch`, `search`) while many are noun/adjective phrases (`all_time_highs`, `most_valuable`, `price_history`). The set is readable but not predictably patterned.
Eleven tools is well-scoped for a read-only trading-card pricing server. Each tool covers a recognizable price-analysis query type without excessive bloat.
The surface covers search, current card prices, price history, movers, all-time highs/lows, most valuable cards, sealed product prices, and set-level aggregates. Minor gaps exist, such as no explicit game-list tool or bulk multi-card price lookup, but core workflows are covered.
Use this when the user asks which cards in one game are at a record price. Returns cards that set an all-time high market price (since February 2024) in the last 7 days and still hold it, with the date of the high, in USD.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam. | pokemon |
| limit | No | 1 to 200. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, non-destructive, idempotent, and closed-world behavior. The description adds valuable temporal semantics: the high must have been set since February 2024, within the last 7 days, and still be held, plus output details like the date and USD currency. It does not disclose pagination or rate-limit behavior, but with annotations present the added context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no wasted words. The usage trigger is front-loaded, followed by the precise return conditions, making it easy for an agent to parse quickly.
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, full schema coverage, and the presence of an output schema, the description provides everything an agent needs: when to use it, what it returns, and the non-obvious time-window semantics. It is complete for this tool's complexity.
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 both parameters are fully documented in the input schema. The description implies a game filter ('one game') but does not add syntax, format, or constraints beyond what the schema already provides for game and limit.
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: it returns cards that set an all-time high market price, with precise scope conditions (since February 2024, last 7 days, still hold it). It distinguishes the tool from its sibling all_time_lows by the 'all-time high' concept and the record-price framing.
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 opening sentence gives a clear trigger: 'Use this when the user asks which cards in one game are at a record price.' It does not explicitly name alternative tools or when not to use this one, so it is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which cards in one game are at their lowest price or have crashed. Returns cards worth $5+ sitting at their all-time low market price after falling at least 50% from their high, with the high and the percent below it, in USD.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam. | pokemon |
| limit | No | 1 to 200. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond them by disclosing the hardcoded filter thresholds and what is included in the result set (cards $5+ that have fallen ≥50%). It does not mention pagination or result ordering, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste: the usage trigger comes first and the return-set definition second. Every clause earns its place, and the front-loading is correct.
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, the description need not explain return shape, yet it still defines the qualifying set precisely. Together with annotations covering safety and a fully documented schema, an agent has everything needed to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with game enumerated and limit defaulted and bounded (1–200), so the schema already carries full parameter meaning. The description adds nothing about how game or limit affect output, which is the expected baseline 3 when the schema does the heavy lifting.
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 — surfacing cards at their all-time low — and pins the exact scope with quantitative filters ($5+ worth, ≥50% below the high). It is clearly distinguishable from the sibling all_time_highs, which would be the opposite screen.
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 an explicit trigger: 'when the user asks which cards in one game are at their lowest price or have crashed.' That is a clear usage context, but it never names all_time_highs or movers as the alternative to avoid, so the exclusion half 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.
Use this when the user asks what one specific card or sealed product is worth today. Returns the latest daily TCGplayer market price and lowest listed price per printing (Normal, Holofoil, Reverse Holofoil, 1st Edition...) with the date of the price, in USD, plus the page URL. Raw (ungraded) prices only; not an appraisal of a particular copy. Needs a product_id from search_cards.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | TickerMint product_id from search_cards. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. The description adds substantial behavioral context beyond that: it specifies the returned price types (latest daily TCGplayer market, lowest listed per printing), date and currency, page URL, and the raw/ungraded limitation.
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?
Four tightly written sentences, front-loaded with the usage condition, then the return summary, limitation, and input prerequisite. Each sentence contributes actionable information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, annotations covering safety, and one fully documented parameter, the description still provides complete invocation context: when to use it, what it returns, its limitations, and the required input source. 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?
Schema description coverage is 100% and the single parameter is fully documented in the schema as a TickerMint product_id from search_cards. The description merely repeats this prerequisite without adding syntax, format, or constraint details 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?
States a specific resource and scope: latest daily TCGplayer market price and lowest listed price per printing for one card or sealed product. However, it does not explicitly differentiate from siblings like sealed_prices or price_history; search_cards is named only as an input dependency, not as an alternative.
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?
Gives a clear usage trigger (user asks what one specific card or sealed product is worth today), an exclusion (raw only; not an appraisal of a particular copy), and a prerequisite (needs product_id from search_cards). It does not name alternative tools such as price_history or all_time_highs for related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this after search to read one product: today's market price per printing
(USD), its move over the last 90 days and the page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product id from `search` results. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered. The description adds the scope ('one product') and roughly what comes back, but the output schema already carries return content, so the marginal behavioral disclosure is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler; the sequencing instruction is front-loaded and the returned payload is itemized compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a rich annotation set, a present output schema, and full parameter documentation, the description only needs to convey purpose and sequencing, which it does. Only the lack of sibling routing (vs `card_price`/`price_history`) keeps 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?
Only one parameter and schema coverage is 100%, so the schema and its own description ('Product id from `search` results') do the work. The description reinforces the dependency on `search` but adds no syntax or format detail beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('read one product') and enumerates the returned fields: market price per printing, 90-day move, page URL. It clearly distinguishes itself from `search` by contrast, though it does not differentiate from siblings like `card_price` or `price_history` that sound thematically similar.
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?
Gives an explicit sequencing prerequisite ('use this after `search`') and clarifies it returns data for a single product rather than a list. It stops short of naming the similar-looking siblings (`card_price`, `price_history`) and when one would be preferred over this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for the most expensive or most valuable cards in one game right now. Returns up to 25 singles ranked by today's raw market price (USD) with set and printing. Raw prices only, not graded values.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam. | pokemon |
| limit | No | 1 to 25. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so safety is covered. The description adds real behavioral context beyond that: the result cap (25 singles), the ranking basis (today's raw market price in USD), the included fields (set and printing), and the important exclusion of graded values.
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 short sentences, all earning their place: trigger condition first, then ranking/return shape, then a scope caveat. Nothing is padded or restated from the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be spelled out, yet the description still orients the agent on cap, ordering and currency. For a read-only, two-parameter, defaulted query tool, nothing needed to invoke it correctly 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 description coverage is 100% with only two parameters (a game enum and a limit), so the schema already carries the parameter meaning. The description's 'one game' and the 25-cap statement loosely echo the parameters but add no format or syntax detail beyond 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 names a specific resource (singles cards) plus the ordering and scope ('ranked by today's raw market price', 'in one game right now'), which implicitly separates it from siblings like all_time_highs, price_history and movers. An agent can pick this tool without opening the schema.
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 an explicit trigger ('Use this when the user asks for the most expensive or most valuable cards in one game right now'), which is clear contextual guidance. It stops short of naming an alternative tool or stating when not to use it, so it doesn't reach the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks which cards in one game rose or fell the most
recently. Returns the biggest percentage moves over the last days (1 to 90) for
cards worth $5 or more, with the start and end market price in USD. Describes past
moves only; not a prediction.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Look-back window, 1 to 90 days. | |
| game | No | Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam. | pokemon |
| limit | No | 1 to 100. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the $5 minimum value filter, the 1-90 day window, that start and end market price in USD are returned, and that it is descriptive of past moves rather than predictive.
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, front-loaded with the use case, then output semantics, then the non-prediction caveat. No sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be spelled out, yet the description still summarizes what comes back (biggest percentage moves with start/end USD price). Nothing an agent needs to call this correctly 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 description coverage is 100%, so the schema already documents days, game, and limit; the description only restates the 1-90 range for days and adds the $5 worthiness threshold. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: the biggest percentage movers in a single game over a recent window. It is readily distinguishable from siblings like all_time_highs/all_time_lows (absolute extremes) and price_history (single-card series).
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?
Gives an explicit trigger ("Use this when the user asks which cards in one game rose or fell the most recently"). It does not name alternative siblings or state when NOT to use it, but the trigger condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks whether a card's price is going up or down, how it
moved over a period, or what it was worth on a past date. Returns the daily market
price per printing for the last days days (7 to 1000; history starts February
2024, later for newer cards) in USD. Past prices only, no forecasts.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many recent days, 7 to 1000. | |
| product_id | Yes | TickerMint product_id from search_cards. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond them: daily granularity, per-printing output, USD currency, the 7–1000 day range, February 2024 history start (later for newer cards), and the no-forecast limitation.
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 tight sentences with zero waste. The usage trigger is front-loaded, followed by return granularity, then the past-only limitation.
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, annotations covering safety, and 100% schema description coverage, the description still supplies the key behavioral context an agent needs: when to call it, what period it returns, and that it excludes forecasts.
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 schema documents both parameters. The description adds the historical-start caveat and the 'later for newer cards' nuance that affect interpretation of `days`, though it repeats the 7–1000 range already in the schema and adds nothing extra for `product_id`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Returns) and resource (daily market price per printing), and scopes it to historical data with 'Past prices only, no forecasts.' This historical, past-only scope distinguishes it from current-price or all-time-high/low siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly enumerates triggering user questions: whether a price is going up or down, how it moved over a period, or what it was worth on a past date. It also gives an exclusion ('no forecasts'), but does not name sibling alternatives such as card_price or all_time_highs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks about sealed product prices in one game: booster boxes, elite trainer boxes, bundles, packs, tins and cases. Returns today's market price (USD) and 30-day percent change per product, most expensive first. For one named product, search_cards plus card_price is more direct.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam. | pokemon |
| limit | No | 1 to 300. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive behavior, and the description adds return semantics: today's USD market price, 30-day percent change, sorted most-expensive-first. It does not cover pagination or what happens with non-matching games, but the added output behavior goes meaningfully beyond the annotation set.
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, zero filler, and the intent trigger is front-loaded before the return-format and alternative-tool guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values need not be spelled out further; annotations cover the safety profile; the description supplies the selection trigger, the alternative tool, and the sort/return shape. Nothing an agent needs to invoke this correctly 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 both parameters (game enum, limit range) are fully documented in the schema, so the description correctly does not duplicate them. It adds no syntax or defaulting nuance beyond the structured data, so 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?
States a specific verb+resource ('sealed product prices in one game') and enumerates the covered product types (booster boxes, ETBs, bundles, packs, tins, cases), which cleanly separates it from siblings like set_prices or 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?
Explicit trigger ('when the user asks about sealed product prices in one game') plus an explicit alternative for the adjacent case: 'For one named product, search_cards plus card_price is more direct.' Both when-to-use and when-to-use-something-else are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to look up trading cards or sealed products (Pokemon, One Piece,
Lorcana, Riftbound, Yu-Gi-Oh, Gundam) by name. Returns up to 10 matches with ids
to pass to fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Card or sealed product name. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, non-openWorld, so the safety profile is covered. The description adds real behavioral value beyond them: a hard result cap of 10 matches and the fact that results are ids intended as input to `fetch`, which shapes how the agent should chain calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, and the front-loaded clause pairs the action with the supported franchises. The follow-up-tool hint is placed last, which is the right ordering for an agent that reads the first sentence to route.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value detail is rightly omitted, and the description still adds the result-count cap and the `fetch` handoff. The one gap is sibling disambiguation against `search_cards`, which a one-clause addition would close.
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?
There is a single parameter with 100% schema description coverage ('Card or sealed product name'), so the schema already carries the semantics. The description's phrase 'by name' restates that at a high level without adding format, matching, or normalization details, so the baseline of 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?
States a specific verb (look up) and resource (trading cards or sealed products) with named supported franchises, so the agent knows exactly what domain it searches. It does not, however, distinguish itself from the sibling `search_cards`, which appears to cover overlapping territory, leaving the agent to guess which search tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context (look up by name) and a concrete follow-up path: the returned ids are passed to `fetch`. It stops short of any when-not guidance, e.g. it never says when to prefer `search_cards` over this tool, which is the obvious ambiguity given 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 this when the user names a trading card or sealed product and you need its TickerMint product_id (required by card_price and price_history) or its set id (group_id, required by set_prices). Returns up to 25 matches with name, set, collector number, the latest raw market price in USD and the page URL. Covers Pokemon, One Piece, Lorcana, Riftbound, Yu-Gi-Oh and Gundam only.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | Limit to one game (pokemon, one-piece, lorcana, riftbound, yugioh, gundam). Omit to search every game. | |
| limit | No | Results to return, 1 to 25. | |
| query | Yes | Card or product name, optionally with set or collector number, e.g. 'charizard ex 199/165'. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the 25-result cap, the exact fields returned, and a hard domain restriction (only six games supported), which prevents futile calls for unsupported titles.
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 tight sentences, front-loaded with the trigger condition, then outputs, then coverage limits. Slight redundancy with the output schema in enumerating return fields, but nothing is wasted or buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an existing output schema, the description needn't detail returns, yet it supplements with the game-coverage constraint and the ID-resolver role. An agent has everything needed to call this correctly and route results to 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%, documenting game, limit (1-25), and query format, so the schema carries the heavy lifting. The description reinforces the 25 cap and the product_id/group_id output meaning, but adds no syntax detail the schema lacks. 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?
States a specific verb (search) and resource (cards/sealed products), and crucially explains the output's purpose: resolving a product_id or group_id needed by named sibling tools. An agent can distinguish this from card_price, price_history, and set_prices without opening any schema.
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?
Clearly says when to use it ('when the user names a trading card or sealed product and you need its product_id...') and names the downstream tools that consume the result. It does not, however, distinguish itself from the sibling 'search' tool or state exclusions, leaving a small ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what a set is worth, what it costs to complete, or which cards in one set are the most valuable. Returns the cost to complete the set in singles today (one copy of each collector number at its cheapest printing, USD, the same figure as the set page), the master set total (every printing we price, labeled separately), the 25 most valuable singles and the 10 priciest sealed products of the set, plus companion sets that ship in the same packs but are catalogued separately (for example a Classic Collection or Trainer Gallery subset) with their own totals. Needs a group_id from search_cards.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Set id (group_id) from search_cards. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context about how costs are computed (one copy of each collector number at cheapest printing, USD, same figure as set page), that the master set total is labeled separately, and that companion sets are catalogued separately with their own totals.
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 usage scenario in the first sentence and then details the return contents before closing with the prerequisite. It is longer than average but every sentence contributes relevant scope or output detail for a complex set-pricing tool. It could be tightened slightly, but it is well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description need not explain return values, yet it provides enough context to understand what the tool returns and when to call it. Annotations cover the safety profile, the schema covers the parameter, and the description covers scope, usage, and output composition. Nothing an agent needs to call it correctly 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 description coverage is 100%, so the single parameter is already fully documented in the schema. The description repeats the same information ('Needs a group_id from search_cards') without adding syntax, format, or source details beyond the schema. Baseline 3 is appropriate when the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it returns set-level pricing aggregates including cost to complete, master set total, top singles, sealed products, and companion set totals. This clearly distinguishes it from siblings like card_price (single-card pricing) and most_valuable (likely cross-set rankings) by scoping everything to one set.
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 to use this when the user asks what a set is worth, what it costs to complete, or which cards in one set are most valuable. It also gives the prerequisite (group_id from search_cards). It does not name alternative tools or conditions when not to use it, which keeps it from a 5.
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.
all_time_highs3 fields changedInput schema / properties / game / descriptionAdded value: +"Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam."Input schema / properties / game / enumAdded value: +[
+ "pokemon",
+ "one-piece",
+ "lorcana",
+ "riftbound",
+ "yugioh",
+ "gundam"
+]Input schema / properties / limit / descriptionAdded value: +"1 to 200."all_time_lows3 fields changedInput schema / properties / game / descriptionAdded value: +"Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam."Input schema / properties / game / enumAdded value: +[
+ "pokemon",
+ "one-piece",
+ "lorcana",
+ "riftbound",
+ "yugioh",
+ "gundam"
+]Input schema / properties / limit / descriptionAdded value: +"1 to 200."card_price1 field changedInput schema / properties / product_id / descriptionAdded value: +"TickerMint product_id from search_cards."fetch1 field changedInput schema / properties / id / descriptionAdded value: +"Product id from `search` results."most_valuable3 fields changedInput schema / properties / game / descriptionAdded value: +"Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam."Input schema / properties / game / enumAdded value: +[
+ "pokemon",
+ "one-piece",
+ "lorcana",
+ "riftbound",
+ "yugioh",
+ "gundam"
+]Input schema / properties / limit / descriptionAdded value: +"1 to 25."movers4 fields changedInput schema / properties / days / descriptionAdded value: +"Look-back window, 1 to 90 days."Input schema / properties / game / descriptionAdded value: +"Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam."Input schema / properties / game / enumAdded value: +[
+ "pokemon",
+ "one-piece",
+ "lorcana",
+ "riftbound",
+ "yugioh",
+ "gundam"
+]Input schema / properties / limit / descriptionAdded value: +"1 to 100."price_history2 fields changedInput schema / properties / days / descriptionAdded value: +"How many recent days, 7 to 1000."Input schema / properties / product_id / descriptionAdded value: +"TickerMint product_id from search_cards."sealed_prices3 fields changedInput schema / properties / game / descriptionAdded value: +"Card game, one of: pokemon, one-piece, lorcana, riftbound, yugioh, gundam."Input schema / properties / game / enumAdded value: +[
+ "pokemon",
+ "one-piece",
+ "lorcana",
+ "riftbound",
+ "yugioh",
+ "gundam"
+]Input schema / properties / limit / descriptionAdded value: +"1 to 300."search1 field changedInput schema / properties / query / descriptionAdded value: +"Card or sealed product name."search_cards4 fields changedInput schema / properties / game / anyOfPrevious value: -[
- {
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "pokemon",
+ "one-piece",
+ "lorcana",
+ "riftbound",
+ "yugioh",
+ "gundam"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Input schema / properties / game / descriptionAdded value: +"Limit to one game (pokemon, one-piece, lorcana, riftbound, yugioh, gundam). Omit to search every game."Input schema / properties / limit / descriptionAdded value: +"Results to return, 1 to 25."Input schema / properties / query / descriptionAdded value: +"Card or product name, optionally with set or collector number, e.g. 'charizard ex 199/165'."set_prices1 field changedInput schema / properties / group_id / descriptionAdded value: +"Set id (group_id) from search_cards."all_time_highsall_time_lowscard_pricefetchmost_valuablemoversprice_historysealed_pricessearchsearch_cardsset_pricesTrading card prices and grading ROI for 1.5M+ Pokémon, Magic, Yu-Gi-Oh! and sports cards. Read-only.
Live TCG card and decklist prices for AI assistants. 22+ games, no account, ready-to-buy links.
Daily EU card prices, deals, EU-vs-US arbitrage and spike alerts for 19 card games.
Pokémon card and sealed prices, recent eBay sales, sets, Market Pulse, and active eBay listings.
Add one secure layer between your agents and this server.