What can you do with this server?

The lorcana-mcp server provides tools for searching, analyzing, and managing Disney Lorcana cards and decks. * Search and filter cards by name, color, type, cost, stats, keywords, text, set, rarity, and more, with pagination, sorting, and an optional TOON-encoded output (≈10% token savings). * Count cards that match any combination of filters. * Aggregate cards by cost (ink curve), rarity, color, set, or type for distribution breakdowns. * Resolve card names using fuzzy matching to find the closest official cards with full data. * Get top traits across all available cards. * Export decks to Dreamborn/Pixelborn-compatible plain text lists. * Import decks from text lists, resolving card names and suggesting candidates for unmatched lines. * Validate decks against format rules (min 60 cards, max 4 copies per card, max 2 ink colors). * Analyze deck statistics including ink curve, color split, inkable counts, type breakdown, keyword/subtype counts, and per-card keyword tags. * Guided deck building via a prompt that assists in assembling a legal deck for chosen colors and playstyles. * Check server status for startup metadata (card count, configuration). Cards are stored in-memory for fast filtering, with daily data refreshes and local JSON caching.

How do I use lorcana-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lorcana-mcp Show me all legendary amber cards" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

lorcana-mcp

by danielenricocahall

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Disney Lorcana MCP Server

MCP Badge

An MCP server that lets Claude (or any MCP client) search, analyze, and build decks for the Disney Lorcana TCG. Ask for cards in plain English, get rules-checked deck validation, ink curves and keyword breakdowns, and round-trip deck lists with Dreamborn/Pixelborn.

2,506 unique cards (3,192 printings including alternate arts and promos), refreshed daily. No API key, no database, no rate limits — the server ships against a snapshot published from our own pipeline, so it never depends on a third-party API being up at query time.

Tools

Tool	What it does
`search_cards`	Filter and retrieve cards by name, color, cost, rarity, type, keyword, stats, set, and body text. Supports `response_format="toon"` for ~10% fewer tokens
`count_cards`	Count cards matching a filter without paying for the card objects
`aggregate_cards`	Group counts by `cost` (ink curve), `rarity`, `color`, `set_code`, or `type`
`resolve_card`	Fuzzy-match an informal, partial, or misspelled card name to the closest cards
`top_traits`	Most common traits (Storyborn, Hero, Villain, Ally, ...) across all cards
`validate_deck`	Check a deck against format rules (≥60 cards, max 4 copies, ≤2 inks, dual-ink requirements); returns `{legal, total_cards, inks, violations}`
`deck_stats`	Ink curve, color split, inkable count, type breakdown, keyword counts, subtype counts, and per-card keyword tags
`import_deck`	Parse a Dreamborn/Pixelborn deck list into resolved cards, with fuzzy candidates for unresolved lines
`export_deck`	Render a deck back out as a Dreamborn/Pixelborn-compatible text list
`server_status`	Startup metadata (card count, configuration)

Related MCP server: lorcana-oracle

Install

uvx (recommended — no clone, no Docker)

uvx lorcana-cards-mcp

Claude Desktop / claude_desktop_config.json:

{
  "mcpServers": {
    "lorcana": {
      "command": "uvx",
      "args": ["lorcana-cards-mcp"]
    }
  }
}

Claude CLI:

claude mcp add --scope user -- lorcana uvx lorcana-cards-mcp

pip / pipx

pipx install lorcana-cards-mcp   # then run: lorcana-cards-mcp

Docker

The server is also published to GHCR and the MCP Registry.

docker run --rm -i ghcr.io/danielenricocahall/lorcana-mcp:latest

{
  "mcpServers": {
    "lorcana": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "ghcr.io/danielenricocahall/lorcana-mcp:latest"]
    }
  }
}

To persist the card cache across container restarts, mount a volume:

docker run --rm -i \
  -e LORCANA_CACHE_PATH=/data/cards.json \
  -e LORCANA_SKIP_IF_DB_EXISTS=true \
  -v lorcana_mcp_data:/data \
  ghcr.io/danielenricocahall/lorcana-mcp:latest

From a clone

uv run python main.py

