AgentTrust

Overview Schema Source Related Servers Score Discussions Admin

Prepare Escrow Transaction

prepare_escrow

Idempotent

Build a ready-to-sign XRPL EscrowCreate transaction, pre-filled with sequence, fee, and condition from a registered escrow.

Instructions

Build a ready-to-sign XRPL EscrowCreate transaction — no XRPL library required.

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.

Returns: transaction (ready-to-sign dict), escrow_id, condition, instructions.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 7, 2026

TDQS

A4.2/5.0

Behavior4/5

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

The description adds meaningful behavioral detail beyond the annotations: the tool does not submit the transaction, the buyer must sign it, and the result is a pre-filled dict with ledger sequence, fee, and condition. This clarifies the non-submitting, preparation-only nature of the tool.

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 well-structured with a clear opening, workflow steps, and a returns list. It is slightly redundant with 'no XRPL library required' and 'the agent never has to construct an XRPL transaction manually,' but overall every section earns its place.

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?

The description fully covers the precondition, the tool's role in the larger flow, the output shape, and the next step. Given the annotations, 100% schema coverage, and output schema, nothing essential is missing for an agent to select and invoke this tool correctly.

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%, and the schema already documents each parameter including defaults and address formats. The description does not need to repeat parameter details, but it also does not add much parameter-specific meaning beyond mentioning escrow_id as an input from create_escrow_vault().

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 opens with a specific verb and resource: 'Build a ready-to-sign XRPL EscrowCreate transaction.' It clearly differentiates from the sibling workflow by positioning itself between create_escrow_vault() and confirm_escrow_transaction(), so an agent immediately knows what this tool is and is not.

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 description explicitly states the required ordering: call create_escrow_vault() first, then this tool, then confirm_escrow_transaction() with the tx hash. It gives clear context and workflow sequencing, though it does not explicitly contrast itself with the sibling submit_escrow_transaction.

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