Grimoire Updates

Grimoire MCP, revealed: the secret sauce

How Grimoire MCP layers your campaign data into context the AI can actually use, without overloading your wallet or losing the nuance of your homebrew.

Zach "Zafety" Townes

As a GM, I built Grimoire because every AI I plugged into my homebrew Notion DB kept contradicting my own canon. Generic AI tools dump everything into context and hope the model figures it out, but for a TTRPG campaign the model can’t tell what’s recent, what’s central, or what’s been retconned. That doesn’t work.

Here’s how Grimoire MCP solves it in five layers. Partly to dispel misgivings about AI in TTRPG spaces. Mostly to show what an AI integration that actually respects the world you built looks like, and why the architecture matters if you care about using AI faithfully at the table.

The basic part: data entry

Grimoire MCP’s first job is the heavy lifting around basics. Data entry. Parsing your notes. Creating entities. Reading what already exists. This is the “generic” part of the system, and you’ll find versions of it in lots of other tools. AI is inherently good at it.

That’s not the gem.

The real gem: layered context

The real difference is how the backend organizes your campaign’s “gamestate” and presents it to the AI in modular layers, activated or ignored based on what you’re actually trying to do. The point is to fully color the AI’s understanding of your homebrew before it answers a question or takes an action on your behalf.

This is research I’ve done against my own homebrew and other fantasy settings. The goal isn’t to build a “really good TTRPG AI.” The goal is to constrain the AI to within the bounds set by your data.

Even the most powerful AI, given all the session notes and recaps and prep at once, will fail to produce a coherent response. It can’t sort what’s recent from what’s old, or what’s central from what’s incidental. So I split how you describe your world into 5 layers, each with a purpose and a criterion for when it gets pulled in.

Here’s the architecture at a glance, then I’ll walk through each layer:

                GM's question to AI


            ┌───────────────────────┐
            │ L1: Constitution      │   ALWAYS loaded.
            │   world foundations + │   grounds every
            │   campaign bible      │   interaction.
            └───────────┬───────────┘

            ┌───────────────────────┐
            │ L2: The Map           │   ALWAYS surveyed.
            │   every entity +      │   AI sees the
            │   relation, no detail │   shape.
            └───────────┬───────────┘

              AI decides what to pull

          ┌─────────────┴─────────────┐
          ▼                           ▼
   ┌─────────────┐             ┌──────────────┐
   │ L3: A full  │             │ L4: Entity   │
   │   graph     │ ◄─────────► │   deep-dive  │   on-demand.
   │ (political/ │             │ (one NPC,    │   AI can
   │  timeline/  │             │  location,   │   iterate.
   │  geography) │             │  etc.)       │
   └──────┬──────┘             └──────┬───────┘
          │                           │
          └─────────────┬─────────────┘

            ┌───────────────────────┐
            │ L5: Combined context  │   the actual
            │   the prompt the AI   │   prompt.
            │   ends up with        │   unique per
            │                       │   question.
            └───────────┬───────────┘

                AI answers the GM

Layer 1: World Foundations

This is the most important layer to define before you connect AI. The code calls the loaded bundle a “Constitution,” and it includes two things: the world foundations knowledge graph and the Campaign Bible.

The world foundations graph describes the biggest concepts of your worldbuilding. Think setting TLDR. What’s uniquely different about your world and the cultures in it? What single historical events define everything else? You usually skip NPC names here. This is where you put anything non-negotiable, or any nuance that breaks from default fantasy assumptions.

The Campaign Bible is a wiki document for things that don’t fit cleanly in the web. It’s also where you put meta information, like “this campaign expects some but not gratuitous gore, no depictions of sexual assault.”

Grimoire MCP highly recommends loading the Constitution first before any other action, even simple ones like parsing notes into entities. Grounding the AI in the mechanics of the world produces better output downstream. The AI knows how to interpret what it’s receiving. When new notes contradict existing data, it flags the contradiction correctly: AI reads existing NPC, new notes say they’re a mole, AI updates the NPC’s DM secrets accordingly.