docker build -t lorcana-mcp:latest .
docker run --rm -i lorcana-mcp:latest

# or via compose
docker compose build
docker compose run --rm -T lorcana-mcp

No port is exposed; MCP communication is over stdio.

Example questions

Once connected to an MCP client, you can ask natural language questions like:

Card lookup

"Show me all cards named Moana"
"What does the card Maui - Hero to All do?"
"Find all legendary amber cards"

Deck building

"What are the cheapest ruby characters with at least 3 strength?"
"Show me inkable sapphire cards that cost 4 or less"
"Find steel characters with 5 or more willpower"
"What 3-lore characters exist in emerald?"

Keyword & ability search

"How many Singer cards cost exactly 5?"
"How many Evasive characters are there in the first set?"
"How many ruby cards have Reckless?"
"Find all cards with Ward in their text"
"Show me Shift cards in amethyst"

Stats & aggregations

"How many cards are in each set?"
"What's the color distribution across all cards?"
"What are the most common traits?"
"Show me the ink curve — how many cards exist at each cost?"
"How many legendary cards are inkable?"

Cross-filter queries

"How many amber characters have 3 or more lore?"
"Find cheap (cost 2-3) characters with high strength (4+) in steel"
"How many cards in set 1 have Evasive and cost less than 4?"

