lorcana-mcp

Overview Schema Source Related Servers Discussions Admin

what_am_i_missing

Compare a deck list against your collection to see which cards you own, which are missing or short, and the estimated cost to complete the deck before buying or playtesting.

Instructions

Compare a deck list against your collection: what you already own, what's missing or short, and the estimated cost to complete it — the shopping-list counterpart to analyze_deck, which checks curve/legality but never looks at ownership.

Cross-references a raw deck list (same format as analyze_deck: 4x Card Name per line) against an enriched collection CSV. Card names are matched the same simple exact-then-substring way as lookup_card (not fuzzy like resolve_card); a name that doesn't resolve is dropped from the "Already have"/"Missing" tallies and listed separately under an "unresolved" section instead of being silently skipped — check that section if the totals look short. For every card you're short on, price comes first from the CSV's own TCG Market Price if you already own at least one printing (no network needed); only cards you own zero copies of fall back to a live TCGPlayer lookup via tcgcsv.com for the cheapest printing across all sets/rarities (gameplay is identical regardless of rarity or art). That fallback fetch only fires if at least one card actually needs it, and its price data is cached 24h — the reported total is always a snapshot, not a quote.

Usage guidelines: use this once you have a specific decklist in hand (hand-written, or build_deck's output) and want to know what to buy or borrow before playtesting it. It doesn't check Core Constructed legality or curve — run analyze_deck on the same list for that. If instead you want a deck built around what you can realistically complete rather than checking a fixed list, use build_deck(mode="ideal"), which folds this same ownership/pricing logic into deck construction itself.

Args: deck_list: Raw deck list text, one card per line (e.g. "4x Goofy - Musketeer"). collection_csv: Absolute path to an enriched Lorcana collection CSV.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`deck_list`	Yes
`collection_csv`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.7Aug 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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, and it does so richly. It discloses name-matching rules (exact-then-substring, not fuzzy), unresolved-name handling, output sections, pricing source order (CSV TCG Market Price first, tcgcsv.com fallback only for zero-owned cards), 24h caching, and that the total is a snapshot rather than a quote.

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?

Front-loads purpose and remains well structured with clear usage guidelines and args sections. Some pricing and matching details are verbose, but most sentences earn their place given the tool's complexity; a small amount could be trimmed without losing correctness.

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?

Given no annotations, low schema description coverage, and an existing output schema, the definition supplies all context an agent needs: scope, alternatives, matching behavior, failure handling, pricing logic, and usage sequence. Return values are covered by the output schema, so the description need not explain them further.

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

Parameters4/5

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, and it does for both required parameters: deck_list format and example, and collection_csv as an absolute path to an enriched CSV. It stops short of enumerating expected CSV columns, but for a 2-param tool with a sibling enrich_csv, the description adds meaningful semantics beyond the bare schema.

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?

States a specific comparison: deck list vs. collection, returning owned/missing/short cards and estimated completion cost. It explicitly distinguishes itself from analyze_deck (curve/legality) and build_deck(mode="ideal") (deck construction), so an agent can select it correctly without opening sibling schemas.

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?

Gives exact when-to-use criteria: after obtaining a specific decklist and before playtesting/buying. It names alternatives and the conditions that select them: analyze_deck for legality/curve, build_deck(mode="ideal") when building around collection constraints, and lookup_card/resolve_card for matching behavior.

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

Deploy Server