Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

world_exec

Send arbitrary verbs to a DayZ mod through the server bridge for debugging, bypassing validation. Use for escape-hatch commands not expressible as standard actions; responses are marked non_standard.

Instructions

Send an arbitrary verb through the bridge -- the debugging escape hatch, not a testing path.

This server does not know the verb, does not validate its arguments beyond stringifying them, and does not answer for what the mod does with it; every answer is marked non_standard to say so. Anything a mod's behaviour can express as an ACTION should go through world_action instead, where the mod's own Can() gives the refusal meaning.

A verb this bridge build does not know comes back as a failure listing the verbs it does -- that is the mod answering, not this tool guessing. A project that needs its own verb adds it to ITS OWN copy of the bridge's dispatcher (IsKnownVerb, the routing, and a handler); this server ships no registration machinery on purpose, because a verb the server typed and validated would be a verb the server answers for.

The verb must be lowercase ASCII (letters, digits, underscore, up to 41 chars): the mod recovers a command's id by a raw string search when a parse fails, and the id embeds the verb -- characters outside that set can make a failure impossible to correlate, which is the silence this product exists to remove.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
argsNo
verbYes
timeoutNo

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 extensively discloses behavioral traits: the server does not know the verb, does not validate arguments beyond stringifying them, marks all responses as 'non_standard', and returns a failure listing known verbs for unknown ones. It also details the verb format constraints (lowercase ASCII, up to 41 chars). This fully covers the tool's behavior given no annotations.

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

Conciseness2/5

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

The description is extremely verbose and repetitive. The same contrast with world_action is stated multiple times, and the language is overly poetic ('silence this product exists to remove'). It could be condensed into a few clear sentences without loss of meaning. The structure is not efficient for an agent to parse.

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?

Given the tool's generic nature (arbitrary verb bridge), the description covers all necessary context: purpose, constraints, failure modes, and relationship to world_action. It is complete enough for an agent to decide when to use it and what to expect. However, the verbose style makes it less accessible, though not incomplete.

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?

The description adds significant meaning to the 'verb' parameter (format and constraints) and 'args' (stringified without validation). It does not explain the 'timeout' parameter, but that is a common parameter with a default value. Overall, it enriches understanding of the schema beyond its bare types.

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 tool's purpose: 'Send an arbitrary verb through the bridge' and positions it as a 'debugging escape hatch'. It distinguishes itself from world_action, which is for normal actions. The core function is unambiguous despite the flowery language.

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 explicitly instructs when to use this tool versus alternatives: 'Anything a mod's behaviour can express as an ACTION should go through `world_action` instead'. It also notes it's for debugging and that unknown verbs return a failure listing valid verbs. This gives clear usage context.

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