Grimoire: designing an AI-enabled workspace with humans in control.

01 / The starting point

A collection is only useful if you can build with it.

Magic: The Gathering players make decisions across two worlds. There is the deck they want to play, and there are the physical cards they actually own. A card may exist in several printings, sit in a different binder, or already be committed to another deck. Testing a new idea adds another question: which changes belong to an experiment, and which belong to the deck you are taking to game night?

We built Grimoire to bring those decisions into one private workspace. It tracks exact printings, organizes collections, supports independent deck variations, and surfaces the gaps between a build and the cards available to it. Players can search the catalog, import a decklist, explore a mana curve, and keep strategy notes beside the cards.

For MrKALTech, this self-initiated project also provided a practical setting to explore AI-enabled software. The challenge was to give an assistant enough context to be useful while making its proposed changes understandable and controllable. Grimoire is an in-house demonstration application, available without subscriptions or fees.

02 / Product & interface design

Make complexity available without making it overwhelming.

The visual language pairs a restrained violet palette and serif headings with clear, compact interface typography. It gives the product a sense of place while leaving room for card artwork and dense information. Shared spacing, color, and component rules keep collection tables, deck workspaces, and proposal reviews recognizably part of the same application.

Different tasks need different views. Text lists support fast scanning and editing; visual and stacked layouts let players recognize cards by their artwork. The commander receives a prominent position because it defines the deck’s identity. Two-sided card previews account for the way the game actually works, rather than forcing every card into a single-image model.

We also designed for repeated use. A command palette, quantity-aware quick add, deep links, and an organized deck library shorten familiar journeys. On smaller screens, navigation becomes a drawer and the workspace adapts to the available width. Light and dark themes support different environments.

Give experiments a home.

A deck family contains a primary build and independent variations. Each variation keeps its own cards, notes, and analysis, while remaining connected to the original idea. Players can compare builds card by card, promote a favorite, or detach an experiment into a new deck. This makes exploration part of the product’s structure.

03 / AI as a product capability

Useful AI starts with useful context.

Grimoire connects to external AI assistants through a documented REST API and the Model Context Protocol, or MCP. MCP exposes named tools and resources that a compatible assistant can use to inspect collections, read decks and notes, analyze a build, and propose changes. The user chooses the assistant and grants it a revocable token.

That connection makes a request such as “explore a lower-cost version of this deck using cards I already own” actionable. An assistant can read the current build, consult ownership and analysis tools, and submit a proposed variation. The resulting suggestion refers to real application data and can appear in the same workspace the player already uses.

The innovative part is how these capabilities fit together: contextual access, domain-specific tools, persistent experiments, and a visible review process. The application supplies structured facts; the assistant interprets intent and suggests possibilities; the player controls what happens next.

Permissions are part of the experience.

Tokens receive read and propose access by default. Proposed deck, collection, and wishlist changes wait for review, expire after 24 hours, and record their outcome. Deck revisions protect against applying suggestions based on an outdated build. Database transactions keep a successful application and its audit record together.

More automation is an explicit choice. An optional apply permission supports direct actions such as deck creation and note updates. A separate approval setting can allow apply-scoped proposals to run immediately; propose-only tokens and collection imports still require review. The article’s example shows the default review workflow. These controls define what an assistant may do; they do not guarantee the quality of its advice.

04 / Engineering the foundation

Reliable collaboration needs reliable state.

Grimoire uses Next.js, React, and TypeScript for its application and API, backed by PostgreSQL. A relational model fits the product: cards have printings, collection lots refer to printings, decks contain card entries, and deck families share relationships. Those distinctions matter when the interface—or an assistant—asks what is owned and what is available.

Model the physical world accurately.

Owning three copies of a card does not necessarily mean three are available. Grimoire accounts for commitments across active primary decks. When analyzing a variation, it substitutes that build for its primary; sibling experiments do not all reserve the same cards. The result is ownership analysis that reflects how players compare alternatives.

Keep facts and suggestions distinct.

Legality checks, mana curves, card counts, and ownership gaps are calculated by application logic. Card data and imagery come from Scryfall. Commander bracket assessments and prices remain estimates. Giving an AI assistant access to these tools grounds its reasoning in inspectable results, while leaving strategic judgment open to the player.

Design for interruption and change.

Collection imports run as durable jobs with progress, unresolved rows, and a review step. Catalog lookups are rate-limited, and exact-printing resolution happens on the server. Separate build and family revisions protect edits at the right level: changing a notebook and changing family membership are different operations with different conflicts.

Performance work followed the same practical approach. Compact MCP collection responses reduce unnecessary payload, batched card caching avoids repeated connection work, and connection-pool tuning suits serverless deployment. In the interface, loading states and background proposal application make waiting visible while keeping navigation available.