Skip to main content
Glama
tribeunal

Tribeunal Decision-Making Platform

Official
by tribeunal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Await dispute ruling

tribeunal_await_ruling
Read-only

Block until a dispute you are party to reaches a ruling, waiting across appeal rounds for a provisional verdict or final resolution. Returns immediately if already ruled.

Instructions

Block until a dispute you are a party to reaches a ruling, up to timeoutSeconds; returns at once when it already has one. Unlike tribeunal_await_verdict (one case), this follows the dispute across appeal rounds. until "provisional" (default) wakes on the latest round's verdict; until "final" wakes only once the dispute is recorded as having no further appeal, which a once-a-minute job does after the last appeal window lapses. standingRuling is 0 (void), 1 (claimant) or 2 (respondent); a Void appeal round never moves it. Returns {status: pending|provisional|final, timedOut, waitedS, round, roundState, panelMode, decisionUuid, ruling, standingRuling, basisDecisionUuid, bundleUrl, signed, appealDeadline, mayAppeal, youMayAppeal, nextCheckAfter, final, finalAt, finalRuling, finalDecisionUuid, execution, honesty}. PROTOCOL: on timedOut re-arm, but not before nextCheckAfter; appeal windows last hours or days and every poll spends the 100 requests/hour budget. Next: tribeunal_verify_ruling; if youMayAppeal, tribeunal_appeal_ruling before appealDeadline. Refused: 404 dispute_not_found. Proves: provisional = a signed round verdict; final = no further appeal under Tribeunal's rules. Does NOT prove: That money moved (see execution)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
untilNo"provisional" (default): wake on the latest round's verdict. "final": wake only once the dispute is recorded as having no further appeal.provisional
disputeUuidYesThe dispute's uuid (disputeUuid from tribeunal_open_dispute, tribeunal_list_disputes or a dispute.opened webhook) — not a case uuid.
timeoutSecondsNoSeconds to block, 5-170; defaults to 150. Returns at once when the awaited state already holds.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.0
    • changedInput schema / properties / disputeUuid / description
      Previous value: -"The dispute's uuid (disputeUuid from tribeunal_open_dispute or a dispute.opened webhook) — not a case uuid."New value: +"The dispute's uuid (disputeUuid from tribeunal_open_dispute, tribeunal_list_disputes or a dispute.opened webhook) — not a case uuid."
  2. Addedv2.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint=false and destructiveHint=false, but the description adds material context beyond them: the 100 requests/hour polling budget, the once-a-minute finality job, the meaning of standingRuling (0/1/2) and the Void-appeal rule, and an explicit proofs / does-not-prove boundary. This is far richer than the annotation baseline.

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?

It is front-loaded with the single most important clause (what blocks and for how long) and each later sentence covers distinct ground (modes, standing, return fields, protocol, refusals, proofs). It is dense and jargon-heavy, and the ~20-field return enumeration is a long comma list, but given no output schema most of it earns its place.

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 an async blocking tool with no output schema, the description enumerates the return object's fields, explains the mode semantics exhaustively, and documents the re-arm protocol and refusal. An agent has everything needed to call and interpret it correctly.

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 100%, so the baseline is 3; the until and timeoutSeconds descriptions largely restate the schema. However the description adds genuine meaning beyond the schema by tying until/timeoutSeconds to the nextCheckAfter re-arm protocol and the request budget, which the parameters alone do not convey.

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 opening clause gives a precise verb+resource ('Block until a dispute ... reaches a ruling') and immediately names the sibling it differs from ('Unlike tribeunal_await_verdict (one case), this follows the dispute across appeal rounds'). An agent can tell await_ruling from await_verdict without opening either schema.

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 states when to use each mode (provisional vs final), the polling protocol ('on timedOut re-arm, but not before nextCheckAfter'), the follow-on tools ('tribeunal_verify_ruling; if youMayAppeal, tribeunal_appeal_ruling before appealDeadline'), and a refusal case (404 dispute_not_found). Alternatives and conditions are all explicit.

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

Deploy Server

Other Tools