Skip to main content
Glama
xvyslo05

cz-mtg-compare-mcp

by xvyslo05

optimize_decklist

Optimize a Magic: The Gathering decklist by comparing prices across Czech card shops and generating a shopping plan that minimizes total cost or number of orders.

Instructions

Resolve a Magic decklist (Arena/MTGO text) against all shops in parallel and return a shopping_plan built under one of two strategies.

Strategies (strategy param):

  • "cheapest" (default): per-card greedy lowest price across all shops. Minimises total CZK; may fragment the order across many shops.

  • "fewest_shops": minimises the number of distinct shops in the final plan so the user places fewer separate orders / pays less shipping. Stays within 10% of the cheapest-split total by default; override the tolerance via the CZ_MTG_CONSOLIDATE_TOLERANCE_PCT env var (integer percent). When no single shop can cover everything, cards missing from the chosen set fall back to the globally-cheapest offer (which may add one or more shops to the plan).

Response shape:

  • strategy: echoes the strategy that produced the picks/plan.

  • picks: chosen offer per card under the active strategy.

  • shopping_plan: the picks regrouped per shop — render as a summary table. Each group has the shop name, a lines list (quantity, card name, edition, condition, foil, unit price, subtotal, url) and a subtotal_czk. Groups sorted by descending shop subtotal.

  • cheapest_split_total_czk: total of the per-card cheapest split, always populated as a reference even in fewest_shops mode.

  • consolidated_total_czk: total of the consolidated plan in fewest_shops mode (equals the sum of shopping_plan subtotals). null in cheapest mode.

  • per_shop_bundles: how each individual shop covers the decklist on its own (cards covered/missing, single-shop total CZK), sorted best-to-worst.

  • cheapest_split_missing: cards no shop has in stock.

When presenting results to the user, render the shopping_plan as a per-shop chart: one section per shop with a table of cards to buy from it, plus the shop subtotal. Then show the headline total (use consolidated_total_czk for fewest_shops, otherwise cheapest_split_total_czk) and any cheapest_split_missing. In fewest_shops mode it's useful to also surface the delta vs. the cheapest split so the user can see the consolidation premium.

The decklist must contain at most 100 cards in total (Commander deck size) AND at most 100 unique cards (one HTTP request per unique card per shop — the unique-cards cap exists to keep a single tool call from spawning a runaway number of requests). Override the unique cap via the CZ_MTG_MAX_UNIQUE_CARDS env var if you need a higher limit. Format example:

4 Lightning Bolt
4 Counterspell
2 Sol Ring (CMR) 263

Sideboard
1 Negate

Display-only products (Art Series, oversized, helper cards) are excluded by default. Pass include_non_playable=True to keep them in the picks.

Shop selection mirrors search_card:

  • shops: allow-list (None = all configured shops).

  • exclude_shops: deny-list (applied after the allow-list). Excluded shops also disappear from per_shop_bundles so the chart only shows the shops the user actually wants to see.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shopsNo
decklistYes
strategyNocheapest
exclude_shopsNo
in_stock_onlyNo
include_non_playableNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
picksYes
strategyNocheapest
total_cardsYes
unique_cardsYes
parser_errorsNo
shopping_planNo
per_shop_bundlesYes
cheapest_split_missingYes
consolidated_total_czkNo
cheapest_split_total_czkYes
Behavior5/5

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

With no annotations, the description fully bears the burden of behavior disclosure. It details parallel requests, strategy logic, limits (100 cards/unique cards), default exclusions, shop filtering, and response shape, leaving no major behavioral gaps.

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?

The description is well-organized in sections but overly verbose, running multiple paragraphs. While thorough, it could be more concise without losing essential information.

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 tool's complexity (two strategies, multiple parameters, output schema), the description is highly complete. It covers response fields, conditional behavior, user presentation guidance, and edge cases like missing cards, exceeding the schema alone.

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 must compensate. It does so thoroughly for all 6 parameters, explaining strategy options, shop filtering, include_non_playable, and in_stock_only, far beyond just listing them.

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 specifies the tool's purpose: 'Resolve a Magic decklist against all shops in parallel and return a shopping_plan.' It differentiates from siblings like search_card (single card) and add_to_cart (cart operations) by focusing on batch optimization.

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 explains when to use the tool and details two strategies with trade-offs, constraints, and override mechanisms. However, it does not explicitly state alternatives for single-card lookups or when not to use it, though the context is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/xvyslo05/czech-mtg-price-comparator-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server