Note: For plain keyword queries (Evasive, Bodyguard, Shift, etc.) use the keyword parameter — it filters against the structured ability list and is more reliable than substring search. For value-specific queries like Singer 5 or Resist +2, use body_text (keyword values live in the card's full text, not the ability list).

MCP prompts

build_deck(colors, playstyle="balanced") — guides the model through assembling a legal Lorcana deck (60-card minimum, ≤2 inks, max 4 copies of any card) for the requested color(s) and playstyle (aggressive / control / lore-race / balanced). Uses the search/aggregate tools above plus the rules embedded in the server instructions.

Card data & startup behavior

On startup, the server fetches a JSON list of cards from https://danielenricocahall.github.io/lorcana-mcp/allCards.json. The snapshot is refreshed daily by data_pipeline/fetch_cards.py, which pulls from the Lorcast API, normalizes each card into our internal schema, and publishes the list to the gh-pages branch. That middle layer insulates running servers from Lorcast's availability and rate limits — the runtime never calls Lorcast directly.

Cards are kept in memory as a Python list for fast filtering. The dataset holds 2,506 unique cards, each carrying a printings array for its alternate sets, numbers, and rarities (3,192 printings in total). Consolidating printings onto one row per card means a search for "Elsa" returns each distinct Elsa once rather than repeating her for every promo reprint. A local JSON file cache (LORCANA_CACHE_PATH, default cards.json) lets the server skip the network fetch on subsequent startups.

Config

LORCANA_API (default: https://danielenricocahall.github.io/lorcana-mcp/allCards.json)
LORCANA_CACHE_PATH (default: cards.json) — local file for caching fetched cards
LORCANA_HTTP_TIMEOUT_SECONDS (default: 60)
LORCANA_REFRESH_ON_STARTUP (default: false) — true always fetches and repopulates storage
LORCANA_SKIP_IF_DB_EXISTS (default: true) — false fetches and repopulates even if the cache is populated

TOON response format

search_cards accepts a response_format argument:

"json" (default) — list of card objects, unchanged from prior versions.
"toon" — a TOON string with one column header line and one row per card, encoded by the toons Rust-backed library (the official community reference implementation).

Example (search_cards(name="elsa", limit=2, response_format="toon")):

cards[2]:
  - id: crd_01c4835a62df4960bb973aeff81f2bb2
    name: Elsa
    version: Ice Maker
    full_name: Elsa - Ice Maker
    cost: 7
    ...
    printings[3]{set_code,set_name,number,rarity}:
      "7",Archazia's Island,69,Super Rare
      C2,Lorcana Challenge Year 3,2,Promo
      C2,Lorcana Challenge Year 3,6,Promo
  - id: crd_04bca46a8e2d4e9ba0fbdbfc6c99e51e
    name: Elsa
    ...

The outer cards[2]: falls back to YAML-style per-card blocks (rather than a single tabular table) because card shapes vary — Actions and Items don't carry strength/willpower/lore, for example. The inner printings[N]{...}: block is fully tabular since every printing has the same four fields.

Benchmark

Measured with benchmarks/bench_toon.py against the live 2,506-card dataset, tokenizing with tiktoken cl100k_base (used as a proxy for Claude's tokenizer):

query	rows	JSON tokens	TOON tokens	Δ
`color="amber", limit=200`	200	44,101	39,680	−10.0%
`color="ruby", limit=50`	50	10,522	9,519	−9.5%
`card_type="action", limit=50` (sparse cols)	50	10,154	9,250	−8.9%
`body_text="when", limit=50` (long full_text)	50	11,602	10,391	−10.4%
`name="elsa", limit=20`	14	3,488	2,940	−15.7%
total		79,867	71,780	−10.1%

Note: TOON's relative savings are smaller here than they were before the printings consolidation (pre-PR-#29 the same queries showed ~50% reductions). That gap is structural to the nested printings array — TOON's columnar encoding wins on the top-level fields but falls back to JSON-style encoding inside the per-printing entries, so the array dilutes the relative gain. Absolute token counts are still down meaningfully versus the equivalent count of pre-consolidation rows, since each unique card is now represented once with a small printings list rather than as 1-3 separate full rows.

Reproduce with PYTHONPATH=. uv run python benchmarks/bench_toon.py (requires a populated cards.json cache).

Disclaimer

This is a personal, unofficial fan and engineering project. It is not affiliated with, endorsed by, sponsored by, or reviewed by Disney, Ravensburger, or the Disney Lorcana TCG team. It is built and distributed in accordance with Ravensburger's Disney Lorcana TCG Community Code, using only publicly available and community data sources. All Disney Lorcana TCG names, card text, trademarks, and related intellectual property belong to Disney and Ravensburger. This project is non-commercial and reflects my personal views only, not those of my employer.

MCP Registry ownership verification — the registry reads this line from the published package description to confirm this project owns the server name.

mcp-name: io.github.danielenricocahall/lorcana-mcp

Available Tools

10 tools

aggregate_cardsA

Return card counts grouped by a field. Valid fields: cost (ink curve), rarity, color, set_code, type. Examples: aggregate_cards('cost') for the ink curve, aggregate_cards('color') for color breakdown, aggregate_cards('rarity') for rarity breakdown, aggregate_cards('set_code') for set distribution.

ParametersJSON Schema

Name	Required	Description	Default
`field`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided; description lacks behavioral details such as read-only nature, rate limits, or output format, leaving agent uninformed.

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

Conciseness5/5

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

Two sentences, front-loaded purpose, includes examples, no wasted words.

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

Completeness3/5

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

Functional for basic use, but missing description of output structure despite available output schema; behavioral gaps reduce completeness.

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?

With 0% schema coverage, description adds examples and lists valid field values, compensating for schema gap.

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?

Clearly states it returns card counts grouped by a field, lists valid fields, and gives examples, distinguishing it from siblings like count_cards.

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

Usage Guidelines4/5

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

Provides valid field options and examples for use, but does not explicitly state when to avoid or name alternatives.

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

count_cardsA

Count cards matching the given filters. Use this for questions like 'how many ruby cards are there?' or 'how many evasive characters?'. Supports stat ranges: min_attack/max_attack, min_defence/max_defence, min_cost/max_cost. Use keyword to filter by Lorcana keyword (Bodyguard, Challenger, Evasive, Reckless, Resist, Rush, Shift, Singer, Sing Together, Support, Vanish, Voiceless, Ward, etc.) — matches against the structured ability list. Use body_text for value-specific keyword queries like 'Singer 5' or 'Resist +2', or for non-keyword phrases like 'gain 2 lore'. Use lore/min_lore/max_lore to filter by lore value. Use card_type to filter by card type: Character, Action, Item, Song, or Location. Use set_code to filter by set number (e.g. '1' for The First Chapter). Use set_name to filter by set name as a case-insensitive substring (e.g. 'Wilds Unknown', 'frozen') — preferred when the user names a set in plain English. Color must be one of: ruby, sapphire, emerald, amber, amethyst, steel.

ParametersJSON Schema

Name	Required	Description	Default
`cost`	No
`lore`	No
`name`	No
`color`	No
`trait`	No
`rarity`	No
`inkwell`	No
`keyword`	No
`max_cost`	No
`max_lore`	No
`min_cost`	No
`min_lore`	No
`set_code`	No
`set_name`	No
`body_text`	No
`card_type`	No
`max_attack`	No
`min_attack`	No
`max_defence`	No
`min_defence`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses filter behavior (e.g., case-insensitive substring for set_name, matches against structured ability list for keyword) and stat ranges. Some behavioral details like AND/OR logic for multiple filters are missing but overall it is transparent.

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 description is front-loaded with the purpose and usage examples. It is organized by parameter groups but could be more concise, especially the list of keywords. Most sentences add value.

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

Completeness4/5

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

Given the complexity of 20 parameters and no annotations, the description covers many filter options and their semantics. The presence of an output schema reduces the need to explain return values. However, it lacks explanation of how multiple filters combine (e.g., AND logic) and does not mention edge cases like no matches.

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

Parameters2/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. It explains many parameters (keyword, body_text, lore, card_type, set_code, set_name, color, stat ranges) but fails to explain several others like name, trait, rarity, inkwell, and the single cost parameter. With 20 parameters, coverage is insufficient.

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

Purpose4/5

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

The description states 'Count cards matching the given filters' and provides examples like 'how many ruby cards are there?' which clearly conveys the purpose. It does not explicitly differentiate from sibling tools like search_cards, but the verb 'count' distinguishes it effectively.

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

Usage Guidelines4/5

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

The description gives explicit examples of questions to use the tool for ('how many ruby cards are there?') and explains when to use keyword vs body_text. However, it does not mention when not to use this tool or suggest alternative tools.

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

deck_statsA

Compute summary stats for a Lorcana deck: ink curve (copies at each cost), color split (copies per color — dual-ink contributes to BOTH buckets, so the sum may exceed total_cards), inkable/uninkable counts, type breakdown (Character/Action/Item/Song/Location), keyword_counts (copies per keyword — Evasive, Ward, Bodyguard, Shift, Singer, ...), subtype_counts (copies per subtype — Floodborn, Hero, Puppy, ...), and card_keywords (per-card keyword tags, so archetype questions like 'how many Evasive bodies does this run?' are answerable without a follow-up search_cards call). Each entry is {name: str, count: int} where name is the card's full_name. Names that don't resolve are listed under unresolved and excluded from the per-card stats (but still counted in total_cards).

ParametersJSON Schema

Name	Required	Description	Default
`deck`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description carries full burden and succeeds: it discloses dual-ink counting behavior (sum may exceed total_cards), the handling of unresolved names (listed separately, excluded from per-card stats, still counted in total_cards), and the inclusion of per-card keyword tags.

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 description is a dense paragraph, but every clause adds specific information about a stat or edge case. It is longer than ideal, but the length is justified by the variety of stats. Slight chunking into bullets would improve scannability.

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

Completeness4/5

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

Output schema exists to cover return values, and the description thoroughly covers behavioral edge cases and stat semantics. The only minor gap is the implicit, not fully explicit, mapping from the deck parameter to the described entry format; otherwise it is complete for a tool of this complexity.

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

Parameters3/5

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

The `deck` parameter has zero schema coverage, but the description partially compensates by indicating each entry is `{name, count}` where name is the card's full_name and explaining how unresolved names are handled. It could be more explicit about the deck input format (e.g., that deck is the array of these entries), but enough meaning is added beyond the 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?

The description opens with an explicit verb and object ('Compute summary stats for a Lorcana deck') and enumerates all stat categories (ink curve, color split, inkable counts, type breakdown, keyword/subtype counts, card_keywords). This makes it clearly distinguishable from sibling search/count/aggregate tools.

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

Usage Guidelines4/5

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

It states a concrete benefit over an alternative ('answerable without a follow-up search_cards call'), which implies when to use this tool instead of searching. It does not explicitly enumerate when not to use it, but the scope (deck-level summarization) is clear.

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

export_deckA

Render a Lorcana deck as a Dreamborn/Pixelborn-compatible text deck list (<count> <full_name> per line, no sections, no set codes). Each entry is {name: str, count: int} where name is the card's full_name from search_cards (e.g. 'Mickey Mouse - Brave Little Tailor'). Returns plain text suitable for pasting into Dreamborn, Pixelborn, untap.in, or a Limitless tournament submission.

ParametersJSON Schema

Name	Required	Description	Default
`deck`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It accurately describes the output format and input requirements. It lacks details on error handling or authorization but is adequate for a read-only export tool.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the core purpose and includes all necessary details without redundancy.

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 the single parameter and clear return type (plain text), the description provides sufficient context. It explains the input structure and output format, making the tool complete for its intended use.

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?

The schema is minimal with additionalProperties: true. The description adds critical meaning by explaining that each array item must have 'name' and 'count' fields, with name being the full_name from search_cards. This compensates for the 0% schema coverage.

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 description clearly states the tool's purpose: rendering a Lorcana deck into a Dreamborn/Pixelborn-compatible text format. It specifies the output format, naming convention, and use cases, distinguishing it from siblings like import_deck or validate_deck.

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

Usage Guidelines4/5

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

The description implicitly indicates when to use the tool (for exporting decks to external platforms) and provides context about compatible tools. However, it does not explicitly state when not to use it or compare with alternatives.

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

import_deckA

Parse a Dreamborn/Pixelborn-style deck list (<count> <full_name> per line) into resolved card objects. Each line is matched to a card by exact full_name first; lines that don't match exactly are returned in unresolved with the top fuzzy candidates so the user can disambiguate. Returns {parsed: [{count, card}], unresolved: [{raw, candidates}]}. Blank lines, comments (#, //), totals (Total: 60), and bracketed section headers are silently skipped.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior5/5

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

No annotations provided, but the description fully discloses behavior: exact match first, fuzzy fallback, returned structure with parsed and unresolved, and silent skipping of blank lines, comments, totals, and section headers. No side effects or hidden constraints are omitted.

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

Conciseness5/5

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

Three sentences, front-loaded with purpose, then detail on matching behavior and output shape. Every sentence adds unique value without redundancy.

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 the output schema exists, the description covers input format, processing rules, and output structure comprehensively. It leaves no gaps for an agent to use the tool effectively.

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?

The single 'text' parameter has 0% schema coverage, but the description enriches it by specifying the expected format (`<count> <full_name>` per line) and what content is ignored. This provides essential guidance beyond the 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?

The description clearly states the tool parses a Dreamborn/Pixelborn-style deck list into resolved card objects, specifying input format and output structure. It distinguishes itself from siblings like export_deck and resolve_card by focusing on bulk parsing with fuzzy matching.

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

Usage Guidelines3/5

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

The description does not explicitly advise when to use this tool versus alternatives like resolve_card or search_cards for single cards, nor does it mention prerequisites or forbidden inputs. Usage context is implied but not directly communicated.

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

resolve_cardA

Resolve an informal, partial, or misspelled card name to the closest matching cards. Returns full card data (stats, abilities, cost, etc.) for each candidate — no follow-up query needed. Use this as follows:

'Tell me about / get stats for X' → call resolve_card only, use the result directly.
'Find cards that synergize with / work well with X' → resolve_card to get X's traits and abilities, then use those as inputs to search_cards.
'Build a deck with X' → resolve_card to identify X, then search_cards for supporting cards. Never call search_cards first when the user has named a specific card — resolve_card avoids failed searches and retry loops. Example: 'Maui Half Shark' resolves to 'Maui - Half-Shark' as the top result.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It states that the tool returns full card data (stats, abilities, cost, etc.) for each candidate, requiring no follow-up. It gives an example resolution. However, it does not explicitly state that the tool is read-only or that it performs no side effects. The behavioral disclosure is good but could be slightly more explicit.

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 description is front-loaded with purpose and includes structured bullet points for usage scenarios. Every sentence adds value, though it is slightly verbose. The example is helpful. Overall well-structured and efficient, but could be trimmed slightly without losing content.

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

Completeness4/5

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

Given the tool's complexity (fuzzy name resolution), schema coverage 0%, and existence of an output schema, the description provides adequate context. It explains when to use it versus search_cards and what it returns. However, it lacks detail on the matching algorithm or confidence levels. The output schema covers return values, so description is mostly sufficient.

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

Parameters3/5

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

Schema coverage is 0%, so description must compensate. It explains the 'query' parameter implicitly through examples (e.g., 'Maui Half Shark') but does not describe its format or constraints. The 'limit' parameter is not mentioned at all, despite having a default of 5. The description adds some meaning for query but insufficiently for both parameters.

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 description clearly states the tool resolves informal, partial, or misspelled card names to closest matching cards, returning full card data. It explicitly distinguishes from sibling tool search_cards, noting that when a specific card is named, resolve_card should be used instead to avoid failed searches. The verb 'resolve' and resource 'card name' are specific and unambiguous.

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?

The description provides explicit when-to-use scenarios: 'Tell me about X' -> use resolve_card directly; 'Find cards that synergize' -> resolve_card then search_cards; 'Build a deck' -> resolve_card then search_cards. It also gives a strong when-not-to-use: 'Never call search_cards first when the user has named a specific card.' This is comprehensive and prevents misuse.

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

search_cardsA

Search Lorcana cards with optional filters. Returns card objects (not counts). Color must be one of: ruby, sapphire, emerald, amber, amethyst, steel. Use card_type to filter by card type: Character, Action, Item, Song, or Location. Use min_attack/max_attack and min_defence/max_defence for stat-based queries (e.g. 'characters with 4+ strength'). Use min_cost/max_cost for cost ranges. Use keyword to filter by Lorcana keyword (Bodyguard, Challenger, Evasive, Reckless, Resist, Rush, Shift, Singer, Sing Together, Support, Vanish, Voiceless, Ward, etc.) — matches against the structured ability list, more reliable than substring search. Use body_text to search card ability text — useful for value-specific keyword queries like 'Singer 5' or 'Resist +2', or for non-keyword phrases like 'gain 2 lore'. Use lore/min_lore/max_lore to filter by lore value. Use sort_by to order results (id, name, cost, strength, willpower, lore, rarity, set_code); use sort_order='asc' or 'desc'. Use set_code to filter by set number (e.g. '1' for The First Chapter). Use set_name to filter by set name as a case-insensitive substring (e.g. 'Wilds Unknown', 'frozen', 'Floodborn') — preferred when the user names a set in plain English so you don't have to look up the code first. Use offset to paginate through results (e.g. offset=20 for the next page). Use count_cards instead if you only need a total count. Set response_format='toon' to receive a TOON-encoded string instead of JSON objects (~10% fewer tokens; the printings array is nested so the savings are smaller than a purely flat schema would yield); default is 'json'.

ParametersJSON Schema

Name	Required	Default
`cost`	No
`lore`	No
`name`	No
`color`	No
`limit`	No
`trait`	No
`offset`	No
`rarity`	No
`inkwell`	No
`keyword`	No
`sort_by`	No	id
`max_cost`	No
`max_lore`	No
`min_cost`	No
`min_lore`	No
`set_code`	No
`set_name`	No
`body_text`	No
`card_type`	No
`max_attack`	No
`min_attack`	No
`sort_order`	No	asc
`max_defence`	No
`min_defence`	No
`response_format`	No	json

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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 discloses that the tool returns card objects (not counts), explains the TOON encoding option for token savings, and implies read-only behavior through its search nature. However, it does not explicitly state that the operation is idempotent or free of side effects, which is acceptable given the context. The description is transparent enough for a search tool.

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 description is well-structured, starting with the core purpose and then systematically covering each parameter. It uses clear language and examples. While it is lengthy (necessary due to 25 parameters), it remains focused and every sentence contributes meaning. A slight deduction for verbosity at times, but overall efficiently organized.

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 the complexity of 25 parameters and the presence of an output schema, the description covers all essential aspects: parameter usage, pagination, sorting, output format options, and alternative tools. It provides complete guidance for an agent to correctly invoke the tool, including edge cases like set_name vs set_code. The description is thorough and leaves no critical gaps.

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?

With schema description coverage at 0%, the description fully compensates by explaining the purpose and usage of most parameters in detail. It lists valid color values, explains keyword vs body_text differences, provides sort_by options, and clarifies set_name preference over set_code. Only a few parameters like 'trait' and 'name' are not explicitly described, but the coverage is extensive and adds significant value beyond the 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?

The description clearly states the tool's purpose: 'Search Lorcana cards with optional filters.' It explicitly mentions it returns card objects (not counts), distinguishing it from count_cards. The verb 'search' combined with 'Lorcana cards' and the mention of filters makes the purpose specific and unambiguous.

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?

The description provides extensive guidance on when to use this tool versus alternatives, such as 'Use count_cards instead if you only need a total count.' It explains when to use specific parameters for different query types (e.g., keyword vs body_text, set_name vs set_code) and how to paginate with offset. This gives clear context for usage.

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

server_statusA

Show startup metadata for this server instance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

Without annotations, the description carries the burden. It states 'Show' implying a read-only operation, but does not elaborate on metadata content or side effects. Adequate given no parameters.

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

Conciseness5/5

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

A single, clear sentence with no unnecessary words. Every part serves the purpose.

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

Completeness4/5

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

Given the simplicity (no parameters, trivial purpose) and the presence of an output schema (presumably detailing return format), the description sufficiently covers what the tool does.

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?

No parameters exist (0 params, 100% schema coverage), so the description need not add parameter details. Baseline score of 4 is appropriate.

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 description specifies a clear verb ('Show') and resource ('startup metadata for this server instance'). It distinguishes the tool from siblings, which focus on cards and decks.

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

Usage Guidelines3/5

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

No explicit guidance on when or when not to use this tool, but the purpose is straightforward (server status check) and alternative tools are unrelated, so usage can be inferred.

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

top_traitsC

Return most common traits.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2/5.0

Behavior1/5

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

With no annotations, the description must disclose behavior. It only states 'return most common traits' with no mention of side effects, data source, ordering, or limitations. Completely opaque.

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

Conciseness3/5

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

Extremely concise (3 words), but at the expense of clarity. It could be expanded slightly without becoming verbose.

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

Completeness2/5

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

The tool is simple but the description lacks context about what 'traits' are, expected input/output, and how it relates to sibling tools. The output schema exists but is not described.

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

Parameters2/5

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

The only parameter 'limit' has a default of 10 but the description does not explain its meaning (e.g., maximum number of traits). Schema coverage is 0%, so description should compensate but fails.

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

Purpose3/5

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

The description 'Return most common traits' identifies a verb and resource, but 'traits' is vague and not differentiated from sibling tools like 'aggregate_cards'. It lacks specificity about what traits are (e.g., card traits).

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

Usage Guidelines1/5

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

No guidance on when to use this tool versus alternatives. The description gives no context or exclusions, leaving the agent to guess.

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

validate_deckA

Validate a Lorcana deck against the format rules: at least 60 cards (no maximum — 60 is just the floor), max 4 copies of any card, max 2 distinct ink colors across the deck. Each entry is {name: str, count: int} where name is the card's full_name (e.g. 'Mickey Mouse - Brave Little Tailor'). Returns {legal: bool, total_cards, inks, violations: [...]}. Violation types: deck_size (under 60 — total below minimum), max_copies (>4 of one card), ink_limit (>2 distinct colors — also catches dual-ink cards adding a forbidden third color), unknown_card (name didn't resolve to a known card). If you have the output of import_deck, build the input as [{name: card.full_name, count: count}] for each parsed entry.

ParametersJSON Schema

Name	Required	Description	Default
`deck`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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 details the validation rules, violation types (deck_size, max_copies, ink_limit, unknown_card), and return structure. It does not mention side effects (assumed read-only) or error handling beyond unknown_card, but the behavioral disclosure is substantial.

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

Conciseness4/5

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

The description is well-structured, starting with purpose, then rules, input format, return format, violation types, and usage note. It is slightly long but every sentence adds value. Could be slightly more concise.

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 the complexity of deck validation (multiple rules) and the existence of an output schema, the description is complete. It covers all rules, violation types, input format, return structure, and integration with import_deck. The output schema likely details return fields, so the description need not repeat them.

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?

The input schema has only one parameter 'deck' with minimal type info (array of objects, additionalProperties true). The description adds critical meaning: each entry must be {name: str, count: int} with name as card.full_name, provides an example, and explains how to build from import_deck output. This fully compensates for the 0% schema coverage.

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 description clearly states the tool validates a Lorcana deck against format rules, specifying the verb 'validate' and resource 'deck'. It distinguishes from sibling tools like import_deck (which parses a deck) and deck_stats (likely summary).

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

Usage Guidelines4/5

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

The description provides clear context for use: validating a deck after importing via import_deck. It explains the input format and how to build it from import_deck output. However, it does not explicitly mention when not to use this tool or alternatives like search_cards for resolving unknown cards.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv2.2.0Jul 7, 2026
- First observedaggregate_cards
- First observedcount_cards
- First observeddeck_stats
- First observedexport_deck
- First observedimport_deck
- First observedresolve_card
- First observedsearch_cards
- First observedserver_status
- First observedtop_traits
- First observedvalidate_deck

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-08-05 05:45 across 10 tools

Disambiguation5/5

Each tool targets a distinct task: search returns card objects, count returns totals, aggregate returns grouped counts, top_traits returns trait frequencies, resolve_card handles fuzzy name matching, and the deck tools each handle import, export, validation, or stats. No two tools overlap in purpose, and the descriptions make the boundaries clear.

Naming Consistency3/5

Most tools follow a verb_noun pattern (search_cards, count_cards, aggregate_cards, resolve_card, export_deck, import_deck, validate_deck), but top_traits, server_status, and deck_stats use noun phrases. The mixed convention is still readable but not uniformly predictable.

Tool Count5/5

With 10 tools, the set is well-scoped for a Lorcana card and deck assistant. It covers both card querying (search, count, aggregate, resolve) and deck management (import, export, validate, stats) without unnecessary bloat.

Completeness5/5

The tool surface provides comprehensive coverage for the domain: card discovery, count/aggregation, fuzzy name resolution, deck import/export, format validation, and detailed deck statistics. Common workflows like 'search for a card -> build a deck -> validate -> analyze stats' are fully supported with no obvious dead ends.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
nü people Job Server A
io.github.nu-people
Public MCP server for discovering open jobs. Search, filter, and get application links.
Search
52
H-Index A
ai.xr-utilities
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Search Documentation Access
2

Related MCP Servers

mtg-oracle
Games & Gamification Search Knowledge & Memory
gregario
A
license
A
quality
C
maintenance
Magic: The Gathering MCP server with card search, rules lookup, deck analysis, and Commander intelligence
Updated 4 months ago (2026-05-02 20:58 UTC)
14
40
4
MIT
lorcana-oracle
Games & Gamification Search
gregario
A
license
A
quality
C
maintenance
Disney Lorcana TCG MCP server -- card search, deck analysis, and franchise browsing powered by LorcanaJSON.
Updated 3 months ago (2026-06-15 17:39 UTC)
7
44
3
MIT
scryfall-mcp-server
Games & Gamification Search
colinhauch
A
license
Not graded
quality
D
maintenance
MCP server that searches and retrieves Magic: The Gathering card data from the Scryfall API.
Updated 8 days ago (2026-09-05 01:57 UTC)
21,790
MIT
Lorcana Event Finder
Games & Gamification Search
zammitt
A
license
Not graded
quality
D
maintenance
An MCP server that lets AI assistants look up Disney Lorcana TCG events, stores, and tournament data via the Ravensburger Play API.
Updated 5 months ago (2026-04-23 10:21 UTC)
6
-