Skip to main content
Glama
eamwhite1

AgentTrust

by eamwhite1
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Create Escrow Vault

create_escrow_vault
Destructive

Lock funds in an XRPL escrow vault and release payment to the worker only after their submission passes AI audit or proof gates, enabling verified agent-to-agent payments.

Instructions

Create an XRPL escrow vault. Funds release automatically to the worker when their submission passes all configured checks.

Two release modes:

  • AI audit (default): worker submits text/files; AI referee scores against task_description.

  • Proof-gate only (require_ai_audit=False): payment releases when all configured proof gates pass (NFT issuer, domain, VC). No AI call. Requires at least one proof gate.

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_hashNo64-character hex transaction hash of the $0.10 payment (XRP/RLUSD) to rmcSrkpZ2i2kuvtCPeTVetee9SixP4djR. Omit if eligible for free tier (wallet created via create_agent_wallet gets 3 free escrows).
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.
require_ai_auditNoDefault True. Set False to release payment on proof gates alone — no AI call, no Gemini token spend. Requires at least one proof gate (require_nft_proof, required_nft_issuer, required_domain, or required_vc_issuer_did). Use for machine-verifiable deliverables: NFT delivery, domain verification, W3C credentials.
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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.2.0
    • addedInput schema / properties / fee_hash / default
      Added value: +""
    • changedInput schema / properties / fee_hash / description
      Previous value: -"64-character hex transaction hash of the payment to the protocol wallet."New value: +"64-character hex transaction hash of the $0.10 payment (XRP/RLUSD) to rmcSrkpZ2i2kuvtCPeTVetee9SixP4djR. Omit if eligible for free tier (wallet created via create_agent_wallet gets 3 free escrows)."
    • addedInput schema / properties / require_ai_audit
      Added value: +{
+  "default": true,
+  "description": "Default True. Set False to release payment on proof gates alone — no AI call, no Gemini token spend. Requires at least one proof gate (require_nft_proof, required_nft_issuer, required_domain, or required_vc_issuer_did). Use for machine-verifiable deliverables: NFT delivery, domain verification, W3C credentials.",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "escrow_id",
-  "fee_hash",
-  "task_description",
-  "buyer_name",
-  "buyer_address",
-  "worker_address"
-]New value: +[
+  "escrow_id",
+  "task_description",
+  "buyer_name",
+  "buyer_address",
+  "worker_address"
+]
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark this as a non-read, destructive-style write, so the bar is lower, and the description clears it easily. It discloses genuinely non-obvious behavior beyond the annotations: the tool does NOT place the on-ledger escrow itself (the user must build an EscrowCreate transaction from the returned condition), a $0.10 protocol fee is required to a specific address unless the wallet is on the free tier, and proof-gate mode requires at least one proof gate with no AI call. These are exactly the kind of side-effect and prerequisite details an agent needs.

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?

The description is long (~200 words) but earns its length given 14 parameters, a multi-step workflow, and fee logistics. It is front-loaded with the purpose sentence, then organized into labeled sections (release modes, flow, returns). Minor redundancy exists — the fee address and worker_address-from-award_job guidance already appear in the input schema — but the structure keeps it navigable.

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?

For a 14-parameter, multi-step tool with an output schema and safety annotations, the description is close to complete: it covers prerequisites (award_job, fee), mode selection, the proof-gate constraint, the on-ledger follow-up, and return values. It does not address idempotency/re-creation with the same escrow_id, but idempotentHint=false and the output schema cover part of that gap, and the description goes well beyond what structured fields alone provide.

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, and the description adds meaning on top: it ties require_ai_audit to concrete release-mode semantics, specifies the $0.10 fee amount and payee address for fee_hash (schema only says '$0.10 payment'), explains the free-tier condition, and tells the agent to source worker_address from award_job(). This is clear added value beyond the already-rich schema.

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?

"Create an XRPL escrow vault" names a specific verb and resource, and the follow-up "Funds release automatically to the worker when their submission passes all configured checks" states the tool's defining behavioral scope. The two release-mode bullets further differentiate it from related siblings (prepare_escrow, submit_escrow_transaction, confirm_escrow_transaction) by showing what this step produces (the vault and condition) versus what later steps do.

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?

The 5-step 'typical flow after job board negotiation' gives explicit sequencing context: call after award_job() and the $0.10 fee, then follow with an XRPL EscrowCreate transaction and confirm_escrow_transaction(). It also explains when to choose each release mode (AI audit vs require_ai_audit=False). It stops short of naming alternatives/exclusions explicitly — prepare_escrow and submit_escrow_transaction exist as siblings but are never mentioned — so it has clear context but no exclusions.

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