Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

asset_export

Export a Blender model into the project's model root as a valid MLOD, returning a job ID to track completion. Verifies all LODs and references stay within the mod.

Instructions

Export a model out of a .blend into the project's model root.

Returns a job_id; wait for it with job_wait(job_id, timeout=...). One five-LOD model measured 2.1 s warm and about 8 s cold, but the ceiling is minutes, because how long an export takes is a property of the model.

This is the pipeline's OPTIONAL first step. It produces the MLOD; the binarized model that the game loads is what asset_build makes from it, and that is a separate call on purpose -- each half has its own verdict, and a mod whose .p3d came from somewhere else skips this entirely.

The project root declared as build.project_root is pushed into the exporting add-on for the duration of the run, so what the add-on has stored decides nothing. That matters: an add-on preference is remembered from whatever was open last, and against the wrong root every texture path comes out with the drive letter stripped and the rest kept -- valid-looking, resolving to nothing, reported as a success.

The verdict is read off the file: it must be an MLOD, this run must be what wrote it, all of the source's LODs must have reached it, and none of its references may leave the mod. Measured on a real model: with the exporter's own default arguments, 2 LODs of 5 came out as a valid MLOD with correct paths, FINISHED, exit 0, and no mention of it in 169 lines of log.

blend is absolute, or relative to the repository, or relative to build.project_root. source is the directory the model should land in, relative to the mod's own folder under that root (e.g. "data/models"); with exactly one such directory already holding models it can be omitted. name is the file to write, defaulting to the source file's own name with a .p3d extension.

Nothing else is touched: an export that produces nothing leaves the model that is already there exactly as it was, and Blender's user preferences are never written back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modNo
nameNo
blendYes
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?

With no annotations, the description carries the full burden of behavioral disclosure, and it goes above and beyond: it reveals the async contract (returns job_id, wait with `job_wait`, seconds-to-minutes latency), a subtle corruption failure mode (wrong root strips drive letters, looks valid, resolves to nothing, reports success), the exact verdict logic (must be an MLOD, this run must have written it, no outgoing references), and guarantees that nothing else is touched and Blender preferences are never written back. That is unusually deep transparency.

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

Conciseness4/5

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

The description is long (six paragraphs) but nearly every sentence carries decision-relevant facts: purpose, timing, failure mode, verdict criteria, side-effect guarantees, parameter semantics. It is front-loaded with the core behavior and only slightly verbose in the measured-example details (the 2-of-5 LODs / 169-line log anecdote), which explains a 5.

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?

For a complex asynchronous pipeline tool with a known silent failure mode and zero annotations, the definition covers everything an agent needs to invoke it correctly: parameters and defaults, the job-waiting protocol, timing bounds, verdict conditions, and non-destructive guarantees. Since an output schema exists, the description need not enumerate return fields, and it still mentions the `job_id` return.

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?

Schema description coverage is 0%, so the description must carry the weight. It compensates well for three parameters: `blend` gets three path-resolution modes, `source` gets its meaning and the single-directory omission rule, and `name` gets its default (source file name with `.p3d` extension). The `mod` parameter, however, is never explicitly explained; an agent must infer it from the 'mod's own folder' phrase.

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 first sentence names a specific verb and resource: Export a model out of a `.blend` into the project's model root. It also explicitly differentiates itself from the sibling `asset_build` by explaining the export produces the MLOD while the binarized game model is a separate call, so an agent can distinguish it from the other 50+ build assets.

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

Usage Guidelines5/5

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

It states positioning explicitly: 'This is the pipeline's OPTIONAL first step' and names the natural next step (`asset_build`) as 'a separate call on purpose.' It also gives a concrete exclusion rule for when to skip the tools: a mod whose `.p3d` came from somewhere else. An agent can decide when to call this tool versus its pipeline neighbor without further inference.

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