Skip to main content
Glama

xrpl-referee

by io.github.eamwhite1

Create Escrow Vault

create_escrow_vault
Destructive

Create an AI-gated XRPL escrow vault. Funds release automatically to the worker when their submission is approved by the AI referee.

Typical flow after job board negotiation:

  1. award_job() returns the worker's address and agreed price

  2. Pay $0.10 protocol fee (XRP or RLUSD) to rmcSrkpZ2i2kuvtCPeTVetee9SixP4djR

  3. Call this tool with worker_address from step 1

  4. Use returned condition in an XRPL EscrowCreate transaction (sign with your wallet)

  5. Call confirm_escrow_transaction() with the EscrowCreate tx hash

Returns: escrow_id, condition (for EscrowCreate tx), cancel_after_human.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
categoryNoMarketplace category for this job. One of: default, creative, code, data, data_analysis, bug_bounty, legal, supply_chain.default
currencyNoCurrency to lock. Use "XRP" (no trustline needed) or "RLUSD" (USD-pegged stablecoin).XRP
fee_hashYes64-character hex transaction hash of the payment to the protocol wallet.
escrow_idYesUnique receipt code for this vault, e.g. AT-7X9K-2MQ4. Used to reference the vault in subsequent calls.
amount_xrpNoAmount of XRP to lock in escrow. Required when currency is XRP. Minimum: 0.000001 XRP (1 drop — XRPL EscrowCreate minimum). Practically, ensure the bounty exceeds the $0.10 protocol fee.
buyer_nameYesName or identifier of the buyer posting the job.
amount_rlusdNoAmount of RLUSD to lock in escrow. Required when currency is RLUSD.
buyer_addressYesXRPL wallet address (r...) of the buyer.
project_labelNoOptional human-readable label for the job, shown in the marketplace.
worker_addressYesXRPL wallet address (r...) of the worker who will receive payment on approval. Use the address returned by award_job().
max_submissionsNoNumber of work submission attempts the worker is allowed before the vault is locked. Default 3.
cancel_after_hrsNoHours until the buyer can reclaim funds if the worker does not deliver. Default 168 = 7 days.
task_descriptionYesDetailed specification the worker must fulfil to be paid. Be precise — the AI referee evaluates against this.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.6/5.0
Behavior4/5

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

While destructiveHint and openWorldHint are annotated, the description clearly states that the tool 'creates' a vault but also implies destructive actions like cancel_after_hrs potentially affecting funds. It lists the returned fields and mentions 'cancel_after_human', which is a behavioral detail. The description adds value by explaining the AI-gating mechanism and fund release logic, which annotations don't capture.

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 description is well-structured with a numbered list and clear returns section. Every sentence adds value: the purpose, the flow steps, and the returned fields. It's appropriately sized for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (13 params, multiple steps), and the description covers the workflow well. It references sibling tools and provides enough context for an agent to proceed. The output schema exists, so returns are documented separately. Loses one point because the description doesn't explain what 'cancel_after_human' is beyond the name, nor does it mention cancellation conditions in detail, but the schema covers all params.

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 context for key parameters like worker_address ('Use the address returned by award_job()') and fee_hash ('payment to the protocol wallet'). It also clarifies the relationship between currency and amount fields. This exceeds baseline by providing cross-parameter guidance.

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 clearly states that it creates an AI-gated XRPL escrow vault and outlines the automated fund release mechanism. It distinguishes itself from sibling tools like prepare_escrow and confirm_escrow_transaction by detailing the full workflow steps.

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?

The description provides explicit step-by-step usage instructions, including prerequisites like paying a protocol fee and obtaining a worker_address from award_job. It also references subsequent steps (confirm_escrow_transaction). This goes beyond mere existence of context and offers actionable guidance.

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

All xrpl-referee toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools target distinct resources and actions clearly. However, list_marketplace_jobs and list_open_jobs both involve browsing jobs and could be confused, and audit_task overlaps somewhat with evaluate_escrow_work in verifying work quality. Descriptions are detailed enough to differentiate with careful reading.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_escrow_vault, list_marketplace_jobs, confirm_wallet_ownership). There are no camelCase or Style deviations, making naming highly predictable.

Tool Count4/5

At 19 tools, the set is slightly heavy but reasonably scoped for a multi-featured platform covering job board, escrow, skills, wallet verification, and pricing. Each tool serves a distinct purpose, though some consolidation could be considered.

Completeness2/5

There is a significant gap: list_marketplace_jobs references a claim_job() function that does not exist in the tool set, breaking the primary workflow for agents to accept available bounties. Additionally, there are no update/delete operations for job postings or skill listings, and no explicit escrow cancellation tool.

Resources