Skip to main content
Glama

build_sealed_deck

Build the best 40-card Sealed (prerelease) deck from a player's opened card pool — for prerelease events, where everyone opens 6 booster packs (~72 cards) on-site and has ~45 minutes to build.

Instructions

Build the best 40-card Sealed (prerelease) deck from a player's opened card pool — for prerelease events, where everyone opens 6 booster packs (~72 cards) on-site and has ~45 minutes to build.

Sealed rules applied: 40-card minimum; NO ink-color limit; NO copy limit (every copy you opened is playable, even 5+); the stamped prerelease promo is allowed; unused cards are the sideboard (swappable between games). No format-legality or rotation check — the set doesn't need to be released yet.

Strategy: ranks every two-ink pair by pool depth and builds around the best one (or ink_colors), splashing a third/fourth ink only when the core pair can't reach 40 on its own — common from 6 packs. Ink is colorless in Lorcana, so a splash costs synergy, not consistency.

Input — pool is one card per line, quantity optional ("2x Card Name", "2 Card Name", or just "Card Name"; repeats are summed). Each line can be:

  • a card name, informal or misspelled is fine ("mickey best in town");

  • the collector number printed at the card's bottom ("123", "123/204", "123/204 EN 14") — matched within set_name.

If the user sends a PHOTO of their pool: read every visible card from the image and pass one line per card. Prefer the collector number when it's legible (most reliable); otherwise the name + subtitle. Count duplicates. Then tell the user which cards came back ambiguous/unrecognized so they can confirm, and re-call with corrected lines.

Output: ink-pair ranking, the 40-card list by cost, splash notes, stats (curve, inkable count, lore), the strongest sideboard cards, and any ambiguous/unrecognized lines (excluded from the build — never guessed). Heuristic curve/keyword-value scoring with Shift-chain awareness, not a full synergy engine: review the list before sleeving it.

Args: pool: The opened cards, one per line (names and/or collector numbers). ink_colors: Optional comma-separated core inks to force, e.g. "Amber,Steel" (any number allowed in Sealed). Empty = auto-pick the deepest pair. set_name: The prerelease set, used to scope name matching and to read collector numbers. Default "Hyperia City" (Set 14).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
poolYes
set_nameNoHyperia City
ink_colorsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.6.0

TDQS

A4.5/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, and it delivers unusual depth: heuristic scoring rather than a 'full synergy engine', ambiguous/unrecognized lines are excluded and 'never guessed', photo input is read card-by-card and the caller is told to confirm and re-call. It does not state whether anything is persisted or whether there are rate/size limits on pool size.

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?

Well front-loaded and sectioned (purpose, rules, strategy, input, output), with the highest-value constraints early. It runs long and repeats some rules detail, but for a tool with three modes of input and non-obvious sealed rules most sentences earn their place.

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 a three-parameter, zero-coverage schema this is complete: every argument is explained, the input edge cases (photos, misspellings, quantity prefixes, ambiguity) are covered, and the strategy applied is stated. An output schema exists, so the output paragraph is a bonus rather than a required gap-filler.

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 supply all meaning, and it does: `pool` line syntax (2x/2/plain, repeats summed, informal or misspelled names accepted, collector-number forms, photo-derived lines), `ink_colors` comma-separated with empty = auto-pick, and `set_name` scoping name matching and defaulting to 'Hyperia City'.

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 and resource: 'Build the best 40-card Sealed (prerelease) deck from a player's opened card pool.' It also names the concrete scenario (6 packs, ~72 cards, 45 minutes), which cleanly separates it from siblings like build_deck or analyze_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 context of use is unambiguous — prerelease/sealed pools, one-off on-site builds — and it states what is NOT applied (no format-legality or rotation check), which implicitly excludes constructed-deck tools. It never explicitly names a sibling alternative or an exclusion like 'use build_deck for constructed', so it stops short of a 5.

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