Skip to main content
Glama

Send a dev trigger to the game

trigger

Send a dev command to the running game and get its reply, with options to target a specific player, use the server side, and set a timeout.

Instructions

Ask the running game to do something, and return what it said.

Args: command: One of the dev commands THIS mod serves — call commands to see them, since they are the running mod's rather than a list kept here. A word it does not serve is refused before anything is written to disk: a game that does not recognise one does nothing, and from outside that is indistinguishable from a hang. target: Address the request to one player by name. Every request is already addressed to this session's own player by default, so pass this only to ask a DIFFERENT client — one another session drives on the same machine. argument: Only some commands read one — commands says which. Passing one to a command that takes none is refused here, because the mod would refuse it too and that costs a round trip. server: Send to the dedicated server rather than the client. Some commands are server-authoritative and refuse on a client, and each side publishes its own list. timeout: Seconds to wait for the game's reply. A command that does real work on a large world can outlast the default, and for capture that is now safe at any value: the capture lock records the deadline this argument implies, so another session waits it out instead of guessing from the lock's age. Raising it no longer trades a slow capture against a collision.

refused is reported separately from ok: a refusal is the mod deliberately saying no, and treating it as success is how a rejected action reads as a completed one.

note is usually null and is the one field with no other way to reach you: something that happened on the way to this reply which the reply itself cannot show. Currently it says a capture lock was broken to take this picture — captures are serialised across sessions sharing a save directory, and this one's holder was judged gone. It names WHICH rule judged it: the holder's own recorded deadline had passed, or the lock recorded no deadline and the 60s age bound decided instead. The second is the weaker claim — a guess about how long a capture can take — and worth knowing you are reading.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
serverNo
targetNo
commandYes
timeoutNo
argumentNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYes
noteYes
textYes
commandYes
refusedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.3

TDQS

A5/5.0
Behavior5/5

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

Beyond the sparse annotations, it discloses failure semantics: unserved commands are refused before disk writes, unknown game responses are indistinguishable from hangs, refusals are reported separately from `ok`, and capture locks serialize across sessions with deadline/age-based takeover. No contradiction with readOnlyHint/destructiveHint.

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 definition is long but dense and well-structured: a one-line purpose, an Args block, then two paragraphs for response semantics and capture-lock behavior. Every paragraph adds information an agent needs to interpret replies correctly, and the purpose is front-loaded.

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?

For a 5-parameter, 1-required tool with subtle refusal/hang/capture behavior, the description covers invocation, response interpretation, side effects, and cross-session concurrency. It names the `commands` sibling for discovery and explains `note` as the only out-of-band field, so an agent has everything needed to call it 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?

Schema description coverage is 0%, but the description carries the entire burden for all five parameters: `command` is dynamic and must be discovered at runtime, `target` defaults to the session's player, `server` selects a different authoritative side, `argument` is command-dependent, and `timeout` interacts with capture locking. This more than compensates for the empty schema descriptions.

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 action and resource: 'Ask the running game to do something, and return what it said.' It frames trigger as the channel for dev commands served by the mod, and points to the sibling `commands` tool to enumerate them, so it is easy to tell apart from list-only sibling tools.

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 gives explicit conditional guidance per parameter: call `commands` to see valid commands, use `target` only for a different client, use `server` for server-authoritative commands, and pass `argument` only when a command reads one. These read as when-to-use rules and route the agent away from the discovery sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.