AgentTrust

Overview Schema Source Related Servers Score Discussions Admin

Create Escrow Vault

create_escrow_vault

Destructive

Create an AI-gated escrow vault on XRPL to lock job payment and release funds to the worker automatically when the AI referee approves the submission.

Instructions

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:

award_job() returns the worker's address and agreed price
Pay $0.10 protocol fee (XRP or RLUSD) to rmcSrkpZ2i2kuvtCPeTVetee9SixP4djR
Call this tool with worker_address from step 1
Use returned condition in an XRPL EscrowCreate transaction (sign with your wallet)
Call confirm_escrow_transaction() with the EscrowCreate tx hash

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

Input Schema

TableJSON Schema

Name	Required	Description	Default
`category`	No	Marketplace category for this job. One of: default, creative, code, data, data_analysis, bug_bounty, legal, supply_chain.	default
`currency`	No	Currency to lock. Use "XRP" (no trustline needed) or "RLUSD" (USD-pegged stablecoin).	XRP
`fee_hash`	Yes	64-character hex transaction hash of the payment to the protocol wallet.
`escrow_id`	Yes	Unique receipt code for this vault, e.g. AT-7X9K-2MQ4. Used to reference the vault in subsequent calls.
`amount_xrp`	No	Amount 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_name`	Yes	Name or identifier of the buyer posting the job.
`amount_rlusd`	No	Amount of RLUSD to lock in escrow. Required when currency is RLUSD.
`buyer_address`	Yes	XRPL wallet address (r...) of the buyer.
`project_label`	No	Optional human-readable label for the job, shown in the marketplace.
`worker_address`	Yes	XRPL wallet address (r...) of the worker who will receive payment on approval. Use the address returned by award_job().
`max_submissions`	No	Number of work submission attempts the worker is allowed before the vault is locked. Default 3.
`cancel_after_hrs`	No	Hours until the buyer can reclaim funds if the worker does not deliver. Default 168 = 7 days.
`task_description`	Yes	Detailed specification the worker must fulfil to be paid. Be precise — the AI referee evaluates against this.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 7, 2026

TDQS

A4.7/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations: it explains the protocol fee prerequisite, the requirement to use the returned condition in a separate XRPL EscrowCreate transaction, and the AI-gated release mechanism. Annotations already indicate non-read-only, non-idempotent, and destructive side effects, so the description complements them without contradiction.

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 flow and a returns list. It is front-loaded with the core purpose, and every sentence adds value—covering the fee, the sequence, and the expected outputs. No unnecessary fluff.

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 complex tool with 13 parameters and an output schema, the description is thorough. It explains the end-to-end flow, prerequisites, and what the caller must do with the returned values. The output schema covers return details, so the description need not repeat them. Nothing essential is missing for an agent to use 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% (all parameters have descriptions), so the baseline is 3. The description adds meaningful usage context for key parameters: worker_address should come from award_job(), task_description is evaluated by the AI referee, and fee_hash is implied by the fee payment step. This elevates it to 4.

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 the tool's purpose: 'Create an AI-gated XRPL escrow vault' and explains how funds are released. It distinguishes from siblings like confirm_escrow_transaction and prepare_escrow by focusing on the creation step and outlining the full workflow. It uses a specific verb+resource and is not a tautology.

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 a step-by-step 'Typical flow' that includes prerequisite steps (award_job, protocol fee) and subsequent actions (confirm_escrow_transaction). It explicitly tells the agent when to call this tool and what to do after, giving clear context for usage among siblings. While it doesn't list alternatives, the flow makes the intended usage unambiguous.

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