AgentTrust

This connector has been deprecated

This connector has been replaced by xrpl-referee.

Prepare Escrow Transaction

prepare_escrow

Idempotent

Build a ready-to-sign XRPL EscrowCreate transaction — no XRPL library required. Free to try: pass network='testnet' (see create_testnet_wallet / try_testnet_demo).

Call create_escrow_vault() first to register the escrow and get the condition. Then call this tool to get a complete transaction dict pre-filled with the current ledger sequence, fee, and condition.

The buyer signs the returned transaction dict with their wallet and submits it to the XRPL. Then call confirm_escrow_transaction() with the tx hash.

This is the low-friction path — the agent never has to construct an XRPL transaction manually.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "escrow_id": "<escrow_id>",
      "buyer_address": "<buyer_address>",
      "worker_address": "<worker_address>"
    },
    "name": "prepare_escrow"
  }
}

Input Schema

Name	Required	Description	Default
`network`	No	'mainnet' (default) or 'testnet'.	mainnet
`currency`	No	Currency to lock. "XRP" or "RLUSD".	XRP
`escrow_id`	Yes	The receipt code from create_escrow_vault().
`amount_xrp`	No	Amount of XRP to lock. Required for XRP escrow.
`buyer_address`	Yes	XRPL address (r...) of the buyer who will sign the EscrowCreate.
`worker_address`	Yes	XRPL address (r...) of the worker who will receive payment on approval.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 2, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description adds important behavior beyond the annotations: this tool only prepares a transaction dict and does not submit it, the buyer must sign it, and the dict is pre-filled with current ledger sequence, fee, and condition. It also clarifies the low-friction path and the downstream confirmation step.

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 front-loaded with the core purpose and follows with a clear workflow. It is mostly efficient, though the final sentence about the low-friction path is somewhat promotional and 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?

Given the output schema and rich annotations, the description supplies everything needed to call this tool correctly: the prerequisite create_escrow_vault step, the returned transaction shape, the external signing/submission step, and the follow-up confirmation call. No essential context is missing.

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 description coverage is 100%, so the schema already documents all six parameters thoroughly. The description only adds provenance for escrow_id and notes the testnet option for network, which is useful but does not materially expand parameter semantics beyond the 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?

The description clearly states that this tool builds a ready-to-sign XRPL EscrowCreate transaction, a specific verb and resource. It distinguishes itself from create_escrow_vault (registration/condition) and confirm_escrow_transaction (hash confirmation), so the agent can identify its role 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?

It gives an explicit ordered workflow: call create_escrow_vault first to register the escrow and get the condition, then call this tool, then have the buyer sign and submit externally, then call confirm_escrow_transaction with the tx hash. It also names testnet as the free alternative and references create_testnet_wallet / try_testnet_demo.

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

All AgentTrust tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.