Skip to main content
Glama
tribeunal

Tribeunal Decision-Making Platform

Official
by tribeunal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get deal

tribeunal_get_deal
Read-onlyIdempotent

Read an escrow deal by slug to check deposit status, terms, wallets, amount, dates, and the indexer's last recorded state after creating a deal or opening a shared link.

Instructions

Read one escrow deal request by its slug: the hashed terms, both wallets, the amount and dates, and the status Tribeunal's indexer last recorded. Use it after tribeunal_create_deal to see whether the payer has deposited, or to read a deal whose shareUrl you were sent; it only reads, and no Tribeunal tool can fund, release, refund or dispute a deal. status is awaiting_deposit, expired (the deposit deadline passed with none recorded), funded, disputed, released, refunded, released_after_deadline, executed (a ruling was applied) or timed_out (no ruling in time, so the money was split). It is built from deposits and outcomes the indexer has recorded, which trail the network by minutes; live.bridge.stale true means the indexer has not kept up and the status may be older still. The account that created the request reads it with slug alone; anyone else must also pass share. Refused: 404 deal_not_found (unknown slug, or not yours to read without a current share value: identical by design); 404 with no code on a server with no deal endpoints. Returns {slug, status, chain, terms: {version, text, hash, metaEvidenceUri}, deal: {payer, payee, amountMinor, amount, asset, decimals, releaseAfter, fundBy, createdAt, panel, description}, params, live, onchain, dispute, resolution, viewer: {isCreator}, shareUrl, honesty}; onchain, dispute and resolution are null until a deposit, a dispute or an outcome is recorded, shareUrl is null unless you created the request, and releaseAfter, fundBy and createdAt are unix seconds. Proves: The stored terms and their hash, and the status Tribeunal's indexer had recorded as of live.bridge.updatedAt. Does NOT prove: The state on the network right now (the indexer trails it by minutes, and live.bridge.stale true means it has not kept up); that the payee accepted the terms; that either address belongs to the person you think; that the description is true

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe deal's slug: the 16 characters after /deals/ in its url or shareUrl (slug from tribeunal_create_deal). Not the whole URL and not a UUID.
shareNoThe ?share= value of the shareUrl you were sent: 64 hex characters. Leave it out for a request your own account created; anyone else needs it, and a link the creator has rotated since no longer works.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.3.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds rich context beyond them: indexer lag by minutes, the meaning of live.bridge.stale, the exact refusal codes (404 deal_not_found vs bare 404), and the creator-vs-share access rule.

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-loaded with the purpose and read-only guarantee before the details. It is dense and long, but for a tool with nine possible statuses and several null-able return fields most sentences carry real information; a few enumerations could be tightened.

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?

There is no output schema, so the description carries the full return-shape burden and does so thoroughly, listing every returned field, which are null until certain events occur, and what the tool proves and does not prove.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both slug and share are already documented with patterns and semantics. The description reinforces the access nuance ('created with slug alone; anyone else must also pass share') but adds little syntax the schema lacks, matching the baseline 3.

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 and resource ('Read one escrow deal request by its slug') and enumerates exactly what is returned (terms, wallets, amount, dates, indexer status). It is clearly distinguishable from siblings like get_case, get_dispute and create_deal.

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?

Gives explicit triggers ('after tribeunal_create_deal to see whether the payer has deposited, or to read a deal whose shareUrl you were sent') and a useful scope boundary ('no Tribeunal tool can fund, release, refund or dispute a deal'). It does not name a specific alternative read tool, so it stops short of a 5.

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