Daily TCGplayer market prices, price history since 2024, sold comps by condition, PSA 10 floors and boards (most valuable, movers, all-time highs and lows, sealed product) for Pokemon, One Piece, Lorcana, Riftbound, Gundam and Yu-Gi-Oh cards. Read-only, no API key. Every answer carries the TickerMint page URL for citation.
Scored across 11 tools
Several tools have unclear boundaries: `search` and `search_cards` both find cards/sealed products by name, and `card_price` and `fetch` both return per-printing price data for a single product. This overlap will cause agents to pick the wrong tool in common workflows.
All tool names use lowercase snake_case, but the pattern is inconsistent: some are verbs (`fetch`, `search`, `search_cards`), some are noun phrases (`card_price`, `set_prices`, `price_history`), and some are descriptive labels (`movers`, `most_valuable`, `all_time_highs`). The names are readable but do not follow a single verb_noun convention.
11 tools is a reasonable size for a TCG pricing server and covers a broad range of price lookups. However, `search`/`search_cards` and `card_price`/`fetch` are near-duplicates, so the count is slightly higher than the actual functional surface needs.
The tool set covers core workflows: searching, current prices, historical trends, movers, set prices, and sealed products. The main gap is that there is no direct way to enumerate all sets or games without relying on search, but this is a minor limitation rather than a critical missing workflow.
Cards that set an all-time high in the last 7 days and still hold it.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | pokemon | |
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the filter condition but does not disclose whether this is a read-only lookup, how results are ordered, whether current price is included, or any other behavior. The output schema covers return shape, but behavioral traits beyond the filter are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler, and the core filter is front-loaded. Every word earns its place; any under-specification is a completeness issue rather than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values and there are no required parameters, which lowers complexity. However, with no annotations, no parameter guidance, and no usage context, the description is only minimally viable for an agent deciding whether and how to 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 description coverage is 0%, so the description needed to compensate by explaining game and limit, but it mentions neither. The parameter names are somewhat self-explanatory and have defaults, which keeps this above 1, but the description adds no meaning 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 identifies the resource (cards) and a precise condition: all-time high in the last 7 days and still holding it. This clearly distinguishes it from the sibling all_time_lows. It lacks an explicit verb like 'list' or 'return', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings like all_time_lows or movers. The only usage cue is inferential: use it when you want cards at all-time highs. There are no explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cards worth $5+ sitting at their all-time low after falling at least half from their high.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | pokemon | |
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal useful selection semantics: cards worth $5+, at all-time low, and down at least 50% from high. However, it does not mention defaults, ordering, pagination, or any other runtime behavior beyond the filter criteria.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with no filler or redundancy. Every phrase contributes to defining the tool's purpose and selection criteria.
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 adequately conveys the core filter logic, and an output schema is present, so return-value details are covered elsewhere. However, with zero parameter documentation and no usage context, the overall definition is only minimally complete for an agent deciding how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the 'game' or 'limit' parameters. It adds no meaning beyond what the bare input schema already shows, so an agent has no guidance on valid values or parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as cards meeting specific all-time-low criteria, and its wording inherently distinguishes it from sibling all_time_highs. However, it lacks an explicit verb such as 'lists' or 'returns,' so it is more of a noun-phrase definition than a fully specified action.
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 criteria imply the tool should be used when the user wants cards at all-time lows that have fallen significantly from their highs. There is no explicit guidance about when to prefer this over siblings like all_time_highs or movers, and no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's price for one product: market price per printing (Normal, Holofoil, Reverse Holofoil...), the lowest listing, the date, and the page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior, and it does list the returned data fields. However, it does not explicitly state that the operation is read-only, nor does it address edge cases such as invalid product IDs, missing prices, or how multiple printings are structured. The output schema exists and likely covers return types, but the description adds limited behavioral context beyond the field list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with the core purpose front-loaded before a clear colon-delimited list of returned fields. Every phrase earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the primary return content and scope. However, it omits usage guidance, alternative tool routing, and parameter semantics, leaving an agent to infer when and how to call it. It is adequate but not 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 description coverage is 0%, so the description must compensate for the undocumented product_id parameter. It only says 'for one product,' which implies product_id identifies a product, but it does not explain what kind of ID it is, where to find it, or how it should be formatted. This is minimal compensation for a parameter with no schema-level description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning today's price for one product, listing specific data points like market price per printing, lowest listing, date, and page URL. It is distinguishable from sibling tools such as price_history and set_prices by emphasizing 'today' and 'one product,' though it lacks an explicit verb like 'retrieve' or 'get.'
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 phrase 'for one product' implies the tool is for single-product current-price lookups, but there is no explicit guidance on when to prefer this over price_history, sealed_prices, or set_prices. No alternatives or exclusion conditions are mentioned, leaving usage largely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one product by id: today's prices per printing, 30 and 90 day moves, page URL.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses what data will be returned, and 'Fetch' implies a read-only operation, but it does not describe error behavior, required permissions, rate limits, or other operational traits. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence: the verb and resource come first, followed by a colon-separated list of return contents. Every word contributes meaning, with no filler or 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 available and only one required id parameter, the description covers the main contract well: what the tool fetches and what it returns. It omits explicit error handling and alternative-tool guidance, but those are not critical for a simple single-product fetch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, and the description only clarifies that 'id' refers to a product id. Since there is only a single simple string parameter, this minimal clarification is sufficient, though no format or source details are given.
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 ('Fetch') and resource ('one product by id'), and lists the key returned data (today's prices per printing, 30/90 day moves, page URL). This makes it distinguishable from broad search/list siblings, though it does not explicitly name any alternative tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies when to use the tool: when you have a product id and need that product's price summary and page URL. However, it does not explicitly state when not to use it or name alternative sibling tools, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most valuable cards right now for a game (raw near-mint TCGplayer market), plus the highest PSA 10 floors. Games: pokemon, one-piece, lorcana, riftbound, gundam.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | pokemon | |
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose the market source and PSA 10 floors, but it does not mention data availability, sorting guarantees, limit behavior, or any constraints. This is minimal behavioral disclosure for a tool with zero annotation support.
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 primary purpose is front-loaded, and the supported games list is concise and relevant. 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?
An output schema exists, so return values need no explanation. The description defines the tool's scope and enumerates game options, which is sufficient for a simple two-parameter tool. Minor gap: the limit parameter is not described, but its name and default make it inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning by enumerating supported games for the game parameter (pokemon, one-piece, lorcana, riftbound, gundam), but it does not explain the limit parameter at all. The game values are helpful, but limit semantics are left to inference from the parameter name.
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 purpose: returning the most valuable cards for a supported game, with clear market source (raw near-mint TCGplayer) and additional PSA 10 floor data. It distinguishes from siblings like all_time_highs and all_time_lows by emphasizing 'right now' current value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use when you need the current most valuable cards for a game. There is no explicit mention of alternatives or when not to use this tool, but the 'right now' framing gives some context relative to historical siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Biggest price gainers and losers over days (1 to 90) for a game, cards over $5.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| game | No | pokemon | |
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the time-window range (1 to 90 days), the game scope, and the $5 card price cutoff. However, it does not mention ordering, whether gainers and losers are returned together, or how the limit parameter affects results.
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 delivers the essential scope, time bounds, and price filter without wasted words. The most important qualifiers are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and only three simple parameters, the description is minimally adequate. The main gaps are the missing limit semantics and lack of usage differentiation from adjacent siblings, but the tool's core behavior is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It explains 'days' with a range and implies 'game' through context, but it does not explain 'limit' at all, leaving one of three parameters semantically undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as price movers for a game, with a specific time window and price threshold. It does not use an explicit verb like 'list' or 'get', and it does not differentiate itself from siblings such as all_time_highs or all_time_lows, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like all_time_highs, all_time_lows, or price_history. The description implies a use case but does not provide conditions, exclusions, or sibling routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Daily market price history per printing for the last days days (max 1000;
history starts February 2024). Use it for trend questions: up or down, since when.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds useful constraints: daily granularity, a configurable `days` window, a maximum of 1000 days, and the February 2024 data start. It does not discuss output structure or edge cases, but an output schema exists to cover return 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?
Two concise sentences with important constraints and the intended use case placed early. There is no filler, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives the key constraints, data availability window, and intended use case, while the output schema handles return-value details. It is slightly incomplete on how `product_id` maps to 'printing' and on explicit alternatives for non-trend price questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for `days` (max 1000 and history start date), but `product_id` is only implied by 'per printing' and is not explained in terms of how to identify a product or printing. This is partial but not complete compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning daily market price history per printing over a configurable window. It adds a use case ('trend questions: up or down, since when'), which distinguishes it from current-price siblings, but it never names an alternative tool explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use it: for trend questions such as whether prices are up or down and since when. It does not explicitly state when not to use it or point to sibling tools like card_price for current price queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Booster boxes, elite trainer boxes, bundles, packs and tins priced today, by kind.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | pokemon | |
| limit | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It usefully states that prices are 'today' and grouped by kind, implying a read-only snapshot. However, it does not mention how the game or limit parameters affect results, nor any output ordering or formatting behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the key product scope is front-loaded. It is efficient, though its brevity means it sacrifices useful detail that would make the structure more informative.
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 two-parameter tool with an output schema, the description plus schema provides enough to make a default call. But it lacks tool-selection context and parameter semantics, so an agent is not fully equipped to use it correctly across likely scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention 'game' or 'limit' at all, and 'by kind' refers to product type, not the game filter. An agent would have to guess what values game accepts or how limit interacts with the grouped results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as current prices for sealed product types (booster boxes, ETBs, bundles, packs, tins). This distinguishes it from card-focused tools like card_price and set_prices, though it lacks an explicit verb like 'get' or 'fetch', so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings such as set_prices or card_price. There are no exclusions, prerequisites, or selection criteria beyond the product-scope hinted at by the phrase 'by kind.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search TickerMint for cards and sealed products. Returns ids for fetch.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It usefully discloses that the tool returns IDs intended for fetch, which is meaningful. It does not mention result limits, pagination, empty-result behavior, or read-only guarantees, but the output schema may cover return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action is front-loaded, and the output behavior is stated efficiently. Every word 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 one-parameter search tool, the description covers the search domain and output purpose, and an output schema exists. However, it lacks sibling differentiation, query-parameter guidance, and behavioral details that would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the undocumented query parameter. The agent must infer that 'query' is the search term; no guidance is given about query format, matching semantics, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Search TickerMint for cards and sealed products.' It also clarifies the output purpose with 'Returns ids for `fetch`,' distinguishing this search-and-ID step from the fetch tool that consumes the IDs. The scope ('cards and sealed products') helps differentiate it from the sibling search_cards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Returns ids for `fetch`' implies a two-step workflow: search first, then fetch by ID. However, there is no explicit guidance about when to prefer this tool over search_cards or other siblings, and no exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find cards or sealed products by name (e.g. "charizard ex 199/165"). Returns
product_id, name, set, number, latest market price and the page URL. game is
one of pokemon, one-piece, lorcana, riftbound, gundam; omit for every game.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure burden. It does disclose return fields and the effect of omitting `game`, but it does not mention ordering, pagination, error behavior, data freshness, or how `limit` affects results. This is a reasonable read-only search tool description but not fully transparent.
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 with no filler. The purpose is front-loaded, the return fields are compactly listed, and the game parameter explanation is placed last without bloating the description.
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 purpose, search example, game filter, and return fields. An output schema exists to further specify return values, reducing the burden on the description. Minor gaps remain around `limit` behavior and result ordering, but the tool is simple enough that this is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains `query` with a concrete example and enumerates the accepted `game` values, but it does not describe `limit` semantics, acceptable formats, or matching behavior. Partial compensation only.
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 and resource ('Find cards or sealed products by name'), includes a concrete example query, and lists what is returned. This makes the tool's purpose unmistakable and distinguishes it from sibling tools like card_price or price_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful filtering guidance for the `game` parameter but never explains when to use search_cards instead of sibling tools such as search, card_price, or sealed_prices. There is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every card in a set with today's price, the most valuable cards, and the set's total market value. Set ids come from search results (group_id).
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses the output contents (today's price, most valuable cards, total market value), which is the core behavior for a read-only pricing tool. It does not mention limitations, freshness, or error behavior, but for this simple query tool the disclosure is adequate though not rich.
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 concise sentences with no filler. The first sentence front-loads what the tool returns, and the second adds the essential parameter provenance. 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?
The tool is simple (one required parameter), and an output schema exists, so return details do not need to be in the description. The description covers what the tool returns and where group_id comes from. Minor gaps remain around when to choose this tool over sibling pricing tools, but nothing essential for a correct call 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 0%, so the description must compensate. It does add meaning by explaining that group_id is a set id and that it comes from search results. However, it does not provide format details, examples, or a range, so it only partially compensates for the absent schema description.
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 that the tool returns every card in a set with today's price, the most valuable cards, and the set's total market value. This is a clear resource and output scope, and 'set ids come from search results' clarifies the input domain. It does not explicitly name a sibling to differentiate from, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides useful contextual guidance: set ids come from search results (group_id), which tells an agent how to obtain the required parameter. However, it does not state when to prefer set_prices over alternatives like card_price or most_valuable, nor does it give any exclusions.
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_highsall_time_lowscard_pricefetchmost_valuablemoversprice_historysealed_pricessearchsearch_cardsset_prices
Add one secure layer between your agents and this server.