SuperAPI AI Directory

5e-quint

D&D 5e SRD 5.2.1 game engine: create characters and run turn-based battles through MCP, backed by Quint formal models, rule-level proofs, and model-based testing.

Open website

About this tool

Purpose

5e-quint is an executable, formally specified implementation of the Dungeons & Dragons Fifth Edition SRD 5.2.1 rules, aimed at character creation, character advancement, character sheets, and combat flow. It can serve as a rules engine for games, character builders, or encounter-running tools.

Main Capabilities

  • Supports all classes in the SRD and their abilities up to level 10, subject to the boundaries of runtime and table adjudication.
  • Rules are formally modeled in Quint and executed by a TypeScript reducer.
  • The published SRD catalog contains only SRD 5.2.1 content and no closed-license content; the architecture separates "authoring content" from "reusable rule procedures" so that separately provided closed content can be built on the same foundation.
  • Provides an MCP server that can expose workflows to agents, including Play Sessions that can be resumed after an HTTP server restart.
  • Provides a character creation UI and a combat visualizer (browser view).

Usage

  • Distribution: the target packages for the SDK and stdio MCP are @dearlordylord/dnd-sdk and @dearlordylord/dnd-mcp.
  • The core runtime does not roll dice or infer battlefield geometry; callers must provide these facts through the API in the form of "witnesses."
  • Required inputs are called Holes, and their answers are called Fills. In combat, the caller discovers available actions (Acts), chooses one, and then answers the questions needed to resolve that action.
  • The engine tells the application what it needs next: character selection, available combat actions, or missing inputs (such as targets or dice results). When a rule depends on a player choice or table observation, the runtime returns a pending question; answering one question may reveal the next question.
  • Example MCP interaction (illustrative, in an existing combat):
    • Player: What can my fighter do?
    • Agent: You can attack with a weapon. Who is the target?
    • Player: That goblin. I roll the dice on the table.
    • Agent: Tell me the attack result.
    • Agent: Hit. What is your damage roll?
    • Agent: This hit deals 8 damage. Here are the next steps you can take.

Applicable Scenarios

  • As a game rules engine.
  • As a character builder.
  • As a tool for running encounters.
  • Interacting with agents through the MCP server for resumable Play Sessions.

Limitations

  • There is a boundary between the runtime and table adjudication; see the documentation for the specific boundary.
  • The published catalog contains only SRD 5.2.1 content; closed-license content is not included and must be provided separately and built on the same foundation.
  • New mechanics must pass through the admission boundary of the runtime they belong to, or gain new procedure support.
  • The core runtime does not roll dice or infer battlefield geometry; these facts are provided by the caller.
  • Implementations for other languages are being advanced through consistency tooling, including language-neutral contracts, formal models, and consistency tools; availability in any language is a goal, not a published SDK promise.

License and Attribution

  • The code is licensed under Apache 2.0.
  • SRD 5.2.1 content is licensed under CC BY 4.0; the NOTICE file provides repository attribution information, and the working Markdown corpus README provides its SRD attribution, acknowledgment of the Downfallx conversion, and source provenance.

Other Notes

  • Abilities are authored as Dhall data. For example, the SRD spell Ice Knife combines an attack phase and a saving throw phase; its dependency tracking is generated from compiled JSON, and the original content is authored in Dhall. Colors distinguish costs, input holes, resolution, effects, and scaling.
  • Another authoring record can reuse already implemented mechanic procedures without needing name-keyed handlers; new procedure shapes require runtime support. The Surface authoring guide shows how to compile, validate, and generate a complete review trace; the architecture documentation explains content boundaries.