lorcana-mcp

Overview Schema Source Related Servers Discussions Admin

get_meta

Return a Disney Lorcana Core Constructed metagame snapshot: tier list of every ink pair plus recent tournament standings and decklists.

Instructions

Return a hand-maintained Core Constructed metagame snapshot: a tier list of every two-ink pair (archetype name, tier, rough meta share, playstyle) plus a summary of recent notable tournament results — for answering "what's strong right now" or "how does my ink pair compare". With event set, returns that tournament's full standings and decklists instead.

Unlike every other tool here, this is NOT a live fetch. There is no free, structured feed for competitive metagame share or tournament decklists — inkDecks.com and lorcana.gg publish this as HTML, and tournament results circulate as social-media images, not an API. This tool instead returns a versioned snapshot bundled into the package at release time (see lorcana_mcp/meta.py / tournaments.py and the CHANGELOG for when it was last refreshed). The response states its own snapshot date and sources up front, and flags which rows have actually been checked against a real recent tournament result versus older, unverified metagame-tracker data — don't treat an old row's tier/meta-share as more current than it is. Tournament decklists are transcribed from card-grid images: counts/art are reliable, but a few 1-of tech slots and some subtitles are best-effort (per-list notes flag where).

Usage guidelines: reach for this when a player asks what's currently good, whether a given ink pair is competitive, or wants context before calling build_deck. For a specific event's lists, pass event (the plain snapshot output lists which events are available). It complements build_deck/analyze_deck, which build or evaluate one concrete deck.

Args: ink_colors: Optional pair of ink colors to filter to one tier-list row, comma- or slash-separated, e.g. "Emerald,Steel" or "Amber/Sapphire" (order doesn't matter). Ignored if event is set. event: Optional tournament key or name fragment (e.g. "nac", "kobe", "asia-championship-2026") to get that event's full standings + decklists instead of the tier list.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`event`	No
`ink_colors`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.3.0Sep 12, 2026

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 full burden and does so exceptionally: it discloses that this is NOT a live fetch, that data is a versioned package snapshot, that the response self-reports snapshot date/sources, that rows are flagged verified vs. unverified, and that decklists are best-effort transcriptions. These are exactly the caveats an agent needs to avoid over-trusting the output.

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-loaded with the purpose and mode split, and every sentence adds real information (data provenance, verification flags, transcription caveats). It is on the long side and slightly repetitive about the non-live-fetch point, but no sentence is filler.

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?

Despite an output schema existing, the description still communicates the shape of the alternate mode's return (standings + decklists) and the freshness caveats, and covers both filter parameters without gaps. Nothing an agent needs before calling is missing.

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 fully compensates: it documents `ink_colors` syntax (comma- or slash-separated, order-insensitive, ignored when `event` is set) and `event` as a key or name fragment with concrete examples, plus the mode switch each triggers.

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?

Opens with a specific verb+resource+scope: returns a Core Constructed metagame snapshot (tier list of two-ink pairs plus recent tournament results), and explicitly notes the alternate `event` mode returning standings and decklists. It also distinguishes itself from siblings by naming build_deck/analyze_deck as complementary rather than equivalent.

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?

Explicit when-to-use ('what's currently good', 'is my ink pair competitive', 'context before build_deck') and when to switch modes (pass `event` for a specific event's lists). Alternatives are named directly, so routing is unambiguous.

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

Deploy Server