Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

client_compile_check

Compile the client half of DayZ scripts and run a time-boxed diagnostic to detect client-only errors—broken menus, widgets, or actions—that server checks miss. Returns a job ID.

Instructions

Compile the CLIENT half of the scripts and judge the result. Returns a job id.

A server boot never compiles anything behind the client-only guard, so a broken menu, a broken widget or a broken client-side action passes every server check and then breaks in front of a player. This runs the diagnostic client for wait_seconds, stops it, and judges what it wrote -- and the verdict does not accept a clean log on its own: the game's own "Module: Mission" line has to appear, otherwise "no errors" only means "not that far yet" and the job says so.

The client runs against a THROWAWAY -profiles directory inside this job's artifacts, so it never reads or writes the test stand. It also joins nothing: this is a compile pass, not a session. For the live client that connects to the stand -- and for looking at it, acting through it, and judging its .RPT -- the tools are client_start and its siblings, and log_verdict(source="client") reads THIS job's log while client_verdict reads the live client's.

extra_mods appends to the -mod list for this run only, for checking that a mod still compiles alongside another one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
extra_modsNo
wait_secondsNo

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 fully discloses behavior. It details that the tool runs a diagnostic client for wait_seconds, stops it, and judges its output, requiring the specific 'Module: Mission' line to accept the log. It also notes the use of a throwaway profiles directory, that it does not read/write the test stand, and that it joins no session. This is comprehensive behavioral 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 information-dense and structured logically, starting with the core function, then nuance, then exclusions, then parameters. While slightly long, every sentence contributes value. It could be tightened, but it remains efficient and well-organized.

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 tool with this complexity—compile logic, judgment criteria, exclusions, parameters—the description covers all necessary aspects: what it compiles, how it judges, what it doesn't do, alternatives, and parameter behavior. It even states the return type ('Returns a job id'). Nothing essential for an agent to call it correctly is missing.

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?

Schema description coverage is 0%, yet the description explains both parameters: 'runs the diagnostic client for wait_seconds' and 'extra_mods appends to the -mod list for this run only.' This fully compensates for the lack of schema documentation, adding meaning beyond the raw property definitions.

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 opens with a clear verb-resource pair: 'Compile the CLIENT half of the scripts and judge the result.' It explicitly distinguishes itself from live-client tools by stating 'this is a compile pass, not a session' and names alternatives like client_start. This leaves no ambiguity about what the tool does relative to its siblings.

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?

The description provides explicit guidance on when to use this tool versus alternatives. It explains that for the live client, one should use client_start and siblings, and it clarifies that log_verdict(source='client') reads this job's log while client_verdict reads the live client's. It also warns that a server boot never compiles the client-only guard, implying this tool is needed for client-side validation.

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