Building Mythic Index As A Portable AI Skill

Magic: The Gathering is a useful stress test for AI agents.

It is not only a game. It is rules, strategy, deck construction, pricing, sealed products, vendor data, formats, bans, market movement, and a large amount of community language that changes over time.

That made it a good place to build something more ambitious than a prompt: a portable AI skill that can teach the game, answer rules questions, build and price decks, and reason about cards as collectible assets.

The project became Mythic Index. The important part is not only that it works for Magic. The important part is the architecture behind it.

The Job I Wanted The Skill To Do

The goal was to create an AI mentor for Magic players and collectors.

I wanted the agent to handle three jobs:

1. Teach new players using the official Comprehensive Rules.
2. Build and price legal decks across vendors.
3. Evaluate cards and sealed products with the right risks visible.

The system now covers:

• 99,000+ cards
• 971 sets
• 534,000+ price listings
• 3,900+ sealed products with EV
• 5 vendors: TCGPlayer, Card Kingdom, CardMarket, CardSphere, and CardHoarder
• 21 MCP tools
• 3,120 Comprehensive Rules
• 726 glossary terms

Those numbers matter because this is not a static prompt pretending to know everything. It is an AI skill connected to tools that can fetch current information.

The Core Pattern

The main design decision was to separate the brain from the data.

The skill should not contain a card database. It should not contain prices. It should not contain the full rules corpus. All of that changes.

Instead, the skill contains behavior:

• When to activate.
• What tools to call.
• How to answer rules questions.
• How to price a deck.
• How to make risk explicit.
• How to avoid answering from stale memory.

The live data sits behind an MCP server and backend.

That separation is what makes the skill portable. It can move across agents because the instructions are lightweight. The data stays current because it is fetched at runtime.

How Mythic Index Is Built

Mythic Index has three layers.

The first layer is the skill. This is a SKILL.md file with instructions for the agent. It defines the role, the activation conditions, the operating rules, and the response style.

The second layer is the MCP server. It is a Python server published as mythic-index-mcp. It exposes 21 tools through the Model Context Protocol and can run with uvx mythic-index-mcp.

The third layer is the backend. It holds cards, sets, prices, sealed EV, official rules, glossary terms, and sync jobs.

The flow looks like this:

1. A user asks a Magic question.
2. The skill tells the agent how to interpret the request.
3. The agent calls the right MCP tool.
4. The MCP server queries the backend.
5. The agent answers with live data instead of memory.

That is the product loop.

What The Skill Tells The Agent

The skill is intentionally opinionated.

For pricing, it tells the agent not to quote prices from memory. Prices change daily, so current market questions must go through tools.

For rules, it tells the agent to search or fetch the official rule and cite rule numbers. A rules assistant should not rely on a model's general memory when the official Comprehensive Rules are available.

For decks, it tells the agent to establish format, budget, and goal before recommending cards. Then it can find cards by role, price the list, check legality, analyze the curve, and suggest budget alternatives.

For investing, it tells the agent to make risk explicit: reprints, bans, liquidity, format shifts, and hype cycles.

That matters because the skill is not trying to make the model sound smart. It is trying to make the model behave usefully.

The 21 Tools

The MCP server exposes tools across seven areas.

| Pillar | Tools | | --- | --- | | Prices and cards | search_cards, find_cards, browse_cards, list_sets, get_card_price, get_price_history | | Sets and sealed | get_set_stats, search_sealed, get_sealed_ev | | Investment | top_movers, find_arbitrage, reserved_list_tracker | | Decks | price_deck, suggest_budget_alternatives, analyze_mana_curve | | Strategy | check_legality, evaluate_card, find_cards_by_role | | Rules | search_rules, get_rule | | System | get_api_status |

The first version had 19 tools. Adding rules changed the feel of the product.

Pricing made Mythic Index useful. Rules made it a mentor.

Teaching The Agent The Official Rules