The Constitution colors every interaction. It’s the enforcement mechanism on the AI’s behavior.

Layer 2: The Map

Layer 2 is the “map” of your Grimoire database. It’s a list of every entity that exists and how they connect, without full details.

Think of it as being able to see that Frodo is from The Shire, with “home” as the relationship, but without knowing anything else. Frodo is a person. The Shire is a place. That’s it.

This is a lightweight way to see the shape of a large campaign without overloading the AI’s context or your wallet. It’s how you avoid lobotomizing both when you tell the AI to consider “everything.” Instead, the agent does see a map of “everything,” decides where to search next, and pulls more detail from there. Much better than trying to cram too many details into one search, missing something important, and then giving an answer without considering that information.

I learned this trick working with smaller local models. Spoiler: they aren’t smart enough to handle a TTRPG campaign on their own. But that’s not an excuse to overload a frontier model either.

Layer 3: A specific knowledge graph, in full

Layer 3 is any single knowledge graph in full detail, one at a time. Higher tiers let you create custom knowledge graphs (we call these “entity graphs”), but every user gets three by default: the political web, the campaign timeline, and geographic memory.

The political web contains all NPCs, factions, and PCs, plus the relationships between them. NPCs and PCs can belong to factions, but relationships can be much more specific: “related (mother),” “despises,” “planning to betray.” It’s the active relationship status between entities in your campaign.

The campaign timeline is one of the most comprehensive graphs and does a lot of work to establish the current narrative state of the campaign. Each node within the timeline graph can be connected to entities that exist in the raw Grimoire database, and that’s how things like character development and historical or geographical changes over time get tracked. When you create the session recap entry for Session 1, you connect any location visited during that session to Session 1. When the AI requests the campaign timeline, it ideally gets a session-by-session sequence of where the party has come and gone, with the recaps for each session included from the session recaps database, so it can understand both what’s most recent and what’s most relevant.

Individual entities that might not be directly connected to the session timeline (the big bad boss, for example) can be individually marked with attention to be included in the “narrative state,” the tool that attempts to organize the details of only the most recent and relevant entities. The AI ends up understanding both what’s going on immediately and the most important canon events that have already occurred, so it doesn’t forget critical context like the party already having found one of four necessary world keys.

The campaign timeline could be described in even further detail, but I’d be writing a novel, so let me move on.

Geographic memory organizes your locations in a hierarchy: Plane → World → Continent and down, with spatial relationships between siblings. The AI can place not just where locations are, but where NPCs and items sit within the hierarchy. If an item is marked as existing on a continent but isn’t yet linked to a specific shop or dungeon, the AI knows to ask. The frontend also lets you upload images and pin entities visually, but that visual layer isn’t presented to the AI in the same way yet.

Layer 4: Individual entity deep dive

Layer 4 is individual database entries presented to the AI with full details. The AI can call this many times to build a detailed picture of any specific entity when the prompt requires it.

Layer 5: The combined result

Layer 5 is the assembled context across the other layers. It’s always unique, because the trajectory the AI takes (which layers it traverses, in what order) is what colors the final understanding and constrains it to respect your world’s nuance.

Steward, not generator

This is the work that has gone into making sure the AI is relying on the user, not the other way around. That isn’t what I think you’ll find in other AI TTRPG services. Grimoire makes an AI a true steward of your world and a partner for things like note-taking, rather than a generic-but-serviceable generator that produces things that sound right but don’t quite fit the way you’d like.

I hope this demonstrates the value of Grimoire MCP a bit more specifically. Grimoire is currently fantasy-oriented, but different themes and genre-agnostic setups of the “Grimoire database” are in development. Grimoire MCP itself is already properly genre-agnostic.

If you’ve made it this far, thanks for reading. I hope you have as much fun playing with Grimoire MCP and crafting your Grimoire database into your very own custom homebrew “TTRPG bot.” wink

Related posts