spicy-monopoly: a two-player board game where the AI is both dealer and opponent

The problem spicy-monopoly solves: an AI that narrates instead of rolls

Ask a language model to run a board game and it will invent the dice. Numbers drift, money stops adding up, and a tile you already landed on comes back three turns later. spicy-monopoly exists to move that arithmetic out of the model and into code. The README describes the AI as both the dealer and a participant: it rolls, moves, draws tasks and settles the accounts by running the engine, while the tasks that fall to it are performed by the model itself in the conversation.

The audience is narrow and stated plainly. It is a two-player game, both players must be adults, and the README limits use to two consenting adults in private. One of the two seats can be the AI. The other two configurations are two humans with the AI acting only as dealer, or two humans with an AI that also plays.

What separates it from a prompt pack is the arithmetic. Coins are earned by completing tasks and collected as rent on claimed tiles. The game runs a fixed number of rounds and the player with more coins wins, with the winner allowed to issue one final instruction to the loser. There is also a library of 900 or more task cards, all written with placeholders such as the acting side and the other side, rendered with the players' own names at setup.

How the engine, the API and the MCP server fit together

There are three ways in, and they are not variations on the same script.

The first is monopoly_play.py, the engine. The README states it has zero third-party dependencies and uses only the Python standard library. It handles dice, card draws, rendering, redline filtering and saving state. The AI calls it one command per turn. State lives on disk, so the conversation can be long and the board still matches the last command.

The second is monopoly_api.py, an optional HTTP service built on FastAPI. The requirements.txt file confirms that fastapi, uvicorn and pydantic are needed only for this service, not for the engine. This is the path for an AI that cannot execute local code but can make HTTP calls, and for running more than one table at once.

The third is mcp-server.js, a Node.js process that exposes the game as MCP tools. The README says an MCP client sees six high-level tools covering setup, rolling, game actions, queries, management and help, with skip, swap, duel, function cards and identity events folded into a single game_action. The server defaults to forwarding to the public hosted instance at https://spicy-monopoly.lol, and the README gives SPICY_MONOPOLY_BASE_URL=http://127.0.0.1:8069 for pointing it at your own service. A local stdio mode is available through node mcp-server.js for clients that do not support remote MCP.

The data layer is plain JSON: monopoly-library.v2.json for tasks, monopoly-truths.json for truth questions, monopoly-identities.json for identity cards. The README describes the task schema as four axes covering intensity, play type, kink and role requirements, with placeholder content. Editing the library means editing JSON, which is the most approachable extension point in the project.

Installing spicy-monopoly and playing the first round from the source

The engine needs nothing installed. The README lists the files to hand to your AI: monopoly_play.py, the three JSON libraries, and monopoly-给AI的操作手册.md, the instruction manual the AI follows. If your AI has a code interpreter, that is the whole setup.

Setup is one command. The README gives this example, and the arguments are, in order, the two players with gender and role, the intensity level, a value the README shows as 0.5, and the number of rounds.

python monopoly_play.py new "Alice:男:攻" "Bob:女:受" heavy 0.5 18

After that, each turn is a single roll. The README states this is the only command needed per turn.

python monopoly_play.py roll

To see the board and the running accounts, the README gives a status command.

python monopoly_play.py status

If you would rather the AI reach the game over HTTP, the API service is installed separately. The requirements.txt file lists fastapi, uvicorn and pydantic, and the README gives this start command on port 8069.

pip install -r requirements.txt
uvicorn monopoly_api:app --host 0.0.0.0 --port 8069

For an MCP client, package.json defines the scripts. The README shows the remote HTTP variant, and package.json also defines npm run mcp for the stdio server. The package declares node >=18.

npm install
npm run mcp:http

One warning belongs here rather than in a footnote. The README says that if you expose the API publicly you must add authentication and rate limiting yourself. The engine ships no auth layer.

The safety design is the most developed part of the project

Most adult game projects treat consent as a paragraph in the README. Here it is implemented as engine behaviour, and that is the strongest argument for using this rather than a prompt pack.

The safe word is 404. The README states that anyone can say it at any time and the game stops immediately, with no reason required. Redlines are configured at setup: each side lists what it does not want, from a set the README enumerates as anal, impact, bondage, toys, exposure, humiliation, incontinence and electricity. The engine avoids those cards for the whole session, and the README says cards that slip through are caught by a second content-level filter. Anal is off by default and must be opened per player with open_anal. A player marked no_penetration is not penetrated in any orifice.