Magic has many good casual explanations online, but a rules assistant needs the official rules.

So the backend ingests the Comprehensive Rules, parses numbered rules and glossary terms, stores them, indexes them, and exposes lookup endpoints. The MCP server wraps those endpoints as search_rules and get_rule.

That lets the agent answer questions like:

Explain how deathtouch and trample interact. Cite the actual rule.

The correct behavior is not to answer from memory. The correct behavior is to search the rules corpus, fetch the relevant rule, explain it plainly, and cite the rule number.

This is the broader lesson: if a domain has a source of truth, give the agent a path to that source of truth.

Decks Need Workflow, Not Just Data

Deck building is more than card search.

A good deck request needs context:

• Format.
• Budget.
• Commander or archetype.
• Power level.
• Color identity.
• Cards the user already owns.
• Competitive or casual expectations.

The skill handles this by guiding the agent through a workflow instead of dumping generic recommendations.

For example, if someone says they want a high-power Commander deck, the agent should ask for the commander or strategy, confirm color identity, search for role players, price the list, check the curve, and explain tradeoffs.

The MCP server does not need to host every decklist in the world. It needs to make a decklist actionable once the user brings one in or chooses a direction.

That is an important product decision. The value is not owning all possible content. The value is turning the user's intent into a concrete decision.

The Process Lessons

The build had several lessons I would repeat in other AI products.

Check The Runtime Early

The MCP server needed Python 3.10+. The environment I started with did not match that requirement, so the server had to run in a newer Python environment.

This is basic, but it matters. Agent tools are still software. They fail for normal software reasons.

Expect SDK Drift

Small API differences can break the server before any tool is called. The practical habit is to test the server construction path, not only individual tool functions.

For AI tooling, the surface area changes quickly. Treat docs, packages, and examples as things to verify.

Test The Product Claim

If a system says it has limits, syncs, access rules, or freshness guarantees, test those claims directly.

For Mythic Index, that meant checking tool startup, rules lookup, pricing calls, rate behavior, and production deploy order.

This is the difference between a demo and a usable capability.

Deploy In Dependency Order

Rules tools depend on rules data. Pricing tools depend on pricing data. A backend can be deployed correctly and still not be ready if the required data has not been ingested.

The deploy sequence matters:

1. Ship the backend behavior.
2. Ingest or sync the data.
3. Publish the tools that depend on that data.
4. Test from the agent, not only from the API.

Keep The Skill Portable

The most important lesson was the simplest one.

Do not put the live world inside the skill.

Put the operating behavior in the skill. Put live facts behind tools. That is what lets the same capability work across different agents.

How To Try It

You need Python 3.10+ and uv.

For Codex, add this to ~/.codex/config.toml:

[mcp_servers.mythic-index]
command = "uvx"
args = ["mythic-index-mcp"]
startup_timeout_sec = 120

Then install the skill by copying the Mythic Index SKILL.md file into:

~/.codex/skills/mythic-index/SKILL.md

For Claude Code:

claude mcp add mythic-index uvx mythic-index-mcp

Claude Desktop can use the release package, or the same uvx mythic-index-mcp command in its MCP config.

Useful links:

• Mythic Index MCP on PyPI
• Repository: wizkid17/mythic-index-mcp
• MCP Registry identifier: io.github.wizkid17/mythic-index-mcp
• Run command: uvx mythic-index-mcp

What This Means Beyond Magic

Magic is just the domain I chose.

The same pattern applies to many specialized AI products:

• Legal research.
• Procurement.
• Healthcare operations.
• Financial analysis.
• Developer tools.
• Customer support.
• Internal company knowledge.

The question is always the same:

1. What should live in portable instructions?
2. What should be a callable tool?
3. What data must stay live?
4. What should the agent never answer from memory?

For Mythic Index, the answer was clear.

The skill is the behavior. The MCP server is the capability. The backend is the truth.

That pattern is portable. That is the part worth reusing.