Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

asset_build

Build DayZ mod models from MLOD sources into game-ready binary format, verify the artifact, and deploy it into the mod. Returns a job ID for asynchronous progress tracking.

Instructions

Build a mod's models from their MLOD sources and put them in the mod.

Returns a job_id immediately: ONE small model measured 75.6 to 78.7 seconds across four runs, so this can never be a blocking call. Wait for it with job_wait(job_id, timeout=...) -- give it minutes, not seconds -- and read the numbers in the job's summary and its asset-build.json artifact.

What it does, in order: run binarize with its working directory set to the project root declared as build.project_root, judge the ARTIFACT that came out (never the tool's exit code -- three separate broken outcomes were measured exiting 0, one of them leaving a zero-length file), and only then copy the models into the mod. A refused build deploys nothing and leaves the artifact the mod already ships exactly as it was.

mod names one of build.mods; with a single declared mod it can be omitted. source is the model directory relative to the mod's own folder under the root (e.g. "data/models"); left out, the only directory holding .p3d files is used and two candidates are a refusal rather than a guess. deploy=False builds and judges without writing into the mod.

The source is the MLOD export and the ODOL is the build's output (decision D3). Handed an ODOL, binarize dies with 0xC0000005 and leaves a zero-length file behind, so that is refused before the process starts.

Model.cfg is never copied for you: it is what the artifact was built from, and a mismatch between the copy under the root and the copy in the mod is reported by C11 with what to do about it. Rebuilds are not byte-stable and are not expected to be -- what a rebuild is compared against is structural.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modNo
deployNo
sourceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataNo
hintNo
errorNo
Behavior5/5

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

The description is highly transparent: it explains the internal steps (running binarize, checking artifact, copying models), side effects (deploy or not), failure modes (refusal for invalid source or ambiguous candidates), and non-deterministic rebuilds. It also notes the return behavior (job_id) and that Model.cfg is not copied. With no annotations, it fully carries the burden.

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

Conciseness3/5

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

The description is verbose and repetitive, with duplicated statements about the process (e.g., 'Build...and put them' vs. 'copy the models into the mod') and an anecdotal timing example that adds length without essential value. While well-paragraphed, it is not concise; it could be streamlined by removing redundancies.

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?

The description covers the main context: parameters, return behavior, refusal conditions, artifact handling, and structural comparison. It references job_wait for polling and mentions the artifact but does not describe the output schema or exact job_id format. Given no output schema is provided, it is reasonably complete for an agent to use the tool correctly.

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

Parameters5/5

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

All three parameters are explained with meaningful detail beyond the schema: mod ('names one of build.mods...'), deploy ('deploy=False builds and judges without writing'), and source ('model directory relative to the mod's own folder...'). It covers defaults, exclusions, and edge cases (e.g., two candidates cause refusal). Schema coverage is 0%, so the description compensates fully.

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 the action: 'Build a mod's models from their MLOD sources and put them in the mod.' It specifies the resource (mod models) and the source (MLOD sources), distinguishing it from siblings like asset_export or asset_convert. The verb 'build' is specific and the scope is well-defined.

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?

The description details the behavior and conditions for use (e.g., default source selection, refusal cases), but it does not explicitly state when to use this tool over alternatives like asset_export or mod_build. The guidance is implicit through detailed process explanation, but lacks a clear 'use this when...' statement.

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

Install Server

Other Tools

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/covalschi/dayz-agentic-modding-mcp'

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