Cardlang
LiveCardlang makes Magic: The Gathering card discovery accessible through natural-language search. Describe deck requirements in plain English and receive matching cards.
Why I built it
Deck building in Magic: The Gathering involves searching a catalog of tens of thousands of cards. Finding suitable cards for a particular deck requires considerable time.
Existing discovery tools do not fully address card discovery. Combo aggregators can expose card relationships from deckbuilder data, but results favor established metagames. Scryfall and comparable search engines offer powerful filters but require specialized query syntax and chained operators.
Experience building AI and agent systems prompted a product question: could natural-language input guide card discovery? Cardlang addresses the question through a conversational search interface.
The interface returns cards rather than prose. Users can save and export card lists, revisit prior searches, and refine results with filters and sorting.
Technical design
An early version called Scryfall’s API directly. Direct API calls suit a prototype but cannot provide reliable public access under rate limits. Cardlang now uses a local ingestion pipeline.
A scheduled Lambda runs each morning. The job downloads Scryfall’s bulk export, parses the data, and imports the complete card catalog into Postgres. The catalog remains less than 24 hours old, and user traffic does not reach Scryfall’s servers.
Catalog replacement posed a harder problem. Rewriting the active card table during user queries risks downtime and inconsistent results. Cardlang uses a blue-green schema arrangement: two complete catalog copies sit behind a database view. The daily import loads the inactive schema. After ingestion completes, the view points to the updated schema. Queries continue over complete data throughout the changeover.
Natural-language queries produce a structured representation rather than direct SQL. A server-side service parses the representation and compiles SQL for the Postgres database. The model does not generate executable SQL, preserving control over database input for correctness and security.
Context management emphasizes selective retrieval. Cardlang separates Magic domain knowledge into discrete skills, exposed to the model as tools in the agent loop, rather than placing the complete domain in a system prompt. The agent retrieves relevant knowledge only when needed.
Much of the Magic domain appears in model training data. Preloading likely-known information consumes tokens unnecessarily. On-demand skill retrieval keeps prompt context compact and supplies supplemental knowledge for unfamiliar questions.
Neuromod provides provider-independent model access. Changes in model performance can drive provider selection without application changes.
Quality and feedback
Cardlang includes an evaluation suite and an in-product feedback workflow. Users can report poor results directly in the application. Each report automatically opens a GitHub issue containing the original query, model-generated structured output, compiled SQL, and returned results.
The workflow identifies the cause of an incorrect result, applies a fix, and adds the failed query to the evaluation suite to prevent regressions. The process applies the engineering discipline used in professional AI systems.
Stack
TypeScript and Node.js power the service, with Angular for the frontend. Postgres uses a blue-green schema arrangement for the card catalog. Lambda runs the daily bulk-ingestion job. Neuromod provides provider-independent model access.