AgentTrust XRPL

Evaluate Escrow Work

evaluate_escrow_work

Destructive

Submit proof of completed work against an existing escrow vault.

On PASS, payment releases automatically — no EscrowFinish needed. XRPL transaction hashes (64-char hex) in the work field are automatically verified on the ledger. Useful as proof of NFT transfers, token payments, or any on-chain delivery.

Evaluation pipeline (when the vault has structured criteria):

Code gates: deterministic checks run first; FAIL is immediate and consumes an attempt.
Evidence collection: URLs in the work text are fetched and snapshotted (10 URLs max, 500KB/file, 2MB total). Evidence criteria require a verbatim quote from fetched content.
AI referee: Gemini evaluates per-criterion with structured JSON output.
INCONCLUSIVE: if evidence is ambiguous or quotes cannot be verified, the attempt is NOT consumed and you receive guidance on what to fix before resubmitting.

Response shape on PASS:

{
  "verdict":          "PASS",
  "status":           "approved",
  "score":            0-100,
  "summary":          "explanation",
  "criteria_results": [{"criterion_id": "c1", "verdict": "PASS", ...}],
  "auto_finish_queued": True,
  "model_used":       "gemini-3.5-flash-lite"
}

Response shape on FAIL:

{
  "verdict":           "FAIL",
  "status":            "rejected",
  "score":             0-100,
  "summary":           "explanation",
  "criteria_results":  [{"criterion_id": "c1", "verdict": "FAIL", "reasoning": "..."}],
  "attempts_remaining": 2,
  "model_used":        "gemini-3.5-flash-lite"
}

Response shape on INCONCLUSIVE (attempt NOT consumed):

{
  "status":   "inconclusive",
  "verdict":  {...},
  "guidance": "what to fix before resubmitting",
  "attempts_used": 0
}

Attempt limits: workers get 3 attempts by default. Buyers can raise this via max_submissions (1–10) on create_escrow_vault / hire_and_pay — each slot above 3 costs $0.05 extra at creation time. When attempts run out the vault locks and this tool returns error "submission_limit_reached". Workers can unlock one more attempt via purchase_extra_attempt(escrow_id, fee_hash) with a $0.05 fee.

On FAIL: read criteria_results (or criteria_failed) for actionable feedback. Resubmit by calling evaluate_escrow_work again with the same escrow_id.

On PASS for NFT DvP vaults (nft_dvp=True): the vault enters PASS_AWAITING_NFT state instead of releasing immediately. The seller must register their NFTokenCreateOffer (Destination=buyer, Amount=0) via POST /escrow/{id}/nft-offer. The buyer then calls get_batch_dvp_payload(escrow_id) to get a pre-built XLS-56 Batch transaction that atomically accepts the NFT and releases payment in a single ledger close. Both legs succeed or both revert.

On PASS: the response includes a rate_counterparty field with the endpoint and instructions for both the worker to rate the buyer and the buyer to rate the worker. Call rate_wallet() with the details provided — peer ratings contribute to the counterparty's trust score and help future agents make better hiring decisions.

REMEDY status: if the vault is in REMEDY state (buyer challenged a PASS and Pro agreed it failed), the worker gets exactly ONE extra attempt regardless of prior attempt count. A PASS on the remedy releases immediately with no challenge window. A FAIL on the remedy cancels the escrow.

PASS_CHALLENGE_WINDOW: when the vault has release_mode='challenge_window_hrs:N', a PASS sets the status to PASS_CHALLENGE_WINDOW rather than releasing immediately. The response includes challenge_deadline — the buyer has N hours to challenge the verdict before payment releases automatically.

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>",
      "work": "<work>"
    },
    "name": "evaluate_escrow_work"
  }
}

Input Schema

Name	Required	Description	Default
`work`	Yes	Work submission or proof of completion. XRPL tx hashes (64-char hex) are auto-verified on the ledger.
`escrow_id`	Yes	The receipt code provided by the buyer when creating the vault.
`task_category`	No	Evaluation rubric. One of: default, creative, code, data, data_analysis, bug_bounty, legal, supply_chain.	default
`evaluate_token`	No	The evaluate_token returned by create_escrow_vault() or hire_and_pay(). The buyer must share this with the worker before submission. Required for vaults created after v2.8.0.
`evidence_links`	No	Up to 3 URLs that are fetched and snapshotted at submission time as supporting evidence.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

removedInput schema / properties / require_consensus

Removed value: -{
-  "default": false,
-  "description": "Require two AI models to agree before returning PASS. Recommended for high-stakes jobs.",
-  "type": "boolean"
-}

Changed2 schema fields changedOct 7, 2026
- addedInput schema / properties / escrow_id / title
```
Added value: +"Escrow ID"
```
- addedInput schema / properties / work / title
```
Added value: +"Completed Work"
```

Changed1 schema field changedSep 26, 2026

addedInput schema / properties / evaluate_token

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The evaluate_token returned by create_escrow_vault() or hire_and_pay(). The buyer must share this with the worker before submission. Required for vaults created after v2.8.0."
+}

First observedJun 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag the operation as non-read-only, non-idempotent, and destructive; the description goes well beyond them by disclosing attempt consumption rules, automatic payment release, ledger auto-verification of tx hashes, fetch/snapshot limits (10 URLs, 500KB/file, 2MB total), the $0.05 fees, and the exact error string "submission_limit_reached". It also explains the nft_dvp PASS_AWAITING_NFT state transition and the rate_wallet follow-up, which nothing in the annotations or schema conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The pipeline numbering and the PASS/FAIL/INCONCLUSIVE distinctions are well front-loaded, but three full JSON response blocks duplicate an output schema that already exists, adding substantial length without new information. Roughly a third of the text could be trimmed with no loss.

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?

For a multi-state, destructive submission tool with branching verdict paths, the description covers verdict handling, attempt accounting, fee mechanics, NFT DvP flow, challenge windows, and remedy states. An agent has everything needed to call it correctly and to interpret each outcome, and return values are separately documented by the output schema.

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?

With 100% schema coverage, the baseline is 3, but the description adds real meaning: the work field's 64-char hex tx hashes are auto-verified on-ledger, and the attempt ceiling is tied to max_submissions (1–10) set at vault creation. It leaves task_category and evaluate_token semantics largely to the schema, keeping it just short of a 5.

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 opening sentence gives a specific verb and resource ("Submit proof of completed work against an existing escrow vault") and scopes it to existing vaults, which cleanly separates it from create_escrow_vault, hire_and_pay, and purchase_extra_attempt. An agent can identify the tool's role without opening the schema.

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?

Explicit guidance covers every branch: resubmit on FAIL, INCONCLUSIVE does not consume an attempt, REMEDY grants exactly one extra attempt, PASS_CHALLENGE_WINDOW delays release, and purchase_extra_attempt is named for exhausted limits. The only soft spot is the absence of an explicit "do not call before a vault exists" exclusion, which is already implied by the opening sentence.

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.