Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wardogs-mcp Design a small FOB: Hesco ring 14m out, two mortars, gate south, under 900 supplies."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that lets an AI assistant design forward operating bases (FOBs) for the shooter WARDOGS, using the wardogs.zone base builder, from a plain text brief.
The builder, its piece data and the base hub are the work of the Wardogs Zone team, the volunteers behind the Wardogs Zone Discord, who built a free, fan-made community hub for the game. This project exists because their builder is excellent. It is an independent tool, not affiliated with or endorsed by Wardogs Zone, BULKHEAD or Team17.
The builder stores a base as a single text string in the browser's draft slot. This server does the geometry (socket pitch, stacking, rings, validation), writes that string into its own Chromium window and reloads the builder so it renders. Other players' hub bases load the same way and can be edited.
It speaks plain MCP over stdio, so it works with any MCP client: Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, Zed, Cline, Gemini CLI, Goose and others.
The first browser tool call downloads the Chromium build Playwright drives (a few hundred MB, once, into Playwright's per-user cache) unless it is already installed. Building and validating plans without the browser needs no download.
No clone and no build. Add this to your client's MCP config:
{
"mcpServers": {
"wardogs": {
"command": "npx",
"args": ["-y", "wardogs-mcp"]
}
}
}Where that config lives depends on the client:
Client | Config file |
Claude Code |
|
Claude Desktop | Settings > Developer > Edit Config |
Cursor |
|
VS Code |
|
Windsurf |
|
Zed |
|
Cline |
|
Gemini CLI |
|
Some clients nest the same block under a different key (servers in VS Code,
context_servers in Zed). The command and args are the same everywhere.
Plans, screenshots, the dataset cache and the browser profile go in wardogs-mcp in your
home folder. Set WARDOGS_HOME to move them. The first run fetches the piece dataset from
wardogs.zone, so it needs the network once.
Download wardogs-mcp.mcpb from the
latest release and
double-click it. Claude Desktop shows an install prompt; click Install. This route needs
no Node.js. Files go in Documents/wardogs-mcp.
git clone https://github.com/MudcrabWarrior/wardogs-mcp.git
cd wardogs-mcp
npm run setupNode.js 20 or newer. npm run setup installs dependencies, downloads Chromium, fetches
the piece dataset from wardogs.zone and compiles dist/. It needs the network once; the
dataset is not tracked in the repo.
Point your client at the built server, using the real absolute path
(/path/to/wardogs-mcp/dist/server.js on macOS and Linux):
{
"mcpServers": {
"wardogs": {
"command": "node",
"args": ["C:\\path\\to\\wardogs-mcp\\dist\\server.js"]
}
}
}Claude Code needs no config from source: .mcp.json in the folder registers the server
when Claude Code runs from there. Full steps are in SETUP.md. A checkout keeps
plans, screenshots and the browser profile in the package folder, and plans/ holds a
worked example, loaded with plan_load vauban-mega-v1.
Related MCP server: ritn3d-mcp
Describe the base you want:
New base. FOB at centre. Hesco small ring 14 m out with a gate on the south side.
Mortar pit north-east inside the ring, two mortars. Stack the ring two high on the
north side only. Keep supplies under 900. Push it and screenshot from camera 2.Units are metres on the flat pad, and yaw is in degrees. In ring(), north is -z, south
is +z, east is +x and west is -x. Every piece must sit inside a FOB's 60 m square.
Good bases need more than geometry: vault heights, standoff distances, where bastions go,
which builder quirks to work around. That ruleset is served over the protocol by the
rules tool, so every client gets it without any per-client setup. Assistants are told to
call rules before planning a base; if yours does not, ask it to. The same text is also
exposed as the resource wardogs://rules, and the source file is AGENTS.md.
Ask for browser_open.
In the Chromium window that appears, click Sign in (Discord) and complete it yourself.
The session is kept in .profile inside the writable home folder.
hub_save fills the save dialog. You complete any captcha and click Save.
Nothing types credentials on your behalf, and nothing outside .profile stores them.
Building and screenshotting bases do not require sign-in.
Two things this tool will never do, by agreement with the Wardogs Zone team: it does not complete or work around the captcha, and it does not save to the hub by itself. The Save click is always yours.
Rules: rules
Plan: plan_new, plan_status, plan_pieces, plan_code, plan_load_code,
plan_save, plan_load, plan_list, undo, redo
Edit: place_fob, place, wall_run, ring, stack, move, set_pose,
remove, remove_all
Browser: browser_open, browser_push, browser_pull, browser_readback,
browser_screenshot, browser_key, browser_close
Hub: hub_import, hub_save
Data: list_buildables, describe_buildable, data_refresh
src/data.ts fetch and cache the piece dataset
src/plan.ts codec, snapping, stats, validation (ports of the site's functions)
src/editor.ts working plan, wall runs, rings, stacking, undo
src/browser.ts Playwright control of the builder
src/server.ts MCP tools
scripts/ dataset extract and .mcpb bundle buildScripts, tests and the pull request process are in CONTRIBUTING.md.
Local clients only. The server drives a real Chromium on your machine and keeps a browser profile on disk. Hosted and remote setups (web chat connectors, server-side MCP) cannot run it.
Open pad only. Map sites (Kavkazi, Europe, North America) need terrain heights and are not wired up yet.
Overlap checks use whole-piece boxes, while the site checks per mesh. A mortar inside a
bunker is valid on the site but reports as an overlap here. Treat overlap as a warning
and trust the builder's own status line after browser_push.
Plans loaded through the draft slot skip the site's placement checks, so an invalid
plan still renders. plan_status is the guard.
Take a screenshot after the first push and mirror yaw if the layout comes out the wrong way round.
wardogs.zone does not support this tool; its maintainers have kindly allowed it, and that is all. Problems with wardogs-mcp go to the issue tracker here or to the wardogs-mcp thread in the field-manual forum of the Wardogs Zone Discord (join the server first, or the link will not open). Problems with the builder itself are theirs, and their normal channels apply.
Wardogs Zone built and runs the base builder, the piece dataset and the hub this server drives, and gave this project their blessing. https://wardogs.zone, Discord https://discord.gg/kTKpbwvF4n
The base-building rules in AGENTS.md draw on
WARDOGS: Build Better Bases - Star Fortress Fundamentals
by Get Gud with Garen.
WARDOGS is by BULKHEAD, published by Team17.
What this server takes from the site: it reads the piece dataset out of the builder's own script bundle (the page and its script chunks, about 2.4 MB, normally once a week, cached locally and never redistributed) and drives the builder in a local Chromium window under your own Discord sign-in. Publishing to the hub is always a button you click yourself.
MIT. See LICENSE. The licence covers this repository's code only, not the site's data or the builder it drives.
Close the MCP's browser window.
Inputs: no named parameters.
Press a key in the builder (camera 1-4, F frame, Tab cycle, Z/V toggles).
Inputs: key (required).
Open (or focus) the builder in the MCP's own Chromium window. The first browser use downloads Chromium (a few hundred MB) if Playwright has not installed it yet. Sign in to Discord there once if you want hub_save.
Inputs: no named parameters.
Adopt whatever the builder currently holds as the working plan (captures hand edits made in the window).
Inputs: no named parameters.
Render the current plan (or a given code) in the builder and read back the site's manifest.
Inputs: code.
Read the builder's manifest, totals, status line and sign-in state without changing anything.
Inputs: no named parameters.
Screenshot the builder window to plans/-.png. camera: 1..4 selects the builder's camera presets, 'f' frames the base.
Inputs: name, camera.
Re-extract the buildables dataset from wardogs.zone (cached 7 days otherwise).
Inputs: no named parameters.
Full data for one piece: boxes, socket positions and kinds. Accepts id, label or a loose name like 'hesco small'.
Inputs: piece (required).
Open another player's hub base (id or URL like https://wardogs.zone/loadouts/base/hub/a5f1729bb1) and adopt it as the working plan unless adopt=false.
Inputs: idOrUrl (required), adopt.
Push the current plan and open the site's save dialog with name and notes filled. Needs a Discord sign-in in the builder window; the user completes any captcha and clicks Save.
Inputs: name (required), notes.
List placeable pieces with id, cost, hp, c4, stack limit and footprint. Filter by kind: core, fortification, defence, support, vehicle, structure.
Inputs: kind.
Move a piece by a delta in metres and degrees.
Inputs: key (required), dx, dy, dz, +1 more.
Count open side sockets per wall piece. A sealed wall shows every piece with exactly 2 open sockets (the outward and inward faces), corners included. 3 or more means a hole or a loose end. Optional filter by piece id.
Inputs: piece.
Place one piece at (x, z) with yaw in degrees and optional height y. By default it snaps to the nearest compatible socket within snapRadius metres; set snap=false for free placement. parent limits snapping to one piece key.
Inputs: x (required), z (required), piece (required), y, +4 more.
Place the Forward Operating Base. Everything else must sit inside its 60 m square. Defaults to the origin.
Inputs: x, z, yaw.
The plan as the site's share string. Paste-able into the builder's draft or another tool.
Inputs: no named parameters.
List saved plans in plans/.
Inputs: no named parameters.
Load a plan saved with plan_save.
Inputs: name (required).
Replace the current plan with a site plan string (from plan_code, hub_import or the browser).
Inputs: code (required).
Start an empty plan. world is null for the open pad (v1 only supports the open pad).
Inputs: world.
List pieces with key, position and yaw. Optional filter by id or label substring.
Inputs: filter.
Save the current plan to plans/.json in the writable home folder. Overwrites an existing plan of the same name.
Inputs: name (required), notes.
Summary, supply cost, breakdown and validation issues for the current plan.
Inputs: no named parameters.
Redo the last undone edit.
Inputs: no named parameters.
Remove pieces by key.
Inputs: keys (required).
Remove every piece, or every piece of one id.
Inputs: piece.
Square ring of walls centred on (cx, cz), half metres from centre to each wall line. Optional gap on one side (north=-z, south=+z, east=+x, west=-x), gapWidth metres, and a gate piece placed in the gap.
Inputs: cx (required), cz (required), half (required), piece (required), +4 more.
The standing WARDOGS base-building ruleset: site limits, player movement facts, firing positions, fortification principles, walls and layers, gates, emplacements and builder quirks. Read this before planning a base.
Inputs: no named parameters.
Set a piece's absolute position and/or yaw.
Inputs: key (required), x, y, z, +1 more.
Stack count more copies on top of piece key using its top socket (respects the stack limit).
Inputs: key (required), count.
Undo the last edit.
Inputs: no named parameters.
Straight run of one piece type from (x1,z1) to (x2,z2) at socket pitch, long axis along the run. count overrides the piece count; skip lists indexes to leave out (for a gap).
Inputs: x1 (required), x2 (required), z1 (required), z2 (required), +4 more.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 33 tools
Most tools target distinct resource+action pairs, and the detailed descriptions make even similar pairs (move vs set_pose as relative vs absolute, plan_pieces vs plan_status) easy to separate. A few pairs could trip up an agent though: plan_load_code vs plan_load (site string vs saved file), hub_import vs plan_load_code (both replace the plan from an external source), and browser_push vs browser_readback.
Snake_case is used throughout and the plan_, browser_, and hub_ prefixes create strong group predictability. However, the word after the prefix alternates between noun (plan_status, plan_code, browser_readback) and verb (plan_save, plan_load, browser_push), and the bare tools mix verb-first (list_buildables, set_pose), noun-verb (data_refresh, wall_run), and imperative (undo, stack) styles.
33 tools is heavy and exceeds the typical comfortable band, but the server genuinely spans several sub-domains: buildables catalog, plan lifecycle, geometry editing, persistence, hub sharing, and browser automation. Some fragmentation exists (wall_run and ring could be one pattern generator; the seven browser_* tools could be consolidated into fewer parameterized tools), so the count earns a middling score rather than a poor one.
The tool surface covers the full base-planning workflow with no dead ends: rules and buildable data, plan creation/query/serialization, every placement and transformation primitive, validation (plan_status, perimeter_check), persistence (plan_save/load/list), sharing (plan_code, hub_import/hub_save), and full browser interactivity including readback and screenshots. Every save has a corresponding load and every import has an export.
Build, validate, deploy — HTTP APIs, cron jobs, webhooks and MCP tools — from your AI client.
Parametric 3D CAD for AI agents: build print-ready parts, check them, export STL, 3MF or STEP.
Design, save, and run outcome-aligned AI workflows and verifiers, with reliable image output.
Build, validate, and deploy multi-agent AI solutions from any AI environment.
