AgentTrust

by eamwhite1

Overview Schema Source Related Servers Discussions Admin

Python

Remote

Hire and Pay

hire_and_pay

One-call shortcut to register an escrow vault AND get the ready-to-sign transaction.

Instructions

One-call shortcut to register an escrow vault AND get the ready-to-sign transaction.

This combines create_escrow_vault() + prepare_escrow() into a single call. The agent only needs to sign the returned transaction and confirm it — no manual XRPL transaction construction required.

Buyers can require NFT ownership, an atomic NFT Delivery-vs-Payment swap, domain verification, or W3C Verifiable Credentials before a PASS releases escrow — set the relevant proof-gate params (require_nft_proof, required_nft_issuer, nft_dvp, required_domain, required_vc_issuer_did).

White-label / headless integration:

Pass callback_url to receive webhook POSTs on all state changes.
Pass metadata (JSON string) to attach your own reference IDs — echoed in every webhook.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`task`	Yes	Detailed description of what the worker must deliver. The AI referee evaluates against this — be precise.
`nft_dvp`	No	Atomic NFT swap: worker must transfer a specific NFT to the buyer before payment releases. On PASS the vault enters PASS_AWAITING_NFT; worker registers their NFTokenCreateOffer and payment auto-releases when buyer accepts.
`fee_hash`	No	64-char hex hash of your $0.10 payment (XRP/RLUSD/USDC) to rmcSrkpZ2i2kuvtCPeTVetee9SixP4djR. Omit to use free tier (if eligible).
`metadata`	No	Optional JSON string of key/value pairs to attach to this escrow and echo back in every webhook payload. Use to round-trip your own reference numbers (invoice_id, po_number, tenant_id, order_ref, etc.). Example: '{"invoice_id": "INV-2026-0042"}'.
`escrow_id`	Yes	Unique receipt code for this escrow, e.g. AT-7X9K-2MQ4. Must be unique.
`amount_xrp`	Yes	Amount of XRP to lock in escrow as the bounty.
`buyer_name`	No	Your name or agent identifier.
`callback_url`	No	HTTPS endpoint on your server to receive webhook POST notifications on escrow state changes (funded, PASS, FAIL, expired). Use this for white-label integrations where you handle all user-facing surfaces yourself. Payload: {escrow_id, event, verdict, timestamp, metadata}.
`proof_policy`	No	When multiple proof gates are set: 'ALL' (default) requires every gate to pass; 'ANY' requires at least one.	ALL
`buyer_address`	Yes	Your XRPL wallet address (r...) — you are the buyer.
`worker_address`	Yes	XRPL address (r...) of the worker to hire directly. Get this from direct_hire() or award_job().
`required_domain`	No	Worker must have their XRPL wallet domain field pointing to this domain. Pass 'ANY' to require any verified domain.
`cancel_after_hrs`	No	Hours until escrow auto-cancels if worker doesn't deliver. Default 168 = 7 days.
`delegate_address`	No	XLS-75 delegated agent XRPL address. When set, the EscrowCreate transaction carries a Delegate field — the delegate agent signs and submits on the buyer's behalf without holding the buyer's seed. The buyer must first submit a DelegateSet granting EscrowCreate permission to this address.
`require_consensus`	No	Require consensus between Gemini Flash AND Gemini Pro. Both must agree on PASS; split verdict returns conservative FAIL. Fee: $0.25 (vs $0.10 standard).
`require_nft_proof`	No	Worker must own an NFT from any trusted issuer (or from required_nft_issuer if set) to receive payment.
`required_nft_issuer`	No	Restrict NFT proof to NFTs minted by this XRPL wallet address.
`required_vc_issuer_did`	No	Worker must present a W3C Verifiable Credential JWT issued by this DID.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv3.1.0Oct 14, 2026

addedInput schema / properties / amount_xrp / title
```
Added value: +"Bounty (XRP)"
```
addedInput schema / properties / buyer_address / title
```
Added value: +"Your XRPL Address"
```

addedInput schema / properties / callback_url

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "HTTPS endpoint on your server to receive webhook POST notifications on escrow state changes (funded, PASS, FAIL, expired). Use this for white-label integrations where you handle all user-facing surfaces yourself. Payload: {escrow_id, event, verdict, timestamp, metadata}.",
+  "title": "Callback URL"
+}

addedInput schema / properties / cancel_after_hrs / title
```
Added value: +"Deadline (hours)"
```

addedInput schema / properties / delegate_address

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "XLS-75 delegated agent XRPL address. When set, the EscrowCreate transaction carries a Delegate field — the delegate agent signs and submits on the buyer's behalf without holding the buyer's seed. The buyer must first submit a DelegateSet granting EscrowCreate permission to this address.",
+  "title": "Delegate Agent Address (XLS-75)"
+}

addedInput schema / properties / escrow_id / title
```
Added value: +"Escrow ID"
```
addedInput schema / properties / fee_hash / title
```
Added value: +"Protocol Fee Hash"
```

addedInput schema / properties / metadata

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional JSON string of key/value pairs to attach to this escrow and echo back in every webhook payload. Use to round-trip your own reference numbers (invoice_id, po_number, tenant_id, order_ref, etc.). Example: '{\"invoice_id\": \"INV-2026-0042\"}'.",
+  "title": "Metadata (JSON string)"
+}

addedInput schema / properties / nft_dvp

Added value: +{
+  "default": false,
+  "description": "Atomic NFT swap: worker must transfer a specific NFT to the buyer before payment releases. On PASS the vault enters PASS_AWAITING_NFT; worker registers their NFTokenCreateOffer and payment auto-releases when buyer accepts.",
+  "title": "NFT Delivery-vs-Payment",
+  "type": "boolean"
+}

addedInput schema / properties / proof_policy

Added value: +{
+  "default": "ALL",
+  "description": "When multiple proof gates are set: 'ALL' (default) requires every gate to pass; 'ANY' requires at least one.",
+  "enum": [
+    "ALL",
+    "ANY"
+  ],
+  "type": "string"
+}

addedInput schema / properties / require_consensus

Added value: +{
+  "default": false,
+  "description": "Require consensus between Gemini Flash AND Gemini Pro. Both must agree on PASS; split verdict returns conservative FAIL. Fee: $0.25 (vs $0.10 standard).",
+  "title": "Premium Consensus Audit",
+  "type": "boolean"
+}

addedInput schema / properties / require_nft_proof

Added value: +{
+  "default": false,
+  "description": "Worker must own an NFT from any trusted issuer (or from required_nft_issuer if set) to receive payment.",
+  "title": "Require NFT Proof",
+  "type": "boolean"
+}

addedInput schema / properties / required_domain

Added value: +{
+  "default": "",
+  "description": "Worker must have their XRPL wallet domain field pointing to this domain. Pass 'ANY' to require any verified domain.",
+  "type": "string"
+}

addedInput schema / properties / required_nft_issuer

Added value: +{
+  "default": "",
+  "description": "Restrict NFT proof to NFTs minted by this XRPL wallet address.",
+  "title": "Required NFT Issuer",
+  "type": "string"
+}

addedInput schema / properties / required_vc_issuer_did

Added value: +{
+  "default": "",
+  "description": "Worker must present a W3C Verifiable Credential JWT issued by this DID.",
+  "title": "Required VC Issuer DID",
+  "type": "string"
+}

addedInput schema / properties / task / title
```
Added value: +"Task Description"
```
addedInput schema / properties / worker_address / title
```
Added value: +"Worker XRPL Address"
```

First observedv0.1.0Sep 7, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare a non-read-only, non-idempotent, open-world write, and the description goes beyond them by disclosing the exact execution flow (vault registration, returned unsigned transaction, sign-and-confirm step) plus white-label behavior via callback_url webhooks and echoed metadata. It doesn't restate reversibility/deadline consequences (auto-cancel), though those live in the schema.

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?

Front-loads the core value in the first sentence, then uses clear labeled sections for the composition, proof gates, and white-label integration. Slightly verbose, but every section maps to a real decision the caller must make, so little is wasted.

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 an 18-param mutation with an output schema, the description covers the flow, the proof-gate surface, and the webhook/metadata integration, so an agent has enough to call it correctly without the description re-explaining return values. It omits some non-obvious prerequisites (e.g. the delegate DelegateSet precondition, which is left to the schema), leaving a minor gap.

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 description coverage is already 100%, so the baseline is 3, but the description adds organizational meaning by grouping the proof-gate params (require_nft_proof, required_nft_issuer, nft_dvp, required_domain, required_vc_issuer_did) into a single 'buyers can require…' concept and explaining the metadata round-trip purpose. It does not add syntax detail beyond what the schema already carries.

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?

States a specific compound action (register escrow vault + return ready-to-sign transaction) and explicitly names the two sibling calls it replaces: create_escrow_vault() + prepare_escrow(). An agent can distinguish it from the two-step path without opening any schema.

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?

Clearly frames the tool as a one-call shortcut versus the manual create_escrow_vault + prepare_escrow route, and states the follow-up ('only needs to sign the returned transaction and confirm it'). It does not explicitly say when NOT to use it (e.g. when the agent needs finer control or wants to reuse an existing vault), so it stops short of full when/when-not guidance.

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

Deploy Server