Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

bridge_status

Determine if the game bridge is alive by checking whether its tick counter advances, returning a clear status like alive, frozen, or unknown within a configurable window.

Instructions

Is the bridge inside the running game still ticking?

Blocks for up to window seconds (default 2, clamped to STATUS_WINDOW_MAX) because that is what it costs to see a tick MOVE. window=0 returns at once and then usually cannot tell -- it reports "unknown", never "frozen".

A stand with no state file at all now costs the FULL window too (measured: 2.07s at the default, 10.05s at the cap), because the reader retries to the deadline rather than giving up on the first miss. If the question is only "is the bridge publishing anything yet" -- the usual one while wiring it up -- pass window=0 and get the same answer in a tenth of a second; a window buys movement, and nothing else.

The answers, told apart in this order:

no_server nothing is running, so there is nothing to ask. Checked FIRST and on the process, not on the file: the state file outlives the server that wrote it, and reading a leftover snapshot as a live bridge is precisely the lie this ordering prevents. stale_command the same, but with a command still sitting in the mailbox. Its own answer because the remedy is its own: the command does not expire, it blocks every send, and a stand booted OUTSIDE these tools would pick it up. (server_start clears the transport before every boot, so a server started through these tools will not.) no_state_file / the server is up but nothing readable came back. Four outdated_bridge / fixes, so four answers: the mod is not loaded; the mod invalid_state / predates this server's protocol (no session_id at all); unreadable_state the document is valid JSON but a named field is wrong (the answer says which field, what was expected and what was seen, and it is checked twice a publish interval apart so a mangled write is never reported as a schema bug); or it does not parse at all. alive / restarted a comparison was made. alive means the tick moved; / frozen / restarted means a new world came up mid-sample (also unknown alive, and NOT frozen); frozen means the same world was seen twice without moving; unknown means no comparison could be made. Only the first two return ok.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
windowNo

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 provided, the description carries full burden and excels: it explains blocking behavior, the cost of window=0, the no-state-file penalty, and the order of answer checks, including why no_server is checked on process not file to avoid stale snapshots. It discloses the multiple return values and their meanings, which is rare and high-value.

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 but densely informative, with a clear front-loaded opening question, then structured sections for answers. Every sentence adds value, though it could tighten some phrasing. The length is justified by the complexity of the tool's semantics.

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?

Given the tool's moderate complexity, one optional parameter, and high-quality schema/output schema coverage, the description is complete: it explains all return states, the reason for ordering, and the cost trade-offs. An agent has everything needed to invoke 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?

The only parameter `window` has 0% schema description coverageible> but the description thoroughly explains its semantics: default, clamping, unit (seconds), and the behavioral impact of different values (window=0 returns immediately and reports unknown vs larger windows detect movement). This is far more than the schema provides.

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 checks if the bridge is 'still ticking' in the running game, with a specific verb and resource. It distinguishes itself from siblings like server_status and bridge_build by focusing on the bridge's live tick status.

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 advises when to use window=0 for quick 'is it publishing' checks vs a larger window for movement detection Menu>implied usage is not present; it gives concrete guidance on block timing and trade-offs, and warns about the cost of no state file. It also implicitly differentiates from siblings like server_status (server-level) and bridge_build (build action).

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