Gundam Card Game cards, prices, tournament meta, and your Deckodex collection and decks.
Scored across 17 tools
Most tools have clearly distinct purposes (card search vs. collection vs. meta vs. pricing). The closest overlap is between buildable_meta_decks and best_buys, as both deal with completing decks, but their descriptions (one for deck access, one for purchase advice) keep them separable. Slight ambiguity also exists between get_archetype and get_meta_deck, but the id-based flow resolves it.
The naming uses three different conventions: get_* for lookups, my_* for user data, and standalone noun phrases (best_buys, buildable_meta_decks, market_movers, price_list) plus a few imperative verbs (save_deck, search_cards, update_collection, validate_deck). This is readable and each prefix has meaning, but the lack of a single consistent verb_noun pattern prevents a higher score.
At 17 tools, the count is slightly above the typical well-scoped range of 3-15, but the server covers a broad domain (card catalog, pricing, meta analysis, collection, deck management). Each tool addresses a distinct need, so the count feels justified rather than bloated. It is borderline but still reasonable for the feature set.
The core flows are solid: search/get cards, view meta, manage collection counts, save/validate decks, and track value. However, deck management is incomplete (save_deck only creates, with no update or delete), and card list support is one-directional (add_to_list exists but no view or remove). Pricing and meta coverage are thorough, but these missing lifecycle operations are notable gaps.
Add cards to one of the signed-in user's card lists (wishlists, trade binders…). Pass listId from a previous result, or listName — an existing list with that name is reused, otherwise a new one is created. printId picks a specific printing from get_card (default: its standard released printing). Up to 20 items per call. Deckodex Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| listId | No | ||
| listName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations give little signal (all false), so the description carries the load. It discloses side effects (a new list is created if listName doesn't exist), default printId behavior, and the 20-item per call limit. It does not cover possible failure modes or return behavior, but the main side effects are 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 tight and front-loaded; the first sentence states purpose. The only questionable sentence is 'Deckodex Pro.' which adds little to invocation, but overall the text is short and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description leaves a few gaps: it does not say what happens if both listId and listName are omitted (both are optional in the schema), and it does not describe the response shape. It covers the main selection logic but not the complete contract.
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 fully compensates: it explains listId (from a previous result), listName (reused/created), printId (from get_card with default), and the items limit. Only count is left to the schema, which already documents min/max.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add cards to one of the signed-in user's card lists (wishlists, trade binders…)' which makes the tool's purpose unambiguous. It does not explicitly name sibling tools to differentiate, but the 'card lists' concept distinguishes it from collection/deck 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 provides concrete guidance on when to use by specifying the target context (signed-in user's card lists) and how to choose a list via listId or listName, including the reuse-or-create behavior. However, it never contrasts it with alternatives like update_collection or save_deck, so an agent must infer when this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deckodex Pro: the single cards that move the signed-in user closest to completing current tournament decks per money spent, given what they already own — with how many copies to buy, the cost, and which decks each one advances. fromPct/toPct are percentages (0-100) of a deck's copies the user owns before/after buying.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | No | Format code like GD05; omit for the latest | |
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds meaningful behavioral context: results are cost-optimized, personalized, and include before/after ownership percentages via fromPct/toPct. It does not reveal return structure or data staleness, but the annotations lower the burden and the added context is useful.
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 and front-loaded with the core purpose, followed by one clarifying sentence about percentage semantics. It is slightly long but every clause earns its place; no filler or redundant restatement of annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only three optional parameters and no output schema, the description gives enough context to understand the recommendation behavior and key output fields. Minor gaps exist: the exact return shape is not described and fromPct/toPct appear without explicit confirmation that they are output fields, but the overall tool is simple enough that the description is nearly 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 already documents format and source well, while limit is constrained with defaults but not described. The description adds semantics for fromPct/toPct, but those are not actual input-schema properties, which may confuse parameter mapping. Overall, the description does not substantially compensate for the 67% schema coverage and the undocumented limit parameter.
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, personalized purchase-advice verb/resource: 'the single cards that move the signed-in user closest to completing current tournament decks per money spent.' It also lists concrete output aspects (copies to buy, cost, decks advanced), which clearly separates it from siblings like price_list or buildable_meta_decks.
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 makes the usage context clear: it is for a signed-in user, based on their existing collection, and oriented to current tournament decks. It does not explicitly name alternatives or say when not to use it, but the context is strong enough for an agent to infer the right scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tournament decks the signed-in user is closest to completing from their collection, one per archetype, closest first — with how much they own, what's missing and the cost to finish.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| format | No | Format code like GD05; omit for the latest | |
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent, so safety is covered. The description adds value by revealing output specifics: one per archetype, sorting by closeness, and including ownership/missing/cost details. No contradictions 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?
A single, dense sentence that front-loads the key action ('Tournament decks') then efficiently details scope, sorting, and output content. No wasted words or redundant 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?
For a read-only tool with no output schema, this is nearly complete. It explains both the output (decks, missing items, cost) and ordering. Minor gaps: how 'closest' is measured isn't specified, and it doesn't state whether the collection source is the my_collection tool, but these are inferable from the sibling set.
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 67% (format and source have descriptions; limit has constraints). The description adds context that cost is involved, which ties to the source parameter, and implies limit controls the number of decks shown. This complements the schema without repeating 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 states a specific verb and resource: lists tournament decks the user is closest to completing, with details like ownership, missing cards, and cost. It clearly differentiates from siblings like get_meta_deck (single deck) or my_collection (card list) by focusing on buildable decks from the user's collection.
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 context is clear: it's for the signed-in user viewing their own collection, and the title 'Meta decks I can almost build' reinforces when to use it. However, it does not explicitly name alternatives or state when not to use it, though the sibling set makes this inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One archetype in a format: meta share and results, its most-played cards with average copies, and its latest top tournament decklists (use get_meta_deck for a full list).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format code like GD05; omit for the latest | |
| archetype | Yes | Archetype name or slug, as returned by get_meta |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond annotations by disclosing the composition of the returned data — meta share, results, most-played cards with average copies, and decklists — which warns the agent about the scope of the payload. Minor gaps: 'latest' and 'results' are not precisely bounded, but with rich annotations the bar is lower.
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 of about 30 words carries the full purpose, scoping condition, output contents, and an alternative-tool pointer. The primary function is front-loaded ('One archetype in a format') and the sibling reference is placed at the end. Every clause earns its place 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 no output schema, the description carries the return-contract burden, and it discharges it well by enumerating the four data groups an agent can expect. Parameters are fully covered by the schema and safety by annotations. The only real gap is ambiguity about how many 'latest top tournament decklists' are returned and what 'results' encompasses, which is minor for a read-only informational 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 100%, with both 'format' and 'archetype' clearly documented in the input schema, including the format-code default behavior and the archetype reference back to get_meta. The description adds no parameter-level detail beyond what the schema already provides, 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?
The description names a specific resource ('One archetype in a format') and enumerates exactly what is returned: meta share, results, most-played cards with average copies, and latest top tournament decklists. It also distinguishes itself from get_meta_deck by pointing out the scope difference, so an agent can tell it apart from siblings without inspecting schemas.
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 explicit routing guidance for the closest sibling ('use get_meta_deck for a full list'), and the framing 'One archetype in a format' implies the selection condition: use this when you want a single archetype's detailed breakdown. It lacks a full when/when-not matrix across all siblings, but the key alternative is named with a condition, which is more than most tools provide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details for one card: stats, effect text, keywords, official rulings, every printing with current prices (TCGplayer USD, CardTrader EUR, Cardmarket EUR) and 30/90-day change + all-time high (d30Pct/d90Pct are percentages, e.g. 12.5 = +12.5%; d90Pct may be null for CardTrader until 90 days of history exist), and where it sees tournament play. Cards with spoiler: true are pre-release reveals (hand-transcribed, may change before release).
| Name | Required | Description | Default |
|---|---|---|---|
| cardNumber | Yes | Card number, e.g. GD01-001 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond these: it explains the format of d30Pct/d90Pct (percentages, null possibility for CardTrader) and the spoiler flag indicating pre-release cards that may change. These are meaningful data semantics that help the agent interpret results correctly, going beyond the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then lists the returned data types. It is detailed but each clause adds necessary information (e.g., price sources, percentage formats, spoiler caveat). It is not overly verbose relative to the complexity, though it could be slightly tightened by grouping related items. Overall it is well-structured and earns a high score.
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 complex with many return fields and no output schema. The description compensates thoroughly by enumerating all major data categories, clarifying percentage semantics, noting the null case for d90Pct, and explaining the spoiler caveat. This gives the agent a complete picture of what to expect, making the description fully adequate for correct invocation and result interpretation.
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 description covers the single parameter cardNumber at 100% coverage with an example ('GD01-001'). The tool description does not add any extra parameter-specific details, so the baseline of 3 is appropriate. The description focuses on the return payload rather than the parameter.
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 verb 'get' and the resource 'one card', then enumerates the specific data returned (stats, effect text, keywords, rulings, printings with prices, tournament play). This level of specificity makes it unambiguous that this tool retrieves comprehensive details for a single card, distinguishing it from siblings like search_cards or price_list without needing to name them.
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 you have a specific card number and need full details. It provides clear context but does not explicitly mention when not to use it or name alternatives. Since it says 'Full details for one card', an agent can infer this is the tool for a single-card lookup, but there is no explicit routing guidance to alternatives like search_cards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The tournament meta for a format: every archetype with its tier, meta share, deck count and top-8 count, built from recent tournament results. Defaults to the latest format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format code like GD05; omit for the latest |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond annotations: it is 'built from recent tournament results' and it 'Defaults to the latest format', which discloses the default-value behavior an agent needs to know. 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?
Two sentences with zero waste. The core purpose and output fields are front-loaded in the first sentence, and the default behavior is in the second. 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?
Complete for a simple read-only list tool: one optional parameter, rich annotations covering safety/idempotency, and the description enumerates the return contents (archetype, tier, meta share, deck count, top-8 count) so no output schema is needed. 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?
With 100% schema description coverage, baseline is 3. The single 'format' parameter is well documented in the schema ('Format code like GD05; omit for the latest'). The description's 'Defaults to the latest format' largely echoes the schema, adding only marginal value. It does not add format-code syntax 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?
The description states a specific verb+resource: 'The tournament meta for a format', enumerates exact output fields (tier, meta share, deck count, top-8 count) and the data source (recent tournament results). This clearly distinguishes it from siblings like get_archetype (a single archetype), get_meta_deck (a specific deck), and get_card (a card lookup).
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 context — it is the overall meta snapshot — but never explicitly names alternatives or says 'use this for the whole meta, not a single archetype/deck'. The sibling distinction is inferable from the sibling names (get_archetype, get_meta_deck) but no explicit when-to-use or when-not-to guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A full tournament decklist by id (ids come from get_archetype and buildable_meta_decks): placement, event, price to build, cards, and paste-ready decklist text.
| Name | Required | Description | Default |
|---|---|---|---|
| deckId | Yes | ||
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context beyond these: it reveals a dependency on other tools for id acquisition and describes the output contents (including paste-ready text). No contradictions exist; the added detail is useful and non-redundant.
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, efficient sentence that front-loads the core purpose, lists the output components, and adds the id source without extraneous words. Every clause earns its place, making it highly scannable for an agent.
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 there is no output schema, the description adequately enumerates the return fields. It also covers the dependency on other tools. It does not mention the optional source parameter, but the schema already documents that. Minor omissions like error cases or rate limits are not critical for a read-only, idempotent get-by-id operation, so the description is sufficiently 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 only 50%: the deckId parameter has no schema description, while source has a description. The tool description compensates for deckId by explicitly stating that ids come from get_archetype and buildable_meta_decks, giving the agent a clear source for valid values. For source, the schema already explains its semantics, so the description adds no new meaning, but overall the gap is adequately addressed.
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 fetches a full tournament decklist by id, enumerates the returned contents (placement, event, price, cards, paste-ready text), and specifies that ids come from get_archetype and buildable_meta_decks. This is a specific verb-resource pairing that distinguishes it from sibling tools like get_archetype or get_meta.
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 clear context by indicating that deck ids originate from get_archetype and buildable_meta_decks, which tells the agent when this tool is appropriate (after obtaining an id). It does not explicitly state when not to use it or mention alternatives, but the guidance is sufficient for sequencing and selection.
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 across the Gundam Card Game market over the last 7 days or month, by percentage or by absolute change. Prices in the user's preferred currency unless source is given. changePct is a percentage (e.g. 12.5 = +12.5%), matching get_card's convention.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | pct = percentage change, abs = change in money | pct |
| limit | No | ||
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. | |
| window | No | 7D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds some useful context by explaining the preferred-currency behavior and the changePct percentage convention matching get_card, but it does not describe return format or ordering in detail.
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 sentences with the core behavior front-loaded, followed by pricing and percentage conventions. It is compact and contains no filler, though the first sentence somewhat restates the title and schema options.
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 read-only market query with optional parameters and no output schema, the description covers the main behavior, time windows, change metrics, currency behavior, and percentage format. It is sufficient for an agent to call the tool correctly, though an explicit output shape would make it 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 only 50%, and the description compensates by adding meaning beyond the schema: it clarifies that changePct is a percentage with an example and that prices use the user's preferred currency unless a source is given. Limit and window semantics remain mostly schema-only, but those are fairly self-explanatory enums.
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 that the tool returns the biggest price gainers and losers across the Gundam Card Game market, with explicit time windows and change metrics. This is specific enough to identify what the tool does and to distinguish it from collection-focused siblings such as my_collection or get_card.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like best_buys, price_list, or get_card, and no exclusions are given. The only usage cues are implicit in the market-wide scope, so an agent is left to infer the intended choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The signed-in user's collection. With no arguments: totals and per-set completion. With cardNumbers: how many copies of each card they own (all printings combined).
| Name | Required | Description | Default |
|---|---|---|---|
| cardNumbers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond annotations: the tool is scoped to the signed-in user, behavior differs with and without arguments, and cardNumbers aggregate across all printings. It does not describe output format or edge cases, but the annotation coverage lowers that burden.
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 resource, and uses a clear conditional structure for the two invocation modes. Every phrase adds information; there is no repetition or 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?
For a simple read-only tool with one optional parameter and no output schema, the description covers the main invocation modes and what the user can expect to get back. Minor gaps remain, such as the exact shape/format of the returned totals and completion data, and overlap with sibling tools is not addressed.
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 low, but the description compensates by explaining what cardNumbers does: it returns how many copies of each requested card the user owns, combining all printings. The schema already provides the format example and array constraints; the description adds the aggregation semantics and the no-argument mode.
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 what the tool does: it reads the signed-in user's collection and provides totals, per-set completion, or owned copies for given cardNumbers. It is specific about behavior based on arguments, but it does not explicitly distinguish itself from siblings like my_set_completion, which likely overlaps on the per-set completion aspect.
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 explicit usage context: call with no arguments for totals/completion, or with cardNumbers for per-card copy counts. It does not, however, mention when to prefer alternative tools such as my_set_completion or my_collection_value, so it lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What the signed-in user's Gundam collection is worth now and how it changed over the last 7 days and month. Deckodex Pro adds longer ranges (3M, 6M, 1Y, ALL), the recorded value history, value by set, top holdings and the biggest gainers/losers in their binder.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | holdings = today's cards at past prices; recorded = the value Deckodex actually recorded each night (Pro) | holdings |
| range | No | 1M | |
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to restate those. It adds genuinely useful behavioral context beyond the annotations: Pro-only longer ranges, recorded value history, value by set, top holdings, and gainers/losers. It does not describe output format, but the annotations carry the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core purpose is front-loaded, and the second sentence efficiently enumerates Pro capabilities without restating schema fields or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with three optional, well-schemaed parameters and no output schema, the description gives enough high-level context about what values are returned and which features require Pro. It does not detail the exact response shape, but the annotations and schema cover the operational essentials.
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?
With 67% schema description coverage and detailed mode/source descriptions already present, the baseline is near 3. The description adds value by clarifying that 3M/6M/1Y/ALL ranges are Pro additions and by mentioning the 'recorded value history' concept tied to the recorded mode. Source semantics are not enriched, but the schema already covers them.
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 (signed-in user's Gundam collection) and the purpose (current worth and change over 7 days/month). It is specific enough to distinguish this from sibling tools like my_collection or price_list, though it uses a noun-phrase framing rather than an explicit action verb.
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 for collection valuation and change-over-time questions, and it notes that longer ranges are Pro-only. However, it does not explicitly say when to prefer this tool over siblings such as best_buys, market_movers, or my_collection, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The signed-in user's saved decks. With no arguments: the list. With deckId: that deck's cards, rule checks, which cards they still need to own, and the cost to finish it.
| Name | Required | Description | Default |
|---|---|---|---|
| deckId | No | ||
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive profile. The description adds behavioral value by specifying the two invocation modes and the exact data points returned (cards, rule checks, missing cards, cost). This gives the agent a richer understanding of output behavior beyond what annotations state.
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 compact sentences with no filler. The resource is front-loaded, and the conditional behavior is organized clearly by argument presence. Every word contributes to understanding.
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 read-only tool with optional parameters and no output schema, the description adequately covers invocation modes and return contents. It could elaborate on the list format or error handling, but annotations and the schema fill the remaining essential 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?
The schema documents 'source' but leaves deckId without a description. The description compensates by explaining deckId's role and the resulting output. Together, the schema and description fully explain both parameters, and the description adds meaningful semantics for deckId.
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 resource (the signed-in user's saved decks) and the two modes: list all decks without arguments, or retrieve a specific deck's cards, rule checks, missing cards, and finish cost with deckId. It is specific enough to distinguish from collection-level tools like my_collection, but it does not explicitly compare against sibling deck tools such as validate_deck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear argument-dependent usage: no arguments returns the list, deckId returns deck details. However, it provides no guidance on when to prefer this tool over alternatives like validate_deck or get_meta_deck, so the appropriate context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How complete the signed-in user's collection is per set — unique cards, playsets (4 of each) or master set (every printing) — and what it costs to finish, using their saved Deckodex targets. With set: that set's rarity breakdown.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | Set code, e.g. GD05 | |
| mode | No | Omit to use the user's Deckodex setting | |
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about depending on the user's saved Deckodex targets and the conditional rarity breakdown when set is provided, which are not conveyed by annotations or schema alone.
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 in the first sentence, and the second sentence adds a conditional detail without redundancy. It is concise and 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?
The tool is read-only with three optional parameters and no output schema. The description explains the core functionality, the dependency on saved user settings, and the conditional behavior of the set parameter. While return format is not specified, the absence of an output schema makes this less critical. Overall, the description is sufficient for an agent to understand the tool's purpose and likely invocation.
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 all three parameters (set, mode, source) are documented in the schema. The description adds extra meaning for the set parameter by noting it triggers a rarity breakdown, which goes beyond the schema's simple 'Set code' explanation. This is a meaningful addition.
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 a specific verb ('How complete'), resource (signed-in user's collection per set), and distinguishes from siblings like my_collection and my_collection_value by focusing on per-set completion status and cost-to-finish. It also mentions the optional rarity breakdown with the set parameter, adding specificity.
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 through the description of what the tool computes, but there is no explicit statement of when to use this vs alternatives like my_collection or my_collection_value. No exclusions or alternative routing is provided, so the agent must infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The most valuable Gundam cards overall, in one set (slug or set code, e.g. gd05) or in one rarity tier, most expensive first, with 30/90-day change and Cardmarket's price alongside.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | Set slug or set code (e.g. gd05), or rarity slug or code (e.g. lr-plus or LR+) | |
| limit | No | ||
| scope | No | all | |
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds value by detailing the output includes 30/90-day change and price. However, it doesn't disclose default behavior (scope defaults to 'all', limit defaults to 10) or that source can be tcgplayer or cardtrader. The mention of 'Cardmarket's price' alone could mislead agents into assuming only one source is available, which contradicts the schema's enum.
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, well-structured sentence that front-loads the core purpose ('most valuable Gundam cards') and then adds details on scoping and output. No redundancy or fluff.
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 listing tool with four parameters and no output schema, the description covers the core function but misses default parameter values and the full set of price sources. The single mention of 'Cardmarket's price' is incomplete given the schema allows tcgplayer and cardtrader. Overall adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers slug and source with descriptions; the description clarifies that slug can be a set code or rarity slug, and explains the sorting. Limit and scope are not elaborated beyond the schema's enums, but the phrase 'in one set or rarity tier' hints at scope usage. Partial value is added, but the description doesn't fully compensate for the 50% schema coverage.
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 that the tool returns the most valuable Gundam cards, sorted by price descending, with 30/90-day change and price info. It specifies the resource (cards) and the key output fields. It doesn't explicitly differentiate from siblings like market_movers or best_buys, but the 'most valuable' focus gives a distinct purpose.
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 explicit guidance on when to use this tool versus alternatives like market_movers or best_buys. It implies usage for valuation queries but doesn't state exclusions, conditions, or when to prefer another tool. The description only provides context on scope (set/rarity) without routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a decklist as a NEW deck in the signed-in user's Deckodex account (never overwrites an existing deck). One card per line, e.g. '4 GD05-019'. Deckodex Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| decklist | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=false, meaning the tool is not destructive. The description adds that it 'never overwrites an existing deck', which provides explicit behavioral context beyond annotations. It also mentions the Pro feature, which is useful. However, it doesn't disclose potential side effects like how it interacts with the user's account or if it requires specific permissions, but the 'never overwrites' is a valuable addition.
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, using three sentences with no filler. The key behavior ('as a NEW deck', 'never overwrites') is front-loaded, followed by a necessary format example that directly aids correct invocation. The 'Deckodex Pro' note is relevant and earns its place. It is well-structured and efficient.
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 relative simplicity with only two parameters and no output schema, the description is fairly complete. It covers the purpose, the new-deck behavior, and the decklist format. However, it lacks details on possible errors (e.g., invalid card codes) or whether the tool creates a new entry in 'my_decks'. The absence of siblings' differentiation is a minor gap, but overall adequate for the 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?
With a schema description coverage of 0%, the description must compensate for undocumented parameters. It does provide a concrete format example for 'decklist' ('4 GD05-019') and specifies 'one card per line', which adds semantics. However, it doesn't explain the 'name' parameter beyond its schema (max 80 chars), and it doesn't clarify how the decklist string is parsed or if errors return. This is partial compensation but not complete.
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 saves a decklist as a new deck in the user's Deckodex account, with a specific verb 'save' and resource 'deck'. It distinguishes from 'update_collection' and 'my_decks' by emphasizing 'new' and 'never overwrites', though it doesn't explicitly name a sibling alternative unlike the high-calibration example. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the action—saving a NEW deck and never overwriting—which implicitly sets the context for use (creating a new deck). However, it doesn't explicitly state when NOT to use this tool or how it differs from sibling tools like 'validate_deck' or 'add_to_list'. The line about 'Deckodex Pro' hints at a prerequisite but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Gundam Card Game catalog. All filters combine with AND. Returns up to 25 cards with their deckodex.com links. Use get_card for full details, effect text and prices of one card. Cards with spoiler: true are pre-release reveals (hand-transcribed, may change before release).
| Name | Required | Description | Default |
|---|---|---|---|
| sets | No | Set codes, e.g. GD05 or ST08 | |
| limit | No | ||
| query | No | Free text over name, effect text, card number and traits, e.g. 'Strike Freedom' or 'Blocker' | |
| types | No | ||
| colors | No | ||
| traits | No | ||
| costMax | No | ||
| costMin | No | ||
| keywords | No | Keyword effects, e.g. Blocker, Repair, First Strike |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context: filters combine with AND, returns up to 25 cards with deckodex.com links, and spoiler cards are pre-release and may change. This goes beyond 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 three sentences, front-loaded with the purpose, and each sentence adds unique value: purpose, filter behavior/limit, alternative routing, and spoiler caveat. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, and no required fields, the description gives enough to start (search, AND logic, link output, spoiler caution) but omits details like sorting, pagination beyond the limit, and the exact structure of returned cards. It also doesn't clarify the distinction between traits and keywords, which could be ambiguous. 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 only 33%, so the description must compensate for the undocumented parameters. It adds the global AND-combining rule and the 25-card limit, but it does not explain the semantics of types, colors, traits, costMin/costMax, or limit beyond what the schema already provides. The low coverage and minimal compensation leave the agent guessing on several parameters.
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 verb 'Search' and the resource 'the Gundam Card Game catalog'. It distinguishes itself from the sibling get_card by explicitly saying 'Use get_card for full details, effect text and prices of one card', so an agent can easily tell them apart.
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 routes to get_card when full details of a single card are needed, providing a clear alternative. It implies the tool is for filtering/searching but doesn't state 'use this when...' explicitly, and it doesn't mention other alternatives like price_list or my_collection. However, for a search tool, the main alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Change owned counts in the signed-in user's collection. mode 'add' adds copies; mode 'set' sets the exact count (0 removes). Counts clamp to 0–99. Up to 20 rows per call; each row reports before/after, and a bad row doesn't block the others. printId picks a specific printing from get_card (default: its standard released printing). Deckodex Pro.
| Name | Required | Description | Default |
|---|---|---|---|
| changes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds beyond that: clamping behavior, row limits, per-row error isolation, and the '0 removes' semantics. It also notes that printId defaults to the standard released printing, which is non-obvious. This provides actionable detail without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with multiple sentences, but each sentence adds a distinct piece of information: mode behavior, clamping, row limit, error isolation, and printId default. It is front-loaded with the main purpose and avoids fluff, though the density could be slightly streamlined. Still, 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?
For a mutation tool with destructiveHint=true and no output schema, the description covers all critical calling constraints: how to specify changes, limits, error handling, and defaults. It also hints at the response format ('each row reports before/after'), giving the agent a clear picture of what to expect. Nothing essential is missing for a correct call.
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%—only cardNumber has a description. The description explains the meaning of 'mode' ('add' vs 'set'), the effect of count (including 0 removal and clamping), the role of printId, and the row limit. It fully compensates for the missing schema descriptions, making parameters self-explanatory.
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 verb 'Change' and the resource 'owned counts in the signed-in user's collection', distinguishing it from read-only siblings like my_collection. It also specifies the two modes ('add' and 'set') and the effect of 'set' with 0, which uniquely identifies this as the update 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?
The description provides explicit behavioral context: mode semantics, count clamping (0–99), row limit (up to 20), partial failure (a bad row doesn't block others), and the default for printId. While it doesn't name alternative tools for when not to use it, the context is specific enough that an agent can infer when to call this tool for collection updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a decklist against the deck rules (50-card main deck, max 4 copies, max 2 colors, banlist, sideboard) and price it. One card per line, e.g. '4 Strike Freedom Gundam (GD05-019)' or '4 GD05-019'; a 'Side Deck' line starts the sideboard.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Price source: tcgplayer (USD) or cardtrader (EUR). Omit to use the user's Deckodex preference. | |
| decklist | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the exact rules checked, the input format (one card per line, examples, side deck marker), and the fact that it also prices the deck. It does not describe the output structure, but given the annotations, this is a moderate addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and then provides concrete input examples. Every word adds value—there is no fluff or repetition, and it is 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 explains the input and the rules checked, but it does not describe the return value. Since there is no output schema, the agent is left guessing what the tool returns (e.g., a validation report, a price, a boolean). This is a notable gap for a tool that checks multiple rules and computes a price; the description should at least hint at the response 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 50%: source has a description, but decklist has none. The description compensates by detailing the decklist format ('One card per line, e.g. ...' and 'a Side Deck line starts the sideboard'), which adds meaning beyond the schema. It also confirms the source semantics by referencing the user's Deckodex preference, already in the schema, so the added value is primarily for decklist.
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: 'Check a decklist against the deck rules... and price it.' It enumerates specific rules (50-card main deck, max 4 copies, max 2 colors, banlist, sideboard) and distinctively positions it as a validation-and-pricing tool, clearly different from siblings like save_deck or price_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what the tool does and the input format, implying it should be used when a user wants to validate and price a decklist. However, it does not explicitly state when not to use it or mention alternatives (e.g., 'use save_deck after validation' or 'use price_list for single cards'), so it lacks explicit exclusion guidance.
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.
add_to_listbest_buysbuildable_meta_decksget_archetypeget_cardget_metaget_meta_deckmarket_moversmy_collectionmy_collection_valuemy_decksmy_set_completionprice_listsave_decksearch_cardsupdate_collectionvalidate_deckHong Kong TCG marketplace (MTG + Riftbound): search cards, read live prices, manage your listings.
TCGdex MCP — multi-language open trading card game database (Pokémon TCG and more).
Scryfall MCP — Magic: The Gathering card database.
MTG market data: search 114K+ cards, price signals, AI analysis. Free tier available.
Add one secure layer between your agents and this server.