Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

world_state

Retrieve a current world snapshot, including player position, health, and held items, within a given radius to avoid round-trip queries.

Instructions

What the world looks like right now.

With NO class_name this costs nothing and waits for nothing: the mod republishes the player's position, health and what is in their hands every tick, so the answer is already on disk. That is deliberate -- a snapshot a caller has to pay a full command round trip for (a second to be claimed, two more of terminal dwell) would make the cheapest question the most expensive one.

With a class_name it also sends a query command to count objects of that class within radius, because a count needs arguments only a command carries. The count comes back in world.query_count as well as in the detail, so it stays readable on later snapshots too -- which is how "is the item I spawned a minute ago still there?" gets answered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
posNo
radiusNo
timeoutNo
class_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
dataNo
hintNo
errorNo
Behavior3/5

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

No annotations are present, so the description must carry the burden. It explains that without class_name it reads cached player state (republished every tick) and with class_name it sends a query command and returns a count. This covers some behavior but does not explicitly state whether the command has side effects or if the tool is read-only. The phrasing 'the answer is already on disk' implies a cached read, but side effects are not fully disclosed.

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 verbose and unnecessarily poetic, repeating a rhythmic pattern that obscures core information. It could convey the same functionality in a fraction of the words. The structure is not concise, making it harder to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description explains the two operational modes (with/without class_name) and the caching rationale, it lacks details on return structure (output schema is not shown), error conditions, required parameters (all are optional but their defaults are unclear), and how the tool integrates with the broader workflow. The description is incomplete for a developer to use it confidently without external knowledge.

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

Parameters2/5

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

The schema provides no parameter descriptions, and the description only partially hints at parameters: pos, radius, timeout, and class_name are mentioned, but their precise meanings and defaults are not fully explained. For example, radius is referenced in the context of the class_name query, but pos and timeout are not clarified. Schema coverage is 0%, so the description must compensate, but it does not sufficiently define each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool returns the current world state (player position, health, items) and optionally a count of objects by class. However, the wording is cryptic and poetic, making the exact purpose less straightforward than it could be. It does differentiate from siblings like world_entities by focusing on player state and optional query counts.

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

Usage Guidelines2/5

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

The description does not explicitly state when to use this tool versus alternatives (e.g., world_entities, world_spawn). It explains the caching behavior and query mechanism but provides no guidance on selection criteria or situational usage.

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