inZOI documents two MCP servers to control the game with AI

Two documented MCP servers so an AI assistant can act on a game of inZOI while it is running. That is what MIXED Reality News reports, and according to the headline it is the game itself that documents these servers: Krafton's life simulator, which launched in early access on Steam in March 2025.

This matters because, until now, most MCP servers tied to video games sat on the development side: connectors for engines such as Unity or Unreal that help create scenes, scripts or assets. The inZOI case points somewhere else. The server doesn't help build the game; it helps drive it from the outside while someone is playing.

What it means for a game to speak MCP

MCP (Model Context Protocol) is the standard Anthropic published so a language model can call external tools in a uniform way. An MCP server exposes actions and data; a compatible client, such as Claude Desktop or Claude Code, discovers them and decides when to use them. Setup usually comes down to adding the server to `claude_desktop_config.json` or registering it from Claude Code.

Applied to a running game, the pattern lets the assistant query the state of the session and carry out actions inside it based on natural language instructions. The exact scope of each of the two servers is in the documentation, and it is worth reading before assuming what can and cannot be done. Having two servers rather than one fits a common MCP practice: splitting responsibilities so each client only sees the tools it needs. That reduces noise in the model's context and limits what can go wrong.

Krafton isn't starting from scratch. At CES 2025 it presented, together with NVIDIA, the “Smart Zoi”, characters driven by a small language model that runs locally. The difference is one of direction: that AI lived inside the game; with MCP, the game opens up to an external assistant chosen by the player.

Who it is useful for

Content creators and advanced players, who can set up complex scenarios by describing them instead of building them click by click.
Modders, who gain a documented interface to automate repetitive tasks without relying on reverse engineering.
QA teams, for whom triggering specific situations from an agent can help reproduce bugs or test edge cases.
Other studios, which get a real example of how to expose a commercial game to agents without opening the source code.

There is also an accessibility angle. Controlling such a dense simulator through written or spoken instructions could open it up to players for whom the traditional interface, full of menus and panels, is a barrier.

What to keep an eye on

Connecting an assistant to a running local process is not trivial. You need to check which permissions each server requests, whether actions can be undone and how you confirm what the model is about to execute. In Claude Code, PreToolUse hooks let you intercept tool calls before they happen, which is useful if you want to manually approve certain actions on the game session.

Cost matters too. A simulation game generates a huge amount of state: characters, relationships, objects, schedules. Dumping it unfiltered into the model's context burns tokens fast and makes the answers worse. The real quality of this integration will depend largely on how well the servers summarise that state and how tightly scoped their tools are.

There is also the question of how this fits with shared sessions, third party mods and future game updates. A documented interface creates expectations of stability, and maintaining it while the game is still in early access requires discipline from the studio.

At ElephantPink we build custom MCP servers, and this is the kind of case we find most interesting: a product that opens up to agents with public documentation instead of waiting for the community to force it. It remains to be seen how many players actually use it, but the precedent for the industry is already there.