Intensity has three levels, and the README defines what each one reaches rather than leaving it to interpretation. light is flirting and touching without oral or penetration. medium is explicit sex up to penetration, opens in the second half, and is the default. heavy means every card is severe, up to a loss-of-control tier. The README also publishes a six-step scale from teasing only, through touching non-genital areas, external genital contact, oral and hand service, penetration, and finally the loss-of-control tier. The dealer is supposed to state at the start how far the session will go, and the level can be changed mid-game. Skipping a task costs nothing but a sentence; swapping one costs something.

Two things are worth saying plainly. The redline list is a fixed enumeration, so a limit outside those categories depends on the second filter, whose coverage the README does not describe. And the engine enforces what it can see; it cannot verify what two people actually do.

Where spicy-monopoly is the wrong tool

The project has no interface. Every interaction is a command the AI runs or an HTTP call. If you want to tap tiles on a screen, this is not it, and nothing in the repository suggests a GUI is planned.

The AI dependency is the real constraint. The design assumes the model will faithfully execute commands and then perform its own tasks in character. A model that paraphrases the roll instead of running it, or refuses the content, breaks the loop. The README names ChatGPT's code interpreter, Claude and Claude Code as examples, but it does not document what happens when a model declines a card, and there is no fallback dealer mode described for a model that will not play.

State is file-based for the source path. Two concurrent games from the same working directory are not addressed in the README, which points at the HTTP service for multi-table play instead. The hosted instance at https://spicy-monopoly.lol is rate limited and keyless, and the README asks users not to overload it, so it is not a foundation for anything heavy.

Finally, the content itself is a hard boundary. This is explicit adult material between two consenting adults. If that is not the use case, no part of the engine is relevant, and the safety features do not make it appropriate for anyone else.

Alternatives, and what actually differs

The nearest comparison is a commercial adult party card game for couples. Those give you a physical or app deck and a fixed set of prompts. The difference is not the content, it is who holds the truth. A deck cannot track your coins, cannot remember that you already claimed a tile, and cannot filter a card because one of you listed it as a redline. spicy-monopoly puts those three things in code, and the README's four-axis task schema is what makes the filtering possible at all. The trade-off is that a deck works the moment you open the box, while this needs an AI that runs code or an MCP client before the first roll.

The other comparison is the general practice of giving a model a rules document and asking it to be the dealer. That is free, needs no files, and works with almost any chat model. It also means the dice are whatever the model says they are, redlines are whatever the model remembers to apply, and a long session will drift. spicy-monopoly's engine exists precisely because that approach fails at bookkeeping. If your sessions are short and you do not care whether the coins add up, the prompt-only approach is simpler. If you want the board to be the same board on turn 40 as it was on turn 1, the engine is the point.

Maintenance, upgrade cost and the licence question

The repository is not archived, and the last push was on 2026-08-02. The README states the project is being updated and maintained and that a multiplayer mode is planned once the two-player version is stable, but no release has been published. There is no versioned release to pin, so upgrading means pulling the default branch. That matters because game state is saved to disk: if the schema of the saved state or the task library changes between pulls, the README does not document a migration path or a rollback. For a long-running session, finish it before updating.

The dependency surface is small. The engine uses only the Python standard library, so it will not break under a dependency upgrade. The API adds fastapi, uvicorn and pydantic, all unpinned in requirements.txt. The MCP server is the one place with real version exposure: package.json pins @modelcontextprotocol/sdk at ^1.29.0 and zod at ^4.4.3, and the MCP specification is still moving, so a client upgrade is the most likely thing to break your setup.

The licence is the loose end. The README states the project uses CC BY-NC 4.0, attribution plus non-commercial, allowing use, modification and sharing but not commercial use. The repository metadata reports the licence as NOASSERTION, meaning GitHub could not identify a standard licence file. Those two signals disagree, and the README's own instruction is to treat the GitHub repository as authoritative. If you intend to modify and redistribute the task library, read the LICENSE file yourself rather than trusting either summary. This is a description of what the files say, not legal advice.

Editorial conclusion

spicy-monopoly suits two consenting adults who already have an AI that runs code or an MCP-capable client, and who want the dice and the task draws to come from an engine instead of from the model's improvisation. It does not suit anyone who wants a finished app: there is no GUI, no mobile client, and no multi-table server out of the box. Before starting, verify three things. That your AI can actually execute Python or connect to the MCP endpoint, since the whole design rests on that. That the intensity level and the redline list are set before the first roll, because the README states the dealer announces at the start how far the session will go. And that you have read the LICENSE file, since the repository metadata reports NOASSERTION while the README names CC BY-NC 4.0, a non-commercial licence.

Frequently asked questions

Official sources

1. Issues
2. README
3. RennAkira/spicy-monopoly on GitHub