Skip to main content
Glama

search_cards

Search the full Disney Lorcana card pool by ink color, type, rarity, cost, keyword, ability text, set, or subtype to find cards matching criteria. Returns paginated Markdown tables.

Instructions

Search the full Lorcana card pool (all sets, every printed card) by any combination of filters — not your collection. This is a discovery tool for "what cards fit X criteria", independent of what you own or have priced.

All filters are optional and ANDed together, except colors: a card matches if it has ANY of the given colors, so dual-ink cards surface for either half. Calling with no filters at all returns the entire card pool, paginated.

Behavior: always fetches from a live, in-process-cached copy of LorcanaJSON (see the "Card data APIs" reference) — never reads a local CSV, so results always include the newest released set. A card that has no Strength/Willpower/Lore (Action, Item, Location) shows "—" for those stats rather than being excluded. Results are grouped and displayed by ink color, then returned as one or more Markdown tables; when more results exist than limit, the response tells you the exact offset to pass next — call again with that offset rather than guessing pages.

Usage guidelines: use this to browse/filter by criteria (e.g. "every Evasive Sapphire character costing 3 or less") — if you already have a specific (possibly misspelled or subtitle-less) card name in mind, use resolve_card or lookup_card instead, they're cheaper and more precise for a single known card. Results carry no ownership or price information; to check what you already own, cross-reference the card names against an enriched collection CSV yourself, or use what_am_i_missing / find_song_synergies's collection_csv param for tools that do that automatically. To narrow to a specific play format's legal pool, combine with set_name, or post-filter the result against filter_collection's format logic.

Args: colors: Comma-separated ink color(s), e.g. "Amber,Steel". Case-insensitive. card_type: "Character", "Action", "Item", "Location", or "Song" (Action cards with the Song subtype). rarity: "Common", "Uncommon", "Rare", "Super Rare", "Legendary", "Enchanted", "Epic", "Iconic", or "Special". set_name: Set name substring, e.g. "Wilds Unknown". cost_min: Minimum ink cost, inclusive. Pass -1 (default) for no minimum. cost_max: Maximum ink cost, inclusive. Pass -1 (default) for no maximum. keyword: Keyword ability name, e.g. "Evasive", "Rush", "Bodyguard", "Shift". ability_text: Substring to search for in full ability text (case-insensitive). subtype: Subtype/classification, e.g. "Toy", "Hero", "Villain", "Princess". offset: Pagination offset, 0-based. limit: Max results in this page (default 25, capped at 200).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
colorsNo
offsetNo
rarityNo
keywordNo
subtypeNo
cost_maxNo
cost_minNo
set_nameNo
card_typeNo
ability_textNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.7

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: it discloses the live cached LorcanaJSON source (never a local CSV), that newest sets are always included, that stat-less card types render '—' rather than being dropped, the group-by-color output shape, and that pagination returns the exact next offset. These are behavioral traits an agent could not derive 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?

Purpose and usage are front-loaded and the Args block is tight and scannable, but there is mild redundancy (ownership/price independence is stated twice, and the format-legality sentence is convoluted). Slightly longer than it needs to be, though no section is wasted.

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?

For an 11-parameter optional-filter tool, this covers filtering semantics, defaults, pagination, data freshness, and edge-case rendering. An output schema exists, yet the description still usefully notes the Markdown-table/color-grouping return shape and no-price/no-ownership content, which is relevant to how the agent must post-process results.

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 description coverage is 0%, so the description must compensate, and it does for all 11 parameters: it defines AND semantics for filters, documents the ANY-of behavior for colors (dual-ink cards included), enumerates valid card_type and rarity values, explains the -1 sentinel for cost bounds, and gives examples for keyword, subtype, and set_name substring matching.

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 (search the full Lorcana card pool) and immediately scopes it with a negation ('not your collection'), which is exactly the distinction that separates it from filter_collection and what_am_i_missing. An agent can classify this tool without opening a 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?

Names concrete alternatives and the conditions that select them: resolve_card/lookup_card for a single known (even misspelled) name, what_am_i_missing or find_song_synergies for ownership, filter_collection for format legality. Also states that no filters returns the whole pool, so the boundary case is explicit rather than inferred.

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