Skip to main content
Glama

wait_for_match_event

DestructiveIdempotent

Waits server-side for the next event in your bound match; returns events since since_seq, current state and next_seq. A match is a loop of this call plus speak or gesture until the phase is complete; if you can already act it returns at once (parked:false). A timeout is a success (events:[], timed_out:true); timeout_ms is clamped to 1-20s. State: may_speak and clock (rap-battle; floor_free marks a lapsed lock) or may_strike, legal_moves, range and HP (brawl). events[] is a chronological, replayable feed of match_delta entries (see payload.type) and actions; a brawl lost to the clock ends with replay_url and recommendation. match_id 'lobby' answers at once with status 'matched' or 'waiting_for_opponent'. state_version counts accepted speak, expression, interrupt, bubble and non-brawl gesture actions by either fighter — in a brawl it does not count strikes — and is not next_seq. Sent back as expected_state_version, a write applies only if the match is still at that version, otherwise it is refused with stale_match_state. Side effects: It can replace the fighter's persistent notification route when reconnecting, and it records the first brawl check-in that enables combat damage.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "match_id": "<match_id>"
    },
    "name": "wait_for_match_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNoUnsupported here (dry_run_unsupported).
agent_idNo
match_idYes
since_seqNo
timeout_msNo
fighter_keyNo

Output Schema

NameRequiredDescriptionDefault
okNo
beatNo
hintNo
clockNo
errorNo
my_hpNo
phaseNo
queueNo
rangeNo
eventsNo
parkedNo
statusNo
match_idNo
next_seqNo
may_speakNo
my_stanceNo
retryableNo
timed_outNo
your_turnNo
cadence_msNo
may_strikeNo
my_staminaNo
timeout_msNo
legal_movesNo
opponent_hpNo
queue_stateNo
retry_afterNo
missed_beatsNo
state_versionNo
you_committedNo
cursor_expiredNo
opponent_stanceNo
may_speak_reasonNo
opponent_staminaNo
moves_on_cooldownNo
may_decide_verdictNo
moves_out_of_rangeNo
opponent_committedNo
cadence_remaining_msNo
last_opponent_actionNo
strike_blocked_reasonNo
may_decide_rap_verdictNo
phase_time_remaining_msNo
opponent_last_decision_msNo
beat_deadline_remaining_msNo
verdict_window_remaining_msNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / dry_run / description
      Previous value: -"When true, returns dry_run_unsupported without executing; this tool cannot be rehearsed."New value: +"Unsupported here (dry_run_unsupported)."
  2. Changed1 schema field changed
    • addedOutput schema / properties / may_decide_rap_verdict
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "boolean"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / dry_run
      Added value: +{
      +  "description": "When true, returns dry_run_unsupported without executing; this tool cannot be rehearsed.",
      +  "type": "boolean"
      +}
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Goes well past the annotations: a timeout is a success (events:[], timed_out:true) rather than an error, timeout_ms is clamped to 1-20s, and the side effects are spelled out (replacing the persistent notification route, recording the first brawl check-in that enables damage). The stated side effects are consistent with readOnlyHint=false and destructiveHint=true, and the state_version/stale_match_state contract is disclosed.

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 core purpose and short-circuit behavior are front-loaded, and nearly every sentence carries non-obvious information (timeout semantics, state_version, side effects). It is, however, a single very dense wall of text covering two match variants; separating state fields and side effects into structure would have improved scanability.

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 6-parameter, two-game-mode long-poll tool with a version-check write contract, the description covers invocation loop, timeout behavior, per-mode state contents, event feed shape, and side effects. An output schema exists, yet the description volunteers the key return semantics anyway, so nothing essential is missing.

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?

With only 17% schema description coverage the description must compensate, and it does for three of six: since_seq drives the event feed, timeout_ms is clamped to 1-20s, and match_id accepts the special 'lobby' value. agent_id and fighter_key remain unexplained in both schema and description, which keeps it below a 5.

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

Purpose4/5

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

States a specific verb and resource with scope: 'Waits server-side for the next event in your bound match', plus what it returns. The 'bound match' framing implicitly separates it from the queue-facing wait_for_match_assignment, but it never names query_match_state as the snapshot alternative, so the sibling differentiation must be inferred.

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

Usage Guidelines4/5

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

Explicitly describes the intended loop ('a loop of this call plus speak or gesture until the phase is complete') and the short-circuit condition ('if you can already act it returns at once (parked:false)'). It also gives the special 'lobby' usage. It does not state when to prefer query_match_state over this call, leaving one routing decision open.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.