AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
MCP verified MIT Self-run

Dayz Mcp

mcp-willy92wins-dayz-mcp · by willy92wins

MCP tool to enable complete AI control over your dayz client/server. Used to develop many mods. Can be used to close the loop and let AI test ingame developed mods, or even use AI as a game orchestrator in a server. Playbook and documentation for IAs included and the product is smoothed out to be usable even by small/less capable agents

No reviews yet
0 installs
10 views
0.0% view→install

Install

$ agentstack add mcp-willy92wins-dayz-mcp

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/mcp-willy92wins-dayz-mcp)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2d ago

Declared compatibility

Claude CodeClaude DesktopCursorWindsurf

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Dayz Mcp? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

DayZ-MCP

An MCP server that puts an agent's hands on a running DayZ: build a mod, launch the game, put the world into a state, act, and read back what the engine did — 63 typed tools, server-authoritative, no keyboard, no OCR.

Two things fall out of that, and both are new for this game:

  • The autonomous mod-development loop closes. Editing Enforce Script, config.cpp

and models is file work; packing a PBO is a command. What could not be automated was the part that decides whether the change actually works — getting the game up with the mod loaded, putting a player, a vehicle or an object into the exact situation the change is about, and reading the result. That step was a human at the client. DayZ-MCP makes it tool calls: an agent can now change, build, run, measure and fix a mod on its own.

  • An agent can run a server. The same verbs that set up a test scene are the ones

an event director or an admin needs: see every player, teleport one, spawn or remove something, change time and weather, message everyone, watch the log, wait for a condition — all through MissionServer, all serialized behind one daemon with leases and an audit trail. Point an agent at a server and it can operate it, not just query it.

The verbs are also useful one at a time — spawn a car and read its telemetry, grab a frame, raycast a placement, record a 20 Hz drive trace as a regression fixture (tools/dayz_mcp/vehicle_trace.py:17).

The development loop, as tools

| Step | Tool(s) | What it does | |---|---|---| | Build + launch | dayz_test_run(project, mode, build=True, …) | Packs the mod with AddonBuilder, starts a diag server and/or client with it loaded, waits for readiness. Managed run, returns a run_id. | | Set up the scene | world_spawn, player_teleport, vehicle_enter, inventory_attach, inventory_give, world_time_set, world_weather_set, engine_set | Put the world into the state the test needs — deterministically, from script. | | Act | vehicle_control, object_anim, camera_set, notify_players | Drive, animate, frame the shot. | | Iterate the UI | ui_reload_layout, ui_tree, ui_dialog, capture_screenshot | Reload a .layout written into the client's profile directory and read back the rectangles the engine computed for it. The file is re-read on every call, so a panel can be edited and re-measured in seconds instead of one repack-and-boot per change. ui_dialog is the client modal (acknowledge/confirm/form) for the local player. | | Observe | wait_for, logs_since, query_player_state, object_inspect, vehicle_telemetry, vehicle_trace, scene_raycast, surface_query, capture_screenshot | Structured state from the server, log tails since a cursor, 20 Hz vehicle traces, raycasts, frames. Data an agent can assert on, not pixels to squint at. | | Reset + repeat | restore_gameplay, dayz_test_stop, session_acquire_wait, session_release, session_status | Return the world to normal, stop the managed run, hand the game to the next session. |

An agent that can call these can iterate on a mod the way it iterates on code: change, build, run, measure, fix — the way this repo itself was developed and gated.

The server, as tools

| Need | Tool(s) | |---|---| | Who is online, where, in what state | query_all_players, query_player_state, object_inspect | | Move, equip, stage | player_teleport, inventory_give, inventory_attach, world_spawn, object_delete, object_anim, vehicle_prepare_fixture | | Set the stage | world_time_set, world_weather_set, engine_set | | Talk to players | notify_players | | Watch | logs_since (tail from a cursor), wait_for (block on a condition or a log substring), telemetry_read, vehicle_telemetry | | Undo, hand over | restore_gameplay, session_acquire_wait / session_release / session_status |

Everything server-side works against a headless server — it returns data, not frames. Visual capture (capture_screenshot, camera_get, camera_set) needs a rendered client on the same machine. Several agents can share one running game: the daemon owns the port, hands out one lease at a time and audits what each holder did.

How it works

Control and data are engine-native and server-authoritative: CreateObjectEx, StartCommand_Vehicle, the Car setters, RaycastRVProxy, SetTimeMultiplier, read back in MissionServer. No synthesised keystrokes, no OCR. The one exception is visual capture — MakeScreenshot is broken in the diag build (T165276), so frames come from an external window grab of the rendered client, which only reads pixels.

63 tools (+ exec_enforce when an allowlist is configured) across world, player, vehicle, camera, telemetry, lifecycle, knowledge and session coordination: action_use, bridge_status, camera_get, camera_set, capture_screenshot, dayz_knowledge_find, dayz_knowledge_prepare, dayz_knowledge_show, dayz_knowledge_status, dayz_test_close, dayz_test_run, dayz_test_stop, engine_set, entities_query, infected_drive, inventory_attach, inventory_give, key_press, lease_acquire, list_projects, logs_since, notify_players, object_anim, object_delete, object_inspect, pipeline_feedback, pipeline_inbox, pipeline_resolve, playbook_reload, playbook_run, player_respawn, player_teleport, query_all_players, query_get_in_condition, query_player_state, restore_gameplay, scene_raycast, session_acquire, session_acquire_wait, session_cancel, session_heartbeat, session_release, session_status, session_wait, surface_query, telemetry_read, ui_click, ui_dialog, ui_focus, ui_reload_layout, ui_set_text, ui_tree, vehicle_control, vehicle_enter, vehicle_get_in_client, vehicle_prepare_fixture, vehicle_release, vehicle_telemetry, vehicle_trace, wait_for, world_spawn, world_time_set, world_weather_set. Several agent sessions can share one running game through a single daemon that owns the port and hands out leases. The full surface, the transport and the security model are in [dayz-mcp-architecture.md](dayz-mcp-architecture.md); the acceptance contract is in [product-spec.md](product-spec.md).

In-game numbers

A1. query_player_state against an independent mission marker (target=marker): 0.0313 m, pass line ```

Tests

The MCP server and its test suite are Windows-only.

cd tools
.\.venv-mcp\Scripts\python.exe -m unittest discover -s tests -t .

Tests that need a built launcher, an installed registry or development-only evidence skip with the reason named. Everything else passes on a fresh clone, so anything red is worth reporting.

The virtualenv has to be the one the installer creates, at tools/.venv-mcp: the daemon resolves that path when it checks its own identity, and an environment somewhere else fails at startup rather than falling back.

Licence

MIT — see [LICENSE](LICENSE).

DayZ is a trademark of Bohemia Interactive. This project is not affiliated with or endorsed by Bohemia Interactive, and ships none of their game data.

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.