Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

bridge_clear

Clear a stale queued command blocking the bridge, freeing the channel for new sends. Refuses if bridge is active; use force to override.

Instructions

Discard whatever command is sitting in the mailbox.

The remedy for bridge_status's stale_command. Inside the game, claiming a command IS deleting the file, so a command sent while the stand was down, or before the bridge was wired into -serverMod, is never claimed and never expires on its own: it blocks every later send until something removes it. Two things on this side do -- this tool, and server_start, which clears the transport before every boot. A stand booted outside these tools would run the command instead.

Its own tool, and never a side effect of asking for status: throwing away a queued command is a decision, and bridge_status reporting the wedge must not be the thing that silently resolves it.

Refuses when anything suggests the bridge is alive, because a running mod could claim that command at any moment and destroying live in-flight work is worse than leaving the wedge. FIRST on the plain fact that a server this session started is running -- whatever its bridge is or is not publishing, which matters most for a mod that has not started writing state yet -- and that refusal costs no probe at all. Otherwise the channel probes for probe_window seconds and refuses on a tick that moved, on a world that restarted, AND on a readable first sample followed by an unreadable second one -- that last is proof something was alive moments ago, which a downed stand never produces. force=True overrides all of it, and what it overrode is reported either way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNo
probe_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 the full burden and handles it exceptionally. It discloses the deletion semantics (claiming IS deleting the file), the safety refusal logic (won't act if the bridge may be alive), the probing preconditions, and that force=True overrides everything. It also contrasts its behavior with server_start and explains what would happen outside these tools.

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

Conciseness5/5

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

The description is substantial but every sentence earns its place. It front-loads the core purpose in the first line, then builds context in tight, meaningful paragraphs without fluff. The structure flows from purpose → context → safety behavior → parameters, and no sentence is wasted.

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?

Despite the complexity — a 2-param tool with an output schema, no annotations, and embedded 'own name references' in the description — the description explains what the tool does, why the problem exists, when to use it, what safety checks apply, and what force does. The only tiny gap is that probe_window units aren't specified, but the output schema presumably covers return values.

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 coverage is 0%, so the description must compensate — and it does. It explains force=True ('overrides all of it') and probe_window ('probes for probe_window seconds'), which adds real meaning beyond the bare schema fields. The only minor gap is not specifying units or boundary behavior for probe_window, but the essential semantics are there.

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 immediately states 'Discard whatever command is sitting in the mailbox' — a specific verb, resource, and action. It clearly distinguishes itself from related tools like bridge_status and server_start by explaining the wedge problem and naming the sibling that also clears it. The purpose is unmistakable.

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 tells when to use it ('the remedy for bridge_status's stale_command') and when not to ('Refuses when anything suggests the bridge is alive'), and names the alternative (server_start) that also clears the transport. It states that throwing away a queued command is a decision, never a side effect of status checks — strong guidance on 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