AgentTrust XRPL

Request Escrow (Seller-Initiated)

request_escrow

Seller-initiated deal. Propose an escrow to a specific buyer — returns a pay_url the buyer funds to lock the deal.

Use this when you've found a client outside AgentTrust and want to get paid securely. No marketplace listing required.

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": {
      "seller_address": "<seller_address>",
      "buyer_address": "<buyer_address>",
      "amount_xrp": "<amount_xrp>",
      "task": "<task>"
    },
    "name": "request_escrow"
  }
}

Input Schema

Name	Required	Description	Default
`task`	Yes	Detailed description of the work you will deliver. The AI referee evaluates your submission against this — be precise.
`criteria`	No	Optional list of evaluation criteria. Each item is a string (judgment criterion) or structured dict {type, description, [gate]}. Types: 'judgment', 'evidence', 'code'.
`amount_xrp`	Yes	Amount of XRP the buyer must lock in escrow as payment.
`external_ref`	No	Reference to where you found this client, e.g. 'upwork:123', 'github:org/repo#45'. Informational.
`external_url`	No	URL of the original job listing (must start with https://).
`release_mode`	No	'auto' (default): immediate release on PASS. 'challenge_window_hrs:N': hold for N hours after PASS so buyer can review.	auto
`signature_ts`	No	Unix timestamp (seconds) used when constructing the signature. Must be within 300 seconds of server time.
`buyer_address`	Yes	XRPL wallet address (r...) of the client or buyer who will fund the escrow.
`deadline_hours`	No	Hours until the escrow auto-cancels if not approved. Default 72. Max 720 (30 days).
`seller_address`	Yes	Your XRPL wallet address (r...) — you are the seller proposing this deal.
`seller_api_key`	No	Enterprise API key linked to your wallet (alternative to XRPL signature proof). Pass via x-api-key header at the API level, or supply here.
`seller_signature`	No	XRPL signature proving wallet ownership. Format: <hexsig>:<unix_ts>:<public_key_hex>. Sign the message 'agenttrust-request:<seller_addr>:<buyer_addr>:<amount_drops>:<task_hash16>:<ts>' with your private key.
`counterparty_type`	No	Whether the buyer is a 'human' (default for seller-initiated deals) or 'agent'.	human
`seller_public_key`	No	Hex-encoded XRPL public key corresponding to the seller_address. Required when using seller_signature.
`funding_deadline_hours`	No	Hours the buyer has to fund the escrow before the request expires. Default 24. Max 72.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedOct 24, 2026

addedInput schema / properties / seller_api_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Enterprise API key linked to your wallet (alternative to XRPL signature proof). Pass via x-api-key header at the API level, or supply here.",
+  "title": "Seller API Key"
+}

addedInput schema / properties / seller_public_key

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Hex-encoded XRPL public key corresponding to the seller_address. Required when using seller_signature."
+}

addedInput schema / properties / seller_signature

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "XRPL signature proving wallet ownership. Format: <hexsig>:<unix_ts>:<public_key_hex>. Sign the message 'agenttrust-request:<seller_addr>:<buyer_addr>:<amount_drops>:<task_hash16>:<ts>' with your private key."
+}

addedInput schema / properties / signature_ts

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Unix timestamp (seconds) used when constructing the signature. Must be within 300 seconds of server time.",
+  "title": "Signature Timestamp"
+}

AddedOct 23, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare the mutation, non-idempotent, and open-world profile, so the description isn't obligated to restate safety. It does add one real behavioral fact — the call returns a pay_url that the buyer must fund to lock the deal — but says nothing about the authentication requirement (signature vs. API key), what happens on funding expiry, or that repeat calls create separate escrows despite idempotentHint=false.

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?

Three short sentences, front-loaded with the operation and its result, then the usage condition. No filler, redundancy, or repetition of schema content.

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

Completeness3/5

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

The output contract is covered (output schema exists, and pay_url is mentioned), but for a 15-parameter escrow flow involving wallet signatures, funding deadlines, and acceptance criteria, the description omits the authentication prerequisite and the two-stage lifecycle (propose → buyer funds). An agent reading only the description would not know it must sign with seller_public_key/seller_signature nor that the escrow only becomes live after buyer funding.

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 every parameter, including the signature format and release_mode syntax, is documented in the schema. The description adds no parameter-level meaning beyond what the schema already carries, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Propose an escrow to a specific buyer') plus the concrete outcome ('returns a pay_url the buyer funds'). The 'seller-initiated' and 'no marketplace listing required' clauses partially separate it from listing-based siblings like post_job or hire_and_pay, but no sibling is named outright.

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?

'Use this when you've found a client outside AgentTrust and want to get paid securely' gives a clear triggering condition, and 'No marketplace listing required' rules out the marketplace path. It stops short of naming alternatives such as direct_hire or hire_and_pay, so there's no explicit when-not.

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

All AgentTrust XRPL 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.