Unofficial MCP server for the wardogs.zone base builder: an AI assistant designs and renders WARDOGS FOB layouts from a plain text brief. Built on the Wardogs Zone community hub.
wardogs-mcp has 33 tools with consistent naming (verb_noun pattern: place, plan, remove, etc.) and detailed descriptions (avg ~120 chars). All tools have input schemas with type definitions. However, output schemas are undocumented, responses are text-wrapped JSON with no declared structure. Parameter descriptions are present but often terse (e.g., 'Piece id, label or name' lacks format guidance). Error handling is minimal; tools return plain text without recovery guidance. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Missing pagination for list_buildables and plan_pieces despite potentially large result sets.
Close the browser window.
Press a builder hotkey (camera 1-4, F to frame).
Open the builder in a Chromium window.
Read the builder's draft back into the plan.
Render the plan in the builder.
Read supplies, piece count and status from the builder.
Screenshot the builder.
No output schemas documented. All tools return text-wrapped JSON via text() helper, but LLMs cannot infer response structure. Responses like plan_status, plan_pieces, describe_buildable lack declared field types and nesting.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels in metadata. Tools like remove_all (DESTRUCTIVE), place (WRITE), undo (REVERSIBLE) should declare hints to guide agent safety.
Parameter descriptions lack format guidance. 'Piece id, label or name' does not explain matching logic (substring? exact? case-insensitive?). 'X coordinate' lacks range or unit clarity. Numeric params (x, z, y, yaw) need min/max bounds.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Re-extract the buildables dataset from wardogs.zone (cached 7 days otherwise).
Full data for one piece: boxes, socket positions and kinds. Accepts id, label or a loose name like 'hesco small'.
Load a hub base into the builder.
Open the hub save dialog with the plan filled in.
List placeable pieces with id, cost, hp, c4, stack limit and footprint. Filter by kind: core, fortification, defence, support, vehicle, structure.
Move pieces.
Report wall pieces with more than two open sockets.
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.
Place the Forward Operating Base. Everything else must sit inside its 60 m square. Defaults to the origin.
The plan as the site's share string. Paste-able into the builder's draft or another tool.
List saved plans in plans/.
Load a plan saved with plan_save.
Replace the current plan with a site plan string (from plan_code, hub_import or the browser).
Start an empty plan. world is null for the open pad (v1 only supports the open pad).
List pieces with key, position and yaw. Optional filter by id or label substring.
Save the current plan to plans/<name>.json in the writable home folder. Overwrites an existing plan of the same name.
Summary, supply cost, breakdown and validation issues for the current plan.
Redo the last undone edit.
Remove pieces.
Clear the plan.
Square ring of walls centred on (cx, cz), half = metres from centre to the wall centre line. Optional gap on one side and a gate in it.
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.
Set a piece's exact position and yaw.
Stack pieces on top of others.
Undo the last edit.
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).
No pagination for list_buildables and plan_pieces despite potentially large result sets. list_buildables can return 100+ pieces; plan_pieces grows with plan size. Missing limit/offset and total count.
Error handling returns plain text without recovery guidance. No categorization of retryable vs user-fixable errors. E.g., 'No match for "piece"' does not suggest calling list_buildables or describe_buildable with a corrected name.