Skip to main content
Glama
covalschi

dayz-agentic-modding-mcp

client_chat

Send a chat message to every connected DayZ player at once, with optional color and timeout settings, and receive confirmation of delivery.

Instructions

Put a line in the connected player's chat. FOCUS IS NOT NEEDED.

Said plainly because the general rule about typing does not apply here. Chat is a SERVER-SIDE MESSAGE: the engine hands the mod a call that delivers text to a player, so the bridge sends it as data -- no keyboard, no window, no foreground, and nothing taken away from whoever is at the machine. It is also more trustworthy than real typing, because the command carries an id and comes back with the mod's own confirmation instead of "typed it and hoped".

This is NOT the tool for a mod's own input field -- a PDA, a terminal, a form. Those exist only on the client and are filled by client_type, which does need the foreground.

The line goes to EVERY connected player, and the answer says how many got it: the engine's call names one recipient, so a verb that quietly took the first player would put the line on one screen and leave it missing from the one the caller was watching.

color is one of colorStatusChannel (the default), colorAction, colorFriendly or colorImportant. Anything else is refused BY THE MOD rather than passed on, because the client turns a colour class it does not know into plain white and says nothing about it. Long lines are refused too, rather than cut somewhere the caller cannot see.

What success promises is that the engine accepted the call for each named recipient -- not that the line was visible. A client drops whole chat channels according to the player's own profile options, so an accepted line that nobody can see is a client setting, not a fault in the bridge.

Requires the bridge to be loaded and ticking, like every other world command, and requires the stand to be running a bridge build that knows the verb; if it is not, the mod says so and the hint says what to do.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
colorNo
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?

With no annotations, the description carries the full burden, and it excels: it discloses that focus is unnecessary, messages are server-side, go to all connected players, color values are validated by the mod with refusal for invalid ones, long lines are refused, success means engine acceptance rather than visibility, and client profile options may drop channels. This is exceptionally transparent.

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 verbose but structured into clarifying paragraphs that each add meaningful detail: purpose, distinction from typing, recipient semantics, color validation, success meaning, and prerequisites. Every section earns its place given the tool's nuance, though it could be tightened without losing clarity.

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 lack of annotations and schema descriptions, the description covers all critical aspects: prerequisites, behavior (all players), validation (color, length), semantics of success, and response meaning (count of recipients). The only notable omissions are the exact behavior of timeout and the precise response format, both of which are partially implied but not fully specified.

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. It explains 'text' as the chat line and 'color' with explicit allowed values and validation/refusal behavior. However, 'timeout' is never mentioned—neither its purpose nor behavior. While this is a common parameter, it is completely undocumented in both schema and description, so compensation is partial.

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 specific verb and resource: 'Put a line in the connected player's chat.' It explicitly distinguishes itself from typing (server-side) and from client_type, which is for mod's own input fields. This leaves no ambiguity about what the tool does.

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?

It clearly states when to use the tool (to send a line to all connected players) and when NOT to use it (for client-only input fields like PDA/terminal, pointing to client_type). It also includes prerequisites (bridge loaded and ticking, bridge build knows the verb) and explains focus is not needed, covering both context and exclusions.

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