Skip to main content
Glama
rapaul

moo2-mcp

by rapaul
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

moo2-mcp

An experiment to let an AI (via Claude) play Master of Orion 2, the 1996 DOS-era 4X strategy game, while it runs inside the DOSBox-X emulator.

Because the emulator isn't modified, the project works in two directions:

MCP tools

The server (python -m moo2mcp.server, stdio) exposes these read-only tools. Every one of them reads a live DOSBox-X process and raises a descriptive error — rather than returning a misleading number — when the target is unavailable or no game is loaded.

Tool

Returns

get_turn

the current turn as an integer: the stardate in tenths (÷10 for the displayed value)

get_empire_status

the player empire: turn, treasury_bc, income_bc, research_per_turn, food, production, research_target, plus unavailable naming the fields not yet reverse-engineered (those come back null, never guessed)

list_colonies

one entry per colony: system (MOO2's own planet name, e.g. "Skynet I"), population, and the labour outputs food_output/production_output/research_output. buildings and production_queue stay empty — unresolved

get_colony(index)

a single colony in the same shape, indexed as in list_colonies

get_home_colony

the home colony's population and labour outputs. Identity, buildings and queue stay null/empty. The raw farmer/worker/scientist counts aren't stored by MOO2, so they aren't reported

get_player_empire

empire_id (0–4) plus the home system's home_system name and home_system_index. Errors if the game wasn't started by the harness, whose home-star marker this relies on

list_systems(explored_only=true)

per system: index (for list_system_planets), name, galaxy x/y, the global planets indices in orbit order, explored_by_player, home_of and colonies_of. Passing explored_only=false includes unexplored systems — information the game itself would not show the player

list_system_planets(system_index)

per planet: index, name, body_type (planet / gas giant / asteroids), size, gravity, climate, minerals. Climate only means anything when body_type is "planet"

list_ships

per ship: name (e.g. "Colony Ship 2"), design, location (the star system it's at) and owner. Ships, not fleets

list_fleets

fleets by location and ship composition — currently always errors: the ship records are resolved but their grouping into fleets is not, so fleets can't be assembled without guessing

get_game_state

a consistent snapshot — empire, colonies, fleets read back-to-back — with any unresolved or unreadable domain returned as null and named in unavailable with a reason

Related MCP server: dosbox-mcp

Reading game state

The game's state is read by peeking directly into the emulator's memory. Locations of interest are reverse-engineered two ways: by changing one thing in-game and observing which memory bytes move, and by searching for structures whose shape is already known — for instance, the planet table was found because each planet must point back at the star that lists it, and only one array in 16 MB reproduced that map.

Those values are exposed through an MCP server, so an AI can ask what turn it is, how much money it has, what its colonies are producing, or which nearby planets are worth settling. What is readable today:

  • Empire — turn, treasury, income, research, food

  • Colonies — the planet's name, population, and the food/production/research its workers generate

  • Galaxy — star systems with their map positions, and every planet's size, gravity, climate and mineral richness

  • Ships — each ship's name, design and the system it is in

Anything not yet reverse-engineered is reported as unavailable rather than guessed, so a wrong answer never reaches the AI. Buildings, production queues, and how ships group into fleets are the main gaps.

One quirk worth knowing: MOO2 gives no reliable way to tell which of the five empires the player is. So the harness names the player's home star with a fixed marker, and the read path finds that star by name and works backwards to the player's identity.

MCP tools

All read-only, over stdio (python -m moo2mcp.server).

Tool

Returns

get_turn

the live stardate (in tenths; ÷10 for the displayed value)

get_empire_status

the player empire: turn, treasury_bc, income_bc, research_per_turn, food; unresolved fields are null and named in unavailable

list_empires

every empire: empire_id, name, is_player, plus the same scalars. Shows what the game would hide — AI treasuries are readable from turn 1, and contact status is not reverse-engineered yet, so it can't be limited to empires the player has met

get_player_empire

which empire the player is: empire_id and the home system's name/index

list_colonies / get_colony

colonies: owner, population, food_output, production_output, research_output, system (e.g. "Skynet I"). buildings/production_queue are unresolved and stay empty. all_empires=true includes the AI empires'. A colony whose record MOO2 hasn't written yet (it does so some turns after founding) still appears, located by the star table: owner and system only, every record field null and named in unavailable

get_home_colony

the home colony alone, found by verifying the record's owner rather than assuming its index

list_systems

star systems: name, color, x/y, planets, home_of, colonies_of, explored_by_player. Explored only unless explored_only=false

list_system_planets

one system's planets: name, body_type, size, gravity, climate, minerals

list_ships

the player's ships: name, design, location. Ships, not fleets

list_fleets

errors — how ships group into fleets is not reverse-engineered

get_game_state

a snapshot of empire + colonies + fleets, with unreadable domains null and named in unavailable

Controlling the game

The game is driven by simulating mouse clicks and keystrokes through a virtual screen (Xephyr + xdotool), since the host desktop blocks normal automation. A harness can launch the game and start a new match from cold, and a second mode lets Claude drive the live UI a screenshot at a time — which is how the memory locations get correlated with what the game actually displays.

This UI driving is a reverse-engineering and verification tool, not the plan for playing. Real gameplay actions are meant to go below the UI, because synthetic input is fragile: MOO2's drags are really two separate clicks, and a stray click in the wrong panel silently reassigns a colony's workers.

In short, this is the plumbing that lets an AI observe and eventually drive an old strategy game it otherwise can't talk to.

Setup, the resolved memory map, and how each address was found are in docs/setup.md.

Available Tools

2 tools
get_empire_statusA

Return the player empire's core stats, read live from DOSBox-X.

Includes the turn and any reverse-engineered empire fields (e.g. treasury). Fields not yet resolved are null and listed in unavailable — never a guessed value. Requires DOSBox-X running MOO2 with a game in progress.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the transparency burden. It discloses that unresolved fields are null and listed in 'unavailable', never guessed. It also discloses the runtime requirement. However, it does not explicitly state if the operation is read-only or has side effects, though 'read live' implies non-destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no wasted words. The first sentence states the main purpose, the second adds detail about field behavior, and the third states requirements. All sentences earn their place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the return format (core stats, null for unavailable fields, unavailable list). It does not list all possible fields, but that's acceptable for a live-read tool. The requirement for DOSBox-X is stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist in the schema, so the description does not need to add parameter details. The baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns the player empire's core stats, read live from DOSBox-X. It specifies the verb 'Return', includes the resource 'player empire's core stats', and distinguishes from sibling tool 'get_turn' by mentioning it includes turn and additional fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states the prerequisite that DOSBox-X must be running with a game in progress, but does not explicitly compare when to use this tool versus the sibling 'get_turn' or provide when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_turnA

Return Master of Orion 2's current turn number, read live from DOSBox-X.

Requires DOSBox-X running MOO2 with a game in progress. Raises a descriptive error if the target is unavailable or no game is loaded.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It mentions live reading and error raising but doesn't explicitly state it's read-only or non-destructive. It could be more transparent about side effects, but it covers essential behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences: first states purpose, second adds prerequisites and error handling. No fluff, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters, and an output schema (not shown but present), the description is complete: it explains what it does, prerequisites, and error behavior. No gaps for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so schema coverage is 100%. The description adds context by specifying the tool returns the turn number live from DOSBox-X, which goes beyond the empty schema. Baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it returns the current turn number from MOO2 via DOSBox-X. The verb 'return' and resource 'current turn number' are specific, and the description distinguishes it from sibling 'get_empire_status' which provides different data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states prerequisites (DOSBox-X running MOO2 with a game in progress) and error behavior. Though it doesn't explicitly say when not to use, the context is clear and no alternatives are needed given the sibling is different.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.0.1
    • First observedget_empire_status
    • First observedget_turn
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct aspect of the game state: one returns comprehensive empire stats including turn, treasury, and unavailable fields, while the other returns only the turn number. There is no overlap in purpose.

Naming Consistency5/5

Both tools follow the consistent 'get_{resource}' pattern with snake_case, making their behavior predictable.

Tool Count2/5

With only 2 tools, the server feels undersized for a game interaction domain. A typical MCP server for a game would include a broader set of actions (e.g., send commands, manage colonies) beyond just reading status.

Completeness1/5

The tool surface is severely limited: it provides read-only access to turn and empire status, with no ability to influence the game, issue orders, or manage other game mechanics. This leaves major gaps for any agent trying to interact with the game.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Disco Engine

    royola1108
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to play Disco Elysium through MCP protocol, with a SQLite ROM containing the game's script and rules, plus a real-time browser observatory.
    2
    -

  • dosbox-mcp

    dosbox-automation
    A
    license
    Not graded
    quality
    C
    maintenance
    Bridges AI agents to a DOSBox emulator, enabling control of DOS programs via MCP tools for typing, screen reading, video capture, Lua scripting, and memory access.
    2
    GPL 2.0

  • local-game-mcp

    rrhoopes3
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to play local Windows games through low-level keyboard/mouse input, screen capture, OCR, and per-game profiles for semantic actions.
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rapaul/moo2-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server