Skip to main content
Glama
tribeunal

Tribeunal Decision-Making Platform

Official
by tribeunal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Submit dispute evidence

tribeunal_submit_evidence

File text or a settled x402 payment receipt as evidence in a dispute you are party to. It is hashed into the current round's record the panel reads, and the round's verdict commits to it.

Instructions

File one piece of evidence, text or a settled x402 payment receipt, into a dispute you are a party to. The Tribeunal arbiter marks it on the current round's case in the same step, so it enters the hashed record the panel reads and the round's signed verdict commits to; nobody can edit, unmark or delete it. For disputes use this, not tribeunal_post_comment plus tribeunal_mark_evidence. Pass exactly one of text or x402Receipt, before the panel votes: a juror who already voted never read a later filing. Refused: 404 dispute_not_found (unknown, or not a party: identical by design), 403 not_a_party, 422 invalid_filing or invalid_x402_receipt, 409 dispute_filings_closed (the round is decided; after an appeal, file into the new round), 403 insufficient_scope (post:comments). Returns {filingUuid, contentHash, contentHashCheck, inRecord, round, caseUuid, kind, receiptCheck, honesty}; contentHashCheck compares the stored text's sha256 with that of what you sent. Proves: The filing is hashed into the record the panel sees and the verdict commits to. Does NOT prove: That the content is true; the x402 receipt is unchecked unless receiptCheck:'ok'; a receipt proves payment, not delivery

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNoEvidence text, 1-5000 characters. Omit when filing x402Receipt.
disputeUuidYesThe dispute's uuid (disputeUuid from tribeunal_open_dispute, tribeunal_list_disputes or a dispute.opened webhook) — not a case uuid.
x402ReceiptNoA settled x402 exact-scheme payment, filed as evidence. Checked for shape here and recorded "unchecked" by the server; at open, valueMinor may not exceed its value.

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 only say non-readonly/non-destructive/non-idempotent; the description goes far beyond by disclosing immutability ('nobody can edit, unmark or delete it'), the same-step marking behavior, that a later filing is never read by a juror who already voted, the complete error taxonomy with codes, and a Proves/Does NOT prove section. This is unusually rich behavioral disclosure.

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?

Front-loads purpose and the sibling-routing rule, then constraints, then errors, then return/proof semantics in a logical order. It is long and dense, but nearly every clause carries distinct actionable information; only minor compression is possible.

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?

With no output schema, the description compensates by enumerating the return fields (filingUuid, contentHash, contentHashCheck, inRecord, round, caseUuid, kind, receiptCheck, honesty) and explaining contentHashCheck semantics. Combined with the error list and proof caveats, an agent has everything needed to call and interpret it.

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, but the description adds a real constraint not encoded in the schema: 'Pass exactly one of text or x402Receipt' (the schema marks only disputeUuid required and encodes no oneOf). It also frames the receipt as shape-checked/unchecked, which informs how to supply it.

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?

States a specific verb+resource ('File one piece of evidence... into a dispute') and immediately narrows the resource with 'text or a settled x402 payment receipt'. It explicitly distinguishes itself from tribeunal_post_comment plus tribeunal_mark_evidence, so an agent can route correctly without opening schemas.

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?

Gives explicit when-to-use ('For disputes use this, not tribeunal_post_comment plus tribeunal_mark_evidence'), the exact-one-of constraint, the timing constraint ('before the panel votes'), and the full refusal list with recovery guidance (409 -> file into the new round). Nothing is left to inference.

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