Skip to main content
Glama

list_printings

Compare every printing of a Lorcana card or all cards sharing a character name. See set, number, cost, stats, rarity, format legality, and cheapest price to pick the right version.

Instructions

List every printed version of a Lorcana card — or every card sharing a character name — side by side: each one's set, card number(s), cost, stats, rarity, per-format legality, and the cheapest market price to acquire it.

Reach for this whenever the answer depends on which printing: "is any Milo Thatch legal in Core?", "which Elsa is cheapest?", "did this card ever get an Enchanted?", "what's the current-set version vs. the rotated-out one?". lookup_card silently collapses to just the newest printing; this shows them all.

Matching, in order: exact full name ("Elsa - Spirit of Winter"); exact character name ("Elsa" → every distinct Elsa card); full-name substring; then a fuzzy resolve. A bare character name lists every subtitle; a full name lists that one card's base + Enchanted/Epic printings. Enchanted and Epic printings are gameplay-identical to the base — they only change the number, rarity, and price, which is exactly what this tool compares.

fmt (optional): one of core, infinity, core_ja, core_zh, poorcana, coconut. When given, adds a legality column for just that format and lists legal cards first. Legality/images come from duels.ink and prices from tcgcsv.com (a daily TCGPlayer mirror); both are fetched live, cached 24h, and shown as "?" / omitted (never errored) when unavailable.

Args: name: A card's full name, or a bare character name. fmt: Optional play format to flag legality for.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fmtNo
nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.3.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: live data sources (duels.ink for legality/images, tcgcsv.com for prices), 24h caching, graceful-degradation behavior ('shown as "?" / omitted (never errored)'), and the gameplay-relevant fact that Enchanted/Epic printings differ only in number/rarity/price. This is behavior an agent cannot infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and routing are front-loaded in the first two paragraphs, which is ideal. However, the trailing 'Args:' block restates the `fmt` details and `name` semantics already given in prose, adding some redundancy to an already long description for a two-parameter tool.

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

Completeness5/5

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

An output schema exists, so return values need not be explained, and the description covers everything else an agent needs: matching behavior, format handling, data provenance, and failure modes. Nothing essential is missing for correct invocation.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate and it does: the `fmt` enum values are enumerated (core, infinity, core_ja, core_zh, poorcana, coconut) along with its effect (adds a legality column, sorts legal cards first), and `name` matching is spelled out as an ordered resolution chain, including how a bare character name differs from a full name.

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

Purpose5/5

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

The opening sentence names a specific verb+resource ('List every printed version of a Lorcana card') and the scope (all printings side by side), then explicitly distinguishes itself from the sibling: 'lookup_card silently collapses to just the newest printing; this shows them all.' An agent can route between the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the exact selection condition ('Reach for this whenever the answer depends on which printing') and reinforces it with four representative questions, plus the explicit alternative (lookup_card) and why it is wrong for these cases. